Meeting logs migrated to git+ssh://git@git.gentoo.org/sites/projects/council.git

263 files changed, 0 insertions, 59033 deletions

diff --git a/xml/htdocs/proj/en/council/meeting-logs/20050915-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20050915-summary.txt
deleted file mode 100644
index 5d8800fd3c..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20050915-summary.txt
+++ /dev/null
@@ -1,26 +0,0 @@
->1. 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)
-
-Confirmed with the caveat that the council is not taking on
-disciplinary responsibilities.  The QA team should take complaints
-regarding unresolved technical violations to devrel to pursue
-displinary action.
-
-Regarding GLEP 31, the council is in favor of enforcement ASAP,
-provided nano is confirmed to be capable of compliance.  That will set
-the bar to require UTF-8 capable editors for portage work.
-
-(note: agenda reordered per request)
-
->3. glep40: Standardizing "arch" keywording across all archs
->   Vote asked by Grant Goodyear
-
-Approved.
-
->2. glep33: Eclass Restructure/Redesign
->   Vote asked by Brian Harring
-
-Approved.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20050915.txt b/xml/htdocs/proj/en/council/meeting-logs/20050915.txt
deleted file mode 100644
index 7240330548..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20050915.txt
+++ /dev/null
@@ -1,500 +0,0 @@
-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"]
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051013-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20051013-summary.txt
deleted file mode 100644
index 1719689639..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20051013-summary.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-- Review of GLEP 41 (Making Arch Testers official Gentoo Staff).  It was
-  rejected due to the following criticisms:
-   * AT's should get an e-mail address on a subdomain (user@xxx.gentoo.org)
-   * AT's should get r/o access to livecvs
-   * a longer probation period to make sure they know their way around
-   * either they get same privileges as current "staff", or they get a new
-     classification other than "staff" or "dev" (voting, access to resources,
-     etc...)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051013.txt b/xml/htdocs/proj/en/council/meeting-logs/20051013.txt
deleted file mode 100644
index a45f2603dd..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20051013.txt
+++ /dev/null
@@ -1,341 +0,0 @@
-15:05 <@az> ok, first and only thing on the agenda, is GLEP 41 (Making Arch Testers official Gentoo Staff)
-15:05 <@vapier> http://www.gentoo.org/proj/en/glep/glep-0041.html
-15:05 <@az> vapier: except if you wanted to add the syslog thing still ?
-15:06 <@vapier> i think everyone in base said we got better things to do then fight over something that trivial
-15:06 <@vapier> mr bones is dependable, so just going to syslog-ng should be fine
-15:06 <@Koon> I'll let that to the "base" project
-15:06 <@az> i dont care either way, as i just merge what i use, but guess we should just ask SwifT to pretty please fix the docs either way
-15:06 <@SwifT> about the AT... as I voiced before on -council, the two week period seems a bit too short to me personally
-15:06 <@seemant> wait wait wait
-15:07 <@seemant> how does syslog thing relate to glep 41?
-15:07 <@az> ok, back to glep 41 ;p
-15:07 <@seemant> I'm completely confused
-15:07 <@seemant> ah
-15:07 <@Koon> seemant: it's just az not chairing properly :)
-15:07 <@seemant> ok, if syslogging isn't an issue, I'm more or less ok with glep41 -- with one change
-15:07 -!- mode/#gentoo-council [+v blubb] by vapier
-15:07 <@az> ok, back to glep 41!
-15:07 <@seemant> I propose 2 weeks mentoring period to be "minimum 2 weeks" instead
-15:08 <@SwifT> gdp uses two months...
-15:08  * agriffis raises his hand
-15:08 <@SwifT> security 4 iirc
-15:08 <@az> im pretty much in agreement with the period as well
-15:08 <@seemant> because even as an arch tester, I don't know that people are guaranteed to get the necessary ebuild training
-15:08 <@Koon> security uses 4-6 yes
-15:08 <@az> and solar have some issues as well
-15:08  * agriffis lowers his hand and talks out of turn
-15:08 <@seemant> agriffis: talk to us, baby
-15:08 <@agriffis> I'm not in favor of GLEP 41 actually.
-15:08 <@az> he said either his vote is no if no changes, or asks for a postponement
-15:08 <@agriffis> I don't like the concept of half-devs.
-15:09 <@SwifT> who sais half-dev?
-15:09 <@Koon> agriffis: we already have them in the form of forum staffers
-15:09 <@SwifT> to me, they seem like full devs but with no write access to gentoo-x86...
-15:09 <@SwifT> which, afaik, is not mandatory to be called a "real dev" :)
-15:10 <@agriffis> yeah, I'm not sure, I suppose my thought is breaking precedent that is set with the forum staffers.
-15:10 <@agriffis> have patience, I'll try to get my thoughts out.
-15:11 <@Koon> ..
-15:11 <@agriffis> basically, you're just *calling* them full devs, but they're not.  they don't have cvs write.  they don't have voting privs.  they don't have access to -core.
-15:11 <+blubb> (could you please +v hparker? it was his idea and he's the AT lead, i just wrote the GLEP)
-15:11 <@agriffis> Forums devs are full devs -- they can vote, and they are on -core, etc, just w/ no write-access to cvs.
-15:11 -!- mode/#gentoo-council [+v hparker] by Koon
-15:12 <@agriffis> So basically we have two kinds of full devs presently.
-15:12 <@agriffis> Those with and those without write access.
-15:12 <+hparker> ty Koon
-15:12 <@agriffis> You're proposing adding a third type with even less access, but still wanting to call them "full devs"
-15:12 <@Koon> agriffis: it's alittle more complicated. Security devs are special
-15:12 <@agriffis> Koon: ah, you're right, so we have 3 and we're adding a 4th
-15:13 <@Koon> agriffis: yes
-15:13 <@agriffis> I would rather just see ATs recognized as power users who are reporting bugs.  I would like to see them with r/o cvs access.  I don't see the point in calling them "full devs", giving them an email address, etc.
-15:13 <@seemant> Koon: can you outline what's special about sec. devs please?
-15:13 <@seemant> (for the record, as it were)
-15:13 <@az> dont we have some documentation guys without cvs access as well ?
-15:13 <@Koon> seemant: no gentoo-x86 access, GLSA commit access, gentoo-announce access
-15:13 <@SwifT> az: only those in recruitment
-15:14 <@az> SwifT: noted, thanks
-15:14 <@agriffis> Regarding the r/o cvs access, that can be accomplished without needing accounts on our infrastructure, it's a pretty simple matter really.
-15:14 <@agriffis> I don't mean to be the one voice against, and if I am, I'll willingly back down.
-15:14 <@agriffis> I'm just not happy with introducing so many different dev types with different levels of access, some can vote, some can't, etc.
-15:15 <@vapier> we already mentioned the e-mail thing
-15:15  * agriffis sits back down
-15:15 <@vapier> blubb seemed to be ok with using a sub-domain since SwifT and i did like giving them top-level ones
-15:15 <@SwifT> I do agree that, if they have a title that contains "dev(eloper)", they should have the voting rights as other developers have (like council voting, ...)
-15:15 <@Koon> agriffis: I agree wit hyou that "gentoo dev" should cover a minimal commitment requirement and basic things like core access and e-mail address (and #-dev op etc)
-15:15 <@vapier> the glep says staff, not developer
-15:15 <@vapier> specifically for this reason
-15:16 <@az> agriffis: i *think* the main thing about them having @g.o emails, is to show them some form of apprciation, or achievement if you want for the work they do (hparker/blubb can correct me) ... this said, is one of the main reasons i think the training period might be fine, but there should be an additional 1-3 month evaluation time
-15:16 <@Koon> I am concerned that people not willing to contribte more are given a second-rate dev class
-15:16 <@Koon> if they are needed we need to find some kind of retribution, secondary email domains might be the solution
-15:17 <+blubb> az: correct :)
-15:17  * agriffis doesn't understand how @....gentoo.org is a reward
-15:17 <@SwifT> if they are needed, getting them on-board as developers is good for me as well
-15:17 <@agriffis> I don't know who that would appeal to.
-15:17 <@SwifT> I mean, actively testing packages is a daunting task
-15:17 <@az> which might bring in additionally some improvement in general developer quality/dependability if you enforce being an accepted AT before being able to become a developer
-15:17 <@agriffis> I suppose it's good for gentoo devs to be able to recognize ATs via their email addresses, but I don't think it's really a reward of any sort to have a gentoo address, particularly with a subdomain.
-15:18 <@Koon> good ATs are offered to become full devs, if they refuse they remain ATs
-15:18 <+blubb> there are users (just normal users) who got a @g.o mail address, which kinda astonished me...
-15:18 <@agriffis> blubb: huh?
-15:18 <+blubb> agriffis: one of them is an amd64 AT
-15:18 <@Koon> -infra boyfriends ?
-15:18 <@az> blubb: clarify ?
-15:18 <@SwifT> I think the few non-devs that have @g.o are an exception which hasn't been granted in a while afaik
-15:18 <+hparker> The @*.g.o address also makes it easier to spot them in bugz
-15:19 <+blubb> agriffis: i asked him how he got that mail addy, and he said there once was a period where power users got a @g.o addy
-15:19 <@Koon> also @amd64.gentoo.org doesn't sound too bad
-15:19 <@agriffis> hparker: true, and that might be a good reason to consider it.  but not on the basis of reward imho
-15:19 <+blubb> Koon: i'm against $(arch).g.o
-15:19 <+hparker> Even @at.g.o
-15:19 <+hparker> blubb wants @@.g.o
-15:19 <@vapier> the specific name doesnt really matter, just the concept of using a subdomain
-15:19 <+blubb> *g*
-15:20 <+blubb> vapier: agreed
-15:20  * agriffis nods
-15:20 <@agriffis> ok, so to sum up:
-15:20 <@Koon> vapier: would it include a touca account ?
-15:20 <@Koon> toucan
-15:20 <+blubb> just please don't make it $(arch). that will lead to confusion
-15:20 <@SwifT> anyone heard the voice of an active AT about his/her opinion?
-15:20 <@az> Koon: think taht will depend on if infra can host annon cvs or not
-15:21 <@agriffis> az: I've been talking with carpaski about that.
-15:21 <@az> last time we asked, they did not have the infrastructure/bandwidth if i remember
-15:21 <@agriffis> az: It's not necessary to give out accounts on toucan or cvs.gentoo.org for the ATs to get r/o access.
-15:21 <+hparker> SwifT: We've discussed it with the amd64 ATs, they are ok with it all
-15:21 <@az> agriffis: from carpaski's servers via the cvsup thing ?
-15:22 <@agriffis> az: They can just provide their id_dsa.pub which goes in a general arch-tester user's allowed keys, then they get r/o access as a single user.
-15:22 <@SwifT> hparker: the glep, or the subdomain, or any of them?
-15:22 <@az> ah, ok
-15:22 <+hparker> SwifT: The whole package ;)
-15:22 <@agriffis> az: I also talked with carpaski about cvsup and stuff, yes, but nothing that's helpful for this topic.
-15:23 <@az> true, just wanted to know if we could do it some way or other
-15:23 <@Koon> so they wouldn't be considered "Gentoo devs" if I understand the consensus here
-15:23 <@SwifT> afaik, we're talking about a few dozen people, no?
-15:23 <@az> ok, anybody have anything to say regarding my '2 weeks training is fine, but might need an additional evaluation period' ?
-15:23 <@Koon> no core, no vote, subdomain
-15:23 <@Koon> I would say 1 month minimal
-15:23 <@az> to make sure they do not dissapear after 3 weeks
-15:24 <@Koon> we had plenty of people that can stay very active for 2 weeks and then disappear (in security)
-15:24 <@SwifT> you can't "make sure" about that, but the recruitee knows that we are expecting continuous support and not a short burst
-15:25 <@SwifT> the GDP had the same... lots of activity, then developer-status and *poof*, goner
-15:25 <+hparker> SwifT: Currently, a couple dozen... Hoping for more though
-15:25 <@az> yes, but sombody sticking around 1-3 months is more likely to stay for another few
-15:25 <@seemant> az: I stand by "minimum 2 weeks"
-15:25 <@agriffis> btw, if a user becomes an AT then wants to be a dev, is it a longer road than simply becoming a dev directly?
-15:25 <@SwifT> longer? naha, hope not :)
-15:25 <+blubb> agriffis: with the proposal in the GLEP, i'd be exactly the same period
-15:25 <@agriffis> blubb: ok, thanks
-15:26 <@az> agriffis: which comes to my next point .. maybe enforcing being at before being able to become a dev ?
-15:26 <+blubb> agriffis: that's actually why we included it... we don't want to punish ATs
-15:26 <+hparker> az: That's how amd64 handles it
-15:26  * SwifT doesn't like taht
-15:26 <@Koon> az: a lot of people enter by co-maintaining package, not arch testing
-15:26 -!- code|work [n=code@gentoo/developer/codeman] has joined #gentoo-council
-15:26 <@SwifT> or documentation, or infrastructure, ...
-15:26 <@az> true, why i was asking for opinions
-15:27 <@az> it obviously would not work for docs
-15:27 <@az> yeah
-15:27 <+blubb> Koon: well, you don't get into an arch team by co-maintaining packages :D
-15:27 <@Koon> az: before becoming an arch member, sure
-15:27 <@vapier> we already have read-only cvs stuff being exported by carpaski ...
-15:27 <@agriffis> vapier: updated once every 3 hours... not useful
-15:28 <@vapier> hrm, true
-15:28 <@SwifT> well, viewcvs is also an (hourly) export, but infra doesn't like people updating from viewcvs
-15:28 <@agriffis> also if we were to use that, I would definitely not suggest giving ATs official status and telling them to use an unofficial server.
-15:28 <@Koon> ok, let's focus, maybe each council member can in turn sum up what needs to be changed in the GLEP so that he accepts it ?
-15:29 <@agriffis> SwifT: yeah, and rsync isn't far behind that.  I think the point here is for ATs to be able to test stuff immediately after it is committed.
-15:29 <@agriffis> should we go in alpha order?
-15:29 <@az> sure
-15:29 <@Koon> agriffis: good idea
-15:30 <@az> agriffis: first if not mistaken
-15:30 <@agriffis> ok, guess it's me.
-15:30 <@agriffis> I'd like to see subdomain and r/o access without needing an account on toucan, cvs.gentoo.org, etc.
-15:31 <@agriffis> i.e. subdomain for email.
-15:31 <@az> right
-15:32 <@az> im ok with what agriffis said, and i really think an probation peroid after the training phase is completed should be considered
-15:32 <@az> Koon: ?
-15:33 <+hparker> az: Probation after becoming an at?
-15:33 <@az> no, before .. to see if they learnt the ropes ok
-15:33 <@Koon> what agriffis said + a specific designation for this class of contributors (other than "dev" or "staff")
-15:33 <@az> seemant: ?
-15:33 <@Koon> + a longer training/probation period (1 month of activity minimum)
-15:34 <@seemant> combine agriffis + koon's last sentence
-15:34 <@Koon> + open this class to other contributors (security GLSA drafters come to mind)
-15:34 <@seemant> I don't want to guarantee a 2 week mentorship (or any fixed period)
-15:34 <@az> ok, SwifT ?
-15:34 <@SwifT> I don't want the AT staff to be treated differently wrt. permissions than forum staff (except for domain-specific stuff of course)... I don't mind the subdomains though. The 2-week period should be lengthened a bit
-15:35 <@az> SwifT: the 'to be treated differently wrt. permissions' meaning voting ?
-15:35 <@SwifT> so either get the perms for "staff" on the same level, or call them differently
-15:35 <@Koon> SwifT: forum staff is official devs (core + vote), no ?
-15:35 <@Koon> hence my call for a specific designation
-15:35 <@agriffis> One more thought: perhaps the subdomain should be staff.gentoo.org to accomodate arch-testers, herd-testers, glsa-drafters, etc.
-15:36 <@SwifT> Koon: yes
-15:36 <@agriffis> Obviously people with existing @gentoo.org addresses don't need to change to staff.gentoo.org, they're grandfathered in.
-15:36 <@az> bit late though to change it for the forum guys
-15:36 <@az> ok, we can touch that again just now
-15:36 <@az> vapier, anything to add ?
-15:37 <@vapier> nope, others covered it
-15:37 <@Koon> I'm a bit concerned about ATs becoming devs and forced to update their email, but I guess that's secondary
-15:37 <@vapier> give em temp forwards
-15:37 <@az> right, anything else on the point SwifT touched ?
-15:37 <@agriffis> Koon: not an issue, really, just give them a forward
-15:37 <@agriffis> right
-15:37 <@az> SwifT: especially, do you just mean they should not be called devs, or do you think they need voting as well ?
-15:38 <@SwifT> az: either be called "devs" and get voting, or call them different
-15:38 <@SwifT> but I actually don't really mind... depends on what the ATs themselves want
-15:38 <@Koon> az: I would go for two big classes, "devs" with core, vote and commit somewhere, and "XXX" without core, without vote, and with r/o access
-15:39 <@az> i think Koon touched that in ' + a specific designation for this class of contributors (other than
-15:39 <@az>                 "dev" or "staff")'
-15:39 <+blubb> az: i think they shouldn't get voting rights without having to read -core, and they don't want to have to wade through tons of mails, so...
-15:39 <+hparker> And the one's we talked with were fine with that
-15:40 <@az> right, i am thinking that should be fairly that
-15:40 <@agriffis> Koon: btw, I would really like that (two big classes)
-15:40  * SwifT too
-15:40 <@az> we can either decide on the 'class' name now
-15:40 <@SwifT> and don't diversitate anymore :)
-15:40 <@agriffis> diversify
-15:40 <@Koon> when i say r/o access, it might be other special power (forum mod, GLSAMaker access...)
-15:40 <@az> or as it seems we will have to postpone voting on this anyhow, give hparker and blubb a time to ponder it ?
-15:41 <@SwifT> whatever :p
-15:41 <+blubb> az: well, i can update the GLEP within a few minutes and you can vote on a specific cvs revision ;)
-15:41 <@agriffis> az: hour isn't up, we can keep talking it over now if it's ok
-15:42 <@az> agriffis: sure, just feeling the water
-15:42 <@az> ok, i we had two suggestions up to now if not mistaken
-15:42 <@Koon> ideas for the "class" name ?
-15:42 <@Koon> "minions"
-15:42 <@az> staff or something else
-15:43 <+blubb> ATs?
-15:43  * agriffis looks in the thesaurus
-15:43 <@SwifT> llamas
-15:43 <@az> blubb: too specific
-15:43 <+blubb> hrm, true
-15:43 <@az> spb would like minions though
-15:44 <@Koon> the problem with "staff" is that some people consider as "staff" all devs that don't have gentoo-x86 commit
-15:44 <@SwifT> kewl, I'm staff :)
-15:44 <@Koon> "monkeys" ?
-15:44 <@agriffis> conspirators
-15:44 <@Koon> SwifT: I was, but I bribed some devrel member
-15:44 <@SwifT> samaritan ?
-15:44 <+blubb> call them assistants ;)
-15:44 <+blubb> "Hi, I'm your dev assistant. It looks like you're trying to test a package. May I help you?"
-15:44 <@SwifT> lol
-15:45 <@SwifT> coadjutrix?
-15:45 <@agriffis> cows
-15:45 <+hparker> moo
-15:45 <+blubb> any relation to microsoft products is pure accident
-15:45 <@az> heh, ok, back on track please ;p
-15:45 <@vapier> no one likes the label 'Tester'
-15:45 <@vapier> Official Gentoo Tester
-15:46 <@agriffis> staff is fine with me, does anybody really have a problem with it?
-15:46 <@Koon> vapier: kinda excludes other uses for the class, like our security apprentices whoi draft GLSAs
-15:46 <@SwifT> no, staff is fine... what about the current "staff" who are actually full devs? :)
-15:46 <@Koon> agriffis: see my concern above
-15:47 <@az> supportstaff ? ;p
-15:47 <@agriffis> Koon: yeah, I saw it, I don't know if it's really an issue though...  perhaps it is.
-15:47 <@agriffis> crew
-15:47 <@vapier> be part of the gentoo crew ? :p
-15:47 <@az> bit korney, but might work ;p
-15:47 <@Koon> agriffis: it probably isn't. We /make/ policy here
-15:47 <@SwifT> or just don't call them anything and give them at.gentoo.org e-mail addies
-15:48 <@vapier> Tester Staff ... Security Staff ... Infra Staff ... Forums Staff
-15:48 <@vapier> Staff Staff
-15:48 <+blubb> the subdomain and the naming should match IMHO
-15:48 <@agriffis> SwifT: nah, I personally think the name is important.  just like it means something to be a "dev", there needs to be a real name for these people, especially if it's the only other big bucket
-15:48 <@SwifT> lieutenant?
-15:49  * agriffis likes crew personally
-15:49  * Koon fires up Google sets to the rescue
-15:49 <+blubb> SwifT: larry the cow looks to peaceful to introduce military names ;)
-15:49 <@vapier> Tester Crew ... Security Crew ... Infra Crew ... Forums Crew
-15:49 <@agriffis> vapier: right!
-15:49 <@az> forum screw
-15:49 <@agriffis> heh
-15:49 <@SwifT> but crew... even developers are crew members
-15:50 <@vapier> Developers
-15:50 <@az> developers are staff as well if you go by that argument
-15:50 <@SwifT> which is, actually, a good way of talking about a group :)
-15:50 <@SwifT> crew= entire lot, developers= -core flamers
-15:50 <@az> ++ on the flames
-15:50 <@az> ok, i dont have an issue with either crew or staff
-15:51 <@az> so anybody that have issues with staff, how does crew sound ?
-15:51 <@SwifT> peachy
-15:51 <@vapier> we could just keep 'staff' and just qualify it
-15:51 <@SwifT> I mean, good
-15:51 <@Koon> sounds like "screw", I like it
-15:51 <@agriffis> I like staff better personally, but if people don't like staff, crew is good.
-15:51 <@agriffis> (I know I suggested crew, it was because some people didn't like staff...1)
-15:51 <@vapier> we can save crew for when we start to recruit pirates
-15:51 <@Koon> well, we can keep "staff", just make sure that what was once named staff is not whet the new staff is
-15:52 <@vapier> Koon: there wont be a "staff"
-15:52 <@vapier> there will be "tester staff"
-15:52 <@agriffis> and a "vapier staff"
-15:52 <@agriffis> jk
-15:52 <@Koon> okok
-15:53 <@agriffis> g2boojum has a comment I'd like him to speak here.
-15:53 <@Koon> I guess the GLEP now needs heavy rewriting
-15:53 <+g2boojum> Personally, I suggest you folks just vote on the existing GLEP.  You've already voiced your comments, so let the community go back to it and draft new solutions.
-15:53 <@az> g2boojum: go ahead please
-15:53 <@Koon> maybe under the form of a more global dev/staff definition
-15:53 <@Koon> I'd reject the GLEP under its current form
-15:54 <@Koon> and call for a new, more global GLEP
-15:54 <+g2boojum> It's not necessary to fix everything right now.  It can wait another month for a new, hopefully improved version.
-15:54 <@agriffis> Thanks g2boojum.
-15:54 <@az> question though .. should we vote now then ?
-15:54 <@agriffis> az: yes, that's the idea
-15:54 <@Koon> az: yes, we can't vote on somethig that's not written
-15:54 <@az> as solar's current vote is no, except on postponement
-15:54 <+hparker> Koon: Will it then be Gelp 42, the answer to all questions?
-15:54 <@SwifT> well, in its current form, "no"
-15:55 <@Koon> hparker: I hope so
-15:55 <@az> and i think thiings might have changed sufficiently for him to be able to reconsider
-15:55 <@SwifT> 42?
-15:55 <@Koon> I was kinda hoping our -core/-dev MLs refurbishment would be GLEP 42
-15:55 <@SwifT> ah, that :)
-15:55 <@Koon> the answer to all spam
-15:55 <@agriffis> let's collect votes on 41 before talking 42, eh?
-15:55  * agriffis votes no to 41
-15:55  * az votes no
-15:55  * az proxy no for solar
-15:56 <@SwifT> (btw, "no" is not "don't go there" but rather "update it a bit")
-15:56 <@agriffis> right
-15:56 <@az> yes
-15:56  * Koon votes no (as in "update more")
-15:56 <@az> seemant: ?
-15:56  * vapier jumps on the 'no;needs-update' pig pile
-15:56 <@az> SwifT: ?
-15:57 <@SwifT> no, needs update
-15:57 <@agriffis> do blubb and hparker understand the updates we want to see?
-15:58 <+hparker> agriffis: Yes
-15:58 <+blubb> agriffis: yup
-15:58 <@agriffis> ok, good
-15:58 <@Koon> az: Q&A ?
-15:58 <@az> waiting for seemant still, but while we do, ferringb wanted to mention something regarding the classes
-15:58 <@az> Koon: yeah
-15:58 -!- mode/#gentoo-council [+v ferringb] by az
-15:58 -!- mode/#gentoo-council [-m] by Koon
-15:59 <+ferringb> heh, timing++ :P
-15:59 <+ferringb> comment was that the arbitrary grouppings don't really fit well; consider portage devs, doc devs, etc.  are they devs under the proposed grouping, which seems a bit gentoo-x86 orientated, or staff?
-15:59 -!- Koon changed the topic of #gentoo-council to: Meeting today at 1900UTC (1500EST) || open Q&A
-15:59 <+ferringb> staff doesn't exactly fit perfectly obviously.
-16:00 <@Koon> ferringb: if you commit somewhere, you are dev
-16:00 <@SwifT> contribute, participate on -core and have vote, then you're a dev
-16:01 <+ferringb> Koon: forums are staff, yet they're effectively 'commiting' via thread mangling :P
-16:01 <@vapier> stupid
-16:01 <+ferringb> heh
-16:01 <@SwifT> but, mind you, the term "developer" is for the foundation
-16:01 <+ferringb> figured that response.  was trying to point out that pure write access is kind of an iffy delimiter.
-16:01 <@Koon> ferringb: forum mods should be staff
-16:01 -!- mkay [i=aye@gentoo/developer/mkay] has joined #gentoo-council
-16:01 <@Koon> IMHO
-16:02 <@vapier> they are staff last i checked
-16:02  * ferringb agrees in that scenario
-16:02 <@Koon> vapier: no, they are devs, they are on core iirc
-16:02 <@vapier> weak !
-16:02 < mkay> hmm - i've got strange feeling i'm late;>
-16:02 <+blubb> just a general thought about this naming discussion: we really shouldn't overrate the classes. it'd kinda piss me off if staff feels like mr. nobody and dev has half-god status
-16:03 <@az> they should not, but like anything if mr. nobody dev makes a valid point, they should respect that due to his hopeful more experience
-16:03 <@agriffis> blubb: I think everybody agrees with you.  It's just easier to start with two big buckets as a starting point to define responsibilities and privileges.
-16:03 <+blubb> agriffis: sure
-16:03 <@agriffis> blubb: rather, I agree with you, I don't know what everybody else thinks :-)
-16:04 <+ferringb> blubb: agreed on that... rather see devs on effectively equal footing, rather then the current non-stinking poo that occurs with some devs.
-16:04 <@Koon> blubb: I just want a clear definition so that we can stick more in
-16:05 <@Koon> I've to go
-16:06 <@agriffis> ok, good time to end the log
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051115-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20051115-summary.txt
deleted file mode 100644
index 03ec570423..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20051115-summary.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-The authors of GLEP #41 made the changes to the GLEP's wording as
-requested by the council during October's meeting.  Thus, it was brought
-to vote.  Before I relieve you of the suspense of the vote's outcome,
-let me say that a policy decision also came about as a result of last
-night's vote.
-
-GLEP 41 was never resubmitted to this mailing list (gentoo-dev) after
-the wording changed.  Most of the council members were uncomfortable
-with this idea.  That was the first and *only* time the council will
-vote that way again.  Following this, every resubmission must be
-discussed on -dev for 7 days minimum before being resubmitted to the
-council 7 days before that meeting.
-
-As such, GLEP 41 was voted in by majority (only one dissenting vote).
-The subdomain for the arch tester email aliases has not been decided (it
-is beyond the scope of the council's role in the GLEP).
-
-
-The last agenda item was a summary of the progress of portage signing as
-presented by Marius Mauch (genone).  The story is dismal -- no progress
-has really been made because nobody has taken ownership of implementing
-it yet.  Thus, the Council decided that its members would scratch the
-beginnings of the GLEP together and forward that GLEP to the original
-participants/proposers in the prior discussion (which was carried out
-last year under the old metastructure management).  From there the GLEP
-will be presented to -dev for discussion before the Council takes
-further action on it.  The Council has agreed to forward their scratch
-GLEP to the original proposers/partcipants before December's Council
-meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051115.txt b/xml/htdocs/proj/en/council/meeting-logs/20051115.txt
deleted file mode 100644
index 066a3b5295..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20051115.txt
+++ /dev/null
@@ -1,248 +0,0 @@
-15:00 -!- seemant [n=trinity@gentoo/developer/seemant] has joined #gentoo-council
-15:00 -!- Topic for #gentoo-council: Meeting starts at 2000 UTC today
-15:00 -!- Topic set by Koon [] [Tue Nov 15 12:05:31 2005]
-15:00 [Users #gentoo-council]
-15:00 [@Koon ] [@vapier  ] [ code|work] [ FuzzyRay] [ spb ] 
-15:00 [@solar] [+g2boojum] [ cryos    ] [ genone  ] [ tove] 
-15:00 [@SwifT] [ agaffney] [ ferringb ] [ seemant ] [ Zr40] 
-15:00 -!- Irssi: #gentoo-council: Total of 15 nicks [4 ops, 0 halfops, 1 voices, 10 normal]
-15:00 -!- mode/#gentoo-council [+o seemant] by ChanServ
-15:00 <@seemant> hi everyone
-15:00 -!- Channel #gentoo-council created Wed Nov  9 05:09:05 2005
-15:00 -!- Irssi: Join to #gentoo-council was synced in 11 secs
-15:00 <@seemant> is everyone present?
-15:00 <@solar> azarah was active about 3 mins ago
-15:00 <@Koon> Dr Kulleen
-15:00 <@seemant> dr. Koon
-15:00 <@Koon> greetings
-15:01 <@solar> erp 15 mins ago now that I double check
-15:01 <@Koon> agriffis missing
-15:01 <@vapier> booga
-15:02 -!- az [n=ms@gentoo/developer/azarah] has joined #gentoo-council
-15:02 -!- mode/#gentoo-council [+o az] by ChanServ
-15:04 <@seemant> let's give agriffis 2 more minutes
-15:07 <@Koon> and.. one slacker point goes to...
-15:07  * SwifT points to oblivion
-15:07 <@seemant> agriffis
-15:08 <@seemant> let's start the meeting
-15:08 -!- mode/#gentoo-council [+m] by seemant
-15:08 <@seemant> right, hello everyone
-15:08 <@seemant> this is the November meeting of the Gentoo Council
-15:08 <@seemant> and our agenda items are:
-15:08 <@seemant> 1. Voting on GLEP 41 (requested hparker)
-15:09 <@seemant> 2. Portage Tree signing status (requested by genone)
-15:09 <@seemant> 3. Q&A (open floor)
-15:09 <@seemant> so let's begin, shall we?
-15:09 <@Koon> (genone and/or g2boojum)
-15:09 <@seemant> Koon: ah, true
-15:09 <@Koon> shoot
-15:09 <@seemant> s/\(genone\)/\1 and g2boojum/
-15:09 <@seemant> right, so let's begin with Agenda Item #1: GLEP 41
-15:10 <@seemant> do I hear 10 dollars?
-15:10 <@seemant> kidding -- the issue is that this GLEP was presented to the council during October's meeting
-15:10 <@seemant> and the Council members requested a number of changes made
-15:10 <@Koon> one question is "should have it been resubmitted to dev for discussion before we vote"
-15:10 <@seemant> the latest version of the GLEP document reflects those changes
-15:11 <@seemant> yes, what Koon said
-15:11 <@Koon> I answer no, since only the mandated changes are in , but YMMV
-15:11 <@Koon> diff at http://tinyurl.com/bmsee
-15:11 <@seemant> I feel that, to be consistent, -dev should have seen it before we got it
-15:12 <@vapier> looks like all the concerns brought up previously have been addressed
-15:12 <@vapier> but yeah, i dont like the idea of making changes and then going back for vote without going through -dev without an announcement
-15:12 <@Koon> having it wait another month just sounds not nice to me
-15:12 -!- kito [n=kito@gentoo/developer/kito] has joined #gentoo-council
-15:12 <@vapier> and there is that
-15:12 <@seemant> Koon: I agree with that as well
-15:13 <@vapier> we could vote on this now and then mandate that in the future, all GLEP changes must be announced before being voted on
-15:13 <@seemant> Koon: however, we wind up on a slippery slope (because yes the changes are trivial, and exactly what the council requested)
-15:13 <@seemant> but strictly speaking, the community should have been notified of those changes
-15:13 <@vapier> make an exception since this is the first time it's come up
-15:13 <@seemant> I'm ok with  vapier's suggestion
-15:14 <@seemant> but then we need to be strict from here on in about such things
-15:14 <@seemant> no more exceptions
-15:14 <@solar> He posted to the list that this topic could be postponed.
-15:14 <@vapier> right, lets get g2boojum to update GLEP1 with this requirement ?
-15:14 <@az> on the other had, should they not have been notified of this on submission ?
-15:14 <@SwifT> I wouldn't ask for postponal, for me the GLEP's issues have been addressed and taken care of
-15:14 <@seemant> solar: I thought that was item #2 (if you speak of g2boojum)?
-15:15 <@seemant> az: this is true -- there is no policy
-15:16 <@Koon> note: no need to argue on this if we intend to refuse it in its current form
-15:16 <@vapier> i think we're all ok with it now in its current form ?
-15:16 <@seemant> I am ok with it, yes
-15:16 <@SwifT> yup
-15:16 <@Koon> any suggestion for (subdomain_to_be_determined) ?
-15:16 <@Koon> just kidding
-15:17 <@Koon> I'm ok with it
-15:17 <@seemant> aide.gentoo.org perhaps ?
-15:17 <@Koon> especially since it has been submitted (a litte late) and didn't spark any negative comment
-15:18 <@seemant> az: solar: comments?
-15:18 <@Koon> We should just say that from now on, GLEP (even minor corrections) should be submitted to -dev at least n days before being put on the agenda
-15:18 <@az> not really, think we covered everything mostly last time
-15:18 <@Koon> k, then , maybe we should move to the meaty stuff
-15:19 <@seemant> so I guess two things have been decided (and need to be hashed out(
-15:19 <@seemant> 1. GLEP 41 is approved
-15:19 <@seemant> 2. -dev needs to be informed of any and all changes before (re)submission of any GLEP for council voting
-15:20 <@seemant> Right, Item # 2 addresses the status of gpg signing of portage tree things
-15:20 <@vapier> put a timeframe on that ? (2) must be at least a week before the actual meeting
-15:20 <@seemant> currently, I believe the signing is limited only to package directories
-15:20 -!- mode/#gentoo-council [+v genone] by Koon
-15:21 <@seemant> vapier: I think a week before meeting is perfect personally
-15:21 <@Koon> that's about when we announce agenda submission deadlines anyway
-15:21 <@az> so then rather 2 weeks ?
-15:21 <@az> 1 week discussion, 1 week to get to us
-15:21 <@vapier> 1 week before agenda submission deadline
-15:22 <@Koon> k, but we must wake up and announce meetings earlier then :)
-15:22 <@vapier> we *remind* we dont announce
-15:23 <@Koon> heh
-15:23 <@vapier> remind everyone on the 1st of each month of the upcoming times
-15:23 <@seemant> Koon: I would like to propose that the meeting times are pre-announced -- we simply fine tune/remind the actual date
-15:23 <@solar> If this is not being postponed on the topic of glep41 as said on the mailing list then I'm going with a no on this topic. So far what I've seen of AT's and the existing AT lead for x86@ has not been very encouraging. thus I dont think it is worth it to put the extra workload on infra.
-15:24 <@vapier> and if it were postponed, what would change your mind ?
-15:24  * Koon feels the sudden cold
-15:25 <@solar> I dont want to hand out access to people who put 30-60 mins of effort into gentoo per week
-15:25 <@vapier> so you dont have to
-15:25 <@vapier> the AT stuff is up to each arch team as they see fit
-15:26 <@vapier> if you dont have people who you think arent fit, no cookie
-15:26 <@Koon> also it's quite a light "access". r/o CVS and a mail alias...
-15:27 <@Koon> anyway, he has the right to vote no, anyone reverting his vote to follow solar ?
-15:27 <@solar> the majority of you have voted yes so it still will pass. I'm fine with that.
-15:28 <@Koon> ok, then, the portage tree signing stuff...
-15:29 <@solar> genone: want to start this topic off?
-15:29 <@Koon> This is more a discussion that should remind/confirm past decisions on this and also discuss how we can speed up things, no ?
-15:29 <@Koon> unless someone has objections on the May 2004 plan
-15:30 <@Koon> ...
-15:30 <@solar> ok I've talked with some key people in the past about this topic. robbat2 pretty much knows what we need. At one point klieber blocked gentoo having it's own keyserver.
-15:30 <@solar> but for us todo it right it is my understanding that is vital
-15:31 <@solar> jstubbs said he is willing to add any additional code to portage itself that is needed to make this happen
-15:31 <@vapier> infra already indexes dev's keys i thought
-15:31 <@Koon> the May 2004 meeting established that we don't really need a keyserver, just a keychain in portage, signed by a master key, no ?
-15:32 <@seemant> that was my understanding as well
-15:32 <@Koon> solar: so it's mostly a problem with devrel not pushing key policy to devs ?
-15:32 <@Koon> (the (1) in genone email ?)
-15:32 <@Koon> and/or an infra problem ?
-15:34 <+genone> someone needs to 1) collect keys 2) sign them with some master key 3) put them somewhere in the (rsync) tree
-15:34 <+g2boojum> Koon: My understanding is that there is on key policy.  Where should they be stored.  How needs to sign the key?  What about expiration dates?  Devs should use a single-purpose key, or a signed subkey, or what?
-15:34 <+g2boojum> s/on key/no key/
-15:34 <@vapier> i thought there was a policy
-15:34 <@Koon> g2boojum/vapier: who should set it ? the council ?
-15:35 <@vapier> it already exists
-15:35 <@vapier> proj/en/devrel/handbook/hb-guide-manifest-signing.xml
-15:36 <@solar> that is not the right policy.
-15:36 <@solar> I recall covering this before. There was no reson to attempt to force DSA keys.
-15:36 <@Koon> solar: consistency ?
-15:36 <+g2boojum> Koon: Ultimately, yes.  Now, there could be a GLEP that specifies this stuff, but there probably needs to be some encouragement for some sane folks to write such a GLEP.
-15:37 <@solar> RSA/DSA are both handled the same. RSA for security has proven itself better. DSA was faster for verifcation
-15:37 <@vapier> ok, but is there any information other than that URL as to our signing policy ?
-15:37 <+g2boojum> vapier: Just the log from that long-ago meeting that genone stripped out and forwarded to the council.
-15:38 <+g2boojum> vapier: Which was pretty much inconclusive.
-15:38 <@Koon> the problem here is that it's nobody's job to make it progress
-15:39 <@Koon> so it's prio 2 for almost everyone
-15:39 <@solar> yes pretty much.
-15:40 <@az> you could say its an security issue, so security heard should take charge of it
-15:40  * az runs
-15:40 <@az> herd*
-15:40 <@vapier> heh, that's stretching it
-15:40 -!- thunder` [n=thunder@gentoo/developer/thunder] has joined #gentoo-council
-15:41 <@Koon> az: why not, but lots of people feel that we are already too aggressive with other teams, so I don't want to overstretch
-15:41 <@solar> there are people willing to work on it. But there is no clear plan thats bullet proof. Adding profiles/ eclass/ package.tbz2 to the list
-15:41 <@seemant> let me ask this -- what would people like to see happen before we go into aggressive mode with a key signing policy?
-15:42 <@seemant> 1. existence of said policy
-15:42 <@seemant> 2. ????
-15:42 <@seemant> 3. profit^W
-15:42 <@solar> repoman not allowing commits to the tree unless FEATURES=sign is enabled
-15:42 <@az> should be start if its implemented i guess
-15:42 <@solar> getting all keys. deciding who is in control of the master key
-15:42 <@vapier> take a step back, we dont even have a policy that is generally accepted
-15:43 <@Koon> ok so we need to GLEP the key policy
-15:43 <@Koon> "we"
-15:43 <@seemant> vapier: see #1 on my mini list
-15:43 <@vapier> so why dont we take it upon ourselves to do that
-15:43 <@vapier> pass around a scratch glep, then send it to the people involved in first meeting, then send to -dev
-15:44 <@solar> I'm in favor of that
-15:44 <@Koon> vapier: sure, but it'd probably still need a primary author, even if the other council members can help in reviewing/correcting
-15:44 <@seemant> all in favour
-15:44 <@seemant> ?
-15:44 <@vapier> primary authors are overrated
-15:44 <@Koon> yes
-15:44 <@seemant> Koon: we'll come to that
-15:44  * Koon hides
-15:44 <@vapier> i'll put down az's name anyways
-15:44 <@seemant> Koon: first let's make sure the council members are ok with it
-15:45 <@SwifT> I'm in favor of such a scratch glep; doesn't need to come from us (but can of course)
-15:45 <@az> if you want a screwup, sure
-15:45 <@seemant> az: explain?
-15:45 <@vapier> he forget the </joke>
-15:45 <@vapier> ;P
-15:45 <@az> i cannot write litrature/anything longer than a paragraph to save my ass
-15:45 <@seemant> SwifT: the idea is probably that the council kicks it off by putting its weight behind it
-15:45 <@vapier> let alone a # comment
-15:46 <@seemant> az: yes, but you can express ideas and that's the important bit
-15:46 <@Koon> especially if it goes a little beyong key policy and mandates who is in charge of what job
-15:46 <@az> i thought vapier wanted me to write it
-15:46 <@Koon> like who asks rogue devs to create new keys
-15:46 <@SwifT> if there is no support from the dev community putting in weight won't work, but I think there is support, just passive
-15:46 <@solar> az he just wants to forge your name on it
-15:46 <@seemant> ok, gavel pound -- the council is hereby charged with scratching the beginnings of the key signing policy document
-15:46 <@az> oh, heh
-15:47 <@seemant> shall we say that the council members will be done with their part of the scratch before the next meeting in December?
-15:47 <@seemant> (ie we would have handed the doc off of to the people involved in the first meeting)
-15:47 <@vapier> sure
-15:48 <@Koon> sure
-15:48 <@SwifT> ack
-15:48 <@az> fine
-15:48 <@seemant> for the sake of the record: the first meeting I refer to is the meeting in genone's email to the council (under the old gentoo metastructure leadership)
-15:48 <@seemant> ok, that is as it is then
-15:48 -!- antarus|work [n=antarus@nagoya.dhcp.egr.msu.edu] has joined #gentoo-council
-15:49 <@seemant> I'll now open up the floor for Q&A
-15:49 -!- mode/#gentoo-council [-m] by seemant
-15:49 <@seemant> don't all talk at once
-15:50 <@solar> Are we supposed to be voting on 43?
-15:50  * antarus|work just got here ;)
-15:50 <@vapier> are we ?  i dont recall it being requested ...
-15:50 <@seemant> solar: wasn't on the agenda I had
-15:50 <@Koon> solar: probably not, wasn't put on the agenda. Which one is it
-15:50 <@seemant> Koon: the hosting of gleps
-15:50 <+g2boojum> solar: It's up to you folks.  I claim that it's a local issue (just affecting the GLEP project), so it doesn't really need a vote by the council.
-15:50 <@seemant> well, files that are related to gleps
-15:50 <@seemant> g2boojum: I should think so as well
-15:50 <@Koon> ah yes, I'd say it's more a GLEP-internal thing
-15:51 <@solar> I'm fine with that. It's pretty much a no brainer
-15:51 <+g2boojum> I'm willing to be smacked down by the council for being uppity, however.
-15:51 <@seemant> who knew g2boojum was kinky
-15:51 <@seemant> I'd rather council stayed far away from the micromanaging thing
-15:52 < ferringb> agreed
-15:52  * vapier knew
-15:52 <@seemant> so seriously, no questions from anyone?
-15:52 < ferringb> what's 2+2?
-15:52 <@seemant> 4
-15:52 <@vapier> how do you stay so sexy ?
-15:52 <@seemant> tae-bo
-15:53 <@seemant> next
-15:53 <@Koon> everything must go very well in Gentoo-land
-15:53 <@SwifT> well, if that's it, I'm off :)
-15:53 <@seemant> next time, we need something more controversial to vote on :P
-15:53 <@Koon> at least two weeks without a -core flame
-15:53 < ferringb> hmm.
-15:54 < ferringb> the site redesign got me wondering if there is any rules regarding accessibility for our pages...
-15:54 <@Koon> seemant: maybe the core announcement glep will be ready by then
-15:54 <@az> if bum touching in dev channels is allowed ?
-15:54 < ferringb> seemant: conversion to the smart pkg manager fex?
-15:54 <@seemant> ferringb: I thought the original requirements for the page redesign had that in?
-15:54 < ferringb> rpm or dpkg, yay!
-15:55 <+g2boojum> SwifT: Still here?
-15:55 < ferringb> seemant: no clue
-15:55 <@seemant> ferringb: we're not voting on that -- we're putting that as a rider to an already existing vote that's virtually guaranteed to go through
-15:55 <@seemant> ferringb: like when we vote to have the AT subdomain be cheese.gentoo.org, fex.
-15:55 < ferringb> hmm.  tag on a "pay harring to sit on his ass" rider to said rider, and you've got my vote
-15:56 < ferringb> ahh, politics.
-15:56 < ferringb> hmm
-15:56 <@vapier> well if this has degenerated into listening to ferringb talk, i'm outs
-15:56 -!- vapier [i=UserBah@wh0rd.org] has left #gentoo-council []
-15:56 < ferringb> seemant: has been brought up earlier and resulted in a massive flaming (yay for knee jerk reactions), but social contract y'all might want to do a careful read through again
-15:57 < ferringb> wonderful timing...
-15:57 <@seemant> ferringb: that might well be a good thing to discuss in December or January's meeting, actually
-15:58 < ferringb> ...and find out what's going on with the copyright assignement (are we doing it, aren't we, were are we at, etc)
-15:58 -!- tove [n=tove@p54A61965.dip0.t-ipconnect.de] has left #gentoo-council []
-15:58 <@seemant> ferringb: ah we'll have to get the trustees to inform us about that
-15:58 < ferringb> crack that whip.
-15:58 -!- agaffney [n=agaffney@gentoo/developer/pdpc.active.agaffney] has left #gentoo-council []
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051215-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20051215-summary.txt
deleted file mode 100644
index 979ab41484..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20051215-summary.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-this months meeting wasnt too eventful, kind of quiet ... on the agenda:
-
-- Marius: decision on multi-hash for Manifest1
-there was a bit of hearsay about why the council was asked to review/decide 
-on this issue since we werent able to locate any portage devs at the time of 
-the meeting ... so our decision comes with a slight caveat.  assuming the 
-reasons our input was asked for was summarized in the e-mail originally sent 
-by Marius [1], then we're for what we dubbed option (2.5.1).  that is, the 
-portage team should go ahead with portage 2.0.54 and include support for 
-SHA256/RMD160 hashes on top of MD5 hashes.  SHA1 should not be included as 
-having both SHA256/SHA1 is pointless.  further more, we hope this is just a 
-hold over until Manifest2 is ironed out/approved/implemented/deployed.  it 
-was also noted that we should probably omit ChangeLog and metadata.xml files 
-from the current Manifest schema as digesting them serves no real purpose.
-[1] http://article.gmane.org/gmane.linux.gentoo.devel/33434
-
-- Council: portage signing
-shortly after our November meeting, a nice summary was posted by Robin 
-Johnson that covered signing issues from top to bottom.  as such, it was felt 
-that trying to throw together a GLEP would not be beneficial.  instead we 
-will be adding a constant agenda item to future council meetings as to the 
-status of portage signing issues to keep the project from slipping into 
-obscurity again.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20051215.txt b/xml/htdocs/proj/en/council/meeting-logs/20051215.txt
deleted file mode 100644
index 085d37624c..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20051215.txt
+++ /dev/null
@@ -1,229 +0,0 @@
-
-Session Start: Thu Dec 15 13:20:24 2005
-Session Ident: #gentoo-council
-* Logging #gentoo-council to 'logs\#gentoo-council.log'
-[13:20] <vapier> ...
-[13:33] <SwifT> \\o
-[13:33] <SwifT> \o/
-[13:33] <SwifT> o//
-[13:33] <SwifT> \o/
-[13:33] <SwifT> and DANCE
-[13:34] <solar> heh.
-[13:34] * vapier stabs SwifT in the eye
-[13:34] <solar> so topics for today include only us deciding on to enable SHA1 ?
-[13:35] <solar> for portage. or was it all those hashing algos (like where he had 5 that overlapped) ?
-[13:35] * SwifT needs to be informed again as to why we need to decide on that; isn't that Portage-specific?
-[13:35] <SwifT> no, not the manifest2 one
-[13:35] <vapier> i think he was looking for advice considering it isnt a trivial change
-[13:35] <vapier> even though yes, it is pretty much a portage-only issue
-[13:36] <vapier> infra OK-ed the extra temp overhead
-[13:36] <solar> that and jstubbs votes for wait. genone votes for now.
-[13:36] <solar> so portage team cant decide within itself
-[13:36] <vapier> hmm, wasnt aware of that nuance
-[13:36] <SwifT> whos portage lead?
-[13:36] <solar> from what I gather
-[13:36] <SwifT> ("who is the Portage lead" in correct English)
-[13:37] <vapier> i dont think they have a real lead
-[13:37] <vapier> they're a little commie group
-[13:37] <solar> I dont think there is a 'lead' but jstubbs handles the portage releases.
-[13:38] <SwifT> and he wants to wait...
-[13:39] <solar> In his notes for 2.0.54 I know he expects that it will be SHA1+MD5
-[13:40] <vapier> seems to me that the manifest2 thing will take sometime to implement while the SHA1+MD5 can be done now ?
-[13:40] <SwifT> both take time to implement, but the sha1+md5 is less intrusive
-[13:41] <vapier> the sha1+md5 is done afaik
-[13:41] <vapier> genone just wanted some feedback as to whether to deploy it
-[13:48] * Joins: marienz (i=marienz@gentoo/developer/marienz)
-[13:55] * Joins: agriffis (n=agriffis@gentoo/developer/agriffis)
-[13:55] * ChanServ sets mode: +o agriffis
-[13:58] * Joins: jaervosz (n=jaervosz@gentoo/developer/jaervosz)
-[14:00] * vapier sets mode: +o jaervosz
-[14:00] <SwifT> *ding* *dong*
-[14:00] <vapier> lets get this shindig going
-[14:00] * Quits: Koon (n=koon@gentoo/developer/Koon) ("Leaving")
-[14:01] <vapier> agriffis / seemant / solar / SwifT / vapier/ jaervosz ?
-[14:01] <jaervosz> yeah, i'm here instead of koon who is taking care of his newborn
-[14:01] <SwifT> yes
-[14:02] <vapier> az for sure wont be here due to fuel crisis in south africa
-[14:03] <vapier> but he has no proxy
-[14:03] <vapier> seemant / solar / agriffis ?
-[14:03] * agriffis is here
-[14:04] <vapier> solar was active a min ago
-[14:04] <solar> I owe him a proxy and todays meeting seems to be a brainstorming session
-[14:04] * Joins: ciaranm (n=ciaranm@alpha.total-knowledge.com)
-[14:04] <vapier> agenda today is Marius's request for decision on multihash support
-[14:04] <vapier> http://article.gmane.org/gmane.linux.gentoo.devel/33434
-[14:06] <vapier> for those who remember, infra a-ok-ed the additional overhead that any of the methods would require
-[14:07] <seemant> hey guys sorry
-[14:07] <seemant> I'm here
-[14:07] <vapier> so that leaves us with 2.5 recommendation choices
-[14:07] <vapier> (1) nothing should be done and we should wait for Manifest2 GLEP to be hammered out/approved/implemented
-[14:08] <vapier> (2) the digests should be updated to start including/using SHA1 as well as MD5
-[14:08] <vapier> (2.5) also include SHA256 and RMD160 hashes
-[14:09] <vapier> the implementation for (2) is done, just not committed
-[14:09] <seemant> 2.5 is my preference
-[14:09] <SwifT> (2) is my preference with (1) being on the roadmap
-[14:09] <vapier> (2.5) is a .5 because it adds overhead of requiring pycrypto
-[14:10] <vapier> but pycrypto, being quite tiny and fast (i looked into it), isnt that big of deal imho
-[14:10] <agriffis> vapier: from my reading of genone's message, it sounds like 2.5 and 2 are mostly the same thing, since 2.5 is optional and only happens if dev-python/pycrypto is installed.
-[14:10] <seemant> that was my followup question
-[14:10] <vapier> agriffis: hence the .5
-[14:10] <SwifT> but I'm wondering why it wasn't added by the portage folks automatically... if they're afraid that the small overhead of the manifest files will hit them like thunderstorm and they want the council to take the heat, or if there's another reason
-[14:11] <vapier> SwifT: there seems to be disagreement whether to go with (1) or (2) so they wish for outside advice
-[14:11] <vapier> (1) seems to be going smoothly, it just looks like it'll take sometime for everything to fall into place
-[14:11] <seemant> vapier: what are the rationales for disagreement
-[14:11] <seemant> ?
-[14:11] <vapier> you'd have to ask jstubbs and genone, neither of which seem to be here atm
-[14:11] <vapier> mayhap solar knows
-[14:12] <solar> Without genone here I would not feel right about trying to approve/disapprove anything on this topic.
-[14:12] <agriffis> what's the reason for going with 2 or 2.5, btw, instead of waiting for the full Manifest2 GLEP?  My understanding is that it's very hard to compromise MD5, even with the recent discoveries.  So is the point of 2/2.5 to ward off people that are unhappy with portage depending on MD5?
-[14:13] <agriffis> Is genone aware the meeting is happening now?
-[14:13] <vapier> we've tried pinging him via e-mail/irc, but no luck
-[14:13] <vapier> (2) can be done right now, no sweat
-[14:14] <vapier> (1) will take time
-[14:14] <SwifT> does (2) bring additional work on the ebuild maintainer's heads?
-[14:14] <SwifT> not really does it?
-[14:14] <vapier> no
-[14:14] <vapier> repoman does it
-[14:14] <SwifT> oh, I thought ebuild did that
-[14:14] <vapier> agriffis: generating a collision with md5 is not hard
-[14:14] <SwifT> does (2) bring additional work on the portage developers's heads?
-[14:15] <vapier> no, (2) is done
-[14:15] <vapier> genone has posted the patch which implements it
-[14:15] <agriffis> okay, so g2boojum tells me that it's mostly a PR thing, because we've been advertising multi-digest for a long time but don't have it yet.  (2) gives it quickly, satisfying many people and letting the portage devs concentrate on Manifest2 without the additional pressure.
-[14:15] <agriffis> (g2boojum didn't say all that, I added interpretation, etc)
-[14:16] <SwifT> I mean for (1)
-[14:16] <vapier> SwifT: yes, it's all in the GLEP
-[14:16] <vapier> Manifest2 eats Manifest and digest files
-[14:16] <SwifT> as far as I'm concerned, I only hear good things about the proposal (2), I honestly don't know why we need to approve anything on it
-[14:16] <SwifT> so, I'm in favor of the proposal
-[14:16] <vapier> SwifT: we're not approving, we're recommending
-[14:16] <SwifT> oh ic
-[14:16] <SwifT> :)
-[14:17] <agriffis> SwifT: I don't think any of it, 1 2 or 2.5 is harder for devs.  Probably all devs will need to install the additional module to generate the SHA256 and RMD160 sums though, so that makes 2.5 a little harder to implement than 2.
-[14:17] <vapier> yes, but we could just add pycrypto as a DEPEND to newer portage
-[14:17] <vapier> as i mentioned, the overhead of the package is trivial, ignoring the fact that it's python
-[14:17] <agriffis> vapier: so everybody would need it then?  any issue with export restrictions, etc?
-[14:17] <solar> if it's going to generate SHA256 is there really any point in waisting the space in the tree with SHA1 ?
-[14:17] <vapier> the more the merrier
-[14:18] <vapier> we could ask for a 2.5.1: add SHA256/RMD160
-[14:18] <vapier> agriffis: i do not know
-[14:18] <agriffis> no, not true.  solar is right, there's no point putting in both SHA1 and SHA256, that's just extra lines in every manifest
-[14:18] <vapier> i stay ignorant of export restrictions as i hate them
-[14:18] <solar> he also includes metadata.xml
-[14:19] <solar> that is also pointless. A while ago metadata.xml and ChangeLog were removbed from files that were supposed to be digested
-[14:19] <vapier> first off, is everyone comfortable with making a recommendation ?  or would we want to get genone/jstubbs here
-[14:20] <agriffis> vapier: I think we have enough questions that we're not able to recommend between the given options.
-[14:20] <agriffis> (just stating my humble opinion, not speaking for everybody)
-[14:20] <SwifT> I'd recommend that the Portage team can do whatever they want on the subject
-[14:21] <vapier> i'm all for 2.5 followed by 1
-[14:21] <vapier> seemant: how about yourself ?
-[14:22] <agriffis> g2boojum would like to say something, is that ok?
-[14:22] * solar sets mode: +v g2boojum
-[14:22] * agriffis realizes he is a council member
-[14:22] <vapier> g2boojum's always welcome to say something
-[14:22] <agriffis> g2boojum: speak, man :-)
-[14:23] <g2boojum> My read, from http://thread.gmane.org/gmane.linux.gentoo.devel/33434, is that the issue is about the relative merits of bloating the tree (temporarily), or waiting an unspecified amount of time for multi-digest to go in.  http://thread.gmane.org/gmane.linux.gentoo.devel/33434
-[14:23] <g2boojum> Arghh.  Sorry about the double link.
-[14:23] <g2boojum> The technical issues are already handled, except for the differences between (2) and (2.5), and I don't think the portage team cares all that much there.
-[14:24] <jaervosz> is there any significant need for (2.5) over (2)?
-[14:24] <agriffis> jaervosz: my question too
-[14:24] <vapier> the hashes provided by 2.5 are thus far not "cracked"
-[14:25] <vapier> the hashes provided by 2 are all "crackable"
-[14:25] <jaervosz> why not take the simplest satisfactory solution until manifest2 is in place?
-[14:25] <vapier> we're just hedging out bets on the idea that it's harder to "crack" multiple hashes simultaneously
-[14:25] <jaervosz> but you'd have to provide a collision for both the md5 and sha1 checksums
-[14:25] <vapier> yes, but we're still hedging our bets
-[14:26] <vapier> and really, when it comes to computing SHA256 vs SHA1 on files in portage, the disk I/O tends to be more overheard than the additional cpu cycles
-[14:27] <vapier> so how about this everyone, we say that 'if the reason they are looking for our feedback is the issues stated in http://thread.gmane.org/gmane.linux.gentoo.devel/33434, we recommend (#)'
-[14:27] <vapier> that way if theres more underlying issues, we can get them to show up next meeting
-[14:28] <vapier> that sit well with people ?
-[14:29] <solar> my understanding is that he is asking for a decision vs a recommendation
-[14:30] <SwifT> something like "can I can I can I? Please? Can I?"
-[14:30] <vapier> give em a strong recommendation ?
-[14:31] <agriffis> vapier: it's fine with me if that's the sentence to send back to them, are you going to take a vote on which number next?
-[14:31] <solar> if you go back to th first mail on the topic he sent to the council. http://rafb.net/paste/results/NQH1vd21.html
-[14:31] <vapier> that's ok with me
-[14:31] <vapier> so shall we pool our cards and see what we got ?
-[14:32] <vapier> (1) ? (2) ? (2.5.1) ?
-[14:32] <agriffis> btw, I've checked wikipedia and it seems that we don't have to worry about export restrictions on these.  IANAL though ;-)
-[14:33] <agriffis> vapier: referring to the link solar provided,
-[14:33] <vapier> it's just a forward of the gmane ive posted
-[14:33] <agriffis> I think the a-b-c-d choices are more explicit.
-[14:33] <jaervosz> (2)2.5.1
-[14:33] <agriffis> Not toward the bottom it isn't.
-[14:33] <jaervosz> bahh forget that
-[14:34] <vapier> agriffis: not really ...
-[14:34] <vapier> (1/a) manifest2 (2/b) SHA1 (2.5/d) force sha256/rmd160
-[14:35] <agriffis> vapier: well, there are 4 choices there ;-) and I like the distinction between c and d.  I think it's best for our recommendation to be one or the other, if either.
-[14:35] <agriffis> vapier: ah ok, so you're just skipping c.  That's fine with me.
-[14:35] <vapier> yes
-[14:35] <agriffis> c seems pretty pointless
-[14:35] <vapier> imo if we're going to do sha256/rmd160, half-assing it is a waste
-[14:35] * agriffis nods
-[14:35] <vapier> btw seemant called me ... he lost network at work
-[14:35] <vapier> he said if it came together, he was pro 2.5.1
-[14:36] <seemant> wow, back
-[14:36] <seemant> thanks vapier
-[14:36] <seemant> agriffis: left you a msg too
-[14:36] <vapier> heh, well that was a waste
-[14:36] <seemant> yeah, sorry
-[14:36] <agriffis> seemant: I have my earphones in, I can't hear my lawn tractor nevermind my phone ;-)
-[14:36] <vapier> i didnt hear my cell cause my acid trance was too loud
-[14:36] <agriffis> hehe
-[14:37] <vapier> so given the e-mail, what are people in favor of ?
-[14:37] * vapier points at 2.5.1
-[14:38] <seemant> "
-[14:39] <agriffis> vapier: based on the idea that the manifests aren't going to take more space blockwise, I'd say 2.5.1 is fine (i.e. d, forced SHA256 / RMD160).  It would be nice to drop MD5 / SHA1 entirely, but dropping MD5 would break older portage.  It's possible though that dropping SHA1 would be cool.
-[14:39] <vapier> that's the .1
-[14:39] <vapier> 2.5 -> {SHA1,SHA256,RMD160}    2.5.1 -> {SHA256,RMD160}
-[14:40] <agriffis> oh, I must have missed that.
-[14:40] <agriffis> 2.5.1 is great with me then.
-[14:40] <solar> I'm in favor of giving genone 1 slacker dev point for calling us in on the subject and not bothering to show up. Otherwise {SHA256,RMD160}
-[14:40] <jaervosz> 2.5.1 is fine with me
-[14:40] <vapier> SwifT: ?
-[14:40] <SwifT> pfft
-[14:40] <SwifT> (2) and (2.5.1) are both okay for me
-[14:41] <SwifT> I mean, the 2.5.1 requires some additional work, no?
-[14:41] <vapier> for portage devs ? no
-[14:41] <SwifT> which could very well be spend to work on the Manifest2 stuff
-[14:41] <vapier> it's done
-[14:41] <SwifT> oh, it's just the python-package dependency then?
-[14:41] <vapier> yes
-[14:41] <solar> vapier: he has too much code in there.
-[14:41] <SwifT> must've missed it, sorry
-[14:41] <SwifT> 2.5.1 it is then
-[14:41] <agriffis> if we try, we could manage to take an hour on this. :-)
-[14:41] <vapier> any other points people wish to mention before we tag it & bag it ?
-[14:42] <vapier> {it -> portage manifesting stuff}
-[14:42] <solar> yank SHA1 and metadata.xml and it would seem fine to me
-[14:42] <vapier> noted
-[14:43] <seemant> let's {t,b}ag
-[14:43] <vapier> {tea,bag}
-[14:43] <vapier> anyways, the last note before people peace out
-[14:43] <vapier> for those who have forgotten, the signing [preglep] stuff
-[14:44] <solar> vapier: ChangeLog not listed in his example anywhere. But I'd say add that the to notes as well for something that should not be added to the hash file
-[14:44] <vapier> i talked with robbat2, and imo, his e-mail thread he posted more than covered anything we need for a first step
-[14:44] <vapier> shall we turn it into a running item for each meeting ?  current signing status ?
-[14:45] <jaervosz> sounds like a good idea to keep the thing flowing
-[14:46] <vapier> we'll call it an Action Item
-[14:46] <vapier> each month needs a TPS report
-[14:47] <SwifT> you mean PSR?
-[14:47] <SwifT> Present Status Report
-[14:47] <vapier> while sipping my warm cup of STFU
-[14:47] <SwifT>  
-[14:47] <vapier> pwnt
-[14:47] <SwifT>  
-[14:47] <vapier> all in all, a quiet meeting ... so i guess unless someone else wants something posted, lets call it a day ?
-[14:47] <solar> stalled. robbat2 has some good ideas but portage team is not in favor
-[14:48] <vapier> ok, so i'll poke robbat2 and genone some more about it
-[14:49] <solar> Each of them have thier own methods. I'd still say step 1 is to make repoman force pkgs to be atleast signed. next step should be for somebody to code whats needed for eclasses and profiles
-[14:50] <vapier> i thought manifest2 covered that, but i guess not huh
-[14:50] <solar> no it does not.
-[14:50] <agriffis> vapier: mtg is over, this is post discussion, right?
-[14:51] <vapier> i think we can wrap it up solar ?
-[14:51] <vapier> post the summary to gentoo-dev and we can expand upon current shortcomings there
-[14:51] <solar> I'm done
-[14:51] <vapier> k
-[14:51] <vapier> agriffis: latesr
-[14:52] <SwifT> I'm off; bye all
-Session Close: Thu Dec 15 14:52:41 2005
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060112-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060112-summary.txt
deleted file mode 100644
index 809f2729fb..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060112-summary.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-Present:
-  Koon (Thierry Carrez)
-  Swift (Sven Vermeulen)
-  agriffis (Aron Griffis)
-  seemant (Seemant Kulleen)
-  solar (Ned Ludd)
-  vapier (Mike Frysinger)
-
-Absent: 
-  azarah (Martin Schlemmer)
-  Where abouts unknown for the last 30 days.
-
-Attendance by non council members appeared to be rather low.
-
-Agenda:
-
- * GLEP 45 - GLEP date format
- * Disallowing council members to act as proxies for other council members.
-* Global gentoo goals for 2006
-
-
-Outcome:
-
-* GLEP 45:
-As stated on the mailing lists minor changes to GLEP's and the GLEP 
-process is best left in the hands of the GLEP editors. Everybody 
-supported g2boojum's ability to decide. Otherwise we would of voted 
-yes.
-
-* Disallowing council members to act as proxies for other council members.
-Approved.
-
-* Global gentoo goals for 2006
-This was mostly a brainstorming session covering such topics as should 
-the council even be setting global goals, enterprise support, GRP, 
-ebuild/profile/eclass and binpkg signing.
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060112.txt b/xml/htdocs/proj/en/council/meeting-logs/20060112.txt
deleted file mode 100644
index ecf3e8ed8a..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060112.txt
+++ /dev/null
@@ -1,257 +0,0 @@
--:- Topic (#gentoo-council): changed by vapier: Meeting at 1900 UTC (1400 EST) || anybody seen azarah in the last month?
-06:54PM <SwifT> where am I?
-06:54PM <SwifT> :p
-06:55PM <vapier> batman
-<solar> anybody want to step up and chair this or open session today?
-06:57PM <vapier> i would but like i said, i'm prob gonna have to pop out early
-06:59PM <vapier> welp, by my clock, it's about that time eh
-07:00PM <vapier> i'm pretty sure az isnt going to show up
--:- tove [n=tove@p54A60D69.dip0.t-ipconnect.de] has joined #gentoo-council
-07:00PM <vapier> Koon / seemant / solar / seemant / vapier
-07:00PM <vapier> who is awake ?
-<solar> check
-07:01PM <SwifT> mate
-07:01PM <seemant> I am awake
-07:02PM <vapier> i'll assume Koon will wake shortly
--:- kloeri_ [n=kloeri@gentoo/developer/kloeri] has joined #gentoo-council
-<solar> * GLEP 45 - GLEP date format <-- ok this one. This is not even for us to decide on is it? The glep editors got that one covered right?
-07:02PM <vapier> yes, g2boojum is for it
-07:02PM * SwifT/#gentoo-council doesn't mind at all
-07:02PM <vapier> and i'm pretty sure we'd all vote yes
--:- NetSplit: irc.freenode.net split from zelazny.freenode.net [07:02pm]
--:- BitchX: Press ^F to see who left ^E to change to [irc.freenode.net]
-07:02PM <seemant> it's not for us to decide, I should think
-07:02PM <vapier> stupid freenode
--:- [Users(#gentoo-council:10)] 
-[ kloeri_   ] [ tove      ] [@seemant   ] [@vapier    ] [ kallamej  ] 
-[vg2boojum  ] [ FuzzyRay  ] [@SwifT     ] [ spb       ] [@solar     ] 
--:- Topic (#gentoo-council): Meeting at 1900 UTC (1400 EST) || anybody seen azarah in the last month?
--:- Topic (#gentoo-council): set by vapier at Thu Jan 12 18:54:06 2006
-07:02PM <SwifT> regarding chairing, sorry, just saw the e-mail. Perhaps next meeting
-<solar> who did we lose on that split?
-07:03PM <seemant> I support g2boojum's ability to decide that :)
-07:03PM <SwifT> Koon
--:- Koon [n=koon@gentoo/developer/Koon] has joined #gentoo-council
--:- mode/#gentoo-council [+o Koon] by ChanServ
-07:03PM <SwifT> here he is
-<solar> ok next item is.
-<solar> * disallow multiple votes per person (from ciaranm)
-<solar>  http://marc.theaimsgroup.com/?t=113467833000002&r=1&w=2
-07:04PM <vapier> WFM
-07:04PM <SwifT> wfm?
-07:04PM <seemant> the reasoning in that email is sound
-07:04PM <Koon> yes too
-07:04PM <seemant> so yes, wfm2
-07:04PM <SwifT> isn't it Windows Meta Format or something?
-07:04PM <seemant> SwifT: works for me
-07:04PM <vapier> emerge wtf && wtf wfm
-07:04PM <SwifT> oh, that
-07:04PM <SwifT> yes, wfmaw
-07:04PM <vapier> pfft that isnt real
-07:05PM <vapier> you're just making s**t up
-07:05PM <Koon> brb phone
-07:05PM <seemant> have we all voted for that?
-07:05PM <seemant> (or a majority anyway)
-07:05PM <vapier> solar hasnt
-<solar> I dont see the point personally and what brought it up was I'm guessing me trying to cover for az last month. 
-<solar> but if the majority want to put into effect thats ok.
-<solar> so yes
-07:06PM <vapier> you're so accommodating
-07:06PM !alindeman:*! Hi all .. Regional server looks to be having some trouble; we're working to resolve it now
-<solar> next item is
-<solar> * global gentoo goals for 2006
-07:06PM <vapier> whee
-07:06PM <vapier> that thread went to garbage fast eh
-<solar> that we talked about a short bit in mail and said that global goals is not something that the council should decide. 
-<solar> anybody have any input towards that subject?
-07:08PM <vapier> i dont think that's it
-07:08PM <seemant> so my followup question is: who's role is that to play?
-<solar> explain please
-07:09PM !lilo:*! Problem with a temporary main rotation server; however, we'd removed it from the main rotation as soon as we could manage, and about 800 users were affected
-07:09PM <vapier> we cant just defer it, if we do we're saying "what Gentoo is now is good enough"
-07:10PM <SwifT> no, but some people would like to see us 7 give the global direction where Gentoo is heading at
-07:10PM <SwifT> which, frankly, will probably upset at least 7 other people :p
-07:10PM <SwifT> however, if the council could work on keeping track of Gentoo's shortcomings and possible interesting areas, we can give a boost to new proposals
-07:10PM <SwifT> well, not really "council" job, but someone has to :)
-07:11PM <vapier> that seems feasible
-07:11PM <SwifT> previously, the gentoo managers did that a bit
-07:11PM <seemant> honestly, that seems more like a gentoo council job than deciding date formats
-07:11PM <vapier> picking out the top "must have" goals and tracking them ?
-07:11PM <SwifT> =)
-07:11PM <SwifT> no, not "must have", a bit more abstract
-07:11PM <seemant> just my opinion, of course, but shouldn't we focus on high level stuff rather than low level stuff?
-07:11PM <seemant> as a council I mean
-07:12PM <SwifT> for instance, if lots of people want Gentoo to focus more to enterprises, the council can attempt to get the enterprise gentoo project up and running
-07:12PM <SwifT> without saying what we (the council) would like to see happen
-07:12PM <SwifT> no?
-07:14PM <seemant> I don't know
-07:14PM <Koon> back
-07:14PM <seemant> I'm honestly unclear on this
-07:14PM <SwifT> or, if people are too upset about lacking QA, we might want to make an analysis of that and start discussions about it
-07:15PM <vapier> theres the conflict of some devs disliking the lack of cohesiveness, singular purpose, while others are specifically looking for that
-07:15PM <SwifT> yet, saying that the gentoo web site is too slow is purely infrastructure project
-07:15PM <SwifT> true, but that doesn't mean we need to stand on opposite sides ourselves
-07:15PM <Koon> I think we can elect the top best cross-project ideas and hope (pray) that some team will form and do it... but not much more
-07:16PM <Koon> we lack people to do things, not people to have ideas
-07:16PM <Koon> see the enterprise stuff
-<solar> enterprise itself is tricky. Some have strong feelings that any enterprise should not contain bins. where I would think enterprise is the exact place we should be providing binpkgs
-07:16PM <SwifT> I'm in the middle, enterprise should inform the users how to create their own, coherent binplg set :)
-07:17PM <Koon> enterprise = freezed tree + reference bins
-07:17PM <SwifT> s/plg/pkg/
-07:17PM <vapier> eh, enterprise/GRP could be unified
-07:17PM <vapier> have some dedicated autobuild boxes ala-Debian and keep a tree of current stable binpkgs
-07:18PM <SwifT> which means freezing USE, C{,XX}FLAGS, make.profile, /etc/portage
-<solar> I'm attempting todo that now for x86
-07:18PM <vapier> there's no issue of freezing
-07:18PM <vapier> expand/automate GRP
-07:18PM <seemant> wait wait wait
-07:18PM <SwifT> sleep(10)
-07:18PM <Koon> vapier: once again, the best solution will probably be the one that a team forms around, not the one some other group decides
-07:18PM <seemant> are we as a council discussing enterprise as a future direction for 2006?
-07:19PM <seemant> or was the above just an example of something or the other?
-07:19PM <Koon> an example, I'd say :)
-07:19PM <SwifT> more of an example how we don't lack ideas
--:- fox2mike [n=fox2mike@gentoo/developer/fox2mike] has joined #gentoo-council
-07:19PM <vapier> i'm pretty sure if we produce such a list and enterprise was not on it, that'd be quite a failing on our part
--:- MetalGOD [n=DevNull@gentoo/developer/MetalGOD] has joined #gentoo-council
-07:19PM <vapier> it'd basically be us saying "Gentoo is not for use in corporations, toss off"
-07:20PM <SwifT> I don't think we'll be giving a list right now
-07:20PM <vapier> we're brainstorming now
-07:20PM <vapier> and i'm simply saying that enterprise/binpkg is a no-brainer imho
--:- nattfodd [n=nattfodd@gentoo/developer/nattfodd] has joined #gentoo-council
-07:20PM <Koon> vapier: it just needs some people to work on it
-<solar> for the sake of anybody reading and willing to test here are my repos. ftp://tinderbox.x86.dev.gentoo.org/default-linux/x86/2005.1/All/Packages
-          ftp://tinderbox.x86.dev.gentoo.org/hardened/x86/Packages
-07:21PM <Koon> that we cannot force in any way
-07:21PM <vapier> i know
-07:21PM <Koon> but we can say "here are what we think would be good directions for Gentoo, if one of them interests you, pick it up"
-07:22PM <vapier> as i'm sure solar knows, i tend to be scatter brained in terms of what i'm working on at any one moment
-07:22PM <SwifT> I'm kinda wondering why, if there would be a good goal for gentoo, it wouldn't be part of a single project... we already have a good separation of duties for all non-pkg
-          development stuff
-07:22PM <vapier> having anyone dictate a specific project would make me angry
-07:23PM <Koon> maybe we should just talk about cross-project goals, not those requiring a whole new project team
--:- agriffis [n=agriffis@gentoo/developer/agriffis] has joined #gentoo-council
--:- mode/#gentoo-council [+o agriffis] by ChanServ
-07:24PM <vapier> chatting about global gentoo direction atm agriffis
-07:24PM <Koon> enterprise is more a project thing than a cross-project thing, so not sure it's our role to say "hey guys, here is a good one, now would you be so kind to form a team"
-07:24PM <agriffis> vapier: ok, thanks.  somebody email me the log so I can catch up?
-07:24PM <SwifT> isn't coaching people with good ideas on who to contact for what and how a good approach?
-07:24PM <Koon> but it might be our role to say, hey, portage and enterprise teams, please play nice
-07:25PM <SwifT> yeah, don't spank each other unless they like it
-07:25PM <Koon> anyway, we'll lack time at this meeting to define the goal list
-07:26PM <vapier> i think of it as us deciding whats most important in terms of greatest benefit to long term Gentoo
-07:26PM <Koon> was there anything else to discuss, 'coz this one can take a long time...
-07:26PM <agriffis> I understand that GLEP 45 and Ciaran's no-multiple-vote proposal have already been discussed.  Regarding the first one, it's fine with me.  Regarding the second, I wish I
-          hadn't missed the discussion, but the otherwise I don't think it's a bad idea anyway, so I'm fine with it.
-07:26PM <vapier> this was last item, but it was more of a brain storm session
-07:26PM <Koon> ok
-07:26PM <SwifT> or attempt to have new stuff well prepared for release... instead of just committing, making sure a press release is made with screenshots and articles, a nice news item, good,
-          solid documentation, ...
-<solar> that would be nice swift.
-07:27PM <Koon> vapier: we should also track progress in portage signing, since last month
-07:27PM <SwifT> that's theoretical :)
-<solar> I still like it
-07:27PM * SwifT/#gentoo-council for instance is really hoping axxo's java repo hits portage with a good release information, updated documentation, ...
-07:27PM <SwifT> :)
-07:28PM <SwifT> same with new features that gentoo/hardened supports
-07:28PM <vapier> well the manifest stuff is in portage now, so next step is handling of keys
-<solar> hardened is and probably will remain in maintenance mode. My goal is of course to see more hardened by default for gentoo
-07:29PM <vapier> hardened i see as being a slightly tweaked flavor
-07:29PM <vapier> that if all the other pieces fall into place, hardened is an extra pass
-07:30PM <SwifT> or what about a knowledge base for gentoo/linux? A place where errors are stored, the circumstances when that error will occur and how to resolve it together with information as
-          to why it happens...
-07:30PM <Koon> vapier: should we follow robbat2 solution or the old simple "keychain-stored-in-portage, validated once using master key, then at each emerge sync" solution ?
-07:30PM * SwifT/#gentoo-council stops brainstorming
-07:30PM <vapier> SwifT: that sounds like hopping onto irc and pasting an error into #gentoo :)
-07:31PM <SwifT> =)
-<solar> that is what wikis are for. But you the formep GDP lead did not want those if I recall
-07:31PM <SwifT> unable to mount root fs, probably the most frequent question on the forums
-07:31PM <agriffis> Koon: is the robbat2 solution published somewhere?
-07:31PM <SwifT> true, I don't like any  documentation way where no qa is involved
-07:31PM <SwifT> wikipedia is great because *many* eyes are watching
-07:31PM <Koon> agriffis: gentoo-dev archive I suppose...
-07:31PM <SwifT> gentoo-wiki fails there for most articles, for instance
-07:31PM <Koon> agriffis: hm. maybe was posted to -core
-<solar> I think there is a problem with robbat2's solution. portage devs seem to want it to go another direction. 
-<solar> sadly none of them are here to speak up
-07:32PM <agriffis> Koon: ok, I'll look for it.  Generally I'm impressed by anything that robbat2 suggests regarding gnupg, signing, etc.  I'd be hesitant to disregard it without careful
-          consideration.
-07:32PM <Koon> agriffis: history on the subject is : we had a painful discussion on gentoo-dev about 18 months ago and the solution most agreed on was the "simple but doable" one
-07:33PM !lilo:*! orphaned group contact for Novell, Inc....that group registration has been inactivated
-07:33PM <agriffis> Koon: ok, I'll have to look it up, I guess.  I'm sure I read it then, but it's slipped away at this point.
-07:33PM <Koon> then robbat2 said he would handle it and designed a nice solution... but apparently not taht easy to implement
-07:33PM <Koon> especially when its author disappears
-<solar> I trust robbat2 also, but the direction he wants to go in requires devs getting together for key signing parties to form big chains of trust.
-07:34PM <vapier> solar: i dont see how it can be done any other way
-<solar> that is clearly going to be a problem when we have a dev tucked away in some corner of the world
-07:34PM <Koon> I prefer the "simple but now" solution to the "unbreakable but tomorrow" one
-07:34PM <vapier> LWE and such help a lot with that
-07:35PM !lilo:*! Okay, deactivated if you prefer. Sheesh. Grammar wonks. *grin*
-07:35PM <SwifT> or, "simple now and unbreakable tomorrow"?
-07:35PM <agriffis> well, clearly whatever is implemented, we don't want to present it as something it isn't.
--:- mpagano [n=mike@70.105.167.111] has joined #gentoo-council
-<solar> anybody ever met azarah or me in person?
-07:36PM <vapier> i'll fly down for butt sex with you solar
-07:36PM <SwifT> not sure I want that ;p
-07:36PM <agriffis> so if we go with a simple solution with flaws, we need to present it as that, and our reasons (meaning gentoo's not the council's) for doing so.
-<solar> I've say it should be simple to begin with and made stronger and better over time
-07:36PM <SwifT> j/k
-07:36PM <vapier> i'm gonna try to fly to fl this year, could make a stop over :p
-<solar> hush you
-07:37PM <Koon> I would just do a flat keychain for starters
-07:37PM <Koon> signed by a master key, verified by release media or public www servers
-07:37PM <vapier> well the level of trust would be up to the user
-07:37PM <Koon> always time to do chain of trust things to replace that
-07:37PM <vapier> same as with gpg, how did you verify the key/person
-07:39PM <Koon> the chain of trust thing adds identification to the process, that's not very useful... people trust "solar" more than "Ned Ludd"
-07:39PM <agriffis> What about a hybrid solution, where the level of trust in a key is reported somehow to the user on request?  (i.e. this package has a chain of trust from the master key vs.
-          this package has no chain of trust, or however robbat2's solution works)
-07:39PM <Koon> we just need authentication
-07:39PM <agriffis> perhaps I'm just demonstrating my lack of knowledge on the topic.
-07:39PM <vapier> agriffis: gpg already tracks that
-07:40PM <agriffis> vapier: good, but it needs to be wrapped in a portage interface so emerge can report easily
-07:41PM <vapier> i gotta jet, time for doctors appt
-<solar> cya vapier 
-07:42PM <agriffis> btw, since I arrived late... who is chairing?
-07:42PM <seemant> solar is chair
-<solar> I am?
-07:43PM <agriffis> ha, strike that from the log, quick!
-07:43PM <SwifT> you are pointing out the agenda subjects :)
-<solar> sorry I just wanted to get this thing going today.
-07:43PM <SwifT> :)
-<solar> anyway I guess the formal meeting was over when agriffis added his votes in
-<solar> everything else remains brainstorming?
-07:44PM <Koon> yes
-07:44PM <Koon> we should require proper glepping of robbat2's solution
-<solar> ok then back to portage signing. 
-<solar> another blocker I see is the whole eclass+profiles 
-07:45PM <Koon> I thought that was taken care of.
-<solar> repoman has no support for those and probably wont for some time. But it's clear we will need a wrapper around commiting to those
--lilo(i=levin@freenode/staff/pdpc.levin)- [Server Notice] Hi all. Just a reminder: we're aiming to restart the server you're on, zelazny.freenode.net, this weekend. Please help us get it done
-                                          by disconnecting and reconnecting to chat.freenode.net at your first opportunity. Thanks in advance for your help, and thank you for using freenode!
-<solar> I'm not away that was taken care of by any tool
-<solar> what have you heard on the subject which makes you think that?
-07:46PM <Koon> maybe discussion on new eclasses a few months ago
-07:46PM <Koon> I don't remember
-07:47PM <agriffis> another thing I'd like to know about is interaction between signing and binary packages.  just wondering how/if that would work.
-07:48PM <SwifT> makes me think about disec
-<solar> we are going to have to come up with a detached method for signatures
-<solar> disec was the in ELF signatures?
-07:48PM <SwifT> yup
-<solar> if so that wont work. think shell scripts
-<solar> that entire idea was flawed. We picked it apart for two days in hardned
-07:49PM <SwifT> ah
-<solar> brb
-07:49PM <Koon> binary packages are tarballs... so I guess they could include signature info
-07:50PM <Koon> but that definitely needs some more work in design
-07:50PM <Koon> hence the "show me your GLEP" thing
-07:51PM * SwifT/#gentoo-council needs to go, catch my train 
-07:51PM <SwifT> sorry folks
-07:52PM <Koon> hm. we should definitely brainstorm some more
-07:52PM <Koon> but no need to do it in-session
-07:55PM <Koon> looks like the meeting is dead -- solar if you have the log you can cvs it... that will earn you your chairman turn :)
-<solar> I do not have a log
-07:56PM <Koon> me neither :)
-<solar> however my scrollback buffer does go back till last meeting
-<solar> I'll do it the hard copy+paste way
-07:57PM <tove> so why not start a tree signing project to gather all problems, questions, solutions, ideas. taking the discussion away from -dev or -core for some time
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060209-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060209-summary.txt
deleted file mode 100644
index ae683c55d8..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060209-summary.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Present:
-  azarah (Martin Schlemmer)
-  Koon (Thierry Carrez)
-  Swift (Sven Vermeulen)
-  agriffis (Aron Griffis)
-  seemant (Seemant Kulleen)
-  solar (Ned Ludd)
-  vapier (Mike Frysinger)
-
-Agenda:
- * GLEP 44 - Manifest2 format
-
-Outcome:
- * Council members were generally in agreement that GLEP 44 is a good idea, but
-   without genone present to answer questions, the council was unwilling to
-   approve or deny it.  Postponed to next meeting, with the expectation that
-   genone or a proxy will attend then.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060209.txt b/xml/htdocs/proj/en/council/meeting-logs/20060209.txt
deleted file mode 100644
index c17d3c281c..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060209.txt
+++ /dev/null
@@ -1,134 +0,0 @@
---- Log opened Thu Feb 09 13:55:27 2006
-14:04 <@Koon> ok, let's start
-14:05 <@Koon> yes
-14:05 -!- mode/#gentoo-council [+m] by Koon
-14:05 <@SwifT> Koon: I'm here
-14:05 <@SwifT> vapier: ^^
-14:05 -!- Halcyon [n=halcy0n@pdpc/supporter/active/Halcy0n-gentoo] has joined #gentoo-council
-14:07 <@solar> yes
-14:07 -!- az [n=ms@gentoo/developer/azarah] has joined #gentoo-council
-14:07 -!- mode/#gentoo-council [+o az] by ChanServ
-14:07 <@vapier> so all we've got is GLEP 44
-14:07 <@vapier> peeps have read it ?
-14:07 <@vapier> http://www.gentoo.org/proj/en/glep/glep-0044.html
-14:07 <@solar> genone is not here agan.
-14:07 <@Koon> vapier: there is also a clarification of wording for the proxy thing asked by ciaranm, we'll discuss it during Q&A
-14:08 <@vapier> no, genone is not here, but i think this glep is pretty straight forward
-14:08 <@Koon> I read it some time ago
-14:09 <@Koon> It wasn't opposed, I tend to vote yes, does anybody need some explanations from genone to approve it ?
-14:09 <@vapier> i'm all for it
-14:09 <@agriffis> I've read it and think it looks great.
-14:10 <@vapier> to extend the compatibly forever, we could just provide old style digests for the portage package
-14:10 <@vapier> then users would `emerge portage --nodeps` and they'd be fine
-14:10 <@vapier> but that's a helpful note, doesnt affect acceptability of the GLEP
-14:10 <@az> dont have an issue, but they dont mention how long the transition will be ?
-14:10 <@az> or i misread it
-14:11 <@Koon> "No timeframe for implementation is presented here as it is highly dependent on the completion of each step."
-14:11  * Koon writes this one down, could serve him well in the future
-14:12 <+g2boojum> az: When talking to the portage team they have said about a year if one wants to minimize user system breakages.  I'd actually prefer a "flag day", myself.
-14:12 <@Koon> az: "... a full conversion will take over a year to be completed ..."
-14:12  * agriffis is surprised to find himself in the credits
-14:12 <@az> well, like vapier said, could just keep the old stuff for portage around
-14:12  * agriffis takes all the credit
-14:13 <@vapier> seemant / SwifT ?
-14:13 <@seemant> I'm here sorry
-14:13 <@SwifT> I'm trying to think of something sensible to say that hasn' tbeen said or isn't in the GLEP, but all I can think of is "can't wait"
-14:13 <@seemant> yep, basically
-14:14 <@SwifT> also, I'm personally in favor of shortening the transition period (< 1 year)... big bang transition :) but that's something that'll be seen later when we're at it
-14:15 <@Koon> so... how do we solve this one
-14:16 <@Koon> it's OK, but transition time needs to e precised and we prefer it short ?
-14:16 <@az> guess that is outside our job
-14:16 <@Koon> last time we half-approved a GLEP there was some backslash :)
-14:16 <@solar> you make the author show up to these meetings vs trying toi figure this stuff out (perhaps incorrectly on our own)
-14:16 <@SwifT> no, it's okay and we're eagerly awaiting the evolution of the work
-14:16 <@az> could maybe just not that we would like it to be short and sweet
-14:16 <@az> note*
-14:16 <@vapier> does timeframe really matter
-14:17 <@vapier> GLEP 44: approved, cant wait to see it !
-14:17 <@vapier> ?
-14:17 <@SwifT> it isn't known yet how the transition period will be, that's something that'll be given later on
-14:17 <@solar> vapier: eh?
-14:17 <@vapier> solar: was asking, not telling
-14:18 <@SwifT> I don't think anyone is against :)
-14:18 <@Koon> I vote yes, don't mind the transition period
-14:18 <@solar> well I can say right now I have no intentions of voting in favor or against
-14:18 <@solar> not without the author being here. I have questions and comments
-14:19 <@vapier> that's fine
-14:19 <@vapier> new rule: for your GLEP to be approved, you must be present ?
-14:19 <@SwifT> it might not be easy for him to get to the meetings; I suppose contacting him through e-mail (probably through mailinglist) is the best
-14:19 <@Koon> or a proxy
-14:20 <@solar> or a proxy. Somebody really needs to be here on behalf of a given glep
-14:20 <@SwifT> err, if a GLEP isn't clear on all subjects, I think it should be covered on the mailinglist; I don't think presence of the author is required (not everyone can be here at 1900UTC)
-14:20 <@solar> AUXFILE, EBUILD, DISTFILE (minor detail but that is a waste of space)
-14:21 <@vapier> {A,E,D} ? :p
-14:21 <@solar> better imo
-14:21 <@vapier> along that line, everyone cool with putting this off for a month requesting someone field our questions ?
-14:22 <@vapier> solar: better for you to start a thread on the list after that with your questions/etc...
-14:22 <@Koon> we should probably have anticipated those...
-14:22 <@Koon> and solved them before the meeting. That's the whole point of putting the GLEP on -dev
-14:23 <@Koon> but I tend to agree that /now/ holding it off might be the only solution without the author here
-14:23 <@Koon> also I'm short in time so I tend to agree with any quick solution
-14:24 <@vapier> works for me
-14:24 <@vapier> anyone else ?
-14:24 <@solar> nod. the 1 year seems a bit extraneous. I like grants idea with a given flag day
-14:25 <@az> month maybe two after support is in, and keep old digest/manifest for only portage around
-14:25 <@az> and make a point that we should try to cover all q&a on -dev, and try to get the author/proxy here in case there is last minute stuff
-14:26 <@Koon> history note: that point was raised during -dev discussion, it's just the author choice to choose long transition rather than flagday
-14:27 <@Koon> so everyone agrees... SwifT  ?
-14:27 <@az> problem with long transitions is they get swept under the rug
-14:27 <@az> anyhow, so we postphone this? now to q&a ?
-14:27 <@SwifT> I'm a bit disappointed that it would be stalled; I think that the issues raised are point-of-view issues that depend on the person...
-14:28 <@SwifT> but I'm not against postponing it... just hoped that it would be approved
-14:28 <@Koon> seemant ?
-14:28 <@seemant> flag day is an idea I tend to prefer
-14:28 <@seemant> but it would *have* to be hugely publicised
-14:29 <@seemant> honestly, I think it's a great idea, and we (gentoo as a whole) should just go towards implementing it
-14:29 <@Koon> OK so, we agree with the GLEP but are not sure to agree with the transition period system, this point needs to be precised before the GLEP is fully approved
-14:29 <@seemant> we just set a day, spread that day, make a countdown or something, and just go
-14:30 <@seemant> Koon: I'd say we all approve of the glep, but just differ on the timelines for items 3, 4, and 5
-14:30 <@SwifT> the transition can be discussed/voted upon later on, when the manifest with backwards compatibility is in place
-14:30 <@solar> well my only two concerns at this point is the filetype specifier should be 1-3 chars. And that a 1-3 month time frame till completion. I'm not really in favor of having so many checksums (a limit of two would be nice).
-14:30 <@solar> 2.5 concerns
-14:31 <@Koon> basically, we really need to discuss those options with the author, maybe he has a good rationale for those choices, aznd we need to hear it before slashing
-14:32 <@Koon> anyone wants to add something before Q&A ?
-14:34 <@az> no
-14:35 <@Koon> ok, Q&A
-14:35 -!- mode/#gentoo-council [-m] by Koon
-14:35 <@Koon> ciaranm had the following question
-14:35 <@Koon>  approval on the exact wording "A proxy must not be an existing council member, and any single person may not be a proxy for more than one council member at any given meeting." for the changes discussed last month
-14:35 <@Koon> sounds ok to me
-14:36 <@SwifT> was what I had in mind back then, yes
-14:36  * ciaranm doesn't want to update the GLEP until he's sure that everyone is totally ok with the wording
-14:36 < ciaranm> there's enough iffy phrasing in the proxy stuff as it is :)
-14:38 < ciaranm> mmmm, guess i'll take that as a yes then
-14:38 <@Koon> that's two yes, in fact
-14:38 <@SwifT> overwhelming majority :)
-14:39  * ciaranm idly wonders who all is here
-14:39  * frilled|home raises a hand
-14:39 <@Koon> ciaranm: those are mostly bots, programmed in java and communicating in XML, that explains the lag
-14:39 < ciaranm> no bittorrent? :(
-14:40 <@Koon> bittorrent is only used to download the GLEP
-14:40 <@SwifT> no, it's SOAP, read by an articifial voice over the Skype network
-14:40 <@Koon> it's then fed to an expert system that makes up silly questions
-14:41 < ciaranm> ok, i have to go eat. feel free to prod me with any wording changes. otherwise i'm assuming silence means "sure, whatever"
-14:41 <@SwifT>  
-14:41 <@Koon> OK, anyone has an other question for the sleeping council members ?
-14:41 < frilled|home> SwifT: let me know if I can be of any help,ok?
-14:42 <@SwifT> frilled|home: mind mailing me? Just in case I need to contact you, it'be good to have tyour e-mail... or are you on the gentoo-pr@ mailinglist?
-14:42 <@az> although i guess this is mostly targetted at me, i missed the last discussion so dont see any use of making comments.
-14:42 < frilled|home> SwifT: no, but I am on #gentoo-security as much as I am only
-14:42 < frilled|home> online :D
-14:43 <@Koon> no more questions, let's call it a day.
-14:43 <@SwifT> frilled|home: okay, I'll try to remember your nickname then :)
-14:43 -!- Koon changed the topic of #gentoo-council to: Meeting was Feb 9 at 1900 UTC (1400 EST)
-14:43 <@agriffis> ciaranm: fwiw, I was distracted, but I think that wording change is fine.
-14:44 <@Koon> anyone with Power-LOG[tm] can post the thing to CVS ?
-14:44  * Koon is log-impaired
-14:44 <@agriffis> regarding the Manifest2 change, I'd personally prefer to see a graceful and gradual transition rather than a flag day, but that's mostly because sudden changes usually break one way or another, then it's a fire.
-14:44 <@agriffis> Koon: I'll post it to cvs, sure
-14:45 <@Koon> for the record, all members were somewhat-here
-14:45 <@agriffis> yep
-14:45 < frilled|home> Koon: nice wording :D
-14:45  * Koon goes back to RL
-14:46 -!- Koon [n=koon@gentoo/developer/Koon] has left #gentoo-council ["Leaving"]
-14:46 <@solar> agriffis: I can see that but I'd hope it personally not be dragged out past 3 months
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060309-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060309-summary.txt
deleted file mode 100644
index ef09167482..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060309-summary.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-Present:
-  Koon (Thierry Carrez)
-  Swift (Sven Vermeulen)
-  agriffis (Aron Griffis)
-  dsd_ (Daniel Drake)
-  cshields (Corey Shields)
-  vapier (Mike Frysinger)
-
-Agenda:
- * GLEP 44 - Manifest2 format after council recommended changes
- * GLEP 42 - Critical News Reporting
-
-Outcome:
- * Council members were generally in agreement that GLEP 44 is a good idea,
-and were happy with the changes that genone made to the document after the
-last meeting.  
-
- * Concil members decided that in order to vote on GLEP 42, an
-implementation plan needed to be submitted with the glep.  Generally, they
-agreed that it's a good idea, but only if it's actually implemented.
-Questions arose as to who will be doing the implementation work.
-
- * An interesting point of concern is what to do in the absence of an active
-maintainer, with regards to security flaws in packages. An absent maintainer
-in this sense is either one who is inattentive or one who is away/missing/gone
-for some reason.  Hopefully a future glep or thread will expand dsd's idea for
-opening up the development community. Has anyone seen where the LWP-UserAgent
-might have gone off to?
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060309.txt b/xml/htdocs/proj/en/council/meeting-logs/20060309.txt
deleted file mode 100644
index 67fb162e47..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060309.txt
+++ /dev/null
@@ -1,189 +0,0 @@
---- Log opened Thu Mar 09 18:22:56 2006
-18:22 -!- dsd_ [n=dsd@gentoo/developer/dsd] has joined #gentoo-council
-18:22 -!- Irssi: #gentoo-council: Total of 9 nicks [3 ops, 0 halfops, 0 voices, 6 normal]
-18:22 -!- Irssi: Join to #gentoo-council was synced in 1 secs
-18:23 -!- Halcyon [n=halcy0n@pdpc/supporter/active/Halcy0n-gentoo] has joined #gentoo-council
-18:32 -!- cshields [n=cshields@osuosl/staff/cshields] has joined #gentoo-council
-18:53 < dsd_> which gleps are voted on tonight?
-18:53 < dsd_> 42 and 44?
-18:55 <@Koon> tyhat's what I have
-18:55 <@Koon> but I didn't read all gentoo-dev so I might have missed some vote requests
-18:55 <@Koon> back in 10 minutes
-18:57 <@SwifT> damned, 42 has been improved since I last read it
-19:00 -!- vapier [i=UserBah@wh0rd.org] has joined #gentoo-council
-19:00 -!- mode/#gentoo-council [+o vapier] by ChanServ
-19:00 -!- Netsplit adams.freenode.net <-> irc.freenode.net quits: Lejban
-19:01 -!- Netsplit over, joins: Lejban
-19:02 -!- seemant [n=trinity@gentoo/developer/seemant] has joined #gentoo-council
-19:02 -!- mode/#gentoo-council [+o seemant] by ChanServ
-19:02 <@seemant> hi all, dsd_ is my proxy
-19:02 -!- mode/#gentoo-council [+o dsd_] by seemant
-19:02 -!- mode/#gentoo-council [-o seemant] by seemant
-19:03  * vapier touches seemant's proxy
-19:03 <@Koon> vapier: proxies are not toys
-19:04 -!- agriffis [n=agriffis@gentoo/developer/agriffis] has joined #gentoo-council
-19:04 -!- mode/#gentoo-council [+o agriffis] by ChanServ
-19:05 <@dsd_> abuse!
-19:06 < cshields> greetings all!  I'll be standing in for solar
-19:06 -!- mode/#gentoo-council [+o cshields] by Koon
-19:06 <@SwifT> 'evening both of you
-19:07 <@cshields> or morning..  ;)
-19:07 <@vapier> dsd_: it's only abuse if you didnt like it
-19:07 <@Koon> who wants to chair ? I may have to leave early so I prefer not to
-19:08 <@vapier> i may have to jet, work has meetings on me today
-19:08 <@vapier> but i think we only have the manifest2 glep today correct ?
-19:08 <@SwifT> and news thingie
-19:08 <@vapier> the news thing wasnt requested i thought
-19:08 <@Koon> well it all depends if we consider we should vote on glep 42 too
-19:08 -!- mode/#gentoo-council [+m] by Koon
-19:08 <@SwifT> if I can believe Koon and dsd
-19:09 <@dsd_> SwifT: dont listen to me
-19:09 <@vapier> lets do GLEP 44 first :P
-19:09 <@Koon> easy cake: yes
-19:09 <@SwifT> 1
-19:09 <@vapier> i think all our maybes and such were covered sufficiently on the list
-19:09 <@cshields> solar votes yes
-19:09 <@Koon> anyone covering up azarah's ass ?
-19:09 <@vapier> any last questions ? (and if you have one i kill you for not asking it on the dev list)
-19:10 <@SwifT> that's blackmail
-19:10 <@dsd_> i vote yes (on seemant's behalf)
-19:10 <@agriffis> yes to 42
-19:10 <@vapier> ok, i'll just poke you, i wont kill you :p
-19:10 <@Koon> agriffis: current itam is 44
-19:11 <@vapier> i'm for 42 as well
-19:11 <@agriffis> I meant 44, sorry
-19:11 <@vapier> adsflkajsdfl 44
-19:11  * vapier blames agriffis
-19:11 <@Koon> ok then we have a winner
-19:12 <@Koon> up to GLEP 42, wit the traditional question: should we really vote on it given it's not been properly submitted
-19:12 <@SwifT> oh well, no then
-19:12 <@Koon> I propose that we emit an opinion and raise any question we may have, and pompously vote on it next month
-19:13 <@cshields> solar touched on this in an email, but to me it seems to be missing an implementation plan.   If it is voted on (and approved) it may end up sitting for a while without any action.  We made a similar mistake with the webiste redesign vote long ago
-19:13 <@Koon> cshields: unfortunately we cannot really enforce implementation plan
-19:13 <@vapier> we can
-19:13 <@Koon> it needs someone to pick it up
-19:13 -!- Netsplit adams.freenode.net <-> irc.freenode.net quits: Lejban
-19:13 <@vapier> we dont approve it w/out an implementation plan :P
-19:13 -!- Netsplit over, joins: Lejban
-19:14 <@cshields> Koon: you don't need to -enforce- one..  but some kind of a plan would be nice  :)
-19:14 <@Koon> then we can emit a favorable opinion on the content but require some implementation details to accept it
-19:14 <@cshields> I could glep that we all get $100k/yr for doing gentoo, and it may sound good and have rationale behind it, but without a plan to implement it will probably never happen  :)
-19:14 <@Koon> I vote yes on that one
-19:14 <@SwifT> who knows
-19:14 <@vapier> details that the portage team is cool with ... but from genone's e-mails, seems they wont have much trouble with it
-19:15 -!- spb [n=spb@gentoo/developer/spb] has quit [Client Quit]
-19:15 -!- spb [n=spb@gentoo/developer/spb] has joined #gentoo-council
-19:15 <@vapier> has infra weighed in on it ?
-19:15 <@Koon> cshields ^
-19:16 <@cshields> vapier: most of us are in favor of the concept (cause we get bit in the ass when something changes drastically and we're not aware..)
-19:16 <@dsd_> does ciaran regard it as complete? there may be a reason it hasnt been properly submitted
-19:16 <@cshields> but, we aren't going to have to write the code behind it either  ;)
-19:16 <@agriffis> it looks like only goodness for infra, not much required on their end and lots of benefit.
-19:16 <@vapier> dsd_: he posted it as "final draft"
-19:16 <@Koon> dsd_: it's just a little late
-19:16 <@cshields> agriffis: exactly
-19:16 <@dsd_> k
-19:16 <@vapier> and he said "he'd like for it to come our way soon"
-19:17 <@cshields> so I guess my question is, was ciaranm's proposal such that he would do the work for it?
-19:17 <@agriffis> anyway, it should be enough for now to say that we're in favor but where is the implementation plan, who is going to do the work, etc?
-19:17 <@cshields> agreed
-19:17 <@dsd_> agreed
-19:18 <@Koon> yes, those precisions might raise interesting questions
-19:18 <@agriffis> this is looking like a nice short meeting.
-19:19 <@Koon> OK, any more comment on glep 42 ?
-19:19 <@Koon> or we can open up traditional Q&A
-19:19 <@vapier> i got nothin more, looks like the previous flame threads covered 42 well
-19:20 <@Koon> I've that concern about active maintainers falling below critical mass as far as security work is concerned, but I guess we can put that in Q&A
-19:20 <@Koon> ok, opening up
-19:20 -!- mode/#gentoo-council [-m] by Koon
-19:21 <@vapier> someone mentioned that the monthly cronjob e-mail i send out is too late
-19:21 <@vapier> i was thinking of a pre-pre-e-mail
-19:21 <@Koon> good idea
-19:21 <@vapier> to be sent out like the 25th of each month
-19:21 <@Koon> we could send it now :)
-19:21 <@SwifT> =)
-19:21 <@SwifT> only two weeks until the deadline :)
-19:22 <@vapier> 25th work ?
-19:22 <@SwifT> so something like "deadline is today"
-19:23 <@Koon> I'm a little concerned about the current state of our maintainers. I feel we fell below critical mass and now it takes too much time (from security PoV) to get fixes in. Someone proposed that a QA team with teeth could be called in that cases
-19:23 <@Koon> we used to have a 48 hours maximal turnout to get fixed ebuilds
-19:23 <@Koon> those days it's more like a week
-19:24 <@vapier> so if a maintainer fails to cover a security bug within 48 hours, the QA team is allowed to handle it ?
-19:24 <@Koon> add to that arch stableization work and low manpower in security... and we fall behind major distros
-19:24 <@Koon> I don't say that's a solution, I just want to know if you noticed the same problem
-19:25 <@SwifT> is it because we are losing maintainers or because our ebuild set is increasing?
-19:25 <@Koon> Our last solution, the hall of shame on #gentoo-dev, didn't solve anything :)
-19:25 <@Koon> it's because we are losing active maintainers
-19:25 <@Koon> (IMHO)
-19:25 <@agriffis> I don't mind the idea of letting a group handle security bugs if the maintainer isn't paying attention, but I don't like the phrase "QA team with teeth" at all.
-19:25 <@dsd_> fwiw, i've been thinking about the topic of opening the developer community recently, with the aim of increasing contribution flow. its a big thing to think about though
-19:25 <@vapier> nobody reads /topic in channels
-19:26 <@cshields> especially #-dev
-19:26 <@Koon> we used to have sufficient new blood to cover maintainers going stale
-19:26 <@cshields> the /topic is a novel there
-19:27 <@Koon> well, security can't force maintainers to do their homework... and with low manpower can't hunt them down everytime
-19:27 <@Koon> vapier: take the games herd for exmaple :P
-19:27 <@vapier> yeah, i have those labeled in my TODO e-mail box :P
-19:27 <@vapier> but i have a lot in that box
-19:28 <@SwifT> mine is symlinked to /dev/null
-19:28 <@Koon> we/I used to be sufficiently active to remind everyone passing by IRC to do their work... but not anymore
-19:28 < Halcyon> I didn't intend on QA to fix security issues.  I figured the security team would handle that portion of "QA".
-19:28 <@Koon> and some people just don't pass by IRC
-19:29 <@vapier> a weekly gentoo-dev e-mail reminder /
-19:29 <@Koon> tss
-19:29 < Halcyon> And you guys will have that proposal maybe by the next meeting to go over :)  (for the QA team)
-19:29 <@Koon> that's not something that will be solved today, just so that you know that we are slowly falling behind
-19:30 <@Koon> sometimes even mandriva releases advisories before us. (shame)
-19:30 <@vapier> ouch
-19:30 <@Koon> vapier: fedora legacy is still behind us though :)
-19:31 <@Koon> and Ubuntu's always first
-19:31 <@SwifT> :)
-19:31 <@Koon> what would I do if I was a millionaire
-19:31 <@SwifT> stop spending time with Gentoo? :)
-19:32 <@Koon> OK, any more rant/question ?
-19:32 <@Koon> Halcyon: about security team, we usually don't have portage commit rights
-19:32 <@agriffis> Koon: it would be good to get a little more raw data regarding the stuff you're bringing up.
-19:33 <@agriffis> Koon: rather than just a feeling, I mean numbers, averages, comparisons with other distros, typical blocking factors (again with numbers), etc.
-19:33 <@SwifT> I wxant my 100I want my $100k
-19:33 <@SwifT> err
-19:33 <@SwifT> stupid network
-19:34 <@cshields> SwifT: you'll have to glep that..
-19:34 <@Koon> agriffis: I have a script that extracts out-of-delay GLSAs for each month
-19:34 < Halcyon> Koon: hmm, then we might be able to work something out where the QA team could commit on your behalf, but we also don't have enough manpower to handle everything as well :)
-19:34 <@Koon> We used to be 85% intime, that fell down to 50% and I didn't ru nthe stats for last month yet
-19:34 < Halcyon> Koon: you publish these stats online somewhere?
-19:35 <@SwifT> Koon: what about a GWN request for interested parties? or a security tester team?
-19:35 <@Koon> the script also ranks the arches from most quick to slowest
-19:35 < Halcyon> Koon: I'd be interested to see that :)
-19:35 <@Koon> heh
-19:35  * Koon tries to find that script again
-19:36 <@cshields> I'd recommend using events like LWE to recruit people.  A lot of high-end users just don't realize that they too can contribute.
-19:36 <@cshields> vapier: you'll be there, right?  ^^
-19:37 < Halcyon> There will be a few of us :)
-19:37 <@agriffis> Koon: That's the kind of data I'm talking about.  Get that published somewhere (the data, not the script, nobody else is going to run it) and keep enhancing it to include more information, graphs over time, etc.
-19:37 <@Koon> I have to do some searches to find that script. Some perl that goes iver Bugzilla changelogs
-19:37 <@agriffis> Koon: I think that would be very interesting.
-19:37 <@Koon> agriffis: ok will do
-19:38 < Halcyon> Koon: I'd like to see if the x86 team helped with x86's response time at all.
-19:38 < Halcyon> I'm sure the arch teams would like to know how well they are responding.
-19:38 <@Koon> Halcyon: yes it did. x86 was usually not top-ranked, now it is
-19:39 <@cshields> gentlement, I have to run.  thanks for letting me sit in for solar
-19:39 <@vapier> i'll be at LWE
-19:39 <@vapier> i gotta jet as well
-19:39 <@vapier> poof
-19:39 -!- vapier [i=UserBah@wh0rd.org] has left #gentoo-council []
-19:40  * Koon just got that script again
-19:41 <@Koon> misses a few perl modules and should be ready to go
---- Log closed Thu Mar 09 19:42:25 2006
---- Log opened Thu Mar 09 19:42:57 2006
-19:42 -!- dsd_ [n=dsd@cpc1-with3-3-0-cust110.bagu.cable.ntl.com] has joined #gentoo-council
-19:42 -!- Irssi: #gentoo-council: Total of 13 nicks [5 ops, 0 halfops, 0 voices, 8 normal]
-19:43 -!- Irssi: Join to #gentoo-council was synced in 34 secs
-19:43 <@Koon> argh, where the fuck is LWP-UserAgent
-19:44 <@Koon> anyway I'll post more when I run those scripts
-19:44 <@Koon> gtg
-19:44 -!- agriffis [n=agriffis@gentoo/developer/agriffis] has left #gentoo-council []
-19:44 <@Koon> someone please post the log and summary
-19:45  * Koon does no logs
-19:45 <@Koon> I usually prefer to forget
-19:45 -!- Koon [n=koon@gentoo/developer/Koon] has quit ["*plop*"]
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060420-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060420-summary.txt
deleted file mode 100644
index fef0389192..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060420-summary.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-The agenda included Gentoo's participation in Google's Summer of Code
-and an update on portage gpg signing.  In the former case, Gentoo has
-applied to participate, and assuming we get one of the handful of
-remaining slots then gerrynjr will be Gentoo's "organization
-admininstrator" (with userrel's help) for the project.  In the latter
-case, council developement of a reasonable key policy has stalled, and
-they are soliciting GLEPs to help solve the problem.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060420.txt b/xml/htdocs/proj/en/council/meeting-logs/20060420.txt
deleted file mode 100644
index 18e250dcc4..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060420.txt
+++ /dev/null
@@ -1,155 +0,0 @@
-19:00 <@g2boojum> Thank you all for being here.  Today's agenda includes (1) Google's Summer of Code, (2) an update on portage gpg signing, and (3) the usual developer floor.  We'll start w/ the Summer of Code.  gerrynjrserver?
-19:00 -!- spb [n=spb@gentoo/developer/spb] has joined #gentoo-council
-19:00 -!- g2boojum changed the topic of #gentoo-council to: meeting at 1900UTC (proxies swift->fox2mike vapier->josejx az->uberlord||halcy0n agriffis->g2boojum) | Topic: Google SOC
-19:00 < gerrynjrserver> well, I'd like to propose that gentoo sign up to join google's summer of code
-19:01 < gerrynjrserver> if done, it would fall under the fairly new userrel subproject
-19:01 < gerrynjrserver> seems like it will be an excellent pr opportunity and would possibly allow us to get some fresh, energetic developers in
-19:02 < gerrynjrserver> I would definitely be willing to take on a lead position for this project
-19:02 -!- agriffis [n=agriffis@gentoo/developer/agriffis] has joined #gentoo-council
-19:02 -!- mode/#gentoo-council [+o agriffis] by ChanServ
-19:02 <@agriffis> hey g2boojum, I made it back in time (I think)
-19:02 <@Koon> g2boojum: impostor !
-19:02 <@agriffis> heh
-19:02  * agriffis just walked in
-19:02  * g2boojum continues to chair the meeting, but no longer votes.
-19:03 < gerrynjrserver> this would entail overviewing proposed projects, maintianing a page of ideas developers have proposed, as well as keeping a list of possible mentors
-19:03 <@agriffis> if you'd like, I can just duck back out :-)
-19:03 < gerrynjrserver> would also ensure student summer of coders get thier review mid way
-19:03 < gerrynjrserver> process shoould go this way
-19:03 < gerrynjrserver> -students should be familiar with gentoo
-19:03 <@Koon> gerrynjrserver: is there a point in catacting Google before we get a final list of projects ?
-19:03 <@Koon> contacting
-19:04 < gerrynjrserver> yes
-19:04 < gerrynjrserver> contact has actually already been made
-19:04 <@g2boojum> gerrynjrserver: You're willing to be Gentoo's "organization administrator", then? (http://code.google.com/soc/mentorfaq.html#2)
-19:04 < gerrynjrserver> g2boojum: indeed
-19:04 <@g2boojum> agriffis: No, please do stay!
-19:04 < gerrynjrserver> contact has been mde by the userrel project, as it was thought that if we wait, it would be too late
-19:04 < gerrynjrserver> and considering gentoo is shooting down most applications now, it was probably a wise decision
-19:05 < nattfodd> s/gentoo/google/
-19:05 < gerrynjrserver> (only 4 seats now remain, and we still do not yet know if we have been accepted)
-19:05 < gerrynjrserver> but, we have not yet received a "denial" notice as most other new signups have received
-19:05 < gerrynjrserver> nattfodd: thanks 8-)
-19:05 <@Koon> gerrynjrserver: OK. When should the final list of projects be sent ? May 1st ?
-19:06 < gerrynjrserver> yes
-19:06 < gerrynjrserver> the following week students will be allowed to submit thier applications as well as ideas
-19:06 < nattfodd> we also need a firm list of mentors by then
-19:06 < gerrynjrserver> nattfodd: yes
-19:07 <@g2boojum> Okay, any other questions from council members?
-19:08 <@Koon> gerrynjrserver: Like I said, I approve that project, but a look on the list of proposed projects would be nice, even if I trust you to remove the non-worthy ones
-19:08 < gerrynjrserver> Koon: of course
-19:08 < gerrynjrserver> i've jsut been notified that gentoo is still on the "maybe" list
-19:08 < gerrynjrserver> with two seats available
-19:09 < gerrynjrserver> so.. still nto shot down
-19:09 < gerrynjrserver> *not
-19:09 < gerrynjrserver> (thanks christel)
-19:09 <@g2boojum> Otherwise I'm going to suggest a vote on giving this an official "go-ahead".
-19:09 <@Koon> gerrynjrserver: They decide  based on the org and not the project if I understand correctly
-19:09 < gerrynjrserver> Koon: yes
-19:09 <@Koon> voting yes for the go-ahead
-19:09 < gerrynjrserver> i'd also request that a mailinglist be setup for this purpsoe
-19:10 < gerrynjrserver> if we are accepted 8-)
-19:10 <@solar> that wont be a problem. just file an -infra bug
-19:10 < gerrynjrserver> will do
-19:11 <@g2boojum> Is anybody actually opposed?
-19:11 <@agriffis> sounds okay to me
-19:11 -!- Irssi: #gentoo-council: Total of 13 nicks [7 ops, 0 halfops, 0 voices, 6 normal]
-19:11 <@JoseJX> I think it's a good idea to try to be involved.
-19:11 <@Koon> and also a good trhing that someone stepped up to organize everything
-19:12 <@g2boojum> fox2mike, seemant?
-19:12 <@Koon> good ideas are common, good ideas with people to support them is better
-19:12 < gerrynjrserver> Koon: thanks for the compliment 8-)
-19:14 <@solar> just try todo it right and not get us rejected from future SoC events for failing to follow up properly this summer. try accept ideas that are realistic and benefit *linux* vs just say gentoo.
-19:14 < gerrynjrserver> solar: I will try
-19:14 <@seemant> I'm all for it,
-19:14 <@seemant> but yes @ solar's caveats
-19:15 <@g2boojum> Okay, that's a strong majority.  Moving on to the next item, gpg signing in portage.  Koon?
-19:15 <@Koon> gerrynjrserver: ideally, a backup organizer would be good, in case Real Life [tm] sucks you away
-19:15 < gerrynjrserver> Koon: i've got christel 8-)
-19:16 < gerrynjrserver> as a co-lead
-19:16 < nattfodd> and there's also bonsaikitten_ and me ready to help wherever needed
-19:16 < gerrynjrserver> nattfodd: nod
-19:16 <@Koon> We were supposed to do regular updates on progress on the portage tree signing functionality
-19:16 <@Koon> There is not much progress to report on. It's a good idea but it lacks someone to push it
-19:17 <@solar> status on it as far as I understand is still at a stalled process. The method of trust itself is not being solved
-19:17 <@Koon> We @security still receive new bugs on that problem
-19:17 <@Koon> solar: we are still waiting on key policy and web of trust
-19:18 <@fox2mike> hey
-19:18 <@g2boojum> Koon: I thought the council was drafting the key policy and web-of-trust.
-19:18 <@fox2mike> sorry, I was fiddling with NetworkManager :|
-19:18 <@Koon> I would go back to the simple-but-better-than-nothing one, since robbat2 didn't follow up on his proposal
-19:18 <@fox2mike> g2boojum: here now, representing Swift
-19:18 <@g2boojum> fox2mike: Thanks, good to have you.
-19:19 <@Koon> The simple-but-better-than-nothing was discussed in a previous managers meeting from before the council time
-19:20 <@fox2mike> g2boojum: and I'm for the SoC thingy (if I'm allowed to express opinion on Swift's behalf) :)
-19:20 <@Koon> master key distributed with media and downloadable from the web used to authenticate the dev keyring
-19:20 <@g2boojum> fox2mike: Absolutely.  Thanks.
-19:20 <@Koon> no need to enter complicated mutual signing if we can't even do that one
-19:21 <@Koon> and dev keyring maintained by devrel
-19:22 <@g2boojum> Anybody else have anything to add on signing?
-19:22 <@Koon> I just can't see any success here without someone stepping up to lead that part
-19:22 <@Koon> unfortunately I already have trouble in doing my current job so I won't do it
-19:23 <@g2boojum> Koon: Someone on the council, or just someone in general?
-19:23 <@seemant> wouldn't it be ideal for a security team member to take the lead on it?
-19:23 <@Koon> I'd say someone in general, with bones to take the usual -dev discussions there are when we discuss signing
-19:24 <@Koon> seemant: there isn't much availability in the sec team, same as me
-19:24 < nattfodd> what would it imply?
-19:24 <@Koon> Even if recitment is in progress with a few promising peeps
-19:24 <@Koon> recruitment
-19:25 <@seemant> Koon: and is there remaining development needed on the portage side of things?
-19:25 <@seemant> or at this point is it just choosing a system and implementing a policy?
-19:25 <@Koon> nattfodd: do proper GLEPs and take the heat from gentoo-dev (saying do your own GLEP and have the council choose rather than trying to please everyone)
-19:25 <@seemant> oh
-19:25 <@solar> yes. eclasses are not signed. repoman still allows unsigned commits. and the entire portage tree is not signed
-19:26 <@solar> now if we are using a single key. then it sounds like devs should not have to worry about signing at all. and it's all done from the cvs commit hooks
-19:26 <@g2boojum> seemant: The portage folks are waiting on a policy to finish implementation.  There's a framework in place, though.
-19:27 <@Koon> seemant: On that subject there are as much possibilities and proposals as there are people subscribed on -dev. And proposals are usually non-compatible. But telling people to formalize it in GLEP usually results in 0 GLEPs
-19:27 <@JoseJX> How many devs are signing now?
-19:27 < nattfodd> Koon: I might be interested in doing that
-19:27 < nattfodd> just need to go through those -dev discussions
-19:27 <@solar> 60% of the tree is signed afaik
-19:28 <@Koon> solar: we would still use dev keys, the master key would just authenticate the dev keyring, which would be downloaded with portage
-19:28 <@Koon> that was the plan back then, and I still have to see a better and simpler proposal
-19:29 <@Koon> emerge --sync would verify integrity of the dev keyring as part of the sync process
-19:29 <@Koon> using a trusted master key seeded by install media / web download
-19:29 <@Koon> you can even update the master key that way
-19:30 <@Koon> nattfodd: you should also look back at those old managers meetings logs
-19:30 <@Koon> where the thing was sorted out after the last -dev flamefest on the subject
-19:31 < nattfodd> Koon: will do
-19:31 <@Koon> back then the problem was "how do we maintain the keyring" and LDAP fud
-19:31 <@seemant> nattfodd: do we assume you're taking this on?
-19:31 <@g2boojum> Okay, then that discussion can move to the mailing list.  Open floor for devs (not that it wasn't already).
-19:32 <@Koon> seemant: he will at least consider the option of taking this on :)
-19:32 -!- g2boojum changed the topic of #gentoo-council to: meeting at 1900UTC (proxies swift->fox2mike vapier->josejx az->uberlord||halcy0n agriffis->g2boojum) | Topic: Signing drifing into an open floor.
-19:32 < nattfodd> seemant: not yet, I have no background on this topic so need to check first that I *can* do it
-19:32 < nattfodd> but I'll try to
-19:34 <@Koon> nattfodd: if you need some details feel free to send an email my way
-19:34 <@Koon> No more questions ?
-19:35 < nattfodd> Koon: ok, I'll certainly do that
-19:35 <@solar> I have no open questions and I wish you guys good luck getting gentoo-SoC off the ground.
-19:36 <@g2boojum> Any other topics?
-19:36 < christel> sorry, i was er, doing soc stuff for one of my other projects, yes, i believe its a good idea to go for it (lots of free pr and all that) and i'm afraid that due to it being 4 places left at time of applying and things occsionally taking a while around here i er, took a seemant advice and went a backway :)
-19:36 <@fox2mike> any update on anoncvs/svn? Last I heard it was ready?
-19:36 <@Koon> nattfodd: it's mostly a job of coordinating a lot of people : devrel for the keyring and key policy (expiration, length...), portage guys to improve integration etc
-19:36 <@Koon> also the releng team to include master key in...
-19:36 <@g2boojum> fox2mike: ask infra?
-19:37 <@Koon> sounds a little like "Mission: Impossible" so good luck, Jim
-19:37 < christel> as for SoC status, they are hoping to let us know if accepted or declined by monday :)
-19:37 <@fox2mike> g2boojum: been doing that for months now
-19:38 < tove> i am still curious if there will be a trustees election this year. maybe one of the trustees here knows?
-19:38 <@Koon> There will be a council election for sure... we were talking of using the same timeframe as last year, voting over July-August
-19:38  * solar votes for everybody that's already a trustee to remain one
-19:38 <@g2boojum> tove: Wrong forum, but yes, there will.  I'll send out an e-mail to -nfp this weekend.
-19:39 < tove> g2boojum: why should this be the wrong forum?
-19:39 <@Koon> because we don't touch trstee stuff, it's slimy
-19:39 <@g2boojum> tove: Because the Gentoo Council and the Gentoo Foundation are completely separate entities.
-19:40 <@seemant> tove: trustees and council have different areas of responsibility -- as such this meeting is a council (development) meeting, rather than a foundation one
-19:40  * Koon disappears
-19:41 <@g2boojum> Anything else?
-19:41 <@g2boojum> Going...
-19:41 -!- tove [n=tove@p54A61CF9.dip0.t-ipconnect.de] has quit ["leaving"]
-19:41 <@g2boojum> Going...
-19:41 <@seemant> Gone
-19:41 <@solar> thanks g2boojum and others
-19:41 <@g2boojum> Meeting adjourned.  Thanks for coming.
---- Log closed Thu Apr 20 19:42:09 2006
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060511-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060511-summary.txt
deleted file mode 100644
index 93932fd9ec..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060511-summary.txt
+++ /dev/null
@@ -1,6 +0,0 @@
-In today's meeting, the QA-team GLEP (48) was brought into the field. 
-The GLEP discusses the role of the QA team and its powers and was accepted
-by the gentoo-dev participants with little to no objections. The council 
-therefore had only a few questions (can a single QA member act - yes, does
-it only work on the tree or on documentation too - tree currently) and 
-accepted the GLEP for execution by 5 votes and 1 abstained.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060511.txt b/xml/htdocs/proj/en/council/meeting-logs/20060511.txt
deleted file mode 100644
index aa38482d72..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060511.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-19:14 <@SwifT> shall we start the meeting, or adjourn it till next thursday?
-19:16 <@seemant> spanky's on his way
-19:16 <@seemant> finally got him
-19:18 <@seemant> agriffis goes straight to voicemail
-19:18 <@seemant> that makes what? 4 of us when spanky gets in
-19:18 <@seemant> wait, solar's here too
-19:18 <@seemant> so 5
-19:22 <@SwifT> anyone mind me asking already something about the QA-glep?
-19:23 < Halcy0n> That's why I was sticking around.  I have to leave soon to go home, so ask me now :P
-19:23 <@SwifT> it's about some red tape; "the qa team" can, if the maintainer doesn't reply soon, take action... what is "the qa team"? any member or a set of members?
-19:24 < Halcy0n> Any member
-19:24 < Halcy0n> And to protect against any one person from doing something stupid, there is the additional clause about disagreements within the team.
-19:24 <@SwifT> is the qa team just about the packages or does it also work on project sites, documentation and the like?
-19:25 < Halcy0n> The team's primary concern (currently) is the tree.  That could always change later on, but right now, no.
-19:26 <@SwifT> will someone of the team ever fill out the qa project site so that it contains a description, goals ? :)
-19:26 < Halcy0n> Well, the GLEP is basically the description :)  I hope to get the devmanual up there somehow soon as well.
-19:28 -!- vapier [i=UserBah@wh0rd.org] has joined #gentoo-council
-19:28 -!- mode/#gentoo-council [+o vapier] by ChanServ
-19:28 -!- agriffis [n=agriffis@gentoo/developer/agriffis] has joined #gentoo-council
-19:28 -!- mode/#gentoo-council [+o agriffis] by ChanServ
-19:28 < Halcy0n> And our subprojects are probably the things that will have goals.  I'm not sure overall what QA would have as a goal besides to "improve stuff" :)
-19:29 <@agriffis> hey, you all arrived early!
-19:29 <@SwifT> glep looks fine by me otherwise; especially since it is hard to interprete it the "I will own you all"-way. Good timelines/guidelines and putting less 
-               easy decisions somewhere higher
-19:30 <@vapier> we're discussing the QA stuff i assume
-19:30 <@SwifT> I was just asking some questions like "tree or docs/site as well" (tree atm) and "the qa team can do stuff -> team is any member"
-19:33 <@SwifT> anyone else having questions about the QA-glep?
-19:34 <@solar> I have no objections to g48.. I'd maybe reword s/look out for the best interests of all developers, as well as our users/look out for the best interest 
-               of the tree/
-19:34 <@solar> but thats not a big deal
-19:36 <@vapier> i think at this point, if the QA team gets out of hand we can reel them in quickly
-19:36 <@az> seems fine to me .. just wondering why if the QA team and dev do not agree, it is changed at all before the council meeting
-19:36 <@az> just seems counter productive if the council is going to go the dev's way
-19:37 <@SwifT> if its serious breakage, I'm sure no-one else (except the maintainer) would disagree
-19:37 <@SwifT> (that it is changed up front)
-19:37 <@az> i dont think it will reach the council if it was serious breakage
-19:37 <@SwifT> :)
-19:37 <@solar> note. we empowered the QA team todo these very things some time ago. One of our first council meetings if I recall.
-19:38 <@seemant> in principle I have no problems with the glep at all -- I hope that it is implemented well and does in fact improve QA
-19:38 <@seemant> solar: yeah, except we had no QA team back then
-19:38 <@solar> we had people on the qa alias. We have always been fixing things that we saw fit
-19:39 <@vapier> we had no team
-19:39 <@solar> but nod.. Nothing offical before
-19:39 <@seemant> yeah we had people on the alias
-19:39 <@vapier> being on an alias a team does not make
-19:39 <@seemant> yep
-19:39 <@solar> it's still the same people
-19:39 <@solar> so really nothings changed :p
-19:39 <@seemant> solar: not quite -- I would Halcy0n has gone in and galvanised a team together
-19:39 < Halcy0n> solar: also, not everyone on the alias is listed as a team member.
-19:39 <@seemant> solar: he's basically taken the reins -- nobody actyually did that before
-19:39 <@solar> seemant: yeah I know. I'm on it
-19:39 <@seemant> and I can not spell
-19:40 <@SwifT> perhaps the authority of the team lead (for adding additional members) could be moved to a team decision?
-19:42 < Halcy0n> SwifT: as I saw it, the team picks the lead, so instead of making it an entire process, I figured they could just trust who they chose :)
-19:43 <@SwifT> just proposing... it looks like something some people might want to counter in the glep
-19:44 <@SwifT> but I wouldn't mind; after all, in larger environments it is too the manager that gets the decision
-19:44 <@SwifT> seemant: note that I can't make well-formed English sentences
-19:45 <@vapier> Halcy0n: so was everything on the mailing list that devs brought up resolved to satisfaction ?  seems like the last thread went well
-19:46 < Halcy0n> vapier: as far as I'm aware, yes.  THe last thread actually stayed on topic, so I was happy :)
-19:48 <@seemant> well, then I vote to approve the glep
-19:49 <@SwifT> i'm in favor
-19:50 <@agriffis> Am I able to abstain?  If not, then I'll vote in favor, but I have to admit I'm just going with teh flow.  I haven't kept up with the recent 
-                  discussion around this GLEP.
-19:51 <@agriffis> (I mean that I haven't read the ML lately)  :-|
-19:52 <@SwifT> sure
-19:53 <@solar> is this the vote?
-19:53 <@SwifT> well yes, yes is it
-19:53 <@solar> yes
-19:55 < Halcy0n> Well, since you guys are done asking me question, I have to run.  Thanks :)
-19:55 <@SwifT> thanks for being here 
-19:55 <@az> yes
-19:55 <@az> and if nothing else, im off ... ?
-19:56 <@SwifT> unclosed foot-wall
-19:57 <@SwifT> no other questions?
-19:57 <@solar> I have no questions.
-19:58 <@SwifT> me neither
-19:58 <@solar> thanks for taking the time to establish that glep to make things official Halcy0n
-20:00 <@SwifT> I'll put the logs online and mail -core, okay?
-20:00 <@solar> who was the chair ?
-20:00 <@solar> great thanks swift
-20:00 <@SwifT> no-one, who needs one anyway when we have SEATS !!
-20:00 <@SwifT> muhahahaha
-20:00  * SwifT needs a coffee
-20:13 <@SwifT> hey wait, vapier, you didn't vote yet :p
-20:15 <@vapier> i said yes
-20:15 <@vapier> in my head
-20:15 <@SwifT> ah, that was that voice I heard
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060615-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060615-summary.txt
deleted file mode 100644
index 6fcfa4f8bb..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060615-summary.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-- GLEP49/GLEP50/Alternate package managers:
-both GLEP49 and GLEP50 are inappropriate solutions.  the new proto-tree idea
-spawned by spb on the gentoo-dev mailing list looks like the correct path to
-move forward, so he will be doing the footwork and ironing out the details 
-with the portage team.
-
-- sunrise status:
-one of the basic ideas of sunrise (opening up the dev process to newcomers) is 
-wholeheartedly supported by the council.  however, the current implementation 
-details are found to be lacking and the community concern is much too great 
-to ignore.  so the project will stay suspended indefinitely until all such 
-concerns can be fully addressed.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060615.txt b/xml/htdocs/proj/en/council/meeting-logs/20060615.txt
deleted file mode 100644
index f56ccc51e5..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060615.txt
+++ /dev/null
@@ -1,550 +0,0 @@
-20:33:16 -!- brix [n=brix@gentoo/developer/brix] has joined #gentoo-council
-20:33:16 -!- Topic for #gentoo-council: http://www.gentoo.org/proj/en/council | June 15th 1900 UTC - Alternative Gentoo package managers and Sunrise discussions.
-20:33:16 -!- Topic set by solar [] [Thu Jun 15 17:40:20 2006]
-20:33:16 [Users #gentoo-council]
-20:33:16 [@Koon    ] [ AllanonJL|W ] [ e-Hernick   ] [ hparker ] [ nattfodd] [ Stuart   ] 
-20:33:16 [@seemant ] [ Arek        ] [ fox2mike    ] [ hydrogen] [ Peper   ] [ tcort    ] 
-20:33:16 [@solar   ] [ Blackb|rd   ] [ frilled     ] [ jokey   ] [ petenj  ] [ tomaw    ] 
-20:33:16 [@SwifT   ] [ bonsaikitten] [ frilled|home] [ marienz ] [ pioto   ] [ tove     ] 
-20:33:16 [@vapier  ] [ brix        ] [ genone      ] [ matje   ] [ Ramereth] [ zmedico  ] 
-20:33:16 [+g2boojum] [ christel    ] [ genstef     ] [ mpagano ] [ rumen   ] [ |mpagano|] 
-20:33:16 -!- Irssi: #gentoo-council: Total of 36 nicks [5 ops, 0 halfops, 1 voices, 30 normal]
-20:33:16 -!- Channel #gentoo-council created Sun Mar  5 00:07:56 2006
-20:33:17 -!- Irssi: Join to #gentoo-council was synced in 1 secs
-20:33:20 < nattfodd> being an erasmus student helps a lot
-20:33:55 < bonsaikitten> nattfodd, being a foreigner in every individual part of europe does not help
-20:34:06 < Blackb|rd> In a related note, Brits are plain crazy, like any isand folk. Go look at the Japanese! Ther must be something to it.
-20:34:18 < Blackb|rd> (plus: my typing sucks)
-20:34:59 < matje> lol
-20:35:12 < Stuart> heh
-20:35:22 < tomaw> Hey!
-20:35:29 < matje> well, I was there a few months ago
-20:35:31 < nattfodd> Blackb|rd: icelandic people look pretty sane
-20:35:35 < nattfodd> or maybe not
-20:35:40 < matje> been a while since I actually had to go to the bank to change money :)
-20:35:45 < Blackb|rd> nattfodd: they're clearly odd, still.
-20:35:57 < nattfodd> yeah, they use 11th century swedish
-20:36:11 < bonsaikitten> Blackb|rd, yeah, they consider to be 20C "very hot"
-20:36:19  * bonsaikitten inverts word order
-20:36:19 < nattfodd> bonsaikitten: it *is* very hot
-20:36:30 < bonsaikitten> nattfodd, 25C right now and it's just ok
-20:36:42 < matje> it was 34 here 2 days ago :)
-20:36:56  * nattfodd suspects about 20/22C and I find it really hot
-20:37:05 < Blackb|rd> $ weather.py EDLN|grep Temp
-20:37:06 < Blackb|rd> Temperature: 16.0 C / 60.0 F
-20:37:14 < Blackb|rd> And it's supposed to be summer 'round here.
-20:37:40 < nattfodd> 16C is nice summer temperature
-20:37:49 < nattfodd> where are you?
-20:38:05 < Blackb|rd> nattfodd: NW Germany
-20:38:24 < matje> 16C is a nice winter temperature!
-20:38:35 < matje> or spring/fall
-20:38:44 < matje> but it's just plain cold for the summer :p
-20:38:48 < bonsaikitten> hehe
-20:38:57 < Blackb|rd> nattfodd: http://maps.google.com/maps?t=k&hl=en&ie=UTF8&ll=51.177083,6.46378&spn=0.001544,0.003304&om=1
-20:39:03 < bonsaikitten> 35C is perfect, you don't need to generate heat then
-20:39:10 < matje> lol
-20:39:16 < bonsaikitten> reptile ...
-20:39:33 < nattfodd> actually 19C
-20:39:34 < matje> as long as the air isn't too moist and there is a breeze, 35 isn't too bad :)
-20:39:42  * nattfodd will maybe consider going outside
-20:39:42 < Blackb|rd> bonsaikitten: if the air is dry enough, that's pretty tolerable.
-20:40:20 < bonsaikitten> heck, 40C is tolerable at 10% humidity
-20:40:33 < bonsaikitten> totally kills my voice, but makess me feel wonderful
-20:40:49 < matje> :)
-20:41:05 < Blackb|rd> bonsaikitten: helium makes nice voices, too ;)
-20:41:23 < matje> lol
-20:41:49 < bonsaikitten> you should use a helium/oxygen mix
-20:41:56 < bonsaikitten> pure helium is the best way to die
-20:42:22 < Blackb|rd> bonsaikitten: depends on the amount you inhale
-20:42:23 <@SwifT> pure oxygen isn't bad either
-20:42:54 < matje> you can always start drinking pure water ;)
-20:43:04 <@SwifT> that's kinky
-20:43:06 < Blackb|rd> fsck. how I "love" pager messages for failing software that's so garbled I barely know which machien is falinig, even less what is wrong with it.
-20:43:11 < bonsaikitten> with pure non-reactive gas you just fall asleep, no averse reaction at all
-20:44:55 <@SwifT> you can always try to inhale vacuüm... if your lungs are strong enoug
-20:45:04 < bonsaikitten> nah, that is evil
-20:45:06 < matje> lol
-20:45:17 < matje> you don't do that yet? :)
-20:45:18 < bonsaikitten> boiling blood in your lungs, slowly drowning you ...
-20:46:02 < bonsaikitten> I guess massive deceleration (sustained >100G) is also an option
-20:46:30 <@SwifT> isn't that something for the roller coaster parks?
-20:46:49 < bonsaikitten> they are limited to 2,5G with rare exceptions at 4G
-20:47:09 <@SwifT> pussies
-20:48:49 -!- wolf31o2|work [n=wolf31o2@gentoo/developer/wolf31o2] has joined #gentoo-council
-20:48:49 -!- kloeri [n=kloeri@gentoo/developer/kloeri] has joined #gentoo-council
-20:49:23 <@SwifT> people are dripping in
-20:49:47  * matje mobs up
-20:49:50 < bonsaikitten> one drop at a time ... that'll take some time :-)
-20:50:01 < matje> or is it mops?
-20:50:14 < marienz> well, a "mob" is probably not what you meant
-20:50:25 < bonsaikitten> marienz, unless it's dripping in?
-20:50:30 <@SwifT> a "murder" perhaps?
-20:50:30 < matje> :)
-20:51:05 < marienz> SwifT: are you suggesting matje should murder the new people coming in?
-20:51:27 <@SwifT> that'd be a nice way of getting my attention
-20:51:42  * matje takes out his shotgung
-20:51:47 < matje> -g
-20:52:07 < bonsaikitten> what is a shotung? ;-)
-20:52:18 < matje> HEADSHOT!
-20:52:21 -!- CHTEKK [n=chtekk@gentoo/developer/chtekk] has joined #gentoo-council
-20:52:24 < matje> one less pussy :p
-20:52:39 -!- Calchan [n=Calchan@84.7.178.12] has joined #gentoo-council
-20:52:41 <@SwifT> the more you kill, the more drop by apparently
-20:52:45 < matje> MULTIKILL!
-20:52:53  * bonsaikitten grabs the GAU-8/A
-20:52:59 < bonsaikitten> oh really?
-20:53:09 <@SwifT> if you say "monsterkill", you're going to leave on my request
-20:53:39 < matje> lol
-20:53:48 <@vapier> is DOMINATING safe then ?
-20:53:51 < matje> RAMPAGE!
-20:53:53 < matje> :)
-20:53:53 <@SwifT> =)
-20:54:09 < Stuart> FLAWLESS VICTORY ? :)
-20:54:09 <@SwifT> good lord, we're full of ctrl+alt+del'ers here
-20:54:18 < bonsaikitten> Fatality!
-20:54:20 < matje> lol
-20:54:36 < matje> why does playing UT make me a ctrl+alt+del'er?
-20:54:42 < matje> it runs on linux you know, natively :p
-20:54:50 <@SwifT> actually I was refering to the comic
-20:54:53 <@solar> do we have a chair for this meeting today?
-20:54:56 <@SwifT> http://www.ctrlaltdel-online.com/
-20:54:57 < matje> comic ?
-20:55:02 <@SwifT> has anice linux character in it too
-20:55:15 -!- kojiro [n=kojiro@gentoo/user/kojiro] has joined #gentoo-council
-20:55:16 <@SwifT> doesn't play any games though
-20:55:18 < matje> never heard of it :)
-20:55:59 <@vapier> those guys are quake fans anyways
-20:57:04 <@SwifT> pfft, quakes are overrated
-20:57:27 <@vapier> your mom is overrated
-20:57:32 <@Koon> crowd attending today, makes us feel useful for once
-20:58:00 < Peper> according to my atom clock: 2 min remaining
-20:58:07 <@SwifT> vapier: she told the same about the size of your...
-20:58:15 < Ramereth> Koon: you're still useless :)
-20:58:19 <@SwifT> brains
-20:58:27 < Blackb|rd> the crowd is just here to see the bashing-in of heads around the two major topics :)
-20:58:34 <@Koon> Ramereth: I know. That's why I'm on the way out
-20:58:51 < brix> evening all
-20:58:57 <@Koon> bricks
-20:58:58 < Stuart> lo brix
-20:59:00 < jokey> evening brix
-20:59:06 < brix> how long does Council meetings usually take?
-20:59:12 <@Koon> too long, why ?
-20:59:14 < Arek> Evening, brix.
-20:59:24 <@Koon> theorically we shouldn't take more than an hour
-20:59:25 < brix> Koon: I've got an exam to study for 
-20:59:36 <@Koon> but for exceptionally boring discussions we can last longer
-20:59:43 < brix> ok
-20:59:53  * solar has a feeling today might just be one of those days.
-21:00:00 < Peper> 19:00 UTC !
-21:00:03 <@SwifT> why do I sudden feel a chill?
-21:00:14 <@solar> cuz I'm cold like ice
-21:00:27 -!- mode/#gentoo-council [+m] by Koon
-21:00:32 <@Koon> About time to start
-21:00:39 <@Koon> who is not there ?
-21:01:01 <@SwifT> any absentees raise your hands
-21:01:06 <@Koon> az
-21:01:27 <@Koon> and agriffis
-21:01:29 <@vapier> i /invited him but he's AFK atm
-21:01:39 -!- spb- [n=me@gentoo/developer/spb] has joined #gentoo-council
-21:01:39 -!- Kugelfang [n=kugelfan@gentoo/developer/Kugelfang] has joined #gentoo-council
-21:01:58 <@vapier> i dont have agriffis' # or i'd call him
-21:02:01 <@vapier> maybe seemant does
-21:02:09 -!- dostrow [n=dostrow@gentoo/developer/dostrow] has joined #gentoo-council
-21:02:14 <@Koon> seemant: are you really with us ?
-21:02:15 -!- dsd_ [n=dsd@gentoo/developer/dsd] has joined #gentoo-council
-21:02:17 -!- Ticho [i=ticho@gentoo/developer/ticho] has joined #gentoo-council
-21:02:24 <@seemant> I am
-21:02:27 <@seemant> sorry
-21:02:33 <@Koon> make a bad joke to prove you are you
-21:02:34 <@seemant> had a thing at my desk but it's done now
-21:02:43 <@seemant> ah shit, ok, let me think
-21:02:58 <@solar> thats good enough.
-21:02:59 -!- Maedhros [n=jc@gentoo/developer/Maedhros] has joined #gentoo-council
-21:03:00 <@seemant> I'm not quite so around any more
-21:03:27 <@vapier> seemant: have you agriffis' # ?
-21:03:28 <@Koon> solar : you push agenda items since you compiled the agenda list ?
-21:03:43 <@seemant> vapier: yes but it's just his house # -- he doesn't have a cell
-21:03:50 <@vapier> k
-21:03:53 <+g2boojum> seemant: He often works from home
-21:04:10 <@seemant> I'm calling
-21:04:19 -!- josip [n=josip@unaffiliated/josip] has joined #gentoo-council
-21:04:49 <@solar> First on the list is Alternative Gentoo Pkg Mgrs. First thing requested to the council was by Halcy0n which is no longer with us.
-21:05:23 <@solar> Later GLEP-49 was proposed and then GLEP-50
-21:05:33 -!- drac [i=drac@gentoo/contributor/drac] has joined #gentoo-council
-21:05:34 <@Koon> but not in time, right
-21:05:43 <@solar> They all pretty much conflict with each other
-21:05:48 <@SwifT> there's still much going on about that subject
-21:05:57 <@SwifT> like the portage (err, tree) definition document
-21:06:09 <@solar> Koon: we are only having discussions today. No votes afaik.
-21:06:12 <@Koon> ok so we should just discuss the thing to give broad inclinations and directions
-21:06:18 <@vapier> i find both GLEPs lacking, one being way too much, the other not being much of anything
-21:06:31 -!- beandog [n=sdibb@gentoo/developer/beandog] has joined #gentoo-council
-21:06:45 <@vapier> i think the best solution to the issue proposed so far is the thread spb just started about the proto-tree
-21:06:51 <@vapier> and everyone is on board with that
-21:07:14 <@SwifT> see, things are falling in place :)
-21:07:52 <@Koon> so that's the thread I should read
-21:08:24 <@vapier> Koon: yes, i spent last nite reading all the threads ... the last three threads should be enough imo
-21:08:25 <@solar> http://www.gentoo.org/proj/en/glep/glep-0049.html http://www.gentoo.org/proj/en/glep/glep-0050.html are the two gleps
-21:08:26 <@SwifT> reading them all requires to take a break from real work :p
-21:08:42 <@vapier> the GLEP 49 by pauldv, g2boojum's half GLEP, and the latest proto-tree thread
-21:09:00 -!- Mr_Bones_ [n=nobody@gentoo/developer/mr-bones] has joined #gentoo-council
-21:09:05 -!- araujo [n=araujo@gentoo/developer/araujo] has joined #gentoo-council
-21:09:10 <@vapier> i'd say you skip the few hundred other e-mails in the first few threads if you soak up those last
-21:09:11 <+g2boojum> vapier: I'm happy to yank mine as unnecessary once spb's gets going.
-21:09:26 <@vapier> am i the only one who felt this way ?
-21:10:03 -!- mode/#gentoo-council [+v spb-] by vapier
-21:10:07 <@vapier> dont think pauldv is around
-21:10:10 -!- DerCorny [n=corny@gentoo/developer/dercorny] has joined #gentoo-council
-21:10:13 <@SwifT> I was too stupid so I started reading them all :p
-21:10:28 <@solar> I'm not sure if that is the end goal that everybody is after. It's a good idea as long as spb is willing todo the work and it's approved by the portage team.
-21:10:41 <@Koon> From what I've read on both issues it's more a conservators/innovators opposition
-21:10:52 <@Koon> My position is that we should make room for both
-21:11:06 <@vapier> s/both/everything/
-21:11:08 <@solar> as it stands the portage documentation is where things are documented.
-21:11:11 <@Koon> withotu one necessarily breaking the other
-21:11:32 <@vapier> solar: which is incomplete and not a spec by any means
-21:11:45 <+spb-> for what it's worth, the vague idea behind those two -dev threads is a yet unwritten glep somewhere between 49 & 50
-21:12:06 <@Koon> vapier : my concern is that all innovative projects (good or bad) are being shot down on -dev, and those people with ideas won't propose a new one after that
-21:12:44 <@vapier> Koon: ok ?  why are you addressing that to me ... my point was that paludius is a specific example, this discussion should not tie itself down to one instance
-21:13:17 <@Koon> yes.
-21:14:15 <+g2boojum> spb-: What's your (realistic) timescale for your spec?
-21:14:36 <@solar> genone, zmedico, marienz if you guys have anything to add to the subject please /msg any one of the ops for a voice
-21:14:55 -!- mode/#gentoo-council [+vvv marienz zmedico genone] by solar
-21:15:05 <+spb-> g2boojum: depends who wants to chip in, what else happens in the next few months, etc ... definitely nontrivial though
-21:15:16 <+spb-> assuming you mean the tree spec
-21:16:02 <+g2boojum> spb-: Yes, that's what I mean.  I would suggest punting 49 and 50 until that's done, but that won't work if it's going to take so long that people won't want to wait.
-21:16:29 <+genone> re tree spec: first step there is to break it down into components and create a spec for each component
-21:16:40 <+marienz> don't know how relevant it is, but speaking as an ebuild dev I appreciate not having to ensure my ebuilds work with half a dozen of package managers. I think that's the main thing that needs to be "fixed" for alternative package managers.
-21:16:43 -!- dertobi123 [n=tobias@gentoo/developer/dertobi123] has joined #gentoo-council
-21:16:50 -!- amne [n=amne@gentoo/developer/amne] has joined #gentoo-council
-21:16:55 <+spb-> g2boojum: it's the sort of thing afaict that's not difficult, but time-consuming
-21:17:14 <+spb-> there's a lot of relevant stuff in the devmanual and elsewhere, which can be used
-21:17:39 <+genone> also depends how detailed things are going to be
-21:17:42 <@vapier> marienz: you ensure the ebuild works with the spec
-21:17:47 <+marienz> exactly.
-21:18:21 <+marienz> so there needs to be either a spec or one (or two, but preferably more than that) must be declared sufficiently "official" that all ebuilds must work with them.
-21:18:34 <+g2boojum> vapier: Actually, I still suggest punting 49 and 50, since the reason behind it (adding a new profile) has gone away, now that paludis is going to use virtual/portage as a band-aid for now.
-21:18:44 <+spb-> this also makes the requirements for supporting another package manager much simpler -- if it supports every ebuild/tree format currently in use, you shouldn't need to worry about little differences between them
-21:18:46 <+marienz> glep 50 kind of addresses that, I'm not sure 49 does (I did not fully understand everything that one was saying)
-21:19:03 <@vapier> g2boojum: agreed
-21:19:21 <+marienz> err, preferably *no* more than that :)
-21:19:57 <@Koon> If everyone is OK maybe we should move on
-21:19:59 <@vapier> i think at this point it's sane to leave the tree spec in the capable hands of our portage devs and let spb help with the footwork ?
-21:20:10 <@vapier> s/sane/safe/, depending on how you want to look at it
-21:20:32 <@seemant> all that's been said I  agree with, really -- get a spec going :)  let everyone know what's going on and how they can chip in (if you need chipping in)
-21:21:13 <@Koon> also this spec will help define what's good and what's bad, without talking of multiple package managers
-21:21:28 <@vapier> sometimes seemant you remind me of Harold
-21:21:31 <@solar> vapier: my understanding is that spb is proposing it. He should probably do most of the legwork and have the portage team review/approve it.
-21:21:47 <@seemant> vapier: harold was modelled after me
-21:21:49 <@seemant> who's harold?
-21:21:57 <@vapier> err sorry, i mean Kumar
-21:22:02 <@Koon> that's a bad one. You're authentified
-21:22:07 <@seemant> who's that?
-21:22:29 <@vapier> spb-: hows that sound ?
-21:22:57 <@vapier> seemant: remind me to bring a dvd next time we hook up :p
-21:23:02 <@seemant> vapier: ha ok
-21:23:11 <+spb-> sounds good to me
-21:23:51 <@vapier> everyone satisfied for now ?  any other input ?
-21:24:26 <@seemant> no, let's move to the next one
-21:24:43 -!- mode/#gentoo-council [+v brix] by solar
-21:24:47 <@Koon> Project Sunrise, or how much official is official
-21:24:51 -!- mode/#gentoo-council [+v Stuart] by solar
-21:25:10 -!- mode/#gentoo-council [-vvv genone marienz spb-] by vapier
-21:25:13 -!- mode/#gentoo-council [-v zmedico] by vapier
-21:25:18 <@solar> thanks guys
-21:25:26 -!- mode/#gentoo-council [+v jokey] by Koon
-21:25:28 <@vapier> hmm, freenode only allows 3 ops per line ?  weak
-21:25:46 <@SwifT> bah, Sunrise... now *that* was a thread
-21:25:53 <@solar> (s)...
-21:25:54 <@Koon> threads, you mean
-21:26:16 <@SwifT> yeah
-21:26:29 -!- mode/#gentoo-council [+v genstef] by Koon
-21:26:45 <@Koon> I must confess I've not read it all
-21:26:46 <@solar> ok so the root problem here is that some people do not want the overlays to be a dumping ground for user submitted ebuilds that have not had the sligest bit of QA?
-21:26:59 <@seemant> I'll go on record here as pretty much agreeing with Gianelloni was saying -- we don't need a dumping ground for untested/unapproved stuff, if that ground is going to exist in an official capacity
-21:27:15 <@solar> others want it to be a place to breed new ideas and welcome the comminty at large?
-21:27:19 <@SwifT> I can agree on that, bmg all over again
-21:27:35 <@seemant> I have no complaints about Sunrise being offsite and harvesting bugzilla for their overlay
-21:27:38 -!- mode/#gentoo-council [+v wolf31o2|work] by solar
-21:27:38 <@vapier> even if they have a bit of QA, the idea is that the interm maintainers arent famailiar at all
-21:27:51 <@Koon> still, opening up the tree a little more to the community is really needed
-21:28:02 <@Koon> the dev community is too closed
-21:28:09 <+brix> so far you've pretty much summarized my concerns
-21:28:14 <@seemant> but my understanding was that overlays.g.o was to collect together the various overlays from spyderous and other devs
-21:28:24 <+brix> Koon: agreed, but Sunrise is not the solution imho
-21:28:43  * vapier copies & pastes what brix said
-21:28:46 <@seemant> Koon: I do agree with you -- and I would wholeheartedly approve of (and indeed encourage!) an offsite project sunrise
-21:29:01 <+brix> seemant: the original proposal for overlays.gentoo.org was to host developer and project/team specific overlays
-21:29:09 <@Koon> hm.
-21:29:13 <@seemant> Koon: I think it has potential as a recruiting ground, a training ground, even
-21:29:36 <@seemant> Koon: and I can see devrel possibly wanting (this is speculation) to work with sunrise to get the user community more involved
-21:29:38 <@Koon> the problem is that you see official/stable as a binary thing
-21:29:49 <@seemant> not stable, just official
-21:30:14 <+genstef> seemant: one of our goals is to find new recruits
-21:30:35 <@solar> I don't want to see us turn into a deb where we recurit people to maintain a 1 single pkg. We end up with to much dev overhead.
-21:30:51 <@seemant> Koon: from the way I see it, if sunrise serves a training ground, that's fine and indeed great, but I do see chris and henrik's concern (and share it) that our actual bugzilla will get spam, and our developers will get overloaded
-21:30:59 <+brix> solar: so introduce a project for proxy maintainers like *BSD does
-21:31:20 <@seemant> Koon: make that BugDay rather than devrel
-21:31:20 <@Koon> For example we could have multiple tree subsets, "enterprise", "security-supported", "official-dev-supported", "dev-overlays", "experimental dumping" and the user gets to choose the one he wants
-21:31:26 <@seemant> since that project is more suited
-21:31:36 <@Koon> of course not doable with our current model
-21:31:43 <@seemant> Koon: and I'll support that as soon as we have a model that can do it
-21:31:51 <@seemant> Koon: as you say we can not right now :)
-21:32:16 <@Koon> OK then. We agree  that the intention is laudable but it's not the right way to do it
-21:32:24 <@seemant> please keep in mind, dear reader (this includes the people reading this on archive): I like project sunrise's potential -- I just think it's misplaced being an official project
-21:32:39 <@SwifT> multiple tree subsets; that will so require too much resources...
-21:32:43 <@seemant> wrong timing, I guess
-21:32:48 <+jokey> seemant: well what  kind of overload do you expect?
-21:32:51 <@Koon> SwifT: or concentric ones
-21:32:51 <+brix> seemant: yes, I agree
-21:32:53 <@seemant> SwifT: it's a conversation for another day -- we'll have to grow into it :)
-21:33:06 <@Koon> SwifT: Ubuntu-like
-21:33:07 <@SwifT> I'm already feeling the growth pains
-21:33:11 <+brix> Project Sunrise is not a bad idea - I just do not wish to see it as an official project
-21:33:20 <@Koon> oh, I said the U-word
-21:33:21 <@solar> for the moment can we not call it sunrise and focus on what our goals for overlays. should be?
-21:33:23 -!- hydrogen [n=hydrogen@amarok/rokymotion/Hydrogen] has quit [Connection timed out]
-21:33:28 <@seemant> jokey: part of the overload I can see immediately would be bugzilla spam for starters
-21:33:38 <@seemant> jokey: bugs that are invalid popping up
-21:33:45 <+genstef> seemant: the whole point of sunrise is being by "gentoo", users should contribute to "gentoo" instead of third-party
-21:34:15 <+brix> genstef: which is a good idea - but I don't see Sunrise as the best solution to that problem
-21:34:22 <@seemant> genstef: and they will, when they are ready -- sunrise isn't a place for quality ebuilds, it's coming across as "harvest all unresolved bugs for ebuilds, put them into a tree and ship"
-21:34:44 <+genstef> seemant: I think we should host more stuff on gentoo infra where we can actually fix it - broken third party overlays give a bad impression about gentoo as well
-21:34:50 <@seemant> genstef: and if that statement is true then those potential developers are not served well by it -- they should be exposed to peer review etc
-21:34:54 <@Koon> brix: it's easier to say no than to propose something better, unfortunately
-21:35:03 -!- Pylon [n=pylon@gentoo/developer/Pylon] has joined #gentoo-council
-21:35:14 <@Koon> I tend to respect those coming up with ideas, projects and energy to do them
-21:35:16 <@seemant> genstef: I disagree, I think third-party development is what makes an entity thrive (as examples, microsoft and apple both serve well)
-21:35:29 <+genstef> seemant: they are, actually we have a certain peer review in the sunrise and -dev-help channels and ebuilds are reviewed by a developer always
-21:35:32 <@Koon> because we lack them atm
-21:35:33 <+brix> Koon: well, had the project been discussed before it was done I could have prepared a proposal
-21:35:59 <@seemant> brix: I'm glad you're here and I'm glad you said that
-21:36:01 <@Koon> brix: here we fall in the "Projects can pop up anywhere" metstructre
-21:36:05 <+genstef> seemant: I cannot think why they should be of low quality - they have all been reviewed
-21:36:11 <@Koon> that was the model voted
-21:36:15 <@seemant> brix: I think it would be appropriate and opportune even now for you to make that proposal
-21:36:49 <+brix> seemant: I will eventually - but I am also in the middle of finishing my education
-21:37:10 <+brix> Koon: the model doesn't say anything about not discussing projects first :)
-21:37:25 <@seemant> genstef: have they? can you take a kernel-sources ebuild or a games ebuild (to remention two examples on the lists -- which I'm reading again, btw!) -- and really Qa them without knowing much about those projects/
-21:37:30 <+jokey> brix: well I guess we can really work together here and improve it together
-21:37:32 <@seemant> or, god help you, a java ebuild?
-21:37:33 <@Koon> brix: they followed the way to create a project as described in g2boojum's metastructure model (which was not my model, as you may remenber), designed to favor innovation
-21:37:34 <@vapier> brix: but it does not require it
-21:38:16 <+genstef> seemant: nope, we can not, but we are providing general ebuild QA + projects which we are in, and I am in mayn projects.
-21:38:17 <+brix> vapier: I didn't say it did
-21:38:19 <+brix> Koon: I know
-21:38:44 <@seemant> genstef: that's a good thing -- what happens when you go on vacation, get sick, etc?
-21:38:49 <@Koon> but we fall in the exception rule, the council arbitrates conflicts created by multiple conflicting projects
-21:39:02 <+g2boojum> vapier: True, and if you don't discuss it first, you get several hundred e-mails of people beating up on you.  I certainly hope people have learned.
-21:39:04 -!- sybille [n=sybille@dra38-3-82-236-190-42.fbx.proxad.net] has joined #gentoo-council
-21:39:08 <@seemant> genstef: again, I'm not against the idea, but I would like to see a more robust plan
-21:39:14 -!- rangerpb [n=ranger@gentoo/developer/rangerpb] has joined #gentoo-council
-21:39:25 <+jokey> seemant: well if there is no dev available then there is no new commit
-21:39:40 <@Koon> anyway, there has been plently of discussion since it was announced, and I've yet to see a model that achieves the openness goal with a better model
-21:39:51 <@vapier> g2boojum: yes, but i just dont want people getting the idea that things need to be approved first
-21:40:01 <@seemant> jokey: I guess I would feel better personally were it to be a semi-official rather than fully official project
-21:40:10 <@seemant> jokey: a partner project, if you will
-21:40:10 <+g2boojum> vapier: Ah, I misunderstood.  Fair enough.
-21:40:27 <@seemant> vapier: touche
-21:40:30 <+jokey> seemant: expand a bit please
-21:40:58 -!- beejay [n=benni@gentoo/user/beejay] has joined #gentoo-council
-21:41:18 <@seemant> jokey: ok, so what I've learned in the last few minutes of talking with you and genstef is 1. you want an official-like way of recognising user input, instead of letting users get discouraged via bugzilla inactivity
-21:41:42 <+jokey> seemant: exactly the point :)
-21:41:42 <@seemant> 2. project sunrise will try and partner up users with developers to try and improve their ebuild/eclass m@dsk1llz
-21:42:02 <@seemant> jokey: what I've learned from henrik and chris (mainly) in the mailing lists is:
-21:42:05 <@seemant> s/is/are:
-21:42:24 <@seemant> 1. there is overhead, 2. is the bar being lowered *too* much for official recognition of things?
-21:42:38 <@solar> I think this is starting to sound like something other than what should be overlays.g.o
-21:43:02 <@seemant> 3. what of the disconnect between portage's official $herd-of-ebuilds vs sunrise's $analagous-herd-of-ebuilds
-21:43:31 <+genstef> what do you mean?
-21:43:45 <@seemant> jokey: I've not, honestly, seen point 3 resolved yet
-21:44:16 -!- `Kumba|work [n=kumba@gentoo/developer/Kumba] has joined #gentoo-council
-21:44:16 <@vapier> brb
-21:44:47 <@seemant> jokey: and an additional concern is the perception of gentoo officially endorsing ricing <-- the potential of that
-21:44:51 <+jokey> seemant: well we're only after maintainer-wanted apps who are not (yet) in the tree and also we don't want to get in conflict with the base system
-21:44:57 <+brix> despite the good intentions of jokey and genstef I fail to see how two developers will be able to keep track of litterally thousands of ebuilds in a parallel portage tree - maintain them, look for security issues, take care of QA, ... - all why educating users and keeping track of their other work assignments in Gentoo
-21:45:12 <+Stuart> solar: o.g.o's there to provide a place for devs and users to collaborate; in that respect, sunrise is in keeping with the spirit of o.g.o.  But it's also about making sure that the user contributions are safe & valid ... and there are question marks about that, to be sure
-21:45:22 <+brix> s/why/when/
-21:45:23 <+genstef> brix: we can always cut down on the number of committers or close the overlay for a period of time
-21:45:29 <@Koon> also we are enable to easily reject bugs coming from unsupported overlays
-21:45:40 <@Koon> the problems may not be tainted enough
-21:45:53 -!- Blackb|rd [i=klausman@eric.schwarzvogel.de] has left #gentoo-council []
-21:46:32 <+Stuart> brix: there's something like 1800 maintainer-wanted bugs iirc
-21:47:04 <+brix> plus maintainer-needed ebuilds
-21:47:30 <@seemant> that's a lot of bugs
-21:47:32 <@seemant> lot of ebuilds
-21:47:36 <@seemant> lots of maintenance required
-21:47:38 <@Koon> plus unidentified maintainer-is-MIA and herd/team-is-empty ebuilds
-21:48:08 <@Koon> my position is that the tree is, at the same time, too large and too closed
-21:48:09 <+jokey> seemant: yep but as genstef said already, we're in full control here. we control the ebuilds and the count of commiters
-21:48:16 <@seemant> Koon: too large yes!
-21:48:24 <+wolf31o2|work> sorry... just noticed I was voiced and have a few minutes at work to chime in... wouldn't something for maintainer-needed (rather than maintainer-wanted) do more to benefit Gentoo, while still giving the "training ground" that many seem to think is needed?
-21:48:27 <+Stuart> seemant: indeed, that's the case whether or not it's on official hardware
-21:48:45 <@seemant> Stuart: no the official tree I mean
-21:48:49 <@Koon> for example there is no way to restrict security activity to a supported set. What we say is that ~ ebuidls are not supported but that's just as much we can do
-21:49:13 <+Stuart> wolf31o2|work: that's a good point
-21:49:42 <+jokey> wolf31o2|work: really a good point. we are allowing both currently, but we easily can focus on that part first
-21:50:09 <+brix> jokey: I still don't see the need for an overlay for this
-21:50:17 <+wolf31o2|work> I guess I see sunrise as a place to dump "junk"... whereas maintainer-needed stuff has already been in the tree... already checked by a developer (at least once) and should be easier to keep up with... it also reduces the amount of "junk" in the tree, by helping find maintainers for packages which are currently abandoned
-21:50:29 <+brix> I'd much rather see some form of proxy maintainership being introduced
-21:50:39 -!- MasterOfDisaster [n=mod@156b.jkh.uni-linz.ac.at] has joined #gentoo-council
-21:50:46 <+wolf31o2|work> don't we already *have* that ability?
-21:50:52 <@solar> yes we do
-21:50:53 <+brix> wolf31o2|work: ability, yes
-21:51:04 <@seemant> brix: I can see an overlay (un- or semi- official at least to begin with) that gets people used to using the tools like repoman and cvs, etc
-21:51:14 <+Stuart> brix: the difference with an overlay is that (done right) it gets more users involved in the dev community
-21:51:17 <@seemant> echangelog, and all that other good stuff
-21:51:40 <+brix> seemant: the committers do not have know CVS if committing through a proxy developer
-21:51:54 <@solar> seemant: your talking about opening up +w access to the community?
-21:51:58 <+wolf31o2|work> brix: then it fails as a trinaing ground
-21:51:59 <+g2boojum> wolf31o2|work: I agree with your general point, but referring to all of the maintainer-wanted stuff as "junk" is rather pejorative.  There are some packages there that are well-written and used by many people.
-21:52:00 <@seemant> brix: correct, but what if you think of it as a training ground?
-21:52:02 <@seemant> solar: um, no
-21:52:14 <@seemant> solar: please re-read and don't panic on the word "cvs"
-21:52:38 <+brix> seemant: if hosted on non *.gentoo.org, fine by me
-21:52:52 <@seemant> brix: that's why I said unofficial or semi-official
-21:52:56 <+wolf31o2|work> g2boojum: it doesn't have a maintainer now, which to me means it would be simply adding to the problems we have now, rather than being any sort of solution... you also notice I used junk in quotes... to denote is as meaning "a lot of stuff" more than "crap"
-21:53:05 <+wolf31o2|work> g2boojum: if I meant crap, I would have said crap... heh
-21:53:32 <+wolf31o2|work> sorry for not being clearer there
-21:53:33 <@solar> if hosted on something other than *.gentoo.org then we don't need to be talking about it here now. It's just an external project.
-21:53:34 <+g2boojum> wolf31o2|work: Sorry, I missed the subtle difference in connotations.  Point made.
-21:54:08 <@seemant> solar: hang on a second
-21:54:22 <@solar> I'm not going anywhere for 6 mins
-21:54:28 -!- mode/#gentoo-council [+v Ramereth] by solar
-21:54:28 <@seemant> solar: what I'm proposing is actually the point -- semi-official project
-21:54:43 <+brix> seemant: please define "semi-official"
-21:54:47 <@seemant> just because it's not an immediate infra concern doesn't make it a non-gentoo concern
-21:54:51 <@SwifT> nongentoo.org ? :)
-21:54:54 <+jokey> well actually m-n/m-w bugs are on gentoo hardware, the forums are so why not the overlay then as well?
-21:55:22 <@seemant> brix: there's the rub :) semi-official -- we recognise the project and its goals, and to a certain extent support it
-21:55:35 <@seemant> brix: unoffical is like bmg -- we know it exists, we don't do anything about it
-21:55:40 <+Stuart> seemant: won't "semi-official" lead to more debate, because it's neither one nor the other?
-21:55:57 <@seemant> Stuart: it's more like pergatory -- a training ground for the project itself
-21:56:26 <+Ramereth> the only way I see it working is if its properly managed by the right people and do a decent amount of training/qa to make sure its being done right
-21:56:31 <+Stuart> seemant: ah, then why not setup a group to oversee the project, act as mentors for it? (ie an incubator)
-21:56:54 <@seemant> Stuart: seems to me genstef and jokey (and patrick) have formed that group
-21:57:01 <+Ramereth> if that can be proven and done right, I don't have much of a problem with us hosting it. But as it stands now, i don't have the confidence so that that it will be like that
-21:57:03 <@seemant> Stuart: the point is what to do with it now
-21:57:04 <@solar> thats to grey for me seemant.. I feel it's needs to be black or white
-21:57:14 <@seemant> solar: not everything in life is, my friewnd
-21:57:18 <+jokey> Ramereth: if you're one of "the right people" then step up and help us :)
-21:57:34 <+Ramereth> i don't have the time
-21:57:43 <+brix> I still don't see why an overlay is needed for involving users, though
-21:57:59 <+Ramereth> is there another mechanism that might work better?
-21:58:03 <@Koon> brix: convenience
-21:58:12 <@seemant> brix: there's more to being a dev than just writing ebuilds -- there's the bit that involves the use of tools -- repoman, echangelog
-21:58:15 <+brix> Ramereth: proxy maintainers
-21:58:19 <@seemant> brix: there's the concerns about digests and signing, etc
-21:58:35 <@solar> mostly it's about reading mails and filtering spam
-21:58:40 <@seemant> brix: why not take advantage of a source control system to provide that additional level of training
-21:58:43 <+Ramereth> see, this idea is bigger and more complex than the original authors realize.
-21:58:53 -!- hydrogen [n=hydrogen@amarok/rokymotion/Hydrogen] has joined #gentoo-council
-21:59:00 <@seemant> Ramereth: I suspect you might be right
-21:59:09  * Koon tries to train a bayesian filter to recognize flames and pointless +1's
-21:59:10 <+Ramereth> you can't just put an overlay up and expect it to solve all the issues
-21:59:28 <+Ramereth> this needs to be a joint project between userrel and devrel
-21:59:42 <+Ramereth> with guidlines and a group of people actually helping users
-22:00:09 <+Ramereth> maybe sandbox area that the general public can't get to so save from the crazy bugs, but the mentors/users can still test it
-22:00:11 <+jokey> Ramereth: well actually the users are already active on the gentoo-dev-help chan
-22:00:15 <@solar> brb (bad smoking habit)
-22:00:47 <+Ramereth> I like the general idea of sunrise, but it needs a lot of work and needs a whole group of developers too deal with it
-22:00:54 <+Ramereth> two people simplly can't do it, i'm sorry, you can't
-22:00:55 <+jokey> Ramereth: and helping devs as well of course
-22:00:57 <+Stuart> we've seen with things like the PHP overlay that you *have* to have knowledgable devs helping the users who have +w access
-22:01:25 <@Koon> Ramereth: they control the number of contribs and can shut it down if they don't have enough manpower
-22:01:42 <+Ramereth> i don't have confidence that they will do that when someone complains
-22:02:00 <@seemant> Ramereth: a project for BugDay, but yes, you're on the right track
-22:02:11 <@seemant> devrel has its hands full already I think
-22:02:18 <+Ramereth> think of it like an ebuild training project
-22:02:19 <@seemant> though sunrise has the potential to ease that load
-22:02:34 -!- mode/#gentoo-council [+v bonsaikitten] by Koon
-22:02:55 <+Ramereth> simply turning off the valve on contribs won't fix it
-22:03:06 <+bonsaikitten> I wish to add that sunrise is already interacting a lot with userrel
-22:03:55 <@Koon> Ramereth: but you agree we need to find a way to make the community a little less binary (in the devclub or out) if Gentoo is to survive, right ?
-22:04:01 <+bonsaikitten> also, it's only two devs now in the beginning - which other project started with many more contributors?
-22:04:08 <+Ramereth> Koon: yes, but it needs to be done *right*
-22:04:23 <+Ramereth> Koon: and it needs to be properly staffed by the *right* people
-22:04:24 <@seemant> Koon: +1 from me on that -- I'm not sure sunrise in its present form is the way :)
-22:04:31 <+Ramereth> seemant++
-22:04:33 <@Koon> Ramereth: I'm not sure it can be done
-22:04:38 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-22:04:52 <+bonsaikitten> Ramereth, the "right" people - we're all devs, what makes some better than others?
-22:04:54 <+Ramereth> Koon: it can be, but people have to be open to different ideas
-22:05:01 <+Ramereth> bonsaikitten: experience and attitude
-22:05:15 <+Ramereth> and respectability
-22:05:28 <+bonsaikitten> but you should trust other devs not to screw up
-22:05:31 <+Ramereth> at least, that's how it used to work around here..
-22:05:38 <@seemant> bonsaikitten: is that coz you're part of both projects that you say that?
-22:05:45 <+Ramereth> bonsaikitten: we don't live in a utopian world
-22:05:54 <@seemant> bonsaikitten: I haven't seen motion on the userrel list about sunrise at all
-22:06:16 <@Koon> Ramereth: today it's more "I can bury you with my own bare email client" vocal minority rule
-22:06:26 <+Ramereth> Koon: yup :(
-22:06:32 <+Ramereth> anyways, back on track..
-22:06:44 <+bonsaikitten> seemant, most of the discussion happens in IRC, userrel is still changing a lot
-22:06:55 <@seemant> I'm in there too, still haven't seen anything..
-22:07:17 <@seemant> but anyway the point here is that project sunrise looks to be a good idea with a not-so-great implementation
-22:07:23 <@seemant> so er, plzfixkthxbye
-22:07:38 <+bonsaikitten> I agree that it was rushed, that was not optimal
-22:07:55 <@Koon> ok, we'll make that the official council position for now, then
-22:07:57 <+bonsaikitten> but it's schizophrenic to say that we lack manpower when we don't actively search for users
-22:08:02 <+Ramereth> that's where the whole experience part comes in patrick.
-22:08:08 <@Koon> solar/Swift/vapier: ?
-22:08:24 <@solar> Koon: one sec reading the scroll
-22:08:25 <@SwifT> still here
-22:08:36 <@seemant> bonsaikitten: I rather think we do actively search -- I'd love for you to see the recruiters bug list
-22:08:46 <@Koon> SwifT: you OK with seemant summary ?
-22:08:50 <@seemant> bonsaikitten: but gentoo isn't quite a free-for-all either
-22:09:00 <@seemant> there are (and rightly so) barriers to entry
-22:09:03 <+bonsaikitten> seemant, ok :-)
-22:09:13 <@Koon> seemant: there should be less barriers and more layers
-22:09:24 <@SwifT> Koon: yup
-22:09:27 <@solar> Koon: what are you saying is the offical council position for now?
-22:09:34 <@seemant> Koon: that is why I support the *intent* of sunrise as a training ground :)
-22:09:36 <+Ramereth> seemant: as tehre should be. I think one of Gentoo's major issues over the few years has been adding too many devs for too few of ebuilds to maintain
-22:09:41 <@Koon> <seemant> but anyway the point here is that project sunrise looks to be a good idea with a not-so-great implementation
-22:09:44 <@vapier> so i guess the end result is: sunrise is still suspended/closed in overlays until the details can be hashed out ?
-22:10:00 <@seemant> vapier: yes
-22:10:06 <@vapier> assuming the end result is the overlay implementation, and if it isnt, then it'll just be punted
-22:10:18 <@seemant> and I would like to add that I'd like to see chris and henrik (after his finals) have a hand in it as well
-22:10:27 <@Koon> vapier: with the risk that it shuts down without anything better emerging, yes
-22:10:36 <@seemant> wolf31o2|work: brix: that means you
-22:10:38 <+Ramereth> as long as it resides not on o.g.o and is shown as completely different than o.g.o, it would be better
-22:10:43 <+Stuart> all: do you need me to take further action, or are you happy with how I've suspended it for the moment?
-22:10:50 <@vapier> i'll sign on to that
-22:10:54 <+brix> seemant: not in Project Sunrise as it stands now, I'm afraid
-22:10:55 <@solar> Koon: I'm not sure it's a good idea at all. I would have to see version-2 to say where I stood
-22:10:57 <@seemant> Stuart: I'm fine with your actions so far :)
-22:11:06 <@seemant> brix: read what I wrote please
-22:11:13 <@seemant> brix: let's not talk in circles
-22:11:32 <+brix> seemant: I would scrap the idea completely and start over if I had anything to say
-22:11:38 <+Stuart> if the council ever lifts the suspension of sunrise, I'd prefer to see it on *.g.o
-22:11:45 <@Koon> brix: please do
-22:11:47 <@seemant> brix: then propose that and show your proposal
-22:12:08 <@seemant> brix: I haven't said you have limits to how you would design it, just that I would like you to have a hand in it
-22:12:13 <+brix> seemant: ok, then I misunderstood your first sentense
-22:12:21 <@seemant> brix: yes you did :P
-22:12:29 <+brix> seemant: fair enough
-22:12:45  * vapier poops on seemant 
-22:12:56 <@seemant> brix: but that's not an official council position just an official seemant position :)
-22:13:15 <+brix> seemant: gotcha
-22:13:29 <@seemant> so let's leave sunrise to be hashed on by brix, wolf31o2|work, userrel, and bugday
-22:13:35 <@Koon> when vapier poops, meeting is over
-22:13:54 <@Koon> anything left to discuss ? got to go soon
-22:14:16 <+jokey> seemant: so what can we do in the meantime then?
-22:14:29 <+Stuart> all: just want to say thanks for hearing this topic at such short notice
-22:14:34 <+Ramereth> work on a better plan that covers all the things said
-22:14:47 <@vapier> who has a log ?
-22:14:47 <@seemant> jokey: start the discussions with them, keep an open mind and come up with a good plan for this
-22:14:55 <@vapier> my xchat's buffer isnt long enough
-22:15:03 <@Koon> same here
-22:15:08 <+brix> I have a log
-22:15:09 <@seemant> jokey: like I say I approve of project sunrise's intentions (or at least a subset)
-22:15:15 <+jokey> I do as well
-22:15:22 -!- mode/#gentoo-council [-m] by Koon
-22:15:26 <@vapier> brix: going back to the start of the meeting ?
-22:15:27 <@seemant> jokey: so I want to see this succeed -- let's make it happen
-22:15:40 <+brix> vapier: yes
-22:15:40 < fox2mike> if neither of them do, I have a log.
-22:15:49 <@vapier> save & e-mail it to me then please
-22:15:53 < Peper> why don't you give a try now?
-22:15:57 -!- DrEeevil [n=pal@gentoo/developer/bonsaikitten] has joined #gentoo-council
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060720-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060720-summary.txt
deleted file mode 100644
index b83e1c4e6e..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060720-summary.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-- GELP 42
-Majority vote ok pending a usable portage based implementation
-
-- Sunrise Status
-Sunrise was taken out of suspension
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060720.txt b/xml/htdocs/proj/en/council/meeting-logs/20060720.txt
deleted file mode 100644
index e92efab671..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060720.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-21:01 <@Koon> man it's hot
-21:01 <@Koon> 19:00 UTC
-21:01 < genstef> hi :)
-21:01 < genstef> so let us start
-21:02 <@vapier> who are you
-21:02 < genstef> nobody
-21:02 <@vapier> agriffis is at OSL but i dont know if he picked a proxy
-21:02 <@vapier> we going to do GLEP42 first ?  be a quickie
-21:03 <@Koon> seemant's missing
-21:04 <@Koon> In today's agenda :
-21:04 <@Koon> - GLEP 42
-21:04 <@Koon> - Sunrise project status
-21:04 <@Koon> anything else ?
-21:04 <@az> noting mailed to -council that i know of
-21:04 <@solar> that is the only thing on the plate that I'm aware of
-21:05 <+genstef> bugzilla being slow and we need a proxy or cache for when it is down - but jakobs request was not accepted afaik
-21:05 <@solar> ok so 42 http://www.gentoo.org/proj/en/glep/glep-0042.html
-21:05 <@Koon> vapier: you asked for portage guys to come to the meeting but...
-21:06 <@vapier> they all seem AFK
-21:06 <@vapier> maybe i need to send a heads up e-mail from now on the nite before
-21:07 <@vapier> ah one is alive after all
-21:07 <@vapier> /mode # +v zmedico
-21:07 <@vapier> aldksjfa stupid mirc
-21:07 <@Koon> you mean that, right
-21:07 <@az> is there anything anybody want to discuss about it ? that, glsa's and info logging have been on the needed list for a long time now
-21:07 <@vapier> zmedico: so we were doing GLEP 42
-21:08 <+zmedico> alrighty
-21:08 <@vapier> zmedico: from what i gather on the list from the portage members, it's all doable/done ?
-21:08 <@Koon> we really need a way to pass vital upgrade information to our users
-21:08 <@Koon> so I'll take whatever comes that achives that goal
-21:08 <+zmedico> vapier: yeah, it'd not all done, but it's certainly doable.
-21:09 <@vapier> so no real qualms with the latest version ?
-21:09 <+zmedico> seems good to me
-21:11 <@solar> most of it can already be accomplished via the post sync hooks easy enough.
-21:12 <@solar> the parts where before you merge a package I dont' see happening
-21:12 <@solar> as it dives deep into the resolver.
-21:13 <@solar> I also would rather see such data going to stderr only.
-21:14 <@solar> as portage/emerge in stable lacks the ability to share it's resolver data right now and many people make use of the --pretend options to parse emerge output. Sending news to stdout would break that
-21:14 <+zmedico> I missed the part about news prior to install.  I thought it was just post sync.
-21:14 <@Koon> Checks for new news messages should be displayed:
-21:14 <@Koon>     * After an emerge sync
-21:14 <@Koon>     * After an emerge --pretend
-21:14 <@Koon>     * Before an emerge <target> (which may also include a red warning message)
-21:15 <@solar> please read it carefully. sbp and ciaranm both use gleps as to smuggle in additional goals they have
-21:15 <@Koon> solar: is taht what you're talking about ?
-21:15 <@solar> like repo-ids
-21:15 <@solar> Koon: yes
-21:17 <@Koon> solar: what would be the problem of pre-emerge notfication of new messages ?
-21:17 <@Koon> no current hook for it ?
-21:18 <+zmedico> no current hook, but we can add it.
-21:19 <@az> cant that be put on hold or something ? or cant portage just after it did the order, just loop over them ?  Dont see why there really need to be a hook as such
-21:20 <@Koon> If I read the GLEp correctly, notification of new messages occur even if the packages are not those you are currently emerging (but are installed) ?
-21:21 <@Koon> meaning "emerge xchat" would warn about the existance of messages about MySQl migration
-21:22 <+zmedico> I don't think so.  all unread would be displayed at sync, and the pertinent ones would be displayed for install commands.
-21:23 <@Koon> That would be better, but that is not mandated in the GLEP
-21:23 <@Koon> or I missed it
-21:24 <+zmedico> you're right
-21:24 <+zmedico> I guess it just shows all unread new items
-21:24 <@Koon> yes, and in the same way "after an emerge sync" and "before an emerge package"
-21:24 <+zmedico> makes sense.  just mark them read and then you won't be bothered again.
-21:25 <@Koon> that simplifies it, no need to dive in the resolver
-21:25 <+zmedico> yeah, no need for emerge to feed a package list to the news scanner.
-21:25 <@Koon> the same is_there_news() routine is called in every case
-21:25  * zmedico nods
-21:26 <@Koon> solar: does that answer your concern ?
-21:27 <@Koon> am I splitted/alone ?
-21:27 <@solar> well. I dislike most of it. So I'll go ahead and say if we are voting I'd reject it
-21:28 <@Koon> what are your (main) issues against it ?
-21:28 <@solar> we are a bit shy and spb nor ciaranm are here so I don't think we should vote
-21:28 <+zmedico> well, if we and a hook for install commands, portage doesn't have to know anything about the news stuff.  it can just be hooked in.
-21:28 <+zmedico> s/and/add/
-21:28 <+zmedico> az: that's where hooks are useful
-21:28 <@Koon> solar: you're against the principle of sending upgrade info to the end user ? Or against the implementation details ?
-21:29 <@Koon> vapier/SwiFT/az: what so you think of it ?
-21:30 <@SwifT> I think the goal is noble and worth implementing
-21:30 <@SwifT> can't care less about spb/ciaranm
-21:30 <@az> well, the idea in itself is fine, if there is issues about implementation that others with more knowledge on portage disagrees with, i guess it should be seen to first
-21:30 <@solar> I don't care for the implementation details. I don't really want eselect forced upon me. the end goal is desireable yes
-21:30 <@SwifT> I also feel that there is enough support for it
-21:31 <@solar> existing portage provide the majority of whats needed todo most of this today
-21:31 <@SwifT> and in the end, if it doesn't work out, no sweat :)
-21:31 <@Koon> eselect is presented as a default/possible news reader
-21:31 <@Koon> not the only option
-21:31 <@vapier> eselect is an option
-21:31 <@Koon> also it's quite easy to ignore the whole system
-21:31 <@vapier> it's also going to happen regardless ... an outstanding issue is all the -config scripts we have
-21:32 <@vapier> that was the point of eselect
-21:32 <@SwifT> the rsync_exclude option? well, it might be more userfriendly to use a FEATURE, but that might be just my own feeling
-21:32 <@SwifT> and it's a detail
-21:32 <@Koon> FEATURE=ignore_news ?
-21:32 <@solar> excluding is easy enough.
-21:33 <@Koon> Should we vote ?
-21:33 <@SwifT> FEATURE="shownews" (I don't like negative entities)
-21:33 <@SwifT> :)
-21:34 <@solar> well from the looks of it portage/emerge would only display the number of unread items
-21:35 <@SwifT> also true
-21:35 <@Koon> it's more a change in development/pr methods than a technical one
-21:35 <@solar> not the news itself so as long as it's a 1 liner it should be ok. Again this can already be done via post sync actions.
-21:36 <@SwifT> disregard my comment then, those few lines don't make much difference as we do that for the config stuff already
-21:36 <@Koon> maintainers should change their habits and prepare news messages for their non-trivial upgrades
-21:37 <@Koon> where they used to rely only on postinstall messages in the past
-21:37 <@solar> maintainers will also have to go edit these news items for every pkg move
-21:38 <@vapier> are you posting a complaint or pointing out the obvious ? ;)
-21:38 <@Koon> it's too hot to think
-21:39 <@SwifT> messages need to be posted on -dev some time in advance; there should be sufficient support from devs and users to craft the message
-21:40 <@Koon> Ready to vote ?
-21:40 <@SwifT> aye here
-21:41 <@az> yeah
-21:41 <@vapier> +1
-21:42 <@Koon> I vote yes, this is long due
-21:43 <@az> +1
-21:43 <@az> that and the elog stuff should hopefully get the needed messages through once they are in use
-21:45 <@Koon> solar?
-21:45 <@vapier> SwifT ?
-21:46 <@SwifT> I said "aye here"
-21:46 <@az> could throw it back with yes if foo bar is resolved if there is issues, and for the eselect issue - just look at etc-config, dispatch-conf and now blubb's new thing
-21:47 <@Koon> That means 4 yes, probably adopted then
-21:48 <@Koon> Now the Sunrise status discussion
-21:48 <@solar> I'd rather not vote on it till a proof of concept exists for the portage ends of things. The way they are planning it seems somewhat ulgy with all the portageq calls. And as stated several times most of the functionality already exists
-21:48 <@vapier> eselect is a reference implementation
-21:48 <@vapier> not required
-21:48 <@solar> that is not for portage
-21:48 <@Koon> Thats a catch-22, there needs to be an OK on the GLEp before anything is developed
-21:48 <@solar> that is for that other pkg mgr.
-21:49 <@az> what i meant, its not like it will be locked down
-21:49 <@Koon> yes, we can still cut its balls if it bevomes nasty
-21:49 <@Koon> well, probably those who come after us
-21:50 <@az> solar: which one of the many otheres these days ? *grin*
-21:50 <@Koon> The Mythical 2007 Council
-21:50 <@solar> who is going to code it anyway? I'm not totally in favor of approving something then the work is dumped on others.
-21:50 <@Koon> we approve the idea of it
-21:51 <@Koon> solar: then you don't agree on the counil/glep thing
-21:51 <@Koon> council
-21:51 <@Koon> because "approving things and then hoping someone will do it" is what we do
-21:52 <@Koon> this GLEP having a particularity : it's not written by the ones that will have to do the work
-21:52 <@Koon> letting some room for the implementer to do it a little differently
-21:52 <@Koon> OK, only 10 minutes left, so let's consider it approved with 4 yes and go to sunrise discussion
-21:53 <@Koon> vapier: you voted yes, right
-21:53 <@solar> I'll vote yes on the basic idea. just not that implementation
-21:53 <+genstef> ok, we have worked with the mailing list on hashing the details out and improving the implementation
-21:54 <+genstef> but apparently interest has ceased since brix got the overlay closed down
-21:54 <@Koon> it should revivce when we open it back
-21:54 <@Koon> revive
-21:54 <@vapier> Koon: +1
-21:55 <+genstef> Koon: yeah, exactly what I am thinking
-21:56 <@Koon> Have all the reasonable objections been addressed ?
-21:56 <@Koon> because you'll never satisfy those who want it dead anyway
-21:56 <+genstef> I hope so. If you can point something more out to me I would love to hear it
-21:56 <@az> last bitching there have been, have stopped when vapier asked to point out the issues
-21:56 <@az> if i remember
-21:56 <@Koon> az: I didn't follow very closely but I remember that too
-21:57 <@Koon> Frankly I don't like too much when people wanting to kill other's innovations do not even stand by to point out reasonable objections
-21:57 <@vapier> so i know wolf and brix had issues, who were some of the other people originally ?  or do i need to flip through some threads again ?
-21:58 <+genstef> vapier: foser probably
-21:58 <+genstef> others had the general objection of unreviewed code which has been adressed by making that part read-only
-21:59 <@solar> genstef: in short.. the new sunrise will provide a place to host maintainer-wanted ebuilds which will be proxied by you and what ever team you put together? the repo itself will be anonymous.
-21:59 <+genstef> one repo for users to commit
-21:59 <@vapier> the team including many user contributions
-21:59 <@Koon> sounds like what some others do without giving it a fancy name
-22:00 <+genstef> one repo for developers to move the ebuilds to
-22:00 <+genstef> the user-commit thing is read only
-22:00 <@solar> so your goal is to open cvs +w up to the world?
-22:00 <@solar> cvs/svn/vcs..
-22:00 <@Koon> vss?
-22:01 <+genstef> solar: no
-22:01 <@solar> version control system. (what ever one is picked in the end.)
-22:01 <+genstef> solar: users get accounts on request
-22:01 <@SwifT> i like the sunrise/ vs reviewed/ qa :)
-22:01 <@Koon> I am all for opening Gentoo more to the community, so I support the idea
-22:01 <+genstef> SwifT: yeah exactly :)
-22:02 <+genstef> and sunrise cannot be checked out anonyous
-22:02 <@solar> what criteria will there be to have a user approved?
-22:02 <@Koon> quality of contrib I suppose
-22:02 <+genstef> solar: ebuild-quiz
-22:02 <+genstef> solar: users can only commit to sunrise/, only developers to reviewed/
-22:03 <@SwifT> solar: ebuilds by non-devs are still staged before they are available for public usage
-22:03 <@solar> who will be reviewing those? recruiters? other?
-22:03 <@Koon> call them wanabees rather than "users" or "world"
-22:03 <+genstef> solar: sunrise developers
-22:03 <+genstef> solar: people in the project
-22:03 <+genstef> solar: but there is not much advantage of taking the ebuild quiz
-22:04 <+genstef> just skipping the pre-commit review
-22:04 <+genstef> of course users are still users even with the quiz and do not get more permissions
-22:04 <@Koon> genstef: I think solar's concern is more about security, giving a +w access to somewhere into Gentoo's infra to someone less controlled
-22:05 <@Koon> not about end-user risk of using a bad ebuild contributed through the system
-22:05 <@solar> Koon: how can you tell :)
-22:05 <+genstef> well the write access is only for unreviewed stuff, so they can do no harm
-22:05 <@Koon> I read your mind, don't move too much
-22:05 <+genstef> like write access to bugzilla attachments
-22:05 <@SwifT> genstef: it's more about the security considerations than the contribution sensibility
-22:06 <@Koon> genstef: the "harm" is more a new attack vector on Gentoo(s infra that we must care for, than potential harm done to users
-22:07 <@Koon> but I say it's the price to pay for a dev community
-22:07 <@solar> genstef: for sunrise. I'd prefer that any cia hooks that you might put in place do not show up under the 'gentoo' name as it would skew real cia stats.. gentoo-sunrise other would be fine.
-22:08 <+genstef> solar: ok
-22:08  * solar has no objections and would encourage anon to be opened up
-22:08 <@Koon> OK. I vote for stopping the suspension of the Sunrise project
-22:08 <@solar> anon-read-only that is to all of it.
-22:08 <@Koon> as all reasonable objections have been addressed
-22:09 <+genstef> solar: it is http accessible, just not for checkout
-22:09 <@solar> right. http:// is useless and webdav is not allowed on infra servers.
-22:09 <@solar> so checking out would be somewhat of a pita. granted anon is what others object to.
-22:10 <@Koon> and kudos to the project Sunrise developers for having addressed those concerns so gracefully
-22:10 <@Koon> without falling into the traps that were set up for them to fall in
-22:10 <@SwifT> the sunrisefaq is a nice document to read
-22:10  * solar has to split for a few mins. 
-22:10 <@Koon> vapier? az?
-22:11 <@SwifT> i'm o
-22:11 <@SwifT> kay for it
-22:11 <@az> fine with me
-22:13 <@Koon> seemant was for the suspension and is not with us today
-22:14 <+genstef> he has sent no proxy either, has he maybe forgotten the meeting? Or does he not care? I have talked long with him after the last meeting
-22:15 <@az> might have forgotten or busy
-22:15 <@az> havent seen him today
-22:15 <@Koon> vapier?
-22:16 <@Koon> I'll have to let you all finish without me... so for the record I'm for stopping the suspension
-22:17 <@az> same here
-22:19 <@vapier> sorry, had phone call
-22:20 <@vapier> i'm for the project and i'm for hunting down the people who had outstanding concerns
-22:20 <@Koon> to kill them or ask them a few questions ?
-22:21 <@Koon> I'm pretty sure once the project is un-suspended they will show up
-22:21 <@SwifT> =)
-22:22 <@Koon> OK then
-22:22 <@Koon> I'll let you finish from here, see you all next month for our last meeting
-22:24 <@SwifT> I'm off as well now
-22:24 <@SwifT> laptop's too heated :)
-22:24 <+genstef> bye SwifT 
-22:26 <@solar> meeting over then.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060817-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060817-summary.txt
deleted file mode 100644
index 4a7a826fb3..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060817-summary.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-- Discussion of need to announce somewhere the stabilization of "critical"
-  packages (like baselayout).  Critical packages should be announced on
-  gentoo-dev (and gentoo-user) until GLEP 42 is put into place.  When
-  appropriate, an upgrade guide should be put together with the docs team.
-  In all cases, "critical" is determined by common sense.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060817.txt b/xml/htdocs/proj/en/council/meeting-logs/20060817.txt
deleted file mode 100644
index 5bbe34544f..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060817.txt
+++ /dev/null
@@ -1,300 +0,0 @@
-18:30 -!- kloeri [n=kloeri@gentoo/developer/kloeri] has joined #gentoo-council
-18:30 -!- Irssi: #gentoo-council: Total of 17 nicks [4 ops, 0 halfops, 0 voices, 13 normal]
-18:30 -!- Irssi: Join to #gentoo-council was synced in 2 secs
-18:55 <@Koon> 18:55
-19:00 <@SwifT> ping!
-19:01 <@Koon> pong?
-19:01 <@SwifT> yes!
-19:01 <@SwifT> ping!
-19:01 <@Koon> No route to host !
-19:01 <@SwifT> okay then... tnsping!
-19:02 <@Koon> aw.
-19:02 <@Koon> It's time to start our last meeting
-19:02 <@Koon> seemant is on his way here
-19:03 <@Koon> solar: are you with us ?
-19:03 <@Koon> agriffis: same
-19:03 <@Koon> az is missing, no answer fro mvapier yet
-19:03 <@SwifT> we should all be absent so a reelection must occur ! :)
-19:03 <@Koon> about time, yes :)
-19:04 -!- seemant [n=trinity@gentoo/developer/seemant] has joined #gentoo-council
-19:04 -!- mode/#gentoo-council [+o seemant] by ChanServ
-19:04  * Koon looks around in the room to see if there are council candidates taking notes
-19:04  * SwifT watches left
-19:04 <@seemant> aha
-19:04  * SwifT watches right
-19:04 <@seemant> I was in here, but not here
-19:04  * agriffis is here
-19:04 <@seemant> irssi thought I was, but there was no activity or response
-19:04 <@seemant> so weird
-19:04 <@seemant> sorry about that, all
-19:05 <@SwifT> don't worry, always fun to see people zap in :)
-19:05 <@SwifT> okay, first point on the agenda... open floor
-19:05 <@SwifT> :)
-19:05 <@Koon> kudos to kloeri and spb then
-19:05 < kloeri> hi all :)
-19:05 <@seemant> hi bryan
-19:06 <@Koon> On the plate for today, the discussion Stuart asked for on how to better handle critical stableization steps
-19:07 <@Koon> My question to start : does GLEP42 answer to taht question (after all, it's the answer to all)
-19:07 <@SwifT> like the baselayout thingie?
-19:07 < kloeri> yeah, came up because of the baselayout stabling afaik
-19:07 <@Koon> SwifT: I think that's what started it, yes
-19:07 <@SwifT> well, I don't think GLEP42 is the answer.... but it is a major part of the answer
-19:07 <@Koon> SwifT: what's left ?
-19:08 <@SwifT> good communication of all participants prior to the news?
-19:08 <@Koon> because the pre-discussion of the GLEP42 Newsarticle on -dev serves as a dev warning
-19:08 <@SwifT> like, if baselayout stabilises, informing devs in advance or so
-19:08 <@SwifT> not blaming here, didn't follow it all
-19:09 <@SwifT> (just in case :)
-19:09 < kloeri> I think Stuart wants to go a bit further, like having upgrade guides and so on
-19:09 <@Koon> Ah. Documentation things. See SwiFT :)
-19:09  * Koon can't read.
-19:09 < kloeri> but we'd also need to decide on what 'critical packages' are if anything is to be done
-19:09 <@SwifT> i'm not active in it currently :p
-19:10 < kloeri> could define it as 'system' but that'd be a bit silly imo :)
-19:11 <@Koon> kloeri: so we would have a list of critical packages that need (1) advance warning (2) an upgrade guide and (3) a GLEP42-style news article (when available) ?
-19:11 < kloeri> yeah, I guess that's what Stuart wants
-19:11 <@Koon> if vapier was there, I'd say that common sense would do better than a rule here
-19:11  * agriffis doesn't like the sound of this, goes to read GLEP42
-19:11 <@Koon> he'd say
-19:12 < kloeri> yeah, I'm not sure I'd like to force upgrade guides etc. down the throat of some devs either
-19:13 < kloeri> GLEP42 + common sense should cover most of it imo
-19:13 <@agriffis> GLEP42 makes sense to me, i.e. a standard mechanism for distribution.
-19:13 <@Koon> + some spanking of non-observant devs
-19:13 < kloeri> agreed
-19:13 <@Koon> critical packages = baselayout, gcc, ...
-19:14 <@Koon> only for major versions
-19:14 <@agriffis> The requirement part, which doesn't seem to be part of GLEP42 anyway, bothers me because I don't like holding anything up for process.  I'd rather see things move forward without good process, rather than see things held up... of course, the best is when common sense is used and news and progress coincide :-)
-19:14 <@solar> shat. thanks seemant I was getting carried away building stuff
-19:14 <@Koon> solar: stop building :P
-19:15 <@seemant> yeah, I'm with Aron on this, I really don't like the idea of adding bureaucracy
-19:15 < kloeri> agriffis: completely agree on that - GLEP42 is a good vehicle to distribute news items but common sense is needed to decide when to use the news system
-19:15 <@seemant> (or rather, *even more* bureaucracy)
-19:16 <@solar> the world needs a new hardened-sources
-19:16 <@Koon> kloeri: also on the baselayout subjects, there were plenty of signs that it was going to stable... It's not like if they pushed it without talking to anyone
-19:16 < kloeri> Koon: right, I don't personally have a problem with baselayout going stable (as an arch lead I was asked in advance anyway)
-19:16 -!- bonsaikitten [n=pal@gentoo/developer/bonsaikitten] has joined #gentoo-council
-19:17 <@Koon> so I'd say if there had been GLEP42 in place there would have been a discussion around it and the need for a separate upgrade guide
-19:17 < kloeri> I haven't actually talked to Stuart about this but as he doesn't seem to be around I'm trying to guess what he wants
-19:17 <@seemant> now, I don't see anything wrong, per se, about having had an upgrade guide, or a "new sexy features" blurb somewhere about it
-19:17 < kloeri> seems we all agree that force / policy / whatever isn't the right solution
-19:17 <@Koon> so in essence my position on this is that GLEP42 goes a long way to solve this problem, and I'm reluctant to adding more rules where common sense usually suffices
-19:18 < Stuart> lo
-19:18 < Stuart> sorry, had to wait for an fsck
-19:18 < kloeri> Stuart: ahh, there you are :)
-19:18 <@Koon> Stuart: ah !
-19:18 <@solar> I already talked with UberLord.. There is no way on earth he diserves any flack for putting together a nice baselayout and waiting for as long as he did for other people to stop being slackers
-19:19 < Stuart> he's not getting any flack
-19:19 < Stuart> not from me, anyway
-19:19 < kloeri> I don't think it's about flack at all, more about avoiding similar problems in the future if possible
-19:19 <@Koon> Stuart: doesn't GLEP42 sufficiently answer your worries (when/if available) ?
-19:20 < Stuart> Koon: no, it doesn't
-19:20 <@Koon> Stuart: ok, please elaborate
-19:20 < Stuart> ok
-19:21 < Stuart> the issue I have is that we stabilised one of the most fundamental parts of Gentoo w/ no announcement, and no upgrade guide on www.g.o
-19:21 < Stuart> GLEP42 doesn't solve that, because a) there's nothing stopping folks making announcements today, even w/out GLEP42,
-19:21 < Stuart> and b) GLEP42 isn't an outlet for upgrade guides
-19:22 < Stuart> it's irresponsible
-19:22 < Stuart> I'm all for stabilising baselayout-1.12
-19:22 < Stuart> I'm just saying that doing so by stealth isn't good
-19:23 < Stuart> clearly, the "common sense" argument that folks love to fall back on isn't up to the job, or there'd have been an announcement and an upgrade guide
-19:23 <@Koon> Stuart: but in the newsarticle prediscussion on -dev, someone could mention the need for an upgrade guide
-19:23 <@solar> so what are you saying.. that every package in 'system' needs prior approval befoe going stable?
-19:23 <@Koon> I agree that the other problem remains
-19:24 < Stuart> solar: something that'll take out boxes, yes please
-19:24 <@solar> I've not seen any shitstorm of bugs related to it and I've updated quite a few. What major breakage was caused?
-19:25 <@Koon> solar: not only in system. The Apache new configuration style brought down quite a few web servers
-19:25 < Stuart> Koon: which is why we posted upgrade guides and plenty of announcements first :)
-19:25 < kloeri> Koon: the apache upgrade was announced quite heavily though
-19:25 <@solar> the only thing I'm aware of is a courier-imap initscript in relation to the new baselayout
-19:25 -!- dev-zero [n=BerryRyd@gw.ptr-80-238-206-183.customer.ch.netstream.com] has joined #gentoo-council
-19:25 < kloeri> Koon: just goes to show that no amount of announcements, guides etc. is going to save everybody in case of major changes :)
-19:25 <@Koon> yes, I didn't say that as an example of failure
-19:26 <@Koon> juust to prove that it's not just "system"
-19:26 < Stuart> solar: some folks had network breakages, and it was stabilised w/ a known problem w/ courier-imap.  the quality of the code isn't the issue here
-19:26 < Stuart> I'm not saying it wasn't ready to go stable
-19:26 <@Koon> to me GLEP42 is there to announce any changes that can bring down a service or a box
-19:26 -!- |jokey| [n=jokey@e176101132.adsl.alicedsl.de] has joined #gentoo-council
-19:27 < Stuart> Koon: GLEP42 is a red-herring in this discussion
-19:27 < Stuart> folks can already post announcements
-19:27 < Stuart> I'm more concerned with the fact that no-one did
-19:27 < kloeri> critical packages are hard to define imo as that set will differ from server to server, from person to person if we're to include stuff like apache etc.
-19:27 < Stuart> kloeri: I think we can agree that baselayout is a critical package :)
-19:28 <@Koon> Stuart: so you want a hard rule that critical changes should always be announced
-19:28 < kloeri> Stuart: sure but I'm not sure what else to include in that set
-19:28 < kloeri> Stuart: baselayout, toolchain, what else?
-19:28 <@Koon> because I see no way of enforcing it with our current QA system
-19:28 <@solar> Stuart: did you attempt to take this up with UberLord vs going directly to the council?
-19:28 < Stuart> solar: yes
-19:28 <@solar> what was his reaction?
-19:28 < genstef> kloeri: cups, X11
-19:29 <@solar> genstef: those dont prevent a system from booting.
-19:29 < Stuart> solar: he said that he was too busy to write one, and that folks could just read the new example file
-19:29 < genstef> solar: apache does not prevent that either
-19:29 < kloeri> solar: neither does gcc but it's probably critical to gentoo systems
-19:29 < Stuart> solar: that's not meant as a critisism of uberlord - I know he's worked hard this week to fix bugs as they've been reported
-19:30 <@agriffis> Stuart: the part that bothers me about this: emerge -upv system/world will show you that baselayout is making a relatively major version transition.  It's the administrator's responsibility to pay attention to that, in fact they should be paying close attention...  I'm not sure I agree this an issue with existing Gentoo practice.
-19:30 <@solar> genstef: and thus it's not valid
-19:30 < Stuart> agriffis: I agree, but 1.11 to 1.12 does not look like a major bump
-19:30 < kloeri> Stuart: that's a bit harsh imo - he said he was busy at work and couldn't immediately take care of any bugs / write any guides iirc
-19:30 <@agriffis> Stuart: ok, I agree with that
-19:30 <@solar> it's valid. But not vital as it wont prevent the admin from logging in and running etc-update and stuff.
-19:30 < Stuart> agriffis: and anyway, with no announcement and no upgrade guide, where can they go to read about the changes? :)
-19:31 < Stuart> kloeri: I did say I wasn't here to critise him
-19:31 <@Koon> solar: then nothing prevents you from booting anoter OS to fix the wreckage
-19:31 < Stuart> kloeri: tbh, I'm much more concerned that the arch teams thought this was acceptable :)
-19:31 <@agriffis> Stuart: I wish the versioning were more obvious.  It *is* true that etc-update or dispatch-conf will show a large delta in net.example, including a pretty exact demonstration of the changes.
-19:31 <@Koon> I'd say any non-trivial upgrades need to be announced
-19:31 < Stuart> agriffis: at that point, it's a bit late perhaps :)
-19:31 <@agriffis> Stuart: no, because at that point, it's still perfectly possible to back the version down
-19:32 < kloeri> Stuart: arch teams had been testing it for quite a while - using it to build the new release etc.
-19:32 < Stuart> kloeri: again, this isn't about the quality of baselayout-1.12
-19:32 <@solar> Koon: I'm saying as long as the box comes back up on the same interfaces as you rebooted it with. I'm not seeing any reason to try and force yet another policy.
-19:32 <@Koon> kloeri: it's not a question of stable, it's a question of upgrade
-19:32 < kloeri> Stuart: but no (reasonable) amount is going to catch all problems unfortunately
-19:32 < Stuart> kloeri: it's about providing folks with a bit more help than just some code dumped on their harddrive :)
-19:32 < kloeri> Koon: yeah, but people have been testing upgrades too
-19:33 < Stuart> agriffis: mmm ... how well do we test downgrading baselayout upgrades?
-19:33 <@agriffis> Stuart: I've done it plenty
-19:33 < Stuart> agriffis: cool
-19:33 < kloeri> it's not that I'm against upgrade guides or anything, I'm just saying that the new baselayout saw quite a bit of testing before being stabled
-19:33 <@agriffis> though I won't claim I make a practice of testing each possible downgrade path :-b
-19:33 <@Koon> Stuart: how about this rule : any non-trivial upgardes should be announced (with GLEP42 when available, on -dev in the meantime)
-19:34 < Stuart> Koon: I'd be very happy w/ that
-19:34 <@Koon> again, that's common sense but better write it down
-19:34 <@solar> who defines non trivial?
-19:34 < Stuart> Koon: not that common, or else at least one of the folks involved in this stabilisation would have done it :)
-19:34 <@Koon> non-trivial = you can't keep your config files the way they are
-19:35 < Stuart> Koon: that's a good definition
-19:35 <@solar> thats going to upset gregkh
-19:35 < Stuart> solar: greg makes a living upsetting folks. he'll cope
-19:36 <@Koon> so you have to announce it when you break forward-compat
-19:36 <@agriffis> greg doesn't cope, he fights back, and in the gentoo case, he'd probably just quit
-19:36 <@Koon> solar: gregkh ? on udev ?
-19:36 < Stuart> he'd quit over being asked to keep users informed when things aren't b-c anymore?
-19:36 <@solar> Stuart: tbh.. To me it really sounds like 42 will cover this. and it was simply a matter of really what he said. not enough freetime and or he saw it as trivial.
-19:37 <@solar> I'd really not like to try and enforce this. But just encourage others to try to be more careful
-19:37 <@Koon> solar: the thing is no rule forces you to announce anything, GLEP42 or not
-19:37 < Stuart> solar: 42 is just an outlet. no-one is required to use it
-19:38 <@agriffis> Stuart: I don't know what gregkh would do, I have no idea how attached he is to Gentoo.  However announcing every udev b-c breakage is *way* harder than the existing process of simply bumping it.
-19:38 <@agriffis> That's a good example, really, because it suggests to me that the *rule* of informing when b-c breaks might be too much.
-19:39 <@Koon> I think that's the minimum that is due to the users
-19:39 <@agriffis> I'm all about making devel easier, it's nearly the only thing I care about in the context of Gentoo.
-19:40 < Stuart> there has to be a balance
-19:40 <@Koon> anyway, the best is probably to GLEP the rule as I spelled it, throw it to gentoo-dev and see it go down in flames or survive the test
-19:40 <@agriffis> I can see it as a rule of thumb, but not something I'd like to see enforced by anything other than shaming of devs that break systems by not informing.
-19:40 <@agriffis> i.e. by not providing instructions/guide/etc.
-19:41 < Stuart> agriffis: and if that doesn't work?
-19:41 <@Koon> agriffis: there is no way to enforce it anyway
-19:41 <@Koon> except call devrel in for repeated "errors"
-19:42 -!- jokey [n=jokey@gentoo/developer/jokey] has quit [Connection timed out]
-19:42 <@agriffis> Koon: sure there is.  we've seen devs ejected because we set up rules, then had to enforce them, where "we" is gentoo not necessarily the council.
-19:42 <@agriffis> Any time you make a rule you have to think about enforcement, somebody's going to file a bug and want you to enforce it eventually.
-19:42 <@Koon> I still think announcing b-c breaks to the users is a minimum
-19:43 <@agriffis> I dunno, maybe this is a *good* one for that, but I'm just slow to make rules. :-)
-19:43 <@Koon> but maybe nobody is with me and Stuart on this one :)
-19:43 <@agriffis> Koon: for what set of packages?
-19:43 <@Koon> I'd say "all" in stable
-19:44 <@Koon> it's not that common
-19:44 <@agriffis> ok, and what consitutes "announcing"?
-19:44 <@SwifT> damnid... guys, I need to go, some incident at work
-19:44 <@Koon> use GLEP42-system when available, use -dev in the meantime
-19:44 <@solar> my fear is that you put such a rule in place.. Then you have a dev that has not upgraded in many moons. He forgets to etc-update; reboots and his services dont all start.. users start calling him. he starts screaming cuz he did not get a upgrade guide.
-19:44 <@Koon> SwifT: that's not a good way to end your Council term :P
-19:45 < Stuart> agriffis: a minimal "we're releasing blah on set date; it breaks your system; go here to read what to do about it"
-19:45 < Stuart> solar: said dev'd quickly get his ass handed back to him for wasting folks time, I'd hope
-19:45 <@Koon> This should definitely be discussed on -dev as a GLEP rather than here
-19:46 <@solar> Stuart: sorry but I feel like this is what has happened here.
-19:46 -!- kallamej [n=kallamej@gentoo/developer/kallamej] has joined #gentoo-council
-19:46 < Stuart> solar: ??
-19:46 <@Koon> and the next council can adopt it with everything balanced
-19:46 < Stuart> Koon: that sounds sensible to me
-19:47 <@solar> Stuart: cuz the upgrade was rather painless tbh. Nothing to major broke. All boxes I've rebooted came back up on the same IP's and all services started.
-19:47 <@solar> imap is the only thing I really am aware of.
-19:47 < kloeri> personally I think it's going to be very hard to define any reasonable rules for this
-19:48 <@Koon> solar: the point is nothing prevents a larger break to occur
-19:48 <@solar> Can you point at some bugs as reference
-19:48 <@solar> Koon: yeah I know nothing prevents it.
-19:48 < genstef> solar: there is a tracker bug
-19:48 < kloeri> one of the problems with the baselayout upgrade afaik was related to the GATEWAY variable - and that's been deprecated for more than a year now
-19:48 < Stuart> solar: I keep saying that it's not about the quality of the code
-19:48 < kloeri> so how far back should upgrade guides go?
-19:48 <@Koon> solar: and there is no rule/advice on how to handle b-c breaks in Gentoo
-19:48 < genstef> solar: http://bugs.gentoo.org/143988
-19:49 < kloeri> we don't have any formal ideas about which versions we still support
-19:49 < Stuart> kloeri: I'm happy w/ upgrade guides only going back as little as possible
-19:49 <@agriffis> so here's a question... is a guide needed, or does a warning suffice?  "Warning: This upgrade contains config changes that are not backward compatible.  Be careful when etc-updating!"
-19:50 <@agriffis> Is it an announcement that's needed, or a guide?
-19:50 <@Koon> agriffis: to me, an announcement
-19:50 < Stuart> agriffis: in general, folks like apache, php, gcc, X and java have tended to post guides as well as warnings
-19:50 < genstef> agriffis: it would be nice if we had an announcement on -dev one day before
-19:51 <@Koon> when the announcement is posted, someone else can write up a guide if he wants to
-19:51 < genstef> agriffis: like I will be marking baselayout stable, any blockers?
-19:51 <@agriffis> I'm not suggesting to drop guides, I think they're *great* and I've made use of them before, but I'm wondering what's the lower limit that a dev could provide to fulfill due diligence.
-19:51 < Stuart> agriffis: for stuff that's gentoo-specific, if we don't provide a guide, where is a user going to get the information from? :)
-19:51 <@solar> agriffis: einfo/elog seems ok to me
-19:52 <@Koon> agriffis: the rule can be to announce it. If the discussion that ensues shows the need to have a guide, then someone can step up and write it, but the rule doesn't require it
-19:52 <@agriffis> Stuart: baselayout has net.example which is kept religiously up to date.  A diff, given by etc-update or dispatch-conf, shows clearly what has changed.  So a warning to Be Careful in that case would seem to be sufficient, that is to fulfill bare miminum requirements.
-19:52 < Stuart> solar: something that folks can read before upgrading would be useful, if there's any prep required (like having some free time to rewrite the config files)
-19:53 <@agriffis> Koon: so if the discussion decides that a guide is needed, and the dev who is not *writing* a package but only maintaining the ebuild is not able to provide the guide, and nobody steps up to write one, then a warning about b-c breakage would suffice?
-19:53 <@agriffis> I'm sorry, I'm not wanting to split hairs here, or drive anybody crazy...
-19:53 <@Koon> agriffis: for me, yes. But I won't be the one that will vote the GLEP when it will be written anyway
-19:54 < Stuart> agriffis: why wouldn't the dev be able to provide the guide?
-19:54  * Stuart is suffering packet loss atm :(
-19:54 <@Koon> Stuart: he can, but he doesn't have to
-19:54 <@agriffis> I'm trying to understand how to keep things super-easy for devs in the minimal case, so that nothing gets clogged by the introduction of new requirements.
-19:54 <@agriffis> Stuart: time, desire, etc.
-19:54 <@Koon> Stuart: the mimimum enforced is the announcement
-19:54 <@solar> From that tracker only 143914 seems like it could cause an admin from not being able to log inyto a remote host
-19:55 < genstef> agriffis: well, if the punishment is a "hall of shame" in the GWN then I think that can be made a requirement, yes
-19:55 <@agriffis> I think udev is a fantastic example.  There's no (gentoo-specific) upgrade guide, I don't want to require greg to start providing one, or make him wait for another dev to write one.
-19:55 <@Koon> Stuart: but once again, this should be GLEPped, and our advice is worth almost nothing since we won't be voting it, this is our last meeting
-19:55 <@agriffis> Btw, there is a very good Gentoo udev guide, I'm not talking about that.  I'm referring to udev changes between version stabilization.
-19:56 < Stuart> does greg maintain a non-gentoo-specific upgrade guide?
-19:57 <@agriffis> Stuart: sorry, I left that open because I don't know
-19:57 < genstef> Stuart: greg deo snot maintain udev upstream, kay sievers does that
-19:57 <@agriffis> deo snot, eh? ;-)
-19:57 < genstef> Stuart: in fact udev in gentoo is often not up to date because greg has not much time
-19:58 < Stuart> I'd be happy w/ just announcements for now, and see how it goes
-19:58 <@solar> Stuart: pre install would be unneeded in most cases. etc-update and having the instructions/examples in/around the # $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/Attic/20060817.txt,v 1.1 2006/09/12 22:38:05 kloeri Exp $ comments should be fine.
-19:59 <@solar> I have to leave. I think I have about the same view point as agriffis here. einfo/elog preinst if needed. I'd go for suggesting people just try to do a better job next time vs shoving another rule down peoples throats.
-20:00 < Stuart> solar: I couldn't agree w/ you less wrt etc-update being good enough
-20:00 <@Koon> OK, let's end the meeting then, this should be GLEped and discussed on -dev anyway
-20:00 <@agriffis> well, I think at least this discussion has provided a good starting point for any discussion on -dev.
-20:00 <@solar> I'm rejected it now
-20:00 <@solar> n/m a glep.
-20:00 <@Koon> thanks everyone for this year, it was great to work with you all guys
-20:01 <@Koon> and good luck to the next Council
-20:01  * kloeri waves goodbye to the old council :)
-20:01 <@solar> you guys try to be on baselayout and see how little gets done with this rule
-20:01 <@solar> base-system rather
-20:01 < Stuart> solar: having a QA guy complain about being asked to tell folks when stuff breaks ... that doesn't look very good :)
-20:02 <@Koon> Stuart: solar has many personalities
-20:02 < Stuart> anyway, appreciate you all discussing this at short notice
-20:02 <@agriffis> Hey guys, I had a good time on Council this year.  It's been a fun team through some ups and downs.  Thank you.
-20:02 < Stuart> and waiting for my hard drive to finish fsck'ing :)
-20:03 <@solar> Stuart: I understand that breakage sucks really bad. I'm just saying putting a rule into place for everything everytime something goes a little left is not ideal for such a organic distro
-20:03 <@agriffis> Koon: will you be posting the minutes and log?
-20:03 <@solar> we should focus on improving common sense vs alot of rules. thats all
-20:03 <@Koon> agriffis: no, I don't have the log
-20:04 <@agriffis> ok, I have it
-20:04 <@agriffis> I can post it and the meeting summary if that's okay with everybody.
-20:04 < genstef> http://genstef.homelinux.org/gentoo-council.08-17.log
-20:05 < Stuart> solar: I agree with the sentiment, but the reality is a little different
-20:05 <@solar> Stuart: I just want gentoo to remain fun.
-20:05 < genstef> Stuart: how would you enforce such a rule, btw?
-20:05 < Stuart> solar: so do I.  but we have to have fun responsibly
-20:06 < Stuart> genstef: ideally, the arch teams should enforce it, because they stabilise packages, not package maintainers
-20:06 <@solar> Stuart: I think you should just try to encourage people to be a little more aware. If it becomes a major problem over time then revisit.
-20:07 < Stuart> solar: I'd rather take a little step now, and avoid there ever being a major problem
-20:07 <@solar> well I just hope the next council decides to not try and enforce such a thing.
-20:08 <@solar> cuz it sounds like a bunch of nofun.
-20:08 < genstef> do we have a stabilization guide? Maybe just add a line "when it is an important update, please inform users before marking it stable"
-20:09 <@solar> it passed the QA tests of every arch team.
-20:10 <@solar> genstef: sure. notice the wording on that. "please"
-20:10 <@solar> which differs from required. Don't get me wrong. I'm not saying it's ok to break things left and right.
-20:11 <@solar> things just change. Sometimes in unforseen ways that are unknown at the time of the stable marking.
-20:12 < Stuart> solar: and that's fair enough
-20:12 <@solar> k now I gotta split. Have fun guys.. And please keep gentoo fun for everybody :)
-20:12 < Stuart> cya solar
-20:15 -!- Koon [n=koon@gentoo/developer/Koon] has quit ["have fun"]
-20:15 -!- Stuart [n=stuart@gentoo/developer/Stuart] has left #gentoo-council []
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060914-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20060914-summary.txt
deleted file mode 100644
index 7e47fc0ae5..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060914-summary.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-First, we voted if we should allow "impromptu" meetings, outside of the
-monthly schedule.  This passed with 6/7 votes, with vapier abstaining
-due to tardiness.  The consensus on the meetings is as follows:
-
-We will allow meetings outside of the schedule on time sensitive issues.
-The meeting needs more than 5 council members, and it should be done
-with no less than 3 days notice, unless the council unanimously decides
-to hold it sooner.
-
-Next were concerns brought about from the QA team.  We decided (6/7,
-vapier abstaining) that the QA team should work with other concerned
-parties to determine the requirements for moving the devmanual SVN to
-Gentoo infrastructure, since it is considered an official Gentoo
-product, before any further decision on it can be made.  It was also
-decided that the QA team should work on their own policies, with input
-from other teams, for approval by the council.  The council volunteered
-to assist in coordination, if necessary.
-
-Next, we decided to push the monthly meetings to 2000UTC on the second
-Thursday of the month to better suit the new council's availability.
-
-During the open floor, we decided that there was no need to mention
-conflicts for most council members, as we should all be adults and
-capable of making unbiased decisions.  The exception to this (being
-adults... just kidding...) was kloeri in response to escalations from
-devrel, as he is the lead there.  This also lead to roll-call being
-updated to show everyone's current roles, so transparency is maintained.
-
-After some minor discussion about USians not knowing their own country
-code (*grin*) we adjourned.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20060914.txt b/xml/htdocs/proj/en/council/meeting-logs/20060914.txt
deleted file mode 100644
index b675645bcf..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20060914.txt
+++ /dev/null
@@ -1,520 +0,0 @@
-[19:05] *** You set the channel mode to 'moderated'.
-[19:05] <Flameeyes> i suppose the timing decision can wait till vapier comes (if he's just late)
-[19:05] <Kugelfang> there we got
-[19:05] <Kugelfang> -t
-[19:06] <Flameeyes> especially as he seems to need to change that :)
-[19:06] <wolf31o2|mobile> yeah, we can hold that one off until near the end
-[19:06] <-- GurliOnTheRoad has left this server (Read error: 60 (Operation timed out)).
-[19:06] <kingtaco|laptop> or just email it
-[19:06] <Kugelfang> heh
-[19:06] <kingtaco|laptop> should be a no brainer
-[19:06] <kingtaco|laptop> anywho
-[19:06] <wolf31o2|mobile> true... we don't need that to be done during the official meeting, really
-[19:07] <Flameeyes> so we can either start with antarus|work's topic or with wolf31o2|mobile's, which one first?
-[19:07] <Kugelfang> wolf
-[19:07] --> ChrisWhite|Work has joined this channel (n=chris@gentoo/developer/ChrisWhite).
-[19:07] <Flameeyes> ack wolf for me too
-[19:07] <kingtaco|laptop> do it
-[19:07] <Kugelfang> wolf31o2|mobile: you have the floor
-[19:08] <wolf31o2|mobile> err... well, there's probably two different questions... the first is; can the council make a decision without it being put on an agenda and have to wait for the monthly meeting?
-[19:09] <kingtaco|laptop> that's why I suggested a 2nd meeting if there was something to discuss
-[19:09] <Kugelfang> i say yes, while this decision should be only intermediate until a proper meeting takes place
-[19:09] <kloeri> I'd say yes as long as we use some common sense, eg. don't rush GLEPs through without prior discussion
-[19:09] <Flameeyes> i'd say yes, for urgent matters or non-controversial decisions
-[19:10] <wolf31o2|mobile> ok... so what is considered an urgent matter?
-[19:10] <Kugelfang> that's up to us :-)
-[19:11] <Flameeyes> decisions that has to be discussed upon asap or they might "fly away"... probably depends on what the issue is
-[19:11] <wolf31o2|mobile> heh... I'd be fine with that
-[19:11] <kloeri> ditto
-[19:12] <wolf31o2|mobile> ok... so we allow "impromptu" meetings, at our own request, to discuss possible time-sensitive issues?
-[19:12] <Flameeyes> kingtaco|laptop, robbat2?
-[19:12] <kingtaco|laptop> sure
-[19:12] <Kugelfang> vote with yes or no
-[19:12] <Kugelfang> yes
-[19:12] <kloeri> yes
-[19:12] <Flameeyes> yes
-[19:12] <kingtaco|laptop> yes
-[19:12] <robbat2> yes, common sense to delay things that have unanswered issues still, but be more flexible in allowing
-[19:12] <wolf31o2|mobile> yes
-[19:12] <Kugelfang> 6 of 7, vapier is late, this one passed
-[19:12] <wolf31o2|mobile> ok... and how many should we require present to have one of these meetings?
-[19:13] <Kugelfang> 5
-[19:13] <wolf31o2|mobile> 4+? 5?
-[19:13] <Flameeyes> Kugelfang, which one passed? both or just the first?
-[19:13] <Kugelfang> more than the half and an odd number
-[19:13] <Flameeyes> 5
-[19:13] <kingtaco|laptop> 5+
-[19:13] <robbat2> 5+
-[19:13] <wolf31o2|mobile> agreed
-[19:13] <Kugelfang> Flameeyes: the first one
-[19:13] <-- GurliGebis has left this server (No route to host).
-[19:13] <Flameeyes> what about the slacker rule for such meetings?
-[19:13] <kloeri> 5+ sounds good
-[19:13] <Kugelfang> i think we have consense of 5 council members
-[19:13] <Flameeyes> should it still rule?
-[19:13] <Kugelfang> Flameeyes: applies only to regular meetings
-[19:13] <kingtaco|laptop> I don't think so
-[19:14] <Flameeyes> Kugelfang, agreed
-[19:14] <kloeri> no, regular meetings only imo
-[19:14] <wolf31o2|mobile> I don't think the slacker rule shoudl count, since it is impromptu, and we don't allow the meeting if we have below the proper threshol
-[19:14] <wolf31o2|mobile> +d
-[19:14] <Flameeyes> so even the second one passed
-[19:14] <Kugelfang> robbat2?
-[19:14] <kingtaco|laptop> how much notice for one of these meetings?
-[19:14] <kingtaco|laptop> 7days?
-[19:14] <kingtaco|laptop> list 2 possible times?
-[19:15] <robbat2> no slacker rule, because we do need time to get ourselves
-[19:15] <wolf31o2|mobile> I would think "impromptu" means it should be possible on the spur of the moment
-[19:15] <Kugelfang> let's say more than 5 days
-[19:15] <Kugelfang> means: we can say on monday "We'll discuss it" and act on firday
-[19:15] <Flameeyes> i'd say the time needed, after all if it's "on the fly", we might need it now
-[19:15] <Kugelfang> friday... i think that's a good rule of thumb...
-[19:15] <Kugelfang> Flameeyes: you mean: no limit at all?
-[19:15] <robbat2> 3 days, or as long as every council member (all 7 of us) agree we need to meet on it immediately
-[19:16] <kingtaco|laptop> that works
-[19:16] <wolf31o2|mobile> sure
-[19:16] <Flameeyes> i like robbat2's solution
-[19:16] <Kugelfang> i like robbat2's proposal
-[19:16] <Kugelfang> heh
-[19:16] <robbat2> 3 days gives us space for the 5+ people, but if it's really urgent, people will find a way to get us
-[19:16] --> dostrow has joined this channel (n=dostrow@gentoo/developer/dostrow).
-[19:17] <wolf31o2|mobile> so... allow meetings outside of the schedule on time sensitive issues, the meeting needs more than 5 members, and it should be done with no less than 3 days notice, unless the council unanimously decides to hold it sooner?
-[19:17] <Kugelfang> yes
-[19:17] <robbat2> yes
-[19:17] <wolf31o2|mobile> (that should cover everything)
-[19:17] <Flameeyes> at least 5 members
-[19:17] <wolf31o2|mobile> yes
-[19:17] <Flameeyes> (>= rather than >)
-[19:17] <wolf31o2|mobile> it says that
-[19:18] <Flameeyes> and yes on that anyway
-[19:18] <wolf31o2|mobile> err... ok
-[19:18] <robbat2> good point Flameeyes
-[19:18] <wolf31o2|mobile> 5+
-[19:18] <wolf31o2|mobile> heh
-[19:18] <Kugelfang> yes
-[19:18] <kingtaco|laptop> yes
-[19:18] <Flameeyes> kloeri, wolf31o2|mobile?
-[19:19] <wolf31o2|mobile> <wolf31o2|mobile> yes
-[19:19] <Kugelfang> wolf31o2|mobile said yes already
-[19:19] <Flameeyes> okay, so kloeri?
-[19:19] <Kugelfang> kloeri honey, we're waiting
-[19:19] <kloeri> sounds good
-[19:19] <Kugelfang> excellent
-[19:20] <Kugelfang> i think this point is done then, isn't it?
-[19:20] <Flameeyes> i'd say so
-[19:20] <robbat2> yup
-[19:20] *** You give antarus|work the permission to talk.
-[19:20] <Kugelfang> i still wonder where vapier is
-[19:20] <Flameeyes> antarus|work, are you here?
-[19:20] <robbat2> unless wolf31o2 wanted to say more about the possible 4th thursday
-[19:20] <kingtaco|laptop> we'll do this instead
-[19:21] <kingtaco|laptop> works better
-[19:21] <wolf31o2|mobile> yeah... doesn't restrict us to a time
-[19:21] <robbat2> ok
-[19:21] <wolf31o2|mobile> so we can be like "hey, friday at 5:30 works for me"
-[19:22] <Flameeyes> strange tho that mike is this late
-[19:22] <Flameeyes> kingtaco|laptop, not you :P
-[19:22] <Kugelfang> does anybody have his cell phone number?
-[19:22] <Kugelfang> oh, that reminds me, shall we exchange contact information via the alias?
-[19:23] <robbat2> yes
-[19:23] <Flameeyes> i suppose that's good
-[19:23] <Kugelfang> robbat2: yes to what?
-[19:23] <robbat2> yes to contact info
-[19:23] <Kugelfang> good, let's do it right after the meetings :-)
-[19:23] <Kugelfang> -s
-[19:23] <Kugelfang> shall we proceed with antarus then?
-[19:23] <wolf31o2|mobile> did Mike get a new cell phone? last I knew (LWE) his was somewhere in a gutter in Shanghai
-[19:24] <wolf31o2|mobile> let's
-[19:24] <Flameeyes> wolf31o2|mobile, ouch, that's bad
-[19:24] <Kugelfang> antarus|work: you have have the floor
-[19:25] * kloeri pokes antarus|work 
-[19:25] <antarus|work> er
-[19:25] <antarus|work> sorry
-[19:25] * antarus|work is back!
-[19:26] <Kugelfang> sure, just give us some beer and we'll forget about it :-P
-[19:27] <Flameeyes> or just talk, that works too
-[19:27] <antarus|work> Quiet you :p
-[19:27] <antarus|work> Moreso I think the current QA policy doesn't work completely
-[19:28] <kingtaco|laptop> explain
-[19:28] <antarus|work> The current policy seems rather vague in areas; to both users and developers
-[19:29] <Kugelfang> which areas
-[19:29] <antarus|work> things like having packages build properly; releng will tell you that it should build properly with default USE flags; Ciaran will tell you it should build properly with the ebuild choosing sane flag defaults
-[19:30] <Kugelfang> well, both sounds sane to me, we gotta find a way in the middle here
-[19:30] <antarus|work> At least for me; the QA team should not be the guys who fix stuff; the team is too small and the amount of work too large.
-[19:30] <wolf31o2|mobile> well, I'd say that both should be true... ;]
-[19:30] * antarus|work doesn't expect the council to come up with new policy ;)
-[19:31] <Kugelfang> antarus|work: i think we should expand the QA team then
-[19:31] <antarus|work> Kugelfang: How?
-[19:31] <Flameeyes> i think one of the point should be that no qa should be enforced unless the policy is properly agreed upon
-[19:31] * antarus|work would rather have QA policy that is followed; then qa that is ignored
-[19:31] <Kugelfang> antarus|work: get people to search for QAcanfix keyword and fix it
-[19:32] <antarus|work> Kugelfang: eh, and if that doesn't work?
-[19:32] <kingtaco|laptop> why don't you revise/rewrite the policy to resolve these problems you see and then we can look at that?
-[19:32] <wolf31o2|mobile> agreed... I think we need a policy to look at and agree to... we can still discuss, to help brainstorm some ideas, btu we can't really decide on a concept so much
-[19:33] <wolf31o2|mobile> I mean, we'll all agree "we need good qa"
-[19:33] <Flameeyes> agreed, we should have a policy to look at before decide on most of the matters there, or we're not making a point
-[19:33] <antarus|work> wolf31o2|mobile: are you willing to sacrifice people for it?
-[19:33] <kloeri> wolf31o2|mobile: right
-[19:33] <Flameeyes> eh, what wolf31o2|mobile said basically
-[19:33] <wolf31o2|mobile> antarus|work: sacrifice, meaning?
-[19:34] <Kugelfang> antarus|work: you mean like: remove persistent offenders, or at least suspend them?
-[19:34] <wolf31o2|mobile> if you mean have disciplinary action taken against repeated offenders, then absolutely... but that's not our job, perse
-[19:34] <antarus|work> Kugelfang: yes
-[19:34] <wolf31o2|mobile> but I would definitely back that action being taken
-[19:34] <Kugelfang> antarus|work: write it up. i'm not against it per se
-[19:34] <Flameeyes> agreed
-[19:35] <antarus|work> wolf31o2|mobile: I think moreso the thought is 'I can break QA and essentially have no reprecussions"
-[19:35] <kloeri> devrel would be happy to suspend or kick off repeat offenders based on proper complaints from qa
-[19:35] <antarus|work> which is obviously a problem
-[19:35] <wolf31o2|mobile> right
-[19:35] <Flameeyes> antarus|work, i think the problem is we don't have an *official* policy
-[19:35] <Kugelfang> Flameeyes: actually, we have, GLEP 39 iirc
-[19:35] * antarus|work notes having a half-dead qa team for large amounts of time
-[19:35] <kloeri> antarus|work: document the offences and complain to devrel after you warned the offender
-[19:35] <antarus|work> Kugelfang: 48 you mean?
-[19:35] <robbat2> i'm not sure that suspend/kick directly is the right solution - re-education first
-[19:36] <Flameeyes> Kugelfang, no i mean, there are still obsure points
-[19:36] <antarus|work> robbat2: I would agree; can't be too hasty ;)
-[19:36] <Kugelfang> antarus|work: eh, yes
-[19:36] <Flameeyes> devmanual wasn't updated in its entirety and there are still debatable points
-[19:36] <Kugelfang> Flameeyes: devmanual was discusses on QA meeting, i attended there
-[19:36] <kloeri> robbat2: qa would need to warn etc. before filing a devrel complaint or I'll bounce it back
-[19:36] <Kugelfang> Flameeyes: the turnout was, unsatisfactory to say the least
-[19:37] <Flameeyes> Kugelfang, can you summarise?
-[19:37] <antarus|work> Flameeyes: I have the log..
-[19:37] <Kugelfang> spb just asked for voice
-[19:37] <Kugelfang> he can if you want
-[19:37] <antarus|work> Flameeyes: it's not pretty :P
-[19:37] <Flameeyes> antarus|work, that's why i asked a summary
-[19:37] *** You give spb the permission to talk.
-[19:37] *** kloeri gives spb the permission to talk.
-[19:38] <Kugelfang> uh, i have op here...... forgot competely :-P
-[19:38] <kloeri> Kugelfang: :)
-[19:38] <spb> the summary, in short terms and based on what i remember, goes something like this
-[19:38] <spb> first item devmanual. it's listed as a qa project yet qa has no access to it, we don't like this, but plasmaroo is resisting any change
-[19:39] <spb> then there was the lack of any properly documented qa policy, which we would like to fix
-[19:39] <Kugelfang> this has to be relevated: plasmaroo doesn'T want to give out SVN access to anybody.. he said he'd include patches as soon as he gets them
-[19:39] <antarus|work> relevated?
-[19:40] <Flameeyes> antarus|work, made notice of
-[19:40] <Kugelfang> plasmaroo is resisting any change
-[19:40] <Kugelfang> ^^^
-[19:40] <antarus|work> Flameeyes: thanks ;)
-[19:40] <spb> also the EAPI-0 spec / package manager standard / whatever you want to call it
-[19:40] <wolf31o2|mobile> what is required to move the devmanual to gentoo infrastructure? and has there been a problem getting patches accepted, so far? (in other words, has the current process proven broken)
-[19:41] <Kugelfang> wolf31o2|mobile: the SVN repo is on halcy0n.org
-[19:41] <Kugelfang> wolf31o2|mobile: it could easily be moved
-[19:41] <spb> wolf31o2|mobile: what's required is an svn repo and someone having access to whichever box hosts devmanual.g.o to pull updates from svn manually
-[19:41] <Kugelfang> i think that can be automated
-[19:41] <spb> at the moment the svn is external and only one person has the latter
-[19:41] <wolf31o2|mobile> it would need to be...
-[19:41] <wolf31o2|mobile> and what about my second question?
-[19:42] <antarus|work> wolf31o2|mobile: No one has submitted actual patches; as far as I'm aware
-[19:42] <Kugelfang> answer is no
-[19:42] <Flameeyes> i think wolf's second question is the important one here
-[19:42] <spb> there's a bug open with some needed changes; it had no response until he was asked in the qa meeting yesterday why that was, at which point he said he was waiting for patches
-[19:42] <spb> which is fine as long as he says he's waiting for patches
-[19:42] * antarus|work nods
-[19:42] <wolf31o2|mobile> ok
-[19:43] <antarus|work> communication was a bit slow there
-[19:43] <wolf31o2|mobile> so now we all know
-[19:43] <wolf31o2|mobile> =]
-[19:43] <spb> we do
-[19:43] <spb> what exactly it is that we know is left as an exercise for the reader
-[19:43] <antarus|work> I guess my last question is; is there a better way to create policy besides doing it internally to QA
-[19:43] <Kugelfang> i can understand that plasmaroo doesn't want every dev to have commit access, on the other hand i think that the Gentoo devmanual should be in Gentoo SVN
-[19:43] <kloeri> there's another problem of backups that nobody have addressed afaik (which would point towards hosting it on gentoo svn)
-[19:44] <spb> my assumption there is that qa drafts something and sends it to $other_party for review
-[19:44] <Flameeyes> i think we shouldn't really try to force anything until it's proven broken, to use wolf's words
-[19:44] <antarus|work> Flameeyes: I was thinking moreso; of making some kind of sub-project
-[19:44] <robbat2> Kugelfang, on Gentoo SVN/CVS we do offer access restrictions if desired
-[19:44] <antarus|work> where we invite people interested in forming poicy
-[19:44] <wolf31o2|mobile> your second point... the qa policy... I think we all agree that we'd like to see one hammered down... what do you need for that to happen?
-[19:44] <Kugelfang> robbat2: i know, i use them for eselect :-P
-[19:44] <antarus|work> maybe thats just too gay
-[19:44] <antarus|work> I dunno :p
-[19:45] * antarus|work spices up the council logs
-[19:45] <Flameeyes> antarus|work, you mean people not involved in the qa project itself?
-[19:45] <antarus|work> Flameeyes: yes
-[19:45] <Flameeyes> separating legislative from executive, basically
-[19:45] <Kugelfang> antarus|work: well, as was already said: come up with a proposal and council can discuss
-[19:46] <antarus|work> Flameeyes: Yeah, basically ;)
-[19:46] <Flameeyes> agreed, we need something to look at to decide, we can only think of the concept this way
-[19:46] <spb> wolf31o2|mobile: for QA policy i suspect just time and the right people
-[19:46] <wolf31o2|mobile> actually... let's do this... for issue #1, the devmanual, there's not been anything shown to be necessarily broken, but points were brought up why moving it to gentoo infrastructure would be desirable... I say we defer on any decision regarding this until a plan has been put in place for migration, as well as any requirements from/for infra... as in, scripts to automate pulls from SVN and access restrictions that need to be p
-[19:46] <wolf31o2|mobile> laced... agreed?
-[19:47] <robbat2> yes
-[19:47] <Flameeyes> yes
-[19:47] * antarus|work was hoping to avoid the devmanual entirely in this meeting ;P
-[19:47] <Kugelfang> yes
-[19:47] <wolf31o2|mobile> yes
-[19:47] <wolf31o2|mobile> heh
-[19:47] <kloeri> yes
-[19:47] <Kugelfang> kloeri: ?
-[19:47] <Kugelfang> kingtaco|laptop: ?
-[19:47] <Kugelfang> kloeri: sorry
-[19:47] <Kugelfang> :-)
-[19:49] <kingtaco|laptop> what are we voting on?
-[19:49] <kingtaco|laptop> that qa needs to be defined?
-[19:49] <Kugelfang> 19:46 <@wolf31o2|mobile> actually... let's do this... for issue #1, the devmanual, there's not been anything shown to be necessarily broken, but points were brought up why moving it to gentoo infrastructure would be desirable... I say we defer on any decision regarding this until a plan has been put in place for
-[19:49] <Kugelfang> migration, as well as ny requirements from/for infra... as in, scripts to automate pull s from SVN and access restrictions that need to be p
-[19:49] --> iluxa has joined this channel (n=anonymou@gentoo/developer/iluxa).
-[19:49] <kingtaco|laptop> yes
-[19:49] * antarus|work will talk to qa about creating a subproject for policy authoring then
-[19:50] <antarus|work> a cross-project subproject ;P
-[19:50] * spb doesn't see the point
-[19:50] * antarus|work nods
-[19:50] <wolf31o2|mobile> re: qa policy... from the discussion here, we'd really like something that we can look at and say that we'd stand behind it 100%... I would say that the best thing would be to try to come up with a somewhat representative (and informal) group to assist in writing/modifying existing policy...
-[19:50] <Flameeyes> wolf31o2|mobile's decision is then agreed upon, 
-[19:50] <Kugelfang> spb, antarus|work: please get in contact with infra to work out details of a possible migration
-[19:50] <antarus|work> Kugelfang: I'll do that
-[19:50] <Kugelfang> wolf31o2|mobile: that one needs no vote :-P
-[19:51] <wolf31o2|mobile> qa heads it up... and again, it doesn't have to be formal... since i'm not sure I see the point... but, for example, you'd probably want to grab a bug-wrangler or two... and some toolchain people, etc
-[19:51] <Flameeyes> and arches
-[19:51] * antarus|work nods
-[19:51] <Kugelfang> wolf31o2|mobile: don't forget releng!
-[19:51] --> nephros has joined this channel (n=nephros@gentoo/userrep/nephros).
-[19:51] <wolf31o2|mobile> Kugelfang: right... heh... I'm just trying to rephrase some stuff that's spread over lots of lines into something coherent
-[19:51] <antarus|work> wolf31o2|mobile: you've been doing a great job too ;)
-[19:52] <wolf31o2|mobile> spb: you had something to say about the EAPI thing? it kinda got lost
-[19:52] <Kugelfang> wolf31o2|mobile: that was part of the QA meeting summary
-[19:52] <spb> i think the conclusion there was that it's probably best as it is for the moment, since the bulk of the work has been/is being done by a non-current-developer
-[19:53] <spb> once it's got some substance to it i'm thinking in terms of forming it into a glep that you guys can vote on
-[19:53] <kingtaco|laptop> wfm
-[19:53] <wolf31o2|mobile> WFM
-[19:53] <wolf31o2|mobile> =]
-[19:53] <Kugelfang> i can say it looks promising already
-[19:53] <robbat2> works
-[19:53] <spb> if nothing else, the introduction of it would be a fairly major change to the way we do things
-[19:53] <Flameeyes> wfm2
-[19:53] * kloeri agrees
-[19:54] * antarus|work shall go poof now
-[19:54] <spb> there's a slight question of who would maintain it once that happens, but we can deal with that later
-[19:54] <antarus|work> unless you need more from me?
-[19:54] <Kugelfang> if you guys want to look at it: http://svn.pioto.org/viewvc/paludis/scratch/eapispec/EAPI-0.txt?view=markup
-[19:54] <wolf31o2|mobile> antarus|work: I think we're good
-[19:54] <antarus|work> wolf31o2|mobile: cool, thanks for the input.
-[19:55] <wolf31o2|mobile> spb: hopefully, it would be a joint operation between QA and the portage team (or $package_managers, if you prefer)
-[19:56] <spb> that's certainly one of the options, yeah
-[19:56] <wolf31o2|mobile> ok... so was there anything else?
-[19:56] <Kugelfang> yeah, the slacker mark for vapier
-[19:56] <Kugelfang> :-/
-[19:56] <wolf31o2|mobile> heh
-[19:57] <spb> nothing i can think of
-[19:57] <wolf31o2|mobile> ok
-[19:57] <wolf31o2|mobile> anything else on the agenda?
-[19:57] <Flameeyes> i can update the project page
-[19:57] <Flameeyes> who's going to do the summary?
-[19:57] <wolf31o2|mobile> Flameeyes: please do
-[19:57] <Kugelfang> wolf31o2|mobile: can you do the summary?
-[19:57] <spb> in which case i shall move myself down the road and reappear in a few minutes
-[19:57] <Kugelfang> wolf31o2|mobile: you had some good summaries in between already :-)
-[19:57] <vapier> hrm
-[19:57] <vapier> meeting today huh
-[19:57] <vapier> that's what i get for getting up late
-[19:57] <Kugelfang> vapier: hehehe
-[19:57] <wolf31o2|mobile> Kugelfang: I can try... I'll need to log it
-[19:58] <robbat2> now that vapier is here
-[19:58] <Kugelfang> so no slacker mark for vapier?
-[19:58] <kingtaco|laptop> what about open discussion
-[19:58] <kingtaco|laptop> or whatever
-[19:58] <robbat2> can we decide quickly on times for the meeting?
-[19:58] <Kugelfang> yes please
-[19:58] --> eroyf|out has joined this channel (n=eroyf@gentoo/developer/eroyf).
-[19:58] <Kugelfang> vapier: YOU ARE LATE!
-[19:58] *** spb is now known as peer.
-[19:58] <wolf31o2|mobile> well... my availability is pretty simple... 10am-6pm UTC -5
-[19:59] <wolf31o2|mobile> mon-fri
-[19:59] <robbat2> while 1900UTC does work presently for me, I'd prefer it 2-3 hours later
-[19:59] <robbat2> wolf31o2|mobile, could you state as UTC for the moment please?
-[19:59] <Kugelfang> yeah, please only UTC times
-[19:59] <Flameeyes> that's 15-23 utc
-[19:59] <wolf31o2|mobile> umm... 1500-2300
-[19:59] <wolf31o2|mobile> heh... the -5 made it kinda easy
-[19:59] <kingtaco|laptop> that works for me too
-[19:59] <Kugelfang> for me too
-[20:00] <kingtaco|laptop> pretty much any time as long as it's not sundays
-[20:00] <Kugelfang> i'd like to keep the thursday
-[20:00] <robbat2> my availability is reliably 2000-0300UTC weekdays, and mixed on weekends
-[20:00] <Flameeyes> 15-23 for me too
-[20:00] <Kugelfang> so, thursdays at 2000UTC ?
-[20:00] <wolf31o2|mobile> ok... so thursday... maybe at 2000?
-[20:00] <wolf31o2|mobile> heh
-[20:00] <kloeri> 2100UTC would probably be the latest for me - unless I'm planning to be late for work once a month :)
-[20:00] <kloeri> 2000 wfm
-[20:00] <robbat2> 2000 Thursdays yes
-[20:00] <Flameeyes> 2000 utc, second thursday then?
-[20:00] <Kugelfang> 2000UTC wfm2
-[20:00] <Kugelfang> yes
-[20:00] <wolf31o2|mobile> vapier: how about you?
-[20:01] <vapier> whatever
-[20:01] <vapier> i dislike sleep
-[20:01] <-- inc_ has left this channel.
-[20:01] <wolf31o2|mobile> (now that you're awake)
-[20:01] <wolf31o2|mobile> ok
-[20:01] <wolf31o2|mobile> heh
-[20:01] <wolf31o2|mobile> vapier: care to change your little script?
-[20:01] * g2boojum notes that DST ends fairly soon; does that affect anybody's times?
-[20:01] <vapier> was not aware that devmanual wasnt on gentoo hardware
-[20:01] <wolf31o2|mobile> g2boojum: not mine... I took it into account
-[20:01] <robbat2> g2boojum, that's why 1900UTC isn't ideal for me presently ;-)
-[20:02] <wolf31o2|mobile> vapier: devmanual (the page) is... devmanual's repo isn't
-[20:02] <vapier> ah
-[20:02] <wolf31o2|mobile> so I guess that's it?
-[20:02] <wolf31o2|mobile> open floor?
-[20:02] <robbat2> yup
-[20:02] <kingtaco|laptop> sure
-[20:02] *** wolf31o2|mobile sets the channel mode to 'unmoderated'.
-[20:02] <kloeri> nod
-[20:02] <Kugelfang> so, outside of DST, 2000UTC is the same as 1900ZUTC in DST, right?
-[20:02] <vapier> i dont think anyone commented on my "review" clause
-[20:02] <vapier> we're talking just GLEPs right
-[20:02] <welp[lap]> but thursday's a school night! :o
-[20:03] <robbat2> vapier: when the meeting is over, email the alias with your contact details
-[20:03] <wolf31o2|mobile> Kugelfang: 2000utc is always the same
-[20:03] <nox-Hand> Hey! I can talk again?
-[20:03] <GurliGebis_> I got a little thing I would like the council to have a look at
-[20:03] <Kugelfang> wolf31o2|mobile: :-)
-[20:03] <nox-Hand> vapier: they've missed you! :o
-[20:03] <nox-Hand> welp[lap]: poke?
-[20:03] <vapier> what contact details
-[20:03] <welp[lap]> nox-Hand: unforunatly, yes you can
-[20:03] <wolf31o2|mobile> brb... boss
-[20:03] <nox-Hand> welp[lap]: lol
-[20:03] <Flameeyes> vapier, phone number, mostly
-[20:03] <nox-Hand> Interesting meeting. Very.....diplomatic
-[20:04] <robbat2> vapier, real world ones, so we can phone you next time you're late
-[20:04] <vapier> `jwhois wh0rd.org`
-[20:04] <kloeri> GurliGebis_: state your question please
-[20:04] <GurliGebis_> is it possible to get you to have a look at the bug about the wildcard ssl cert, and come to a conclusion? ( https://bugs.gentoo.org/show_bug.cgi?id=117837 )
-[20:04] <GurliGebis_> it's holding back the new bugday site
-[20:05] *** GurliGebis_ is now known as GurliGebis.
-[20:05] <Flameeyes> shouldn't that be a question for foundation?
-[20:05] <christel> GurliGebis_: i thought we were waiting for the trustees on that one?
-[20:05] <robbat2> could we consider StartCom for certs instead?
-[20:05] <robbat2> they'd be free for the Class 1 CA
-[20:05] <nox-Hand> Night folks, and thanks for an interesting meeting :P
-[20:05] <robbat2> and have better inclusion than CACert
-[20:05] <vapier> we leave funding as a foundation exercise ?
-[20:05] <GurliGebis> christel, the bug has been standing still for a while
-[20:06] <-- nox-Hand has left this server ("leaving").
-[20:06] <GurliGebis> maybe they have forgot it
-[20:06] <kloeri> funding is a foundation issue
-[20:06] <robbat2> their Class 2 CA is not free, but still very cheap
-[20:06] <christel> GurliGebis: i know :/
-[20:06] <-- nephros has left this channel ("A trap door opens under you!").
-[20:06] <kloeri> but I thought some company donated a wildcard cert a while back?
-[20:06] <kingtaco|laptop> GurliGebis, you just got a new foundation, try talking to them
-[20:06] <vapier> then there isnt much for the council to say other than "the trustees should be notified"
-[20:07] <GurliGebis> okay, I'll try and contact them
-[20:07] <GurliGebis> wasn't sure who to ask about it ;)
-[20:07] <vapier> there is a nfp list
-[20:07] <vapier> please use that rather than e-mailing the trustees alias
-[20:07] <GurliGebis> nfp list?
-[20:07] <g2boojum> We're waiting on -infra, incidentally, because a wildcard cert was donated.
-[20:08] <agaffney> GurliGebis: gentoo-nfp (not for profit)
-[20:08] <g2boojum> If -infra would rather we just buy one, I'm okay w/ that.
-[20:08] <kloeri> g2boojum: that's my understanding as well
-[20:09] <GurliGebis> hmm, waiting on -infra :(
-[20:09] <GurliGebis> should I poke them?
-[20:09] <vapier> seems to be the common theme
-[20:09] <vapier> yes, infra needs much poking before something happens
-[20:09] <g2boojum> GurliGebis: Go right ahead.
-[20:09] <GurliGebis> :)
-[20:10] <-- beu has left this server ("brb").
-[20:10] <antarus|work> not like we don't have the cash :0
-[20:10] <antarus|work> wihch reminds me...we have a few grand in SoC money coming
-[20:11] <kloeri> cash could have been squandered away since the last report :)
-[20:11] <robbat2> vapier: you may poke us, but we are working on things
-[20:11] --> beu has joined this channel (i=beu@freenode/developer/gentoo.developer.beu).
-[20:11] <Flameeyes> okay leaving a part the certificate issue
-[20:11] <antarus|work> robbat2: you hiring? :)
-[20:11] <vapier> where's my image gallery :p
-[20:11] <Flameeyes> [that's now infra/foundation matter]
-[20:11] <Flameeyes> any other question for the council?
-[20:12] <kloeri> robbat2: make sure to let people know about that - that would probably reduce frustrations quite a bit
-[20:12] <fmccor> I have an unfair one, if there's no one else.
-[20:12] <Kugelfang> fmccor: shoot :-)
-[20:12] <kloeri> robbat2: infra has been good about bugzie updates lately btw
-[20:12] <robbat2> kloeri, yup, that's where I'm working at the moment
-[20:12] <fmccor> As I say, this is unfair, because it's a new council.
-[20:13] <robbat2> fmccor, vapier is still here, you can try to blame him
-[20:13] <Flameeyes> robbat2, i was going to say that
-[20:13] <fmccor> Now, necessarily, you all wear several hats, because you are all developers, in some cases, leads.
-[20:13] <-- rhican has left this channel ("Ik ga weg").
-[20:13] <frilled|home> robbat2: could you make kind of an "official" statement on how things are going with bugzie, then? I guess that would interest a lot of people :)
-[20:14] <Kugelfang> fmccor: sooo?
-[20:14] <kloeri> frilled|home: there's been several statements regarding bugzie the last few weeks
-[20:14] <robbat2> frilled|home, let fmccor finish his point
-[20:14] <fmccor> Which means situations can arise where there are conflicts of interest.  (E.g., voting on your own GLEP, considering an appeal from devrel, or whatever).
-[20:14] <frilled|home> I know ^^
-[20:14] <Kugelfang> fmccor: the previous council members didn't vote on their own stuff
-[20:14] <fmccor> Well, no.
-[20:15] <kloeri> we just have to abstain from voting in cases of conflict of interest
-[20:15] <fmccor> My question is if there is a policy on that, or should there be?
-[20:15] * robbat2 doesn't intend to vote on his own GLEP on signing in the tree when he finally gets it much closer to ready
-[20:15] <Kugelfang> fmccor: i think we can handle that
-[20:15] <fmccor> Fair enough.
-[20:16] <Flameeyes> i agree with the others
-[20:16] <robbat2> as an addenda to fmccor, could each of us perhaps have stated on the council page what our areas are that might be considered conflict of interest
-[20:16] <fmccor> It's worth mentioning, though.
-[20:16] <Flameeyes> robbat2, that's not an easy one
-[20:16] <robbat2> Flameeyes, just generally, not specifically
-[20:17] <robbat2> eg for myself, infra is my main involvement outside of development
-[20:17] * g2boojum thinks that conflict-of-interest recusals are silly, since you folks are there to advance your (and your team's) interests.  That's why there's six other council members to outvote you if necessary.
-[20:17] <vapier> that was part of the voting process
-[20:17] <Kugelfang> *nod*
-[20:17] <Kugelfang> there is just a slight move to AMD64 in here :-)
-[20:17] <vapier> you werent supposed to run for council if you are unable to handle conflicts of interest
-[20:18] <Flameeyes> vapier has a point, too
-[20:18] <robbat2> g2boojum, I ask for the disclosure so that we can see for ourselves at least that there isn't any strange cabal here where a majority of council is also part of some other group
-[20:18] <vapier> iirc, when the council was first formed, the conflict issue was much bigger as the devrel shakeup was going on at the sametime
-[20:19] <vapier> which is why in the nomination list, we show all the groups each person is part of
-[20:19] <Flameeyes> robbat2, it's a difficult one to decide what has to be put there and what not, what's a big involvement? lead? member? founding member?
-[20:20] <g2boojum> robbat2: I'm not opposed to disclosure, but in general I'm w/ vapier.  It's not like what any of you do is secret, so if people voted you in w/o doing their research that's their problem.
-[20:20] <Flameeyes> also, our roles aren't secret, there's the roll-call
-[20:20] <Flameeyes> but might require updating
-[20:20] <kingtaco|laptop> and ldap
-[20:20] <robbat2> Flameeyes, a lot of updating
-[20:20] <Flameeyes> robbat2, indeed
-[20:21] <Flameeyes> robbat2, what would you think of updating at least the councilers' roles in the next days?
-[20:21] <robbat2> g2boojum, ok, so you would say it's ok for us to vote on our own GLEPs by that then?
-[20:21] <robbat2> Flameeyes, sure, I'll update mine
-[20:21] <kloeri> I can update all the council members in ldap + roll-call
-[20:21] <g2boojum> robbat2: Yep.
-[20:21] <vapier> if you truly cant get over a personal conflict, then you are free to obstain over a point
-[20:22] <Flameeyes> vapier, you forgot the prefix for the number tho
-[20:22] <vapier> it's a US number
-[20:22] <christel> Flameeyes: 001/+1
-[20:22] <vapier> Flameeyes: arent you an american ? :p
-[20:22] <kloeri> I'm more worried about appeals for devrel disciplinary actions than GLEPs personally
-[20:22] <Flameeyes> vapier, >_<
-[20:22] <Flameeyes> christel, yeah i knew that
-[20:22] <g2boojum> Flameeyes: Most USians (myself included) have no idea what our prefix actually is.
-[20:22] <kingtaco|laptop> 001
-[20:22] <g2boojum> s/prefix/country code/
-[20:22] <robbat2> actually the 00 depends where you are
-[20:23] <kingtaco|laptop> it's 1!!!
-[20:23] <robbat2> the + in +1 indicates whatever you outbound international prefix is
-[20:23] <robbat2> '1' is the code for north america
-[20:23] <Flameeyes> okay, done with the country code thing too
-[20:25] <Flameeyes> by the way, do we want this in the log, should i cut it over it, or should leave it unedited?
-[20:25] <robbat2> the above stuff about conflict-of-interest should probably be included
-[20:26] <Flameeyes> robbat2, i meant the country code discussion, the conflict should be included for sure
-[20:26] --> ferringb has joined this channel (n=bharring@c-24-21-135-117.hsd1.mn.comcast.net).
-[20:26] <robbat2> maybe just leave the log up to the defined end of meeting unedited
-[20:26] <robbat2> and let a summary come together
-[20:27] <Flameeyes> acknowledged
-[20:27] <Flameeyes> so?
-[20:27] <Flameeyes> other questions, topics, or we end up here?
-[20:28] <kloeri> I have no more for today
-[20:28] <Kugelfang> i think we're done
-[20:28] <kingtaco|laptop> done
-[20:28] <robbat2> done
-[20:28] <Flameeyes> vapier, wolf31o2|mobile?
-[20:29] <Flameeyes> actually, wolf called a brb because of his boss a while back, so he's probably afk
-[20:30] <Flameeyes> remains vapier, if he's still awake :)
-[20:30] <vapier> ?
-[20:30] <vapier> you asking me if i have any other topics ?
-[20:30] <Flameeyes> vapier, yeah
-[20:30] <vapier> i got nothin
-[20:30] <Flameeyes> so the council meeting for 14 september 2006 closes here
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061019-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20061019-summary.txt
deleted file mode 100644
index 34cb58fa65..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20061019-summary.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-On behalf of the Council: following a summary of topics discussed during 
-the last Council meeting. (2006/10/19)
-
-1) As requested by Robbin H. Johnson, the Council discussed the member's
-   current involvement with Gentoo projects:
-
-   Chris Gianelloni:  games, gwn, genkernel, catalyst, new profile
-                      structure, planning for 2007.0
-   Robbin H. Johnson: tree-signing, infra (Bugzilla, anon(cvs|svn))
-   Danny van Dyk:     AMD64 releng (testing, soon new profiles)
-   Kingtaco:          infra(Bugzilla, anon(cvs|svn), utf8 on pecker)
-   Mike Frysinger:    toolchain, base-system
-   Diego Petteno:     Gentoo/FreeBSD
-   Bryan Ostergaard:  Devrel (Developer stats, fact-finding)
-   
-2) Chris Gianelloni had issued a small agenda for this meeting
- 
- Inter-project communication: Consensus that communication has improved
-   as of late. This covers especially spread information about project
-   work from Portage/Devrel/Infra to the developers.
-
-   Additionally, the council wants to put meeting summaries on
-   Planet Gentoo and the Gentoo Forums starting with this summary.
-
- Design phase for new projects: New projects need to post an RFC
-   containing information about their goals, the plan on how to
-   implement their goals and the necessary resources to -dev prior to
-   creating the project.
-
-   This proposal was accepted with 6 members voting yes and one member
-   abstained from voting
-
- Devrel etiquette guide: Needs still work before Council can discuss.
-   Rescheduled for next meeting. Bryan Ostergaard will be working on it.
-
- QA Policies: Nothing new and QA lead was not available during the
-   meeting. Discussion has been rescheduled for the next meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061019.txt b/xml/htdocs/proj/en/council/meeting-logs/20061019.txt
deleted file mode 100644
index 4ea14790f7..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20061019.txt
+++ /dev/null
@@ -1,385 +0,0 @@
-[21:59] *** robbat2 sets the channel mode to 'moderated'.
-[21:59] <wolf31o2|mobile> and I have those profiles mostly done... I've been trying to update them a bit so they're not so far out of date
-[21:59] <wolf31o2|mobile> heh
-[22:00] <Kugelfang> wolf31o2|mobile: what we could discuss is, when to use it
-[22:00] <kloeri> lo all
-[22:00] <wolf31o2|mobile> hi
-[22:00] <Flameeyes> good, 22CEST here, time to start
-[22:00] <robbat2> heya
-[22:00] * KingTaco peeks in
-[22:00] <Kugelfang> wolf31o2|mobile: care to send them to me in a free minute or two?
-[22:00] --> diox has joined this channel (n=diox@gentoo/contributor/diox).
-[22:00] <Flameeyes> vapier
-[22:00] *** Kugelfang sets the channel mode to 'moderated'.
-[22:00] <Kugelfang> consider this as "start" :-)
-[22:00] <Flameeyes> so who's starting?
-[22:01] <robbat2> besides wolf31o2's agenda, could we all mention stuff we're working on lately?
-[22:01] <wolf31o2|mobile> Kugelfang: well... they're really rough right now... I was planning on sending them to everyone
-[22:01] <robbat2> i've got a few bits on infra things
-[22:01] <wolf31o2|mobile> I'll start, if nobody minds
-[22:01] <Flameeyes> robbat2, to which detail?
-[22:01] <Flameeyes> wolf31o2|mobile, you have the stage
-[22:01] <Kugelfang> wolf31o2|mobile: go ahead
-[22:01] <robbat2> wolf31o2|mobile, go
-[22:01] <Kugelfang> i hope vapier isn't late again :-)
-[22:02] <wolf31o2|mobile> games, gwn, genkernel, catalyst... other than that, I've been working on a set of profiles that allow for multiple inheritance, which I plan on showing to everyone once I've got them mostly workable
-[22:02] <Flameeyes> Kugelfang, he was discussing with mcummings on #-dev a while ago
-[22:02] <vapier> your mom is late again
-[22:02] <wolf31o2|mobile> we've started taking requests for 2007.0 on the gentoo-releng mailing list, so planning for that has begun
-[22:02] <wolf31o2|mobile> that's about it
-[22:03] * wolf31o2|mobile hands the floor to robbat2 
-[22:03] <robbat2> besides the tree-signing (i'll return to it in a moment), I've been working with KingTaco on two infra projects
-[22:03] <robbat2> firstly is anoncvs/anonsvn
-[22:03] <robbat2> it's ready to roll, with the exception of one weird iptables issue affecting bandwidth
-[22:04] <robbat2> until that's solved, you can use it, but it is painfully slow
-[22:05] <robbat2> secondly is the new bugzie
-[22:05] <wolf31o2|mobile> yay!
-[22:05] <Kugelfang> (yay)
-[22:05] <Kugelfang> :-)
-[22:05] <Flameeyes> new bugzie or new bugzie setup?
-[22:05] <robbat2> that ones a lot further behind unfortuntely, for a couple of reasons
-[22:05] <kingtaco|laptop> you'll get both
-[22:06] <robbat2> originally we were going to go with a cluster-aware FS for the two database boxes, but then found the status of that in Linux (esp the kernels used by infra), was badly lacking
-[22:07] <robbat2> I've come up with another idea instead for the DB stuff, and I've been prototyping it on the fibrechannel gear I have at home, but it may fall over because of some of the bugzilla code
-[22:07] <robbat2> worst case here, is that we can't use both of the DB boxes we've got
-[22:07] <kingtaco|laptop> in this way
-[22:08] <kingtaco|laptop> remember, they still have local 320
-[22:08] <kingtaco|laptop> which is nothing to sneeze at
-[22:08] * Kugelfang has been slacking due to exam and first week.... i'm going to remove my away status tonight and will try to build a set of test stages for amd64 using latest portage and wolf's implementation of the multiple-inheritance profiles
-[22:08] --> thunder has joined this channel (n=thunder@gentoo/developer/thunder).
-[22:08] <Kugelfang> s/week/% of the semester/
-[22:08] <robbat2> the problem with bugzilla, is that it writes to on-disk tables for some searches done by users
-[22:08] <robbat2> (the 'regetlastsearch')
-[22:09] <robbat2> and if you happen to be sent to the other DB box, you get errors saying your search is invalid
-[22:09] <robbat2> or nonexistent
-[22:09] <wolf31o2|mobile> how much RAM do the boxes have?  Is RAM-based clustering possible?
-[22:09] <kingtaco|laptop> 4G on the 2 db nodes
-[22:09] <wolf31o2|mobile> I know disk-based in mysql is still considered alpha
-[22:10] <robbat2> wolf31o2|mobile, given the limitations of mysql NDB, no
-[22:10] <wolf31o2|mobile> k
-[22:10] <robbat2> it's mainly a matter of hacking out something that will work here
-[22:10] <robbat2> it seems that in other big deployments of bugzilla
-[22:10] <robbat2> they've simply gone with larger and larger DB machines
-[22:11] <robbat2> singular DB
-[22:11] <robbat2> we get to work with what's donated however, so life is 'interesting'
-[22:11] <wolf31o2|mobile> right
-[22:11] <kingtaco|laptop> robbat2, why can't we do single master/slave
-[22:12] <kingtaco|laptop> if multimaster is going to be such a issue
-[22:12] <robbat2> kingtaco|laptop, because of the write problems with the searches :-(
-[22:12] <wolf31o2|mobile> what? writes on master, reads on slave?
-[22:12] <kingtaco|laptop> robbat2, we had it set up on pitr
-[22:12] --> so|home has joined this channel (n=so@gentoo/developer/so).
-[22:12] <robbat2> the replication time in the middle breaks searches, at least when I was testing :-(
-[22:12] <kingtaco|laptop> robbat2, I suppose it's possible that wasn't tested
-[22:13] <robbat2> anyway, we'll get it going soon I hope
-[22:13] <Flameeyes> we all hope so :)
-[22:13] <robbat2> i'll come back to tree-signing later I think, depending on how the rest of this meeting goes.
-[22:13] <kingtaco|laptop> robbat2, anywho, if that's the only thing holding us back, we can simply disable that function
-[22:13] <robbat2> kingtaco|laptop, is there anything other than that infra work you want to add that you've been doing?
-[22:13] <robbat2> kingtaco|laptop, disable searches? you're nuts
-[22:14] <kingtaco|laptop> robbat2, erm, you said redo last search
-[22:14] <vapier> he means the fact you write it to disk
-[22:14] --> jmbsvicetto has joined this channel (n=jmbsvice@gentoo/developer/jmbsvicetto).
-[22:14] <kingtaco|laptop> robbat2, not really, some box moves, that's about it
-[22:14] <robbat2> vapier, maybe you next then?
-[22:15] <kingtaco|laptop> utf8 on pecker
-[22:16] --> edit_lp2 has joined this channel (n=edwho@about/uk/editlp2).
-[22:16] <vapier> does anyone really care what i work on ?
-[22:16] <Flameeyes> vapier, we care what you *don't* work on
-[22:16] <Flameeyes> [it's quicker to say]
-[22:17] <robbat2> vapier, if there's anything amongst it that affects the Gentoo in a big way (eg anoncvs/bugzie), it's probably worth hearing
-[22:17] <vapier> not really
-[22:17] <Flameeyes> vapier, GCC 4.2?
-[22:17] <vapier> i spend most of my day working on the toolchain and/or base-system
-[22:18] <vapier> what about it ?  we have snapshots but no releases
-[22:18] <Flameeyes> vapier, any trouble with it we must be aware of?
-[22:18] <vapier> *shrug*
-[22:19] <Flameeyes> myself, I'm working on Gentoo/FreeBSD as usual...
-[22:20] <Kugelfang> ahhh, do you think you'll be able to release a set of stages for next release?
-[22:20] <Flameeyes> a part the problems to get the new box up now, catalyst works fine to generate the stages, baselayout is now merged back so we have a pretty gentooish setup, should minimise the porting effort in the future
-[22:20] <Flameeyes> Kugelfang, not sure, but if multiple inheritance profiles will be available for that, I might be able to get something
-[22:21] <Kugelfang> cool
-[22:21] <Flameeyes> I can ensure the first stage built with catalyst worked fine, as it's what I'm using now to rebuild the box ;)
-[22:21] <wolf31o2|mobile> =]
-[22:21] <Flameeyes> [and all the trouble I had was hardware/bootloader related up to now]
-[22:22] <Flameeyes> I doubt it can be of interest to list the daily maintainership troubles with this and that :P
-[22:23] <robbat2> so that just leaves Kloeri?
-[22:23] <kloeri> I'm trying to figure out which areas devrel needs to be more proactive in and how we can best improve those aspects of devrel
-[22:24] <kloeri> also, somewhat devrel related I'm trying to do more graphs on developer activity, how many developers joins and leaves the team etc.
-[22:25] <kloeri> hopefully that's going to show some interesting facts important to all the discussions about solving problems by adding more devs etc.
-[22:25] <kloeri> ebuild stuff, I'm trying to bring alpha back up to speed and seeing what I need to do for ia64 now that plasmaroo has resigned
-[22:26] <kloeri> I should be setting up some tinderbox stuff soonish on alpha and ia64 (that's the plan at least)
-[22:26] <Kugelfang> yeah, we need somebody to step up (or to be appointed) to ia64 release coordinator
-[22:26] <kloeri> and finally I'm going to the UK linuxawards on wednesday with Christel and hopefully bringing back an award for "Best Linux / Open source project" :)
-[22:26] <christel> :D
-[22:27] <Flameeyes> christel, sst you shouldn't be talking here ;)
-[22:27] <kloeri> Kugelfang: that's going to be me or agriffis I guess but plasmaroo have promised to help
-[22:27] <christel> oops. sorry!
-[22:28] <kloeri> I'm also trying to pass the bugday project on to eroyf (new dev that's very dedicated to userrel and bugday) to free up some time for stuff where I'm more needed
-[22:29] <robbat2> ok, sounds good
-[22:29] <Kugelfang> kloeri: while we're discussing you and devrel....
-[22:29] <kloeri> ohh, I'm also trying to clean up some of the developer data in ldap/roll-call together with robbat2
-[22:29] <kloeri> that's sort of a longterm project though
-[22:29] <Kugelfang> have you all seen the bug patrick filed against kloeri?
-[22:30] <Flameeyes> no
-[22:30] <robbat2> no
-[22:30] <Kugelfang> I'd like the council to offically back kloeri there
-[22:30] <Kugelfang> lemme dig it up
-[22:30] <Kugelfang> 150851
-[22:30] <vapier> other devrel members weighed in as did i
-[22:31] <vapier> the issue seems to have settled, do we need to add another comment ?
-[22:31] <Kugelfang> no comment... it's just that in this case a devrel bug has been filed against devrel member
-[22:32] <kloeri> s/member/lead/
-[22:32] <Kugelfang> complaints rose up in regard to closing w/o discussion
-[22:32] <robbat2> i'm reading it still
-[22:32] <kloeri> but I agree the issue have settled for now
-[22:33] <Kugelfang> i for one (as laready stated) back him in his decission and would like to have council state that publicly, i.e. in the summary mail to -dev
-[22:33] <vapier> whatever floats your boat, i dont see any mishandling of the issue as kloeri knows
-[22:33] <Kugelfang> i don't see any mishandling either :-)
-[22:33] <wolf31o2|mobile> me either
-[22:34] <kloeri> I don't think there's any current issues but I'm sure it's going to flare up again if/when patrick requests to become a developer again
-[22:34] <wolf31o2|mobile> (though this should have been taken to us, as it really falls under "appeal" more than a report against kloeri)
-[22:34] <kloeri> but devrel will just have to handle that when it comes up
-[22:35] <Kugelfang> can we vote on this please?
-[22:35] <Flameeyes> I don't see any particular reason trying to start a flame, as vapier and kloeri said, the issue is settled now
-[22:35] <robbat2> ok, read it now. in the summary, could we please make some note that the OBJECTIVE is to auto-retired developers with 60 days of inactivity, unless otherwise provable
-[22:35] <robbat2> and that provable is actually doing something, not just offering to do something
-[22:36] <robbat2> eg, you say you're working with me on X, and I can confirm it.
-[22:36] <robbat2> eg Patrick noting that he offered to help infra, and noted he was ignored
-[22:36] <kloeri> robbat2: I'm trying to figure out how to make current policy more clear and will discuss it with devrel soon
-[22:37] <Kugelfang> seems my proposal isn't being voted on :-)
-[22:38] <Kugelfang> shall we proceed with wolf's atgenda then?
-[22:38] <Flameeyes> I'd say so
-[22:38] <robbat2> Kugelfang, i'm not certain I'd stand with you here, I do see the old (previously undertaken) policy as insufficently clear
-[22:39] <wolf31o2|mobile> Kugelfang: to have a vote, specify in a single succinct sentence, etc what to vote on... ex. "Do you think we need to stomp on kloeri for retiring inactive devs?" or "Should we buy a soft-service ice cream machine for the developer lounge?"
-[22:39] <Kugelfang> robbat2: i think that devrel has a certain area of interpretation there
-[22:39] <robbat2> yup, wolf's stuff next
-[22:39] <kloeri> wolf31o2|mobile: yes and yes :)
-[22:39] <Kugelfang> wolf31o2|mobile: retracted my vote :-)
-[22:39] * wolf31o2|mobile stomps on kloeri 
-[22:40] <kloeri> thanks
-[22:40] <wolf31o2|mobile> welcome
-[22:40] <Kugelfang> where's my ice cream machine?
-[22:40] <Kugelfang> wolf31o2|mobile: your first point was inter-project communication iirc
-[22:41] <wolf31o2|mobile> yes
-[22:41] <wolf31o2|mobile> and I thin we got devrel/infra covered
-[22:41] <kloeri> I think the policy can be improved but would also note that it's somewhat intentionally vague as it's impossible to state exactly what constitutes activity with the amount of different roles people have (and new roles getting invented often enough)
-[22:42] <kloeri> I'm probably going to discuss improvements to that part of policy internally in devrel first and then on -devrel ML when we have some proposed improvements
-[22:42] <-- nox-Hand has left this server (Read error: 104 (Connection reset by peer)).
-[22:42] <robbat2> kloeri, could you throw me a copy when you sent it to the devrel ML?
-[22:43] <kloeri> robbat2: sure
-[22:43] <Kugelfang> wolf31o2|mobile: portage communication improved lately imho
-[22:43] <kloeri> think I've done enough interproject communication now :)
-[22:43] <wolf31o2|mobile> yes, it has
-[22:44] <Kugelfang> wolf31o2|mobile: zmedico's mails are quite nice, and the rfcs actually do create discussion with less flames than usual :-)
-[22:44] <wolf31o2|mobile> and for the people that didn't get the email... the basis here was to identify several projects that we thought required more communications... we came up with (basically) infra, devrel, and portage... (from my memory anyway)
-[22:44] <robbat2> i'd like to make an interesting observation point - the discussions about the lack of communication have actually started to improve communication - because many of the lurkers are reading them and being constructive about results ;-)
-[22:45] <kloeri> trustees as well I guess
-[22:45] <wolf31o2|mobile> robbat2 and KingTaco covered infra... kloeri covered devrel... and portage has improved....
-[22:45] <Kugelfang> wolf31o2|mobile: so next point?
-[22:45] <wolf31o2|mobile> trustees are kinda waiting on the votes, last I knew... I haven't seen much activity, but I also keep forgetting to join the stupid invite-only channel
-[22:45] <Flameeyes> gentoo/freebsd should be pretty covered by me and roy on planet :P
-[22:45] <wolf31o2|mobile> ;]
-[22:46] <Kugelfang> wolf31o2|mobile: design phase?
-[22:46] <wolf31o2|mobile> Kugelfang: go for it
-[22:46] <Kugelfang> ah, one thing re inter-project commonication still
-[22:46] <Kugelfang> can we put the council summary on planet.g.o?
-[22:46] <wolf31o2|mobile> I don't see why not... might be a good place for it
-[22:46] <Kugelfang> with a link to the log?
-[22:47] <Kugelfang> do we need a vote? :-P
-[22:47] <wolf31o2|mobile> how about we just ask if anyone objects?
-[22:47] <wolf31o2|mobile> heh
-[22:48] * kingtaco|laptop objects to people who object
-[22:48] <robbat2> yeah, planet sounds good
-[22:48] <kloeri> that reminds me.. some users told me that they were kind of afraid interrupting on -dev ML so they'd be quite happy to see meeting announcements and possibly even logs on forums.g.o
-[22:48] <Flameeyes> who can handle the publishing of the summary then?
-[22:48] <Kugelfang> Flameeyes: i'll poke beandog :-)
-[22:48] <Flameeyes> I can do the log, alright, but I'm not good at summarising
-[22:48] <kloeri> forums sucks for discussion but we could easily announce our meetings at least
-[22:48] <wolf31o2|mobile> yeah
-[22:49] * Kugelfang volunteers for both forums announcement and summary and planet
-[22:49] <wolf31o2|mobile> sold!
-[22:49] <Kugelfang> both?
-[22:49] <Kugelfang> s/both/
-[22:49] <kloeri> this meeting was actually announced on forums btw
-[22:49] <kloeri> yeah, both
-[22:50] <Kugelfang> :-)
-[22:50] <Flameeyes> next item?
-[22:52] <Kugelfang> mandatory design phase for projects
-[22:52] <robbat2> i think some folk might object to the term mandatory ;-)
-[22:52] <Flameeyes> I think wolf did a pretty good speech about this on his mail
-[22:53] <kloeri> I think requiring a design phase is a good idea (even if it's very short for some projects)
-[22:53] <Kugelfang> robbat2: hm... probably the wrong word... lemme check the dictionary :_)
-[22:53] <Kugelfang> no, i meant mandatory
-[22:54] <robbat2> call them project proposals instead maybe
-[22:54] <Flameeyes> robbat2, I'd avoid the word "proposal"
-[22:54] * Flameeyes points at the bad gleps fame
-[22:54] <Kugelfang> no GLEP
-[22:54] <wolf31o2|mobile> Really, it should be something along the lines of a RFC being posted.
-[22:54] <wolf31o2|mobile> It should list the project's intended goal, and how they plan on getting
-[22:54] <wolf31o2|mobile> there.  This is mostly to solve the problems that can occur when a new
-[22:54] <wolf31o2|mobile> project forms and they say what they plan on doing without any knowledge
-[22:54] <wolf31o2|mobile> being passed of how they plan on getting there.
-[22:54] <wolf31o2|mobile> Essentially, it needs 3 things:
-[22:54] <wolf31o2|mobile> 1. goal(s)
-[22:54] <wolf31o2|mobile> 2. plan - how do they achieve #1?
-[22:54] <wolf31o2|mobile> 3. resources - do they need infra? money?
-[22:54] <Flameeyes> Kugelfang, indeed.. the problem is that "proposal" resembles too much gelp ;)
-[22:54] <wolf31o2|mobile> ^^^ from the email nobody but us read... :P
-[22:55] <kloeri> wolf31o2|mobile: yeah, I'd definitely agree with that
-[22:55] <Kugelfang> dito here
-[22:55] <Flameeyes> ibid
-[22:55] <robbat2> yup, that's it. maybe even reuse the RFC name in some way?
-[22:55] <robbat2> request for comments does describe what it needs to be
-[22:56] <kloeri> agreed
-[22:57] <wolf31o2|mobile> honestly, that info could even be on their project page... though the point was to discuss before the project is built... the idea here is not to disallow projects to be formed, or even to allow blocking a project... but just to convey information to other people so you don't have people (like I do) freaking out any time there's a new project that sounds like suddenly someone (like releng) is going to have to do a lot more wo
-[22:57] <wolf31o2|mobile> rk when they really don't, at all
-[22:57] <Flameeyes> what does the thesaurus say wrt proposal?
-[22:57] <Kugelfang> New projects need to post an RFC containing information about their goals, the plan on how to implement their goals and the necessary resources to -core prior to creating the project
-[22:57] <Kugelfang> ^^^???
-[22:57] <Flameeyes> s/-core/-dev/
-[22:57] <wolf31o2|mobile> Kugelfang: sounds succinct and to-the-point... vote?
-[22:57] <wolf31o2|mobile> yeah, -dev
-[22:58] <Kugelfang> hm, -dev then
-[22:58] <robbat2> vote (i'm counting): "New projects need to post an RFC containing information about their goals, the plan on how to implement their goals and the necessary resources to -dev prior to creating the project"
-[22:58] <Kugelfang> vote: New projects need to post an RFC containing information about their goals, the plan on how to implement their goals and the necessary resources to -dev prior to creating the project
-[22:58] * Kugelfang votes yes
-[22:58] <wolf31o2|mobile> heh
-[22:58] <Flameeyes> vote: yes
-[22:58] <wolf31o2|mobile> yes
-[22:58] <robbat2> yes
-[22:58] <kloeri> yes
-[22:58] <Flameeyes> kingtaco, vapier?
-[22:58] <kingtaco|laptop> yes
-[22:59] * Flameeyes wonders if "kingtaco, vapier" could have been replaced with "mikes?"
-[22:59] <kingtaco|laptop> he's an impostor
-[23:00] <Kugelfang> vote: cyborg vapier and force him to monitor this channel for eternity
-[23:00] <Flameeyes> vote: yes (if you also cyborg me)
-[23:00] <Kugelfang> no way, i just got one ki
-[23:00] <Kugelfang> t
-[23:01] <robbat2> vapier, ping
-[23:01] <Kugelfang> vapier: your vote?
-[23:01] <kloeri> the slacker rule should also count when vapier falls asleep :)
-[23:01] <Kugelfang> hehehe
-[23:02] <Flameeyes> we can say the request passes with 6 yes and 1 absent? :P
-[23:02] <kingtaco|laptop> only takes 4
-[23:02] <wolf31o2|mobile> one abstained... heh
-[23:02] <wolf31o2|mobile> what else do we have? I've got a meeting?
-[23:02] <Kugelfang> unless he votes later during the meeting
-[23:02] <Flameeyes> wolf31o2|mobile, do you have one?
-[23:02] <wolf31o2|mobile> err... no ? on the second one
-[23:02] <wolf31o2|mobile> have one what?
-[23:02] <Flameeyes> wolf31o2|mobile, meeting
-[23:03] <Flameeyes> anyway, next item on your agenda was about devrel
-[23:03] <wolf31o2|mobile> yeah
-[23:03] <Flameeyes> kloeri?
-[23:03] <wolf31o2|mobile> go for it
-[23:03] <kloeri> hmm?
-[23:03] <wolf31o2|mobile> I'll bbiab
-[23:03] <Flameeyes> kloeri, it was the etiquette thing mostly
-[23:03] <kloeri> ahh, yeah
-[23:04] <kloeri> devrel needs to figure out how to be more proactive about issues such as etiquette etc.
-[23:04] <kloeri> there's a couple things we need to figure out really
-[23:04] <Flameeyes> kloeri, should we take it as "you're working on it" (seeing the status update above) and wait for the next month to address that?
-[23:05] <kloeri> actually, I'd like to hear some ideas about which areas we should try to attack
-[23:05] <Kugelfang> kloeri: there is still kingtaco's proposal of silencing subscriber to -dev for a small amount of time
-[23:05] <Kugelfang> kloeri: which i back :-)
-[23:05] <kloeri> yeah but there's a lot of different issues we could attack really
-[23:06] <kloeri> like devs bickering about useless crap like top posting, devs going at each others throat in #-dev etc.
-[23:06] <kloeri> and we definitely got an issue with manpower if we need to do much about any of that
-[23:06] <wolf31o2|mobile> heh... back
-[23:06] <Kugelfang> wolf31o2|mobile: that was quick
-[23:06] <wolf31o2|mobile> I'm just good like that
-[23:06] <kloeri> so my biggest concern is where we should spend our limited ressources
-[23:07] <kloeri> I'll be having a meeting with the rest of devrel about this but ideas and suggestions are certainly welcome :)
-[23:07] <kloeri> other than that we should get back to it next month I think
-[23:08] <Kugelfang> *nod*
-[23:08] <wolf31o2|mobile> well... my main concern really was people who consistently break QA, which means it would be a joint thing... now, these people don't necessarily need "punishment" so much as we need to fix the problem, which is bad things making it into the tree
-[23:08] <Kugelfang> as far as i know, QA go a t list of people
-[23:09] <Flameeyes> wolf31o2|mobile, we still need qa to complete the policy, though
-[23:09] <kloeri> people breaking QA should be handled by the QA project imo
-[23:09] <Kugelfang> for know there are two people on it, who i won't name in here
-[23:09] <Flameeyes> there are still shady points that needs to be addressed
-[23:09] <wolf31o2|mobile> kloeri: and that's fine... then what powers, if any, do QA need to fulfill that role? do they just give people the virtual smackdown, and if it keeps up they file devrel bugs?
-[23:09] <kloeri> and if things gets out of hand devrel is happy to help but a warning (or some friendly advice) from QA should be enough in most cases
-[23:10] <kloeri> yes, that's what I'm thinking at least
-[23:10] <kingtaco|laptop> wolf31o2|mobile, no "powers" needed
-[23:10] <kingtaco|laptop> just teamwork
-[23:10] <robbat2> one comment on the QA side (partially in regards to patrick)
-[23:10] <kloeri> I've been discussing this with spb on a few occasions and I think he's happy about that arrangement as well
-[23:10] <wolf31o2|mobile> yeah, that's fine
-[23:10] <wolf31o2|mobile> that was really my question... do they "escalate" it to devrel once it's a real problem
-[23:10] <kingtaco|laptop> QA should be able to ask devrel for help in that department if the other QA stuff has failed first
-[23:11] <robbat2> anybody should be able to file QA issues, and for the most part, any dev that feels motivated should be able to fix them
-[23:11] <Kugelfang> 1rtt is already implemented
-[23:11] <kingtaco|laptop> and devrel should do what QA needs
-[23:11] <Kugelfang> robbat2: see the QAcanfix keyword
-[23:11] <wolf31o2|mobile> So do we (we being all developers) need to send information about QA violations to the QA team?
-[23:11] <kingtaco|laptop> they need to nail down a policy
-[23:11] <Kugelfang> robbat2: besides... whenever i saw i QA bug i could fix, i did
-[23:11] <kingtaco|laptop> where is sbp
-[23:11] <wolf31o2|mobile> specifically things that aren't being addressed
-[23:12] <Kugelfang> robbat2: hadn arrangement with jakub on that :-)
-[23:12] <Flameeyes> kingtaco|laptop, who's sbp? :P
-[23:12] *** kingtaco|laptop gives spb the permission to talk.
-[23:12] <Flameeyes> the one for firewire access?
-[23:12] <kingtaco|laptop> spb, any news on QA?
-[23:12] <robbat2> patrick said he wanted to join QA, but there was no lead - so the logical course should have been for him to file bugs to QA
-[23:12] <Kugelfang> robbat2: wrong
-[23:13] <kloeri> I think common sense should rule tbh - if you see some horrific QA violation you should probably contact QA about it
-[23:13] <Kugelfang> robbat2: patrick as to join QA, and the QA lead said:'QA recrutieuits from activtive evuild devs'
-[23:13] <Kugelfang> damn lag
-[23:13] <kloeri> Kugelfang: without all the typos though :)
-[23:13] <Kugelfang> 'QA recruits from active ebuild devs'
-[23:14] <Kugelfang> robbat2: as patrick as neither active nor an build dev, he didn't qaulify
-[23:14] <Kugelfang> qualify
-[23:14] <robbat2> there no reason that you can't have a non-dev checking ebuilds for specific problems
-[23:14] <Kugelfang> robbat2: true... still doesn't warant membership in QA project
-[23:14] <Kugelfang> robbat2: users file bugs, too
-[23:15] <kloeri> QA is also about fixing problems, writing up policy etc. which really should be left to ebuild devs imo
-[23:15] <robbat2> on the side of finding problems, some dedicated searchers could fill a similar slot as arch-testers
-[23:15] <Flameeyes> qa-testers?
-[23:16] <Kugelfang> that sounds.... odd
-[23:16] <Kugelfang> robbat2: i guess that's up to how qa wants to handl eit :-)
-[23:16] <robbat2> i got invited to joined Gentoo, because I filed a whack of bugs on use.desc being out of sync with the tree
-[23:17] <Kugelfang> back in 5 mins
-[23:17] <wolf31o2|mobile> k
-[23:17] <robbat2> i need to bail in about 10 myself
-[23:18] <wolf31o2|mobile> yeah, we're over on time... what else was on the agenda?
-[23:18] <robbat2> spb: not sure if you are here, but you could please consider a well-defined way for users to bring various QA issues to the attension of the QA team
-[23:18] <robbat2> wolf31o2, err, anything else on your list, else it's open floor
-[23:18] <Kugelfang> back already
-[23:18] <Kugelfang> robbat2: in contrast to filing bugs?
-[23:18] <kloeri> QA is kinda special in that a lot of stuff they're doing (or at least supposed to do) require fairly intricate ebuild knowledge as they're overseeing the work of all the other ebuild devs
-[23:18] <-- thunder has left this server (Client Quit).
-[23:18] <wolf31o2|mobile> can we hold off on the other and perhaps schedule another meeting in $short_amount_of_time to cover it, then open the floor?
-[23:19] <Kugelfang> wolf31o2|mobile: like, next week?
-[23:19] <wolf31o2|mobile> sure... though looking over... everything else was the devrel/qa stuff
-[23:19] <wolf31o2|mobile> so there's not really another topic
-[23:19] <wolf31o2|mobile> just this one, which I think could be discussed quite a bit
-[23:19] <wolf31o2|mobile> heh
-[23:19] <kingtaco|laptop> Kugelfang, I'm out of time until after the 26th
-[23:19] <Kugelfang> wolf31o2|mobile: there is a GLEP in the works by malverian :-)
-[23:20] <Kugelfang> kingtaco|laptop: ah, ok
-[23:20] <Flameeyes> so let's reschedule for next month the rest of stuff about qa/devrel ?
-[23:20] <robbat2> kloeri, while you may need to be an experience ebuild writer to find some of the really weird stuff, that doesn't user-level can't spot some basic mistakes
-[23:20] <Kugelfang> robbat2: again, what does it need else but bugs.g.o.?
-[23:20] <Kugelfang> robbat2: people file bugs, and jakub assign stuff to qa
-[23:20] <Kugelfang> robbat2: i'm watching the QA alias, and this works pretty well
-[23:21] <kloeri> robbat2: not saying you couldn't have some "QA-lite" team, just noting that we have no such team now and I'm not sure if QA would really want to go that way
-[23:21] <wolf31o2|mobile> Flameeyes: I say yes
-[23:21] <Flameeyes> agreed then
-[23:21] <wolf31o2|mobile> well... I tend to think that QA has their hands full... what they need most is helping hands fixing stuff, I would guess
-[23:21] <Flameeyes> if nobody object, that is
-[23:21] <wolf31o2|mobile> anyway... let's say we hold off on this until next time, and open the floor?
-[23:21] <Kugelfang> i agree
-[23:22] <robbat2> i'm not sure about my schedule for next week, but i'll see anyway
-[23:22] *** You set the channel mode to 'unmoderated'.
-[23:22] <kloeri> rescheduling for next month is fine
-[23:22] <wolf31o2|mobile> k
-[23:22] <Flameeyes> open floor then
-[23:22] <Kugelfang> Flameeyes: you got a log to send to me?
-[23:22] <kloeri> I'm at the UK linuxawards / linuxexpo wednesday and thursday next week so more or less completely offline I guess
-[23:22] <Kugelfang> Flameeyes: so i can summarise :-)
-[23:23] <Flameeyes> Kugelfang, I'd wait till the end of the openfloor, but if you want it now, I can
-[23:23] <Kugelfang> please do so
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061109-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20061109-summary.txt
deleted file mode 100644
index 45669acffa..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20061109-summary.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Agenda was:
-1. Reply-to-list
-2. SPF
-3. QA update / plans
-4. Bugzilla status
-
-1. Council decided that there were no need to change mailinglist behaviour
-regarding reply-to-list. Bryan Østergaard (kloeri) mentioned that a
-replytolist plugin for thunderbird-2 had just been committed the day
-before. Bryan will update the handbook to include information on
-procmail recipes to change reply-to behaviour on an individual basis.
-Bug 154595 tracks progress of this update.
-
-2. Council decided that Infra needs to document use of third party smtp
-servers and usage of dev.gentoo.org SMTP server. Bug 154594 tracks this
-issue.
-
-3. Bryan Østergaard gave a short update on QA team on behalf of Stephen
-Bennett (spb). Plans currently include:
-- Documenting EAPI-0 and PMS (Package Manager Standard)
-- Doing more automated QA checks.
-- Implementing GLEP 48 (see http://glep.gentoo.org/glep-0048.html)
-- Working out what each QA team member wants to work on.
-
-4. Robin Johnson (robbat2) gave a quick status update on bugzilla. The
-load-balanced mysql is working very well now but there's still some
-webserver tuning that needs to be done. There's no timeframe as such as
-there might still be unexpected issues cropping up.
-
-Open floor discussion:
-Torsten Veller asked if there was any news on portage tree signing.
-Robin Johnson said there was no news as he'd spend all his time working
-on new bugzilla setup and anonymous cvs.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061109.txt b/xml/htdocs/proj/en/council/meeting-logs/20061109.txt
deleted file mode 100644
index 6d58baa47f..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20061109.txt
+++ /dev/null
@@ -1,567 +0,0 @@
-[14:36] <agaffney> 25 minutes?
-[14:37] <Flameeyes> 24
-[14:37] <kingtaco|laptop> 29 here
-[14:37] <Kugelfang> 24
-[14:37] <agaffney> kingtaco|laptop: *cough* ntp *cough*
-[14:37] <Kugelfang> kingtaco|laptop: fix our hwclock :-P
-[14:38] <agaffney> can someone +v me since I'll be speaking for chris today?
-[14:38] <kingtaco|laptop> heh, guess I'm going to be 5 minutes late :)
-[14:38] --- kingtaco|laptop sets modes [#gentoo-council +v agaffney]
-[14:38] --- Kugelfang sets modes [#gentoo-council +o agaffney]
-[14:38] <agaffney> Kugelfang: that works too :P
-[14:38] <Kugelfang> he's replacement for today, so he should be opped
-[14:38] <kingtaco|laptop> hah
-[14:38] <kingtaco|laptop> fine
-[14:39] <agaffney> what is on the agenda?
-[14:39] --- Flameeyes sets modes [#gentoo-council +v wolf31o2]
-[14:39] <agaffney> just reply-to and SPF?
-[14:39] --- Flameeyes sets modes [#gentoo-council -o wolf31o2]
-[14:39] <Flameeyes> then we need to downgrade wolf :P
-[14:39] <agaffney> hah
-[14:39] <agaffney> owned
-[14:39] <kingtaco|laptop> agaffney, and QA
-[14:39] <kloeri> update on qa plans
-[14:39] * Kugelfang hrms
-[14:39] <Kugelfang> spb: are you available?
-[14:39] <kingtaco|laptop> there will b e a bugs update too
-[14:39] <Flameeyes> anybody heard from curtis in the last months btw?
-[14:39] <Kugelfang> nope
-[14:40] <agaffney> Flameeyes: not that I'm aware of
-[14:40] * Flameeyes sighs
-[14:40] <kloeri> Flameeyes: nope, a few people are trying to track him down though
-[14:40] <agaffney> he seems to have completely disappeared 6+ weeks ago
-[14:40] <agaffney> his IRC session was idle for 3+ weeks before it got disconnected
-[14:40] <agaffney> and he's not been back
-[14:40] <agaffney> not responding to email
-[14:40] <agaffney> he's probably in a ditch somewhere :/
-[14:40] <Flameeyes> kloeri, what about giving RFID tags to developers?
-[14:40] <agaffney> heh
-[14:40] <kloeri> amne and christel are both doing what they can to find out what's up
-[14:40] <kingtaco|laptop> agaffney, someone in devrel has his phone number
-[14:40] <agaffney> like they do with dogs? :P
-[14:41] <agaffney> kingtaco|laptop: have they tried to call him?
-[14:41] <kingtaco|laptop> Flameeyes, 1984
-[14:41] <kingtaco|laptop> agaffney, probably... they are concerned where he went
-[14:41] <kloeri> Flameeyes: good idea.. and a few satelites sensitive enough to read the tags :p
-[14:41] <Flameeyes> kingtaco|laptop, that's older than me
-[14:41] <kloeri> agaffney: don't think anybody have his number
-[14:41] <kingtaco|laptop> Flameeyes, really???
-[14:41] <Flameeyes> kloeri, yes, use foundation's money for that ;)
-[14:41] <kingtaco|laptop> Flameeyes, god, I feel old then
-[14:42] <kloeri> kingtaco|laptop: afaik, yes
-[14:42] <Flameeyes> kingtaco|laptop, yeah, I'll be 21 at the end of the month :P
-[14:42] * kingtaco|laptop checks into an old folks home
-[14:43] * agaffney was born in '84
-[14:43] * Kugelfang is getting 24 start of next month..
-[14:43] <kingtaco|laptop> hahah
-[14:43] * agaffney is 22 for anyone too lazy to do the math :P
-[14:44] <Flameeyes> so I suppose that asking for news about the redesign this month is basically pointless
-[14:44] <kingtaco|laptop> Flameeyes, absolutly pointless
-[14:44] <kingtaco|laptop> I don't have any idea about it and I doubt robbat2|na does
-[14:45] * kloeri will be 32 at the end of the month
-[14:45] <Kugelfang> OOOLD!
-[14:45] <kingtaco|laptop> kloeri, I'll put your name on the list for the old folks home
-[14:45] <kloeri> heh
-[14:45] <kloeri> kingtaco|laptop: thanks, I can hardly manage writing my name anymore due to old age :)
-[14:46] <kingtaco|laptop> kloeri, I'm suprised you're not in adult dipers yet
-[14:46] <kingtaco|laptop> I mean 32
-[14:46] <kingtaco|laptop> jeez
-[14:46] <kingtaco|laptop> :p
-[14:46] <kloeri> can't figure out how they work.. I'm not really that technically minded :p
-[14:46] <kloeri> tricky stuff, those adult diapers
-[14:47] <kingtaco|laptop> I'm pretty sure they work the same as other diapers...
-[14:47] <kingtaco|laptop> I mean, how many possible ways are there....
-[14:47] <kingtaco|laptop> hahah, gentoo has surely gone down the toilet today
-[14:47] <agaffney> today? :P
-[14:48] <kingtaco|laptop> hehe
-[14:48] <SpanKY> i just read that book, was pretty good
-[14:48] <SpanKY> that and Fahrenheit 451
-[14:48] <kingtaco|laptop> which, 1984?
-[14:48] <Flameeyes> SpanKY, "Gone down the toilet"?
-[14:48] <kingtaco|laptop> ah
-[14:48] <kingtaco|laptop> both are very good books
-[14:48] <Flameeyes> SpanKY, yeah fahrenheit 451 is a great book
-[14:48] <kingtaco|laptop> SpanKY, you should try to find a copy of "brave new world"
-[14:49] <kingtaco|laptop> that's another fun classic
-[14:49] <Kugelfang> Fahrenheit 451 is cool
-[14:49] <wolf31o2> heh
-[14:49] <Flameeyes> wolf31o2, what are you doing here? :P weren't you away? :P
-[14:50] --- robbat2|na is now known as robbat2
-[14:50] <wolf31o2> Flameeyes: no... I'm *leaving* in like 5-10 minutes for my CISSP classes...
-[14:50] <Flameeyes> wolf31o2, I'm afraid to ask what CISSP is
-[14:50] <wolf31o2> which is why I appointed a proxy... since I know I won't be here for the whole meeting
-[14:50] <SpanKY> i just pick random books from here to read: http://books.google.com/googlebooks/banned/
-[14:50] <wolf31o2> Certified Information Systems Security Professional
-[14:50] <kingtaco|laptop> hahah
-[14:51] <agaffney> SpanKY: both are good books. the movie for F451 was *horrible* :P
-[14:51] <robbat2> morning
-[14:51] --> vorlon078 (n=vorlon@gentoo/developer/vorlon) has joined #gentoo-council
-[14:51] <Flameeyes> agaffney, like almost every movie coming from a book
-[14:51] <agaffney> Flameeyes: well, it was even worse because it was the 70s and british :P
-[14:52] <agaffney> it was so bad it was comical
-[14:52] <Flameeyes> agaffney, the only thing I liked, taken from a book, was the Dune mini-series
-[14:52] <kingtaco|laptop> heh, I've read most of those books
-[14:52] <Flameeyes> not the '80s film with sting of course
-[14:52] <agaffney> Flameeyes: the 2000 Dune mini-series kicked serious ass
-[14:52] <agaffney> the original Dune movie sucked goat nuts
-[14:52] <Flameeyes> agaffney, yeah
-[14:53] <agaffney> and oddly, I've got the first Dune book on my desk right now :P
-[14:53] <Flameeyes> I still have to watch the children of dune mini-series
-[14:53] <agaffney> reading through the series for the 4th or 5th time
-[14:53] <Kugelfang> agaffney: i got them all in german and in english
-[14:53] <agaffney> Flameeyes: I caught part of it, but it wasn't very good
-[14:53] <Kugelfang> agaffney: and the english one, i got as hardcover and pocketbooks
-[14:53] <Flameeyes> I have the original dune books in the shelf at my left
-[14:53] <agaffney> SciFi spent their entire year's movie budget on the Dune miniseries
-[14:53] <Flameeyes> wow that's a lot
-[14:53] <agaffney> and it was well worth it
-[14:53] <Kugelfang> well spent
-[14:53] <agaffney> *damn* good
-[14:53] <agaffney> for children of dune, they did it like any other mini-series
-[14:54] <Flameeyes> -7
-[14:54] * agaffney will probably stop reading after book 4 or 5 this time
-[14:54] <Flameeyes> I should try to look for herber's son's books... but I doubt they'll be at the same level of the father's
-[14:54] <Kugelfang> it's just sad that herbert didn't finish the last part
-[14:55] <Kugelfang> Flameeyes: they aren't
-[14:55] <agaffney> God Emperor is really the last good book
-[14:55] <agaffney> didn't his son write a book on the Butlerian Jihad?
-[14:55] <Kugelfang> Flameeyes: i got them all, and i only read them once
-[14:55] <Kugelfang> agaffney: 6 books
-[14:55] <agaffney> o_O
-[14:55] <Kugelfang> agaffney: 6 prequels to Dune
-[14:55] <Flameeyes> Kugelfang, well, lately I haven't been able to re-read any book :| got a lot of new ones to read
-[14:55] <agaffney> I need to get some new ones
-[14:55] <Kugelfang> agaffney: 3 short before dune, 3 in the time of Butler's Jihad
-[14:56] <agaffney> I keep re-reading Dune, Wheel of Time, and Harry Potter series :P
-[14:56] <SpanKY> i should read a clockwork orange
-[14:56] <SpanKY> i lubz the book
-[14:56] <SpanKY> agaffney: why would you re-read wheel of time ... once was painful enough
-[14:56] <Flameeyes> agaffney, you fell with the third title :P
-[14:56] * Flameeyes still has to finish the eye of the world
-[14:56] <kingtaco|laptop> of mice and men
-[14:56] <agaffney> SpanKY: because eventually they'll get to the last battle :P
-[14:56] <kingtaco|laptop> I can't believe that's banned
-[14:56] <kingtaco|laptop> I red that in 4th grade or something
-[14:56] <kingtaco|laptop> *read
-[14:57] <agaffney> apparently it was instead of learning how to spell ;)
-[14:57] <Flameeyes> kingtaco|laptop, for non-usians what's 4th grade? :P
-[14:57] <kingtaco|laptop> Flameeyes, I was 8
-[14:57] <agaffney> Flameeyes: 9-10 years old
-[14:57] <Flameeyes> kingtaco|laptop, okay :)
-[14:57] * agaffney runs to refill his water bottle
-[14:57] <kingtaco|laptop> banned for "vulgarity"
-[14:58] <kingtaco|laptop> I think it has the word "damn" in it
-[14:58] <kingtaco|laptop> ZOMG!!1111
-[14:59] --> marienz (i=marienz@gentoo/developer/marienz) has joined #gentoo-council
-[14:59] --> nightmorph|amd64 (n=nightmor@gentoo/developer/nightmorph) has joined #gentoo-council
-[14:59] --> AllanonJL|W (n=allanonl@gentoo/developer/allanonjl) has joined #gentoo-council
-[15:01] --> bonsaikitten (n=pal@gentoo/user/bonsaikitten) has joined #gentoo-council
-[15:01] <kingtaco|laptop> ok, we starting this shindig?
-[15:01] --- kingtaco|laptop sets modes [#gentoo-council +m]
-[15:02] <Kugelfang> sure
-[15:02] <Flameeyes> ready to rumble
-[15:02] <kingtaco|laptop> ok, whos the logger this month?
-[15:02] <kloeri> me?
-[15:02] <Kugelfang> i propose kloeri
-[15:02] <kingtaco|laptop> ok
-[15:02] <kingtaco|laptop> done
-[15:02] <robbat2> ok
-[15:02] <kingtaco|laptop> who's here
-[15:02] * Kugelfang 
-[15:02] * robbat2 robbat2
-[15:02] * agaffney raises his hand with his wolf31o2 mask on
-[15:02] * kingtaco|laptop kingtaco
-[15:03] * Flameeyes is here and is logging as usual
-[15:03] <Kugelfang> vapier: stop hiding
-[15:03] * kingtaco|laptop pokes spanky with a stick
-[15:03] <SpanKY> reading books
-[15:03] <kloeri> heh
-[15:03] <agaffney> he was just here :P
-[15:03] * agaffney throw his copy of Dune at SpanKY
-[15:03] <kingtaco|laptop> ok
-[15:03] <kingtaco|laptop> topics for today
-[15:03] <Kugelfang> so, let's discuss Reply-To and SPF first please
-[15:03] <kingtaco|laptop> 1.  spf
-[15:03] <kingtaco|laptop> 2.  reply-to
-[15:04] <kingtaco|laptop> 3. QA
-[15:04] <Kugelfang> i'd like to have reply-to first
-[15:04] <Kugelfang> if nobody objects
-[15:04] <kingtaco|laptop> 4.  bugs
-[15:04] <kingtaco|laptop> anytthing else?
-[15:04] <kingtaco|laptop> Kugelfang, sure
-[15:04] <Flameeyes> Kugelfang, start then
-[15:04] <kingtaco|laptop> aight
-[15:04] <kingtaco|laptop> Kugelfang, go for it
-[15:04] <Kugelfang> ok, Reply-TO:
-[15:05] <Kugelfang> some people want to switch -core ML to add a reply-to filed to the mail header
-[15:05] <Kugelfang> others just want to make all mailing lists show the same behaviour
-[15:05] <Kugelfang> i say: get a new mail client or use the procmail recipes that wolf posted to gentoo-dev ML
-[15:05] <kingtaco|laptop> my position is that it's been posted for both procmail and maildrop the way for a person to configure it to either preference
-[15:05] <Kugelfang> exactly
-[15:05] <kingtaco|laptop> I don't see any reason to change
-[15:06] <Kugelfang> this is why i want to immediately vote on this
-[15:06] <kingtaco|laptop> anyone else?
-[15:06] <kloeri> I just committed a reply-to-list plugin for thunderbird-2 yesterday
-[15:06] <kingtaco|laptop> and there you go
-[15:06] <Kugelfang> excellent
-[15:06] <kingtaco|laptop> yet another way
-[15:06] <agaffney> it would be nice for all the lists to behave the same, but the behavior can be changed with procmail
-[15:06] <Flameeyes> for me it's fine as it is, if the mail clients aren't good enough, just improve them
-[15:06] <Kugelfang> vote: DonÄ't change reply-to for gentoo-core or any other mailing list
-[15:06] <agaffney> so it's really a non-issue
-[15:06] <kloeri> so we're not touching thunderbird itself but still fixing the client :)
-[15:06] * Kugelfang votes yes
-[15:06] * kingtaco|laptop yes
-[15:06] * kloeri votes yes
-[15:06] * robbat2 yes
-[15:06] * Flameeyes yes
-[15:06] * agaffney yes
-[15:07] <SpanKY> umm clarify "dont change"
-[15:07] <Kugelfang> SpanKY: you'r elagging
-[15:07] <Flameeyes> SpanKY?
-[15:07] <kingtaco|laptop> SpanKY, no change
-[15:07] <Kugelfang> SpanKY: don't change from what it's currently doing
-[15:07] <SpanKY> "dont change existing behavior for any lists"
-[15:07] --> Falco (n=Falco@gentoo/developer/falco) has joined #gentoo-council
-[15:07] <kloeri> no header munging
-[15:07] <kingtaco|laptop> yea
-[15:07] <Kugelfang> precisely
-[15:07] <SpanKY> we're doing header munging now
-[15:07] <SpanKY> for all non-core lists
-[15:07] <kloeri> not on -core
-[15:07] <kloeri> yes
-[15:07] <Kugelfang> correct...
-[15:08] <Kugelfang> i think this is a non-issue
-[15:08] <SpanKY> so "dont change" could mean "dont set Reply-To on non-core lists"
-[15:08] <Kugelfang> no
-[15:08] <SpanKY> if you're going with "dont change existing behavior" then whatever, that's fine
-[15:08] <Flameeyes> don't change the behaviour from the current one
-[15:08] <kingtaco|laptop> on any list
-[15:08] <agaffney> SpanKY: "don't change" means "leave everything alone"
-[15:08] <Flameeyes> I'd suggest also to update the documentation on the dev handbook
-[15:08] <kingtaco|laptop> ok
-[15:08] <Flameeyes> so that new devs can see the way to change -core behaviour through procmail
-[15:08] <kingtaco|laptop> so we're not changing behavior
-[15:08] <SpanKY> seems lame that everything acts the same but one list, but ive personally never had a problem and i dont use rules
-[15:08] <Kugelfang> i'm sorry that my vote request was not precise
-[15:08] <Flameeyes> kloeri, devrel handles that?
-[15:09] <kloeri> Flameeyes: sure
-[15:09] <kingtaco|laptop> I would like one thing though, someone write up a doc explaining how to change it to your preference
-[15:09] <Flameeyes> kloeri, can you make it so? :)
-[15:09] <Kugelfang> ok, next try.
-[15:09] <Flameeyes> kingtaco|laptop, that's what I said :P
-[15:09] --> NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-[15:09] <kloeri> I think I just volunteered..
-[15:09] <kingtaco|laptop> Flameeyes, ah, I missed that
-[15:09] <kingtaco|laptop> ok, next issue
-[15:09] <Flameeyes> kloeri, perfect
-[15:09] <Flameeyes> spf then
-[15:09] <kingtaco|laptop> Kugelfang, spf?
-[15:09] <Kugelfang> Don't change the current behaviour of reply-to munging for all gentoo mailing lists, including gentoo-core
-[15:10] <Kugelfang> did we agree on that?
-[15:10] <kloeri> Kugelfang: yes
-[15:10] <Flameeyes> Kugelfang, yes
-[15:10] <agaffney> I believe so
-[15:10] <Kugelfang> good
-[15:10] <kingtaco|laptop> yes
-[15:10] <Kugelfang> SPF:
-[15:10] <Kugelfang> for the first, i'd like to voice kurt, if he's available
-[15:10] <robbat2> err, I didn't see a final vote from spanky
-[15:10] <Kugelfang> @SpanKY> if you're going with "dont change existing behavior" then whatever, that's fine
-[15:10] <kingtaco|laptop> robbat2, "thats fine"
-[15:10] <robbat2> ok
-[15:10] <Flameeyes> robbat2, he said he's fine, although he's hardly needed to confirm his own vote at this point :P
-[15:11] <Kugelfang> hm, kurt's not here
-[15:11] <kingtaco|laptop> Kugelfang, I've invited
-[15:11] <kingtaco|laptop> lets see if he's here
-[15:11] <kingtaco|laptop> wanna make it last?
-[15:11] <Kugelfang> hmm
-[15:11] <Flameeyes> fine by me
-[15:11] <agaffney> he's active
-[15:11] --> klieber (i=klieber@freenode/facilities-host/gentoo/klieber) has joined #gentoo-council
-[15:11] <kingtaco|laptop> ok
-[15:11] <SpanKY> do we need him to state anything else
-[15:11] --- kingtaco|laptop sets modes [#gentoo-council +v klieber]
-[15:11] <SpanKY> he's already posted enough info
-[15:11] --- Kugelfang sets modes [#gentoo-council +v kingtaco|laptop]
-[15:11] <Kugelfang> ups
-[15:11] --> dostrow (n=dostrow@gentoo/developer/dostrow) has joined #gentoo-council
-[15:12] <SpanKY> http://www.gentoo.org/proj/en/infrastructure/spf.xml
-[15:12] <Kugelfang> SpanKY: i got a question
-[15:12] --> welp (n=welp@gentoo/contributor/welp) has joined #gentoo-council
-[15:12] <Kugelfang> klieber: hi, thanks for joining
-[15:12] <klieber> 'lo
-[15:12] <Kugelfang> klieber: i got one question regarding to our current setup
-[15:12] <agaffney> klieber: did you state how you got the mail sent from your gmail with your @gentoo.org in From: to give *negative* score in SA?
-[15:12] <klieber> agaffney: because it was sent via a valid MX for that domain.
-[15:13] <klieber> via the return-path
-[15:13] <robbat2> valid MX for the domain in the return path
-[15:13] <Kugelfang> klieber: why do we use the TXT record still, though there has been an SPF record added to DNS?
-[15:13] <klieber> Kugelfang: the SPF record is a TXT record
-[15:13] <Kugelfang> klieber: not according to the RFC
-[15:13] <klieber> that's what you put in DNS -- a TXT record (vs. A or MX)
-[15:13] <Kugelfang> klieber: it says for servers that don'T support it, you can use TXT
-[15:14] <Kugelfang> klieber: for other, you should use SPF
-[15:14] <klieber> 1 sec
-[15:14] <Kugelfang> sure
-[15:14] <klieber> I'm at work now
-[15:14] <SpanKY> is that really relevant to the issue at hand ?
-[15:14] <kingtaco|laptop> I don't think so
-[15:14] <agaffney> no
-[15:14] <kingtaco|laptop> Kugelfang, I think the debate is to use ?all *all or not publish spf
-[15:15] <wolf31o2> ok guys... I'm out
-[15:15] <Kugelfang> *shrug*, i just wanted to be covers for any decission that could come up
-[15:15] <-- wolf31o2 has quit ("Leaving")
-[15:15] --> wolf31o2|work (n=wolf31o2@gentoo/developer/wolf31o2) has joined #gentoo-council
-[15:15] --- ChanServ sets modes [#gentoo-council +o wolf31o2|work]
-[15:15] <klieber> http://www.openspf.org/dns.html <-- that says use txt.
-[15:15] <klieber> so if there is an SPF record, it's news to me
-[15:15] <kingtaco|laptop> Kugelfang, how does the dns type matter though?
-[15:15] <agaffney> klieber: in my current setup (at home and at work), I have my @g.o address set as an identity and send out through the local mail server. how would I set this up to get a negative score in SA?
-[15:15] <Kugelfang> kingtaco|laptop: well, i can discuss it with klieber later on
-[15:15] <agaffney> I bet most people's setups are closet to mine than your gmail example
-[15:16] <agaffney> *closer
-[15:16] <klieber> guys, i have a meeting -- I have to go.  sorry.
-[15:16] <Kugelfang> kingtaco|laptop: it was one of the points that critics bring up in regard to SPF
-[15:16] <klieber> agaffney: don't forge return-path, you won't piss off SPF.  thats the bottom line.
-[15:16] <SpanKY> thx klieber 
-[15:16] <kingtaco|laptop> Kugelfang, I don't see how it applies though
-[15:16] * klieber vanishes
-[15:16] <kingtaco|laptop> thanks klieber
-[15:16] <Flameeyes> agaffney, is the mail server authenticated or open?
-[15:16] <SpanKY> brb, FYI i vote in favor of keeping SPF as is
-[15:16] <agaffney> it only relays to internal IPs
-[15:17] <Flameeyes> authenticated mail servers usually just rewrite the Return-Path with the actual user used
-[15:17] <kingtaco|laptop> guys, can we agree that someone(infra?) will document how to use a 3rd party email server with spf?
-[15:17] <Flameeyes> [gmail for instance]
-[15:17] <agaffney> kingtaco|laptop: that would certainly be one solution
-[15:17] <kingtaco|laptop> so we don't end up spending an hour figuring it out :)
-[15:17] <Flameeyes> kingtaco|laptop, that would be useful, yes
-[15:17] <kingtaco|laptop> anyone oppose?
-[15:17] <Flameeyes> kingtaco|laptop, and also update the documentation about the use of the gentoo ssmtp server
-[15:17] <agaffney> with examples for all major MTAs (postfix, exim, qmail, etc.)
-[15:18] <kloeri> documentation on using third party and gentoo ssmtp server would solve it imo
-[15:18] <Flameeyes> kloeri, same for me
-[15:18] <kingtaco|laptop> ok, vote: infra updates smtp docs and adds docs about howto use spf.  spf stays the same, and if it's needed we're revisit
-[15:18] <kingtaco|laptop> *we'll
-[15:18] <Flameeyes> s/we're/we'll/ i suppose?
-[15:18] <kloeri> kingtaco|laptop: wfm
-[15:18] --- kingtaco|laptop has changed the topic to: http://www.gentoo.org/proj/en/council | Last log : http://www.gentoeso.org/proj/en/council/meeting-logs/20060914.txt | meeting @ Nov 9th 2000UTC
-[15:19] <Flameeyes> yes for me too
-[15:19] * kingtaco|laptop yes
-[15:19] <agaffney> yes, but it needs to be in a timely fashion
-[15:19] <Kugelfang> klieber: see RFC4408, Section 3.1.1
-[15:19] <kingtaco|laptop> agaffney, a month
-[15:19] <agaffney> kingtaco|laptop: WFM
-[15:19] <kingtaco|laptop> next council meeting
-[15:19] <robbat2> works for me
-[15:19] * Kugelfang votes yes
-[15:19] <kingtaco|laptop> SpanKY?
-[15:19] <agaffney> proper docs by the next meeting or SPF goes?
-[15:19] <agaffney> or atleast it gets "revisited" :P
-[15:20] <kloeri> proper docs
-[15:20] <kingtaco|laptop> agaffney, not really, it'll be reviewed
-[15:20] <SpanKY> [15:16] <SpanKY> brb, FYI i vote in favor of keeping SPF as is
-[15:20] <kingtaco|laptop> heh
-[15:20] <kingtaco|laptop> ok
-[15:20] <kingtaco|laptop> ok
-[15:20] <kingtaco|laptop> next topic then
-[15:20] <kingtaco|laptop> robbat2, wanna update us on bugs?
-[15:21] <robbat2> kingtaco|laptop, go play with bugstest.g.o folks
-[15:21] <robbat2> it's up
-[15:21] <kingtaco|laptop> robbat2, in "final" configuration?
-[15:21] <robbat2> i'm happy with the db stuff, but I think the web needs more tuning
-[15:21] <Kugelfang> yay
-[15:21] <kingtaco|laptop> ok
-[15:21] <kingtaco|laptop> any questions?
-[15:21] <Flameeyes> robbat2, do you have a timeframe?
-[15:21] <agaffney> what are some queries that would typically bring down the existing setup?
-[15:21] --- kingtaco|laptop sets modes [#gentoo-council +v spb]
-[15:21] <Kugelfang> robbat2: is jforman going to administrate it any further?
-[15:22] <Kugelfang> robbat2: just informational :-)
-[15:22] <kingtaco|laptop> Kugelfang, I'd think so
-[15:22] <kloeri> agaffney: "all kernel"
-[15:22] <robbat2> agaffney, 'ALL kernel' and 'ALL gentoo'
-[15:22] <kingtaco|laptop> all e
-[15:22] <Flameeyes> "ALL R"
-[15:22] <robbat2> Flameeyes, I don't have a timeframe
-[15:22] <kloeri> agaffney: queries returning insane amounts of results generally
-[15:22] <Kugelfang> querying ALL kernel
-[15:22] <Kugelfang> right now
-[15:22] * Flameeyes querying ALL R
-[15:22] <kingtaco|laptop> Flameeyes, depends on how well the test goes
-[15:23] <robbat2> ALL kernel is 36k results
-[15:23] <kingtaco|laptop> no bugs?  we'll consider moving after a couple weeks of testing
-[15:23] <Flameeyes> kingtaco|laptop, supposed so, but a question had to be done
-[15:23] <kloeri> ALL R is some 146k results iirc
-[15:23] <SpanKY> so who do i have to talk to in order to get bug regressions actually fixed
-[15:23] <SpanKY> filing bugs in bugzilla doesnt work
-[15:23] <Flameeyes> so a parallel ALL R and All amarok had the second return bugs with a decent timing
-[15:23] <SpanKY> i have no problem doing the work myself
-[15:23] <Kugelfang> ALL Kernel still hasn't finished :-P
-[15:23] <robbat2> SpanKY, email me if you have a regression on bugstest
-[15:24] <agaffney> I'm still waiting for a return on "ALL kernel" after 2-3 minutes
-[15:24] <Flameeyes> uhm
-[15:24] <Kugelfang> ah, mine just returend
-[15:24] <Flameeyes> the results for ALL amarok are mixed with bugs that has nothing to do with amarok
-[15:24] <SpanKY> robbat2: i'm talking user experience, not db load
-[15:24] <kingtaco|laptop> agaffney, it'll take ~5 minutes to start returning results
-[15:24] <SpanKY> robbat2: things like default search values, css fixups, etc...
-[15:24] <kloeri> Flameeyes: sure amarok isn't in a comment?
-[15:24] <Flameeyes> kloeri, not sure, will check now
-[15:25] <Flameeyes> yeah it's in comments
-[15:25] <kloeri> ALL searches subject + comments
-[15:25] <Flameeyes> is this a new thing?
-[15:25] <robbat2> jforman has said he doesn't have much time at all, so I'm doing my best with all issues for bugstest at the moment
-[15:25] <agaffney> ok, firefox is gobbling up memory like a mofo
-[15:25] <kloeri> nope
-[15:25] <Flameeyes> kloeri, used to check just subject
-[15:25] <agaffney> so it must be trying to dispaly the results
-[15:25] <Kugelfang> agaffney: use konqueror :-P
-[15:25] <kloeri> agaffney: yeah, I pretty much killed my laptop yesterday with "ALL R" :)
-[15:25] <kingtaco|laptop> agaffney, oh yeah, it's some GB of html :)
-[15:25] <agaffney> there we go
-[15:25] <SpanKY> robbat2: i know jforman doesnt have time, but when i've asked to help, i havent gotten any response
-[15:25] <agaffney> 36k for ALL kernel
-[15:26] <Kugelfang> kloeri: the correct query is 'ALL dev-lang/R'
-[15:26] <Flameeyes> kloeri, bugs.gentoo.org shows only for subjet, not comments
-[15:26] <Flameeyes> [which is good
-[15:26] <Flameeyes> because it asctually gives _decent_ results
-[15:26] <Flameeyes> in comments we have useflags that will make such a search request pointless
-[15:26] <kloeri> Kugelfang: no, I wanted ALL R because we we're trying to push bugstest as much as possible
-[15:26] <kingtaco|laptop> ok, so we're all good on bugs?
-[15:26] <-- dostrow has quit (Client Quit)
-[15:26] <robbat2> ok, so I should change the 'ALL' search to only search summaries
-[15:26] <Flameeyes> ALL R returning data now
-[15:26] <Kugelfang> kloeri: :-P
-[15:26] <Flameeyes> robbat2, would be appreciated, yes
-[15:26] <agaffney> robbat2: what's different about the bugstest setup?
-[15:27] <robbat2> agaffney, dual database backend, and I've gotten the searching stuff totally parallized between the two databases
-[15:27] <robbat2> one sec, i'll give you a cheesy diagram
-[15:28] <Kugelfang> hmm, cheese
-[15:28] <kingtaco|laptop> can we move this to the open discussion?
-[15:28] <robbat2> Slave1 <--- (DB1 <--> DB2) --> Slave2
-[15:28] <robbat2> sure
-[15:28] <kingtaco|laptop> kk
-[15:28] <agaffney> did we forget about QA?
-[15:28] <Kugelfang> no
-[15:28] <kingtaco|laptop> that's next
-[15:28] <Kugelfang> agaffney: that's comming now
-[15:28] <SpanKY> i thought the last two items were pretty much open discussion
-[15:28] <agaffney> ah
-[15:28] <Kugelfang> spb: ping?
-[15:28] <Flameeyes> qa issues, kloeri want to talk?
-[15:29] <kingtaco|laptop> spb, consider yourself poked
-[15:29] <kingtaco|laptop> SpanKY, pretty much
-[15:29] <kloeri> yup, I'll give a quick update on QA and hopefully spb will be around to answer questions
-[15:29] <kingtaco|laptop> SpanKY, I'll -m in a minute
-[15:30] <agaffney> robbat2: can I pick your brain about that setup in a little while?
-[15:30] <robbat2> agaffney, yeah
-[15:30] <robbat2> find me in -infra about it
-[15:30] <kloeri> as soon as spb manage to free up some time he wants to start work on EAPI-0 and package manager specification documents
-[15:30] <kloeri> that's the big stuff more or less
-[15:30] <kingtaco|laptop> when will he "have time"?
-[15:31] <Kugelfang> i guess that means real life issues?
-[15:31] <kingtaco|laptop> having guidelines will help avoid a lot of the fighting that goes one
-[15:31] <kingtaco|laptop> *on
-[15:31] <kloeri> smaller items includes working on implementing GLEP 48, doing more automated QA scans and going through all the QA team members and seeing who wants to do what etc.
-[15:31] <kloeri> Kugelfang: he's busy with finishing university currently
-[15:31] <Kugelfang> ah, i see
-[15:32] <agaffney> school is overrated
-[15:32] <Kugelfang> that surely has priorit y:-)
-[15:32] <Kugelfang> agaffney: pfff
-[15:32] <kingtaco|laptop> ok, so I guess we will need to revisit again next month?
-[15:32] <Kugelfang> probably
-[15:32] <kloeri> as for when he'll have time I can't answer that
-[15:32] <kingtaco|laptop> kloeri, any other info?
-[15:33] <Kugelfang> is there anything to vote one? or can i get back to the birthday party upstairs? :-P
-[15:33] <kingtaco|laptop> just open discussion now I think
-[15:33] <kingtaco|laptop> anyone have any other issues?
-[15:33] <Kugelfang> coolies....
-[15:33] <kingtaco|laptop> before open floor?
-[15:33] <Kugelfang> i certainly don't
-[15:33] * agaffney has an issue with the fact he wasn't invited to the birthday parts upstairs
-[15:33] <agaffney> *party
-[15:33] <Kugelfang> that was a quick thing
-[15:33] <kloeri> I asked him who's going to work on EAPI-0 and PMS and he said QA would be in charge but that interested parties were free to submit docs, patches etc.
-[15:33] <Kugelfang> agaffney: :-P
-[15:33] <agaffney> Kugelfang: save me cake!
-[15:34] <Kugelfang> ah, right, the location of preliminary EAPI-0:
-[15:34] <Flameeyes> err sorry had problems with the ALL r results
-[15:34] <kloeri> some paludis people are very interested and portage team and ferringb have expressed interest in helping as well
-[15:34] <Kugelfang> svn.pioto.org
-[15:34] <kingtaco|laptop> aight
-[15:34] <kloeri> Kugelfang: that's something we need to figure out later I think
-[15:34] <Kugelfang> svn:// works, so people can do nice patches, too :-)
-[15:34] --> dostrow (n=dostrow@gentoo/developer/dostrow) has joined #gentoo-council
-[15:35] <Kugelfang> kloeri: as it is svn, it can easily be migrated later on
-[15:35] --- kingtaco|laptop sets modes [#gentoo-council -m]
-[15:35] <kingtaco|laptop> aight, open floor
-[15:35] <kloeri> there's some !gentoo devs that could be quite valuable helping with the EAPI / PSM documentation but that raises the whole debate about things not being on gentoo infra again
-[15:35] <Kugelfang> http://svn.pioto.org/viewvc/paludis/scratch/eapispec/
-[15:35] <kloeri> maybe we could use overlays.g.o for that
-[15:35] --> musikc (n=musikc@mail.erwinpenland.com) has joined #gentoo-council
-[15:35] --- agaffney sets modes [#gentoo-council -o agaffney]
-[15:35] <kingtaco|laptop> kloeri, I think we addressed that, for it to be "official" it has to be on gentoo hardware
-[15:35] <kloeri> kingtaco|laptop: indeed
-[15:35] <Kugelfang> kloeri: or we can use this until it has at least a 'draft' status, no?
-[15:35] <Kugelfang> kloeri: besides, this is very open
-[15:36] <kingtaco|laptop> devmanual set prescedence
-[15:36] <Kugelfang> kloeri: pioto has his thumb on the repo
-[15:36] <kloeri> overlays.g.o could probably be a middle ground as it's official gentoo infra and "outsiders" can get access as well
-[15:36] --> _masterdriverz_ (n=MasterDr@cpc3-bexl4-0-0-cust498.bmly.cable.ntl.com) has joined #gentoo-council
-[15:37] <kloeri> anyway, I don't believe documentation is very far at all atm so it's probably something we need to get back to later when something materializes
-[15:37] --> ferringb (n=bharring@c-24-21-135-117.hsd1.mn.comcast.net) has joined #gentoo-council
-[15:37] <Kugelfang> so we can open the floor now?
-[15:37] <kingtaco|laptop> I did
-[15:38] <Kugelfang> ah, up there
-[15:38] <Kugelfang> *nod*
-[15:38] <kingtaco|laptop> people, speak now or wait another month!
-[15:38] <ferringb> boobies!
-[15:38] <Kugelfang> ...
-[15:38] <kingtaco|laptop> heh
-[15:38] <ferringb> :)
-[15:38] <Flameeyes> if wolf31o2 was here I would ask about the icons but .. next month :P
-[15:39] <robbat2> anybody in the audience have questions etc?
-[15:39] <robbat2> or can we all pack up and go home?
-[15:39] <tove> robbat2: the tree signing?
-[15:40] <robbat2> tove: I haven't touched for the last few weeks while working on anoncvs and bugstest, sorry
-[15:41] <nightmorph|amd64> (from the floor) so, if i understand it correctly, the posted workarounds for the reply-to cruft will be added to the devmanual?
-[15:41] <Flameeyes> the colour of the soft icecream machine?
-[15:41] <Flameeyes> nightmorph|amd64, I'd rather say dev handbook than devmanual, as it's not a "technical" view
-[15:42] <kingtaco|laptop> nightmorph|amd64, it will be documented
-[15:42] <nightmorph|amd64> ah yes, i meant the handbook
-[15:42] <ferringb> sidenote related to eapi=0...
-[15:42] <nightmorph|amd64> fantabulous! i knew i voted for the council for this reason :)
-[15:42] <ferringb> bug 152127
-[15:42] <kloeri> yes, I stupidly volunteered to document that :)
-[15:42] <kingtaco|laptop> kloeri, someone else already did the work, you just gotta xml it and commit
-[15:43] <agaffney> Flameeyes: what icons?
-[15:43] <kloeri> kingtaco|laptop: yeah, I'm not entirely crazy after all :)
-[15:44] <Flameeyes> agaffney, on the site
-[15:44] <Flameeyes> agaffney, we have some icons that are not exactly legal (modified versions of windows's software, lgpl-licensed icons not respecting it ...
-[15:44] <agaffney> ah
-[15:45] <kingtaco|laptop> I think neysx is trying to fix the icons
-[15:45] <kingtaco|laptop> he posted a bug for a change to the xmlcheck script on cvs
-[15:45] <kingtaco|laptop> Kugelfang, maybe you can do that
-[15:45] <Kugelfang> i have no clue about cvs
-[15:45] <Kugelfang> i'm an svn man
-[15:45] <kingtaco|laptop> ok
-[15:45] <Kugelfang> and i think pylon already did it
-[15:46] <kingtaco|laptop> well someone will do it
-[15:46] <kingtaco|laptop> and I bet neysx will clean it up
-[15:46] <Kugelfang> 19:36 <+CIA-1> pylon * CVSROOT/checkxml.pl: Added ico to the allowed filetypes; bug #154544.
-[15:46] <Kugelfang> 19:36 < jeeves> CIA-1: https://bugs.gentoo.org/154544 nor, P2, All, neysx@gentoo.org->infra-bugs@gentoo.org, NEW, pending, Please add *.ico to the list of allowed file types
-[15:46] <Flameeyes> kingtaco|laptop, the quick fix is to remove them for now, but the issue is still open since last year
-[15:46] * Kugelfang goes to the party now
-[15:46] <Kugelfang> see you guys
-[15:47] <Flameeyes> night danny
-[15:47] <kingtaco|laptop> see ya danny
-[15:47] <Flameeyes> closing here then, who's going to put log and summary?
-[15:47] <kloeri> later Kugelfang
-[15:47] <kloeri> Flameeyes: me
-[15:47] <-- ferringb (n=bharring@c-24-21-135-117.hsd1.mn.comcast.net) has left #gentoo-council
-[15:49] --> spb- (n=christel@gentoo/developer/spb) has joined #gentoo-council
-[15:50] <kloeri> spb-: meeting just finished, thanks and enjoy your evening :)
-[15:50] <spb-> sorry if i be late, beu got us lost
-[15:50] --- bonsaikitten is now known as AmazingPudding
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061214-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20061214-summary.txt
deleted file mode 100644
index 83eceefdb8..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20061214-summary.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Issues discussed:
-- Removal of icons from http://www.gentoo.org due to possible licensing
-  issues. The issue ended up being refered to Trustees who decided to
-  remove the icons.
-- Status of documentation on Reply-To and SPF. This isn't finished yet
-  but is expected do be done soon.
-- Status on bugstest / bugs.gentoo.org. There's still a couple minor
-  issues that needs to be fixed but Robin Johnson (robbat2) hope we can
-  switch over to bugstest 23 dec.
-- Short discussion about what's happening in the QA project.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20061214.txt b/xml/htdocs/proj/en/council/meeting-logs/20061214.txt
deleted file mode 100644
index 0e22cf82c3..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20061214.txt
+++ /dev/null
@@ -1,446 +0,0 @@
-20:59 <@robbat2> kloeri, Kugelfang, SpanKY, you here?
-20:59 < vapier> moo
-20:59 <@FlameBook> kingtaco?
-20:59 < vapier> how do you rebind a channel in bx to a window ?
-20:59 <@kloeri> yup
-21:00 < vapier> ah here we go
-21:00 <@FlameBook> somebody knows why kingtaco is not here?
-21:00 < vapier> i may pop in and out
-21:00 <@wolf31o2|mobile> nope
-21:01 <@Kugelfang> heya there
-21:02  * Kugelfang is now available, too -)
-21:02 <@FlameBook> do we start?
-21:02 <@robbat2> just missing kingtaco
-21:03 <@FlameBook> yeah pinged him in #-dev
-21:03 <@Kugelfang> oh
-21:03 <@FlameBook> he was around a few mins ago
-21:03 <@Kugelfang> well, he'll pop up eventually i guess :-)
-21:04 <@FlameBook> so let's start with an easy one
-21:04 -!- mode/#gentoo-council [+m] by FlameBook
-21:05 <@FlameBook> did you read my mail about icons we have on the site'
-21:05 <@robbat2> what all is on the agenda
-21:05 <@FlameBook> ?
-21:05 <@wolf31o2|mobile> I did... and I agree that we should probably unlink them from the site until it can be cleared up by the trustees
-21:06 <@FlameBook> trustees never cleared it up in more than one year
-21:07 <@wolf31o2|mobile> until you said something, I'd not heard a thing about it
-21:07 <@FlameBook> the most clear statement we have is that we're not liable unless they demonstrate we broke copyright laws intentionally
-21:07 <@robbat2> yes, I saw the email. i don't think trustees are going to help - perhaps better to announce that unless the license issues are cleared up, they will be going away
-21:07 <@wolf31o2|mobile> basically, anything that was tasked to the old trustees, the new ones likely know nothing about
-21:07 <@FlameBook> wolf31o2|mobile, I mailed last year about that
-21:07 <@FlameBook> sigh -_-
-21:07 -!- mpagano [n=mpagano@pool-70-105-167-94.nwrknj.fios.verizon.net] has quit [Client Quit]
-21:07 <@kloeri> we have new trustees now so I think it'd be worth bringing it up with trustees again
-21:08 <@wolf31o2|mobile> right
-21:08 <@Kugelfang> remove until they have settled?
-21:08 <@wolf31o2|mobile> I would say so
-21:08 <@Kugelfang> nod
-21:08 <@FlameBook> I'd remove them and ask for new artists
-21:08 <@kloeri> they may or may not know about it but a reminder certainly won't hurt a bit
-21:08 <@wolf31o2|mobile> better safe than sorry and all that jazz
-21:08 <@FlameBook> it's impossible to clear them up anyway
-21:08 <@FlameBook> most of them are copied from Windows software
-21:08 <@Kugelfang> vote: remove the icons and let the trustees handle the situation afterwards
-21:08 <@wolf31o2|mobile> right... unless we simply removed any offending ones
-21:08 <@FlameBook> is anybody going to write Microsoft to ask permission to use them? :D
-21:08 <@wolf31o2|mobile> Kugelfang: yes
-21:08 <@Kugelfang> vote: yes
-21:08 <@kloeri> yes
-21:09 <@robbat2> vote: yes
-21:09 <@FlameBook> Kugelfang, yes, although I'd rather take a definitive approach
-21:09 <@Kugelfang> phone
-21:09 <@wolf31o2|mobile> FlameBook: the "definitive" approach is they're being removed... if the trustees don't do anything beyond that, they're still removed
-21:09 <@robbat2> there's voicemail for kingtaco (thanks to solar), so he should be here soon
-21:10 <@FlameBook> wolf31o2|mobile, well, if we wait for trustees, we're "waiting to clear up"
-21:10 <@FlameBook> if we're just scratching them we're "asking new artists to contribute a true Gentoo icon set"
-21:10 <@robbat2> with all of the license issues clear
-21:10 <@FlameBook> right
-21:11 <@FlameBook> a new icon set, either original or derived, with a proper license
-21:11 <@Kugelfang> so your proposal is to remove them permanently?
-21:11 <@FlameBook> I'm not sure how much lila is related to gentoo, but it might as well be asked to made official
-21:11 <@FlameBook> Kugelfang, yes
-21:11 <@Kugelfang> i can live with that :-)
-21:13 <@Kugelfang> so new vote?
-21:13 <@wolf31o2|mobile> on what?
-21:13 <@Kugelfang> remove them permanently
-21:13 <@FlameBook> The Lila theme is a community project, originally created by Daniel G. Taylor and members of the Gentoo Linux community.
-21:13 <@FlameBook> http://www.lila-center.info/doku.php?id=about we might as well consider the idea of making these the suggested one or something
-21:14 -!- mode/#gentoo-council [+o vapier] by ChanServ
-21:14 <@wolf31o2|mobile> I would prefer that if we were to have an "official" icon theme that it at least attempt to match the other themes we have
-21:15 <@FlameBook> wolf31o2|mobile, the current one does not really match anything
-21:15 <@FlameBook> lila at least match the colour
-21:15 <@wolf31o2|mobile> so if the vote is just to drop the current icon set, then I'm giving a yes... if it involves including *any* current icon set as some sort of "official" set then I'd say no
-21:15 <@wolf31o2|mobile> I don't care about the current ones other than the fact that they are in violation of other people's IP
-21:15 <@vapier> lila isnt part of the icons on the Gentoo website
-21:16 <@Kugelfang> phone again
-21:16 <@FlameBook> I'd just remove the one in the website, and then lend it over to userrel
-21:16 <@kloeri> vapier: lila could be adapted instead of the current icons, that's what FlameBook is aiming at I think
-21:16 <@Kugelfang> i'm fine with either removing it permenently or just until the trustees have settled on it
-21:16 <@Kugelfang> biab
-21:16 <@wolf31o2|mobile> and lila doesn't match our themes... but again, I don't think that needs to have *anything* to do with the discussion, which should be focused 100% on the current set, which is in violation of several trademarks
-21:16 <@vapier> what themes
-21:16 <@vapier> the only themes we have are on the livecd
-21:17 <@wolf31o2|mobile> yes
-21:17 <@wolf31o2|mobile> those are the only current "gentoo" themes that I am aware of
-21:17 <@vapier> easier to transition livecd to lila than create something compeletely new to match livecd
-21:17 <@wolf31o2|mobile> I'm sorry, but I'm not putting that gay ass pastel purple on anything with my name on it
-21:17 <@wolf31o2|mobile> ;]
-21:17 <@FlameBook> just ignore the lila problem now
-21:18 <@FlameBook> consider just the icons on the website
-21:18 <@wolf31o2|mobile> thank you
-21:18 <@FlameBook> those, IMHO, has to go
-21:18 <@wolf31o2|mobile> agreed
-21:18 <@kloeri> agreed
-21:18 <@FlameBook> after that, we might ask userrel to handle it, or some other project
-21:19 <@FlameBook> but the icons on the site has to go quickly
-21:19 <@vapier> the purple on the livecd blows and everyone knows it ;p
-21:20 <@vapier> well just vote cause the discussion is going nowhere and our sense/ability to put together a decent theme is close to nil
-21:20 <@FlameBook> as vapier said
-21:20 <@FlameBook> so votes on removing the icons permanently and closing the discussion without asking trustees to clear anything up
-21:20 <@FlameBook> me: yes
-21:20 <@Kugelfang> yes
-21:20 <@robbat2> yes
-21:20 <@wolf31o2|mobile> yes
-21:20 <@kloeri> yes
-21:21 <@robbat2> vapier, your vote?
-21:21 <@vapier> whatever
-21:22 <@vapier> i imagine the icons will be fetchable via the forums, so it's fine to scrub from www
-21:22 <@robbat2> vapier, could you give a definitive yes/no
-21:22 <@vapier> sure
-21:23 <@FlameBook> so, robbat2 can you handle it as part of infra, or can you tell me who to ask to enact this?
-21:23 <@robbat2> 6 votes for, 1 absent
-21:23 <@robbat2> FlameBook, one of the web docs folks I think
-21:23 <@wolf31o2|mobile> neysx would be the best bet
-21:23 <@vapier> licensing is so lame
-21:24 -!- amne [n=amne@gentoo/developer/amne] has joined #gentoo-council
-21:24 <@FlameBook> okay next point? spf? how's the status on that?
-21:25 <@Kugelfang> anybody from infra who can tell us the status of the docs?
-21:25 <@Kugelfang> that's the only thing missing, right?
-21:25 <@kloeri> yes
-21:25 <@robbat2> not my side of infra
-21:26 <@kloeri> I was supposed to document some of it but haven't quite finished that yet due to RL constraints
-21:26 <@FlameBook> kloeri, do you need help with the Reply-To doc btw?
-21:27 <@kloeri> I mostly need to read what I've got one more time, making sure it's actually correct and makes sense + xml'ify it
-21:27 <@FlameBook> if you want, I can easily xmlify it
-21:27 <@kloeri> I definitely expect to get it done this weekend (I'm behind on a few different things so spending the weekend playing catch up)
-21:27 <@kloeri> xmlifying isn't a problem
-21:28 <@kloeri> it's not that much text anyway so it shouldn't take long adding a few xml tags
-21:28 <@kloeri> I'm more concerned about making sure it's actually correct before committing any junk :)
-21:30 <@FlameBook> so, let's just wait a it more about spf doc, hoping that it can actually be addressed?
-21:30 <@kloeri> infra was supposed to document some sample configurations of using dev.g.o smtp iirc
-21:30 <@Kugelfang> FlameBook: nod
-21:30 <@kloeri> yes
-21:30 <@FlameBook> kloeri, and change the doc so that does not say that the smtp is only for who can't really do otherwise
-21:30 <@kloeri> FlameBook: right
-21:31 <@vapier> i'm satisfied
-21:31 <@FlameBook> just want to be sure, if next month we'll be still waiting, it would make us a bunch of clowns..
-21:31 <@robbat2> yup, thats all fine
-21:31 <@FlameBook> [at least waiting without any progress on it]
-21:32 <@kloeri> that's not going to happen - at least not my part of it
-21:32 <@FlameBook> kloeri, thanks, but I was actually concerned about SPF
-21:34 <@kloeri> well, I can't answer on infras behalf - think you need kingtaco in this case
-21:34 <@FlameBook> and he's the one missing :/
-21:34 <@FlameBook> robbat2, what remains on agenda?
-21:34 <@robbat2> FlameBook, not sure, that's why I asked what was on the agenda at the start!
-21:34 <@FlameBook> [after two items from me, I'd leave some space to someone else before the last one :P]
-21:35 <@wolf31o2|mobile> robbat2: how about an update on bugstest/bugs?
-21:35 <@vapier> that'd be nice, bugs.g.o just gets worse everyday
-21:36 <@robbat2> bugstest is up, there's two more enhancements that people have asked for, next weekend is a possible for moving
-21:36 <@wolf31o2|mobile> nice
-21:36 <@FlameBook> next 16/12 or 23/12?
-21:37 <@vapier> robbat2: who is taking care of bugs now ?  you ?
-21:37 <@vapier> jforman seems to have peaced out
-21:37 <@robbat2> 23/12
-21:37 <@robbat2> but sooner might happen if bugs.g.o gets really bad
-21:38 <@FlameBook> robbat2, is utf-8 fixed or fixable easily?
-21:38 <@robbat2> the utf-8 it turns out wasn't an actual bug in bugzilla, just in how we did the test migration
-21:38 <@kloeri> bugs.g.o is already really bad imo
-21:38 <@Kugelfang> definitely
-21:39 <@FlameBook> so anybody has an idea on what is going on with qa? do we have a qa project at all at the moment?
-21:40 <@Kugelfang> we do
-21:40 <@kloeri> spb is actually working on EAPI docs and eroyf are working on setting up automated QA scans
-21:40 <@Kugelfang> sbp just finished his studies and is back on open source work now
-21:40 <@FlameBook> and who is addressing the shadowy things for which we still miss a policy?
-21:41 <@wolf31o2|mobile> I've been doing weekly builds for both RelEng/QA
-21:41  * FlameBook poins to /usr/libexec vs /usr/lib/misc
-21:41 <@kloeri> I'm providing boxes etc. for the qa scans and try to help get that part set up
-21:41 <@vapier> robbat2: so who is taking care of bugs now ?  you ? ;p
-21:41 <@kloeri> I'll be doing weekly alpha builds and probably weekly ia64 builds too from this weekend forward
-21:41 <@Kugelfang> FlameBook: remind me, should spb handle that?
-21:42 <@FlameBook> Kugelfang, if QA wants to enforce a policy, QA should decide on policies, shouldn't they?
-21:42 <@kloeri> and setting up alpha tinderboxing too I guess
-21:42 <@robbat2> vapier, for the new boxes, there is no actual plan yet, beyond a rough guess that the bugzilla admin interface is still jforman, but the rest of it I can handle
-21:42 <@Kugelfang> FlameBook: iirc that was an open discussion, and if QA doesn't think it's a problem, should they make it one?
-21:42 <@FlameBook> this is one of the many things we don't have any clear rule or at least path to follow
-21:42 <@robbat2> as I don't have any experience with the bugzilla admin stuff, just mysql on the back
-21:42 <@Kugelfang> FlameBook: speaking just avbout the misc thing right now
-21:42 <@FlameBook> Kugelfang, well, it _is_ a problem for Gentoo practice
-21:42 <@kloeri> FlameBook: I was talking to spb about documentation and policies the other day actually
-21:43 <@kloeri> FlameBook: glep 40? (the one about the qa team) mentions that qa should help devrel with updating quizzes etc. so I expect to get started on that soon'ish
-21:43 <@FlameBook> Kugelfang, Quality Assurance is not just checking if an ebuild has a misplaced braket
-21:43 <@FlameBook> kloeri, when was glep 40 dated, just to know?
-21:44 <@kloeri> glep 48 it is
-21:44 <@Kugelfang> FlameBook: please, no commonplaces
-21:44 <@FlameBook> dated when?
-21:44 <@kloeri> 24 april 2006
-21:44 -!- spb [i=spb@gentoo/developer/spb] has joined #gentoo-council
-21:45 <@FlameBook> Kugelfang, uhm? I was just saying that IMHO even issues like places where we put stuff, so that they won't break in the long run if we need to relocate them, are part of QA concerns
-21:45 <@FlameBook> so yes, QA should be handling them, and not only
-21:45 <@Kugelfang> FlameBook: i think this was handled on the mailing list sufficiently
-21:45 <@vapier> robbat2: i'm interested in helping with the frontend stuff ... jforman never gets back to me
-21:45 <@vapier> robbat2: things like all these user interface regressions
-21:46 <@Kugelfang> FlameBook: but i guess vapier can give more insight there, as he was one of the most active participants in that discussion
-21:46 <@FlameBook> Kugelfang, this as in QA concerns, or the misc thing? because at the moment, it's not handled at all
-21:46 <@FlameBook> [the misc thing, that is]
-21:46 <@robbat2> vapier, consider yourself hired then, get into #gentoo-infra later on today
-21:46 <@Kugelfang> FlameBook: the misc stuff
-21:47 <@vapier> k
-21:47 <@FlameBook> Kugelfang, last time we talked (me and vapier) the result was that he wants to use /usr/$(get_libdir)/misc, while I know of at least one package that requires a single directory for two ABIs...
-21:47 <@FlameBook> and we have stil ccache and distcc using /usr/$PN
-21:47 <@FlameBook> so I don't think it was handled in the mailing list, not enough at least...
-21:48 <@Kugelfang> ok...
-21:48 <@Kugelfang> i will put it on my agenda than to create a proper polcy for it and put it into the devmanual after propser discussion
-21:48 <@Kugelfang> FlameBook: ok?
-21:49 <@vapier> symlinks across multiple ABI's would address that
-21:49 <@vapier> while libexec does not have the ability to handle the cas
-21:49 <@vapier> e
-21:49 <@Kugelfang> nod
-21:49 <@FlameBook> but besides that, what I'd like to ask QA is to commit for a broader involvement of developers in the process, and accept that they have to address multiple faces of QA, not only on correctness of ebuilds or proper code generation
-21:49 <@vapier> plus libexec screws up my tab completion
-21:49 <@Kugelfang> i have no time this weekend, but starting monday i will be able to work on it
-21:49 <@FlameBook> vapier, I don't think that, we'll fill up with a lot of symlinks at the end
-21:49 <@Kugelfang> FlameBook: sure... but this needs people to actually contribute
-21:50 <@Kugelfang> vapier: *g*
-21:51 <@vapier> your mom is a symlink
-21:51 <@Kugelfang> is she?
-21:52 <@Kugelfang> you surely know
-21:52 <@Kugelfang> sticking your pointer into any symlink!
-21:52 <@FlameBook> so anything else or we open the floor?
-21:53 <@Kugelfang> i have nothing else
-21:53 <@kloeri> I don't have anything either
-21:53 <@Kugelfang> FlameBook: can you pleas esummarise why the current practive is bad in your eyes (in regard to /misc/?) per mail?
-21:53 <@Kugelfang> FlameBook: either to -dev or to me directly
-21:54 <@Kugelfang> (if it's not too much an effort :-))
-21:54 <@FlameBook> Kugelfang, sure, just give me a bit of time, tonight I'm off sooner than usual
-21:55 <@Kugelfang> FlameBook: sure, as i said... i won't work on it before monday
-21:56 <@wolf31o2|mobile> so open floor?
-21:56 -!- mode/#gentoo-council [-m] by Kugelfang
-21:56 -!- kingtaco|work [n=kingtaco@gentoo/developer/kingtaco] has joined #gentoo-council
-21:56 -!- mode/#gentoo-council [+o kingtaco|work] by ChanServ
-21:56 <@kingtaco|work> doh
-21:56 <@Kugelfang> yes :-)
-21:56 <@Kugelfang> kingtaco|work: hahaha
-21:56 <@Kugelfang> kingtaco|work: the meeting just finished
-21:56 <@FlameBook> kingtaco|work, your timing i just the funniest :)
-21:56 <@kingtaco|work> sorry, damn time zones messed me up
-21:56 <@robbat2> UTC never moves
-21:56 <@FlameBook> kingtaco|work, do you want to add something before we open the floor?
-21:56 <@Kugelfang> FlameBook: the floor has been opened
-21:56  * jokey is curious about gentoo-x86 migration
-21:56 <@kingtaco|work> FlameBook, nothing I have thiss month
-21:57 <@FlameBook> we discussed about the icons currently on the site (resolution: remove them as soon as possible)
-21:57 <@Kugelfang> and kingtaco|work is now officially a slacker!!!!!!
-21:57 <@Kugelfang> :-P
-21:57 <@robbat2> jokey, to git/svn you mean?
-21:57 <@kloeri> heh
-21:57 < jokey> robbat2: yep
-21:57 <@Kugelfang> kingtaco|work: sorry dude ;-)
-21:57 <@kingtaco|work> Kugelfang, tis ok
-21:57 <@robbat2> jokey, it was covered previously, but i'll recap
-21:57 <@kingtaco|work> I do want to vote on that
-21:57 <@robbat2> jokey, while svn would work at the moment, it isn't ideal
-21:57 <@vapier> why are we converting
-21:58 <@vapier> first i've heard
-21:58 <@vapier> cvs works fine
-21:58 <@kingtaco|work> vapier, no reason to
-21:58 <@robbat2> jokey, git almost fills the requirements
-21:58 <@Kugelfang> git was not designed for that
-21:58 <@kloeri> cvs is shit but the pain of migrating is probably not worth it imo
-21:58 <@robbat2> the final recommendation from antarus' SoC was that until git gets a few more specific features, we should hold off from any migration
-21:59 -!- spb- [n=spb@gentoo/developer/spb] has joined #gentoo-council
-21:59  * Kugelfang would probably vote yes for a migration to svn, but certainly not for git
-21:59 <+g2boojum> FlameBook: Sorry, somehow I completely lack any memory of the icons issue.  It's a non-issue now, but care to fill me in?
-21:59 <@robbat2> in specific, git needs history slicing and repo slicing
-21:59  * jokey is fully with Kugelfang here
-21:59 <@FlameBook> g2boojum, the icons we have on the /dyn/icons.xml page, contributed by the users, most certainly infringe copyrights and licenses
-21:59 <@robbat2> upstream git does claim to be working on those issues, but says not to expect  results for several months
-22:00 <@kingtaco|work> how is the icons thing our problem?
-22:00 <@Kugelfang> robbat2: git is not the proper tool for that in my eyes
-22:00 <@FlameBook> we have edited copies of windows's icons, other proprietary software icons, real and other logos, and some crystalsvg icons (from kde) that are licensed under LGPL (the icons on the site have no license)
-22:00 <@wolf31o2|mobile> we put it on our page
-22:00 <@kingtaco|work> has soneone claimed we're violating something?
-22:00 <@kingtaco|work> IMO it's a trustees issue
-22:00 <@robbat2> Kugelfang, on what grounds do you make that claim?
-22:00 <@FlameBook> kingtaco|work, the previous trustees never answered to the call
-22:00 <@kingtaco|work> FlameBook, so?  we have new ones now
-22:00 <@wolf31o2|mobile> which is what I said... and FlameBook says the previous trustees didn't do anything about it... so brought it here
-22:00 <@kingtaco|work> and it still isn't our place
-22:01 <@Kugelfang> git is designed as a tool for distributed development
-22:01 <@robbat2> jokey, i'm interested in your objections to git as well
-22:01 <@FlameBook> kingtaco|work, right but what can they do? ask windows the permission to use the icons?
-22:01 <@kingtaco|work> FlameBook, wait until someone proves we're infringing and then remove the infringing stuff?
-22:01 <@Kugelfang> robbat2: gentoo's work is not of distributed nature
-22:01 <+g2boojum> FlameBook: Do we know which ones violate copyright?  I'm happy to suggest that all infringing ones should go; I just don't know which those are.
-22:01 <@FlameBook> kingtaco|work, it would be bad PR if it happens
-22:01 <@kingtaco|work> FlameBook, we have plenty of that already
-22:01 <@Kugelfang> kingtaco|work: no, as in that case we would liable for compensation
-22:01 <@kingtaco|work> misbehaving devs
-22:01 <@FlameBook> g2boojum, I can spot a lot that are infringing, so much that's IMHO not worth the hassle of spotting them
-22:01 <@Kugelfang> kingtaco|work: as soon as we know it, we need to remove it
-22:01 <@FlameBook> and we might miss some
-22:02 <@FlameBook> kingtaco|work, any reason you have to keep em?
-22:02 <@robbat2> err, noisy in here, Kugelfang/jokey, would you join #gentoo-cvs-migration to discuss this at length please?
-22:02 < jokey> just that gentoo-x86 highly depends on the latest ebuilds everywhere so distributing it doesn't make sense
-22:02 <@kingtaco|work> Kugelfang, I don't admit to gentoo putting up any copyrighted material
-22:02  * jokey joins
-22:02 <@wolf31o2|mobile> FlameBook: uhh... it's the trustees job (not the council's) to deal with *anything* legal... so if they wanted to ask MS, that's their choice... at the same time, they're responsible for making sure we comply with any licenses/laws
-22:02 <@kingtaco|work> afaik, it's all free
-22:02 <@kingtaco|work> until someone says otherwise
-22:02 <+g2boojum> FlameBook: Okay, fair enough.
-22:02 <@kingtaco|work> honestly, the council needs to stay out of legal issues
-22:02 <@FlameBook> kingtaco|work, the point is that it's risky, we might be liable, and I'd rather avoid it for the icons we have
-22:02 <@kingtaco|work> has anyone talked to the new trustees?
-22:03 <@kingtaco|work> wolf31o2|mobile, you're one, right?
-22:03 <@wolf31o2|mobile> kingtaco|work: I am
-22:03 <@FlameBook> kingtaco|work, uhm no, it's not free until said otherwise, windows's icons are for sure copyrighted and thus not usable
-22:03 <@vapier> trustees need to stop making legal desicions and talk to the lawyers
-22:03 <@wolf31o2|mobile> vapier: we do
-22:03 <@kingtaco|work> vapier, agreed, but it's still not our shindig
-22:03 <@kingtaco|work> wolf31o2|mobile, tell me that the trustees are handling it
-22:04 <@wolf31o2|mobile> anyway... nobody has said anything about it to the trustees since I've been on the alias
-22:04 <@wolf31o2|mobile> kingtaco|work: as a trustee, I just say we remove the whole damn lot of them
-22:04 <@wolf31o2|mobile> be done with it
-22:04 <@kingtaco|work> wolf31o2|mobile, I'd agree with you, but _we_ don't make that decision
-22:04 <+g2boojum> wolf31o2|mobile: I'd be happy to go along with that.
-22:04 <@wolf31o2|mobile> kingtaco|work: correct... the council has no say on legal matters other than to make suggestions (as anyone can do) to the trustees
-22:05 <@wolf31o2|mobile> anyway... bbiab
-22:05 <@kingtaco|work> da
-22:05 <@FlameBook> kingtaco|work, err why can't we make that decision, considering the icons territory is currently not looked after anyone, technically?
-22:05 <@kingtaco|work> FlameBook, because the only ground for removing them is that it might violate some copyright
-22:05 <@kingtaco|work> it's not proven either way
-22:05 <@kingtaco|work> thus it's a legal issue
-22:05 <@kingtaco|work> and we don't touch them
-22:05 <@FlameBook> I see it in the opposite logic
-22:05 <@FlameBook> we have no standing to leave them there
-22:06 <@kingtaco|work> sure we do
-22:06 <@kingtaco|work> they already exist
-22:06 <@kingtaco|work> presumably people use them
-22:06 <@FlameBook> _and_ we know we'll never have a clearance to use most of them
-22:06 <@kingtaco|work> FlameBook, I don't admit that
-22:06 <@kingtaco|work> and you shouldn't either
-22:07 <@kingtaco|work> if M$ gets sand in their panties for us using their icons(if indeed it's theirs) then the trustees will remove it for copyright violations
-22:07 <@kingtaco|work> unless you've done the byte by byte comparison of our files with theirs, noone knows
-22:07 <@kingtaco|work> you can't assert either way
-22:07 <@kingtaco|work> nor I
-22:08 <@FlameBook> *shrug* then I will say that the council is pointless, if we can't even decide that we want to avoid issues and get rid of something unmaintained that might make us liable to copyright infridgement
-22:08 <@FlameBook> really, I try to be pragmatic, those icons are a risk, they are not even that good IMHO, they are not in an usable format for icon themes, they are a bunch of graphics that is currently unmaintained
-22:08 -!- kingtaco|laptop [n=kingtaco@gentoo/developer/kingtaco] has joined #gentoo-council
-22:08 -!- mode/#gentoo-council [+o kingtaco|laptop] by ChanServ
-22:09 <@kingtaco|laptop> damn video card
-22:09 <@FlameBook> I don't find worth the risk and the hassle to leave them on there, if you want to bring it to the trustees, do so then.
-22:09 <@kingtaco|laptop> where was I
-22:09 <@FlameBook> [22:09]  <FlameBook> *shrug* then I will say that the council is pointless, if we can't even decide that we want to avoid issues and get rid of something unmaintained that might make us liable to copyright infridgement
-22:09 <@FlameBook> [22:10]  <FlameBook> really, I try to be pragmatic, those icons are a risk, they are not even that good IMHO, they are not in an usable format for icon themes, they are a bunch of graphics that is currently unmaintained
-22:09 <@FlameBook> [22:10]  * kingtaco|laptop (n=kingtaco@gentoo/developer/kingtaco) has joined #gentoo-council
-22:09 <@kingtaco|laptop> FlameBook, again, it's not our choice
-22:09 <@kingtaco|laptop> moreover, it's a moot point
-22:09 <@kingtaco|laptop> 2 of the N trustees agree
-22:09 -!- kingtaco|work [n=kingtaco@gentoo/developer/kingtaco] has quit [Read error: 113 (No route to host)]
-22:09 <@FlameBook> I can't see why it's not our choice
-22:09 <@FlameBook> are we deciding on technical matters, aren't we?
-22:09 <@kingtaco|laptop> because we don't make legal decisions
-22:10 <@kingtaco|laptop> this isn't remotly technical
-22:10 <+g2boojum> FlameBook: We have a quorum in #-trustees now.  Working on the issue.
-22:10 <@FlameBook> do whatever you want, if the meeting is finished, I'll work on danny's mail.. and I'll consider twice for next council, really.
-22:10 <+g2boojum> rl03 suggests keeping the Gentoo icons (the ones w/ a gentoo icon inside), and dumping the rest.
-22:11 <@kingtaco|laptop> FlameBook, that' really silly
-22:11 <+g2boojum> FlameBook: Would you please get off your high horse.  You're getting what you wanted, even if it's not quite the way you intended.
-22:12 <@FlameBook> kingtaco|laptop, no it is not, it's just that I think we're just losing time here if we have to jump in fire circles on every decision
-22:12 -!- kingtaco|work [n=kingtaco@gentoo/developer/kingtaco] has joined #gentoo-council
-22:12 -!- mode/#gentoo-council [+o kingtaco|work] by ChanServ
-22:12 <+g2boojum> FlameBook: Had you popped into #-trustees, we probably could have handled it there, too.
-22:12 <@FlameBook> g2boojum, my point is not the icons by themselves
-22:12 <@FlameBook> it's just that it's a bureaucracy I'm no more sure I want to be part of.
-22:14 <@kingtaco|laptop> FlameBook, feel free to write a GLEP changing what we can and cannot do
-22:14 <@kingtaco|laptop> that's what it boils down to
-22:14 <@kingtaco|laptop> we're not without limits
-22:15 <@kingtaco|laptop> however, if we vote on it, then it probalby couldn't go into effect until the next set of council people
-22:15 <@kingtaco|laptop> if we wanted it this year, then I guess it'd have to be a general vote
-22:16 <@FlameBook> kingtaco|laptop, it's not just this particular thing, it's a more general problem
-22:16 <@FlameBook> you can compare with my latest rant on blog.
-22:18 <@FlameBook> besides, I mailed about the icons thing on Nov 24, if it was clear the issue was not our to decide, I wonder why nobody said it...
-22:19 <@kingtaco|work> I would have cought it if I wasn't moving
-22:19 <@kingtaco|work> I'm still behind on emails
-22:19 <@kingtaco|work> I can't speak for the others
-22:19 <@FlameBook> I'm just more used to the technical side, so I'll consider what I'll do before next meeting.
-22:20 <@kingtaco|work> I don't understand
-22:21 <+g2boojum> FlameBook: I saw your "rant", but that seemed like a different issue (the person who was supposed to write up summaries wasn't).
-22:21 <+g2boojum> FlameBook: Or was your complaint that the last two meetings were dull and uninteresting?
-22:22 <@FlameBook> g2boojum, no, it's just the same issue, we're losing ourselves in non-issues, and we can't enact anything decided, even if we stated we wanted to be a stronger council
-22:22 <@FlameBook> this issue just confirmed my impression, so I'm not sure anymore if I want to have part in this, and I'll have to think about it.
-22:22 <@kingtaco|work> FlameBook, the council exists to deside on technical issues, not legal issues
-22:23 <@kingtaco|work> there is no technical reason to decide to keep or remove any or all icons from that page
-22:23 <@kingtaco|work> there is a possible legal reason
-22:23 <@kingtaco|work> even then the jurisdiction matters
-22:23 <@FlameBook> kingtaco|work, there's no need to continue really, I said what I had to say, if the meeting is finished, I'll close here
-22:23 <@kingtaco|work> frankly, we're not competent to decide on such issues
-22:24 <@wolf31o2|mobile> neither are the trustees... we defer legal questions to the lawyers
-22:24 <@kingtaco|work> FlameBook, if you're not willing to listen then I'll stop talking
-22:25 <@FlameBook> kingtaco|work, I just think you're repeating "it's a legal issue you has to ignore it and leave ti to trustees" which is something I don't agree with, and I won't even if you repeat it 30 times
-22:26 <@wolf31o2|mobile> jesus fucking christ on a stick
-22:26 <@kingtaco|work> I've said all I can say
-22:26 <@wolf31o2|mobile> nobody said you haev to ignore it
-22:26 <@kingtaco|work> do what you want
-22:26 <@wolf31o2|mobile> they just said you have to take it to the right people
-22:26 <@wolf31o2|mobile> it is *that* simple
-22:27 <@wolf31o2|mobile> anyway...
-22:27  * kloeri agrees
-22:27 <@wolf31o2|mobile> I mean... if you wanted... you could hound the trustees daily about it
-22:27 <@wolf31o2|mobile> heh
-22:27 <@FlameBook> wolf31o2|mobile, I still think that legal or not legal, deciding on removing them should be allowed to us, considering there's no one maintaining that page anymore
-22:27 <@FlameBook> wolf31o2|mobile, have to look up the response from the previous trustees?
-22:28 <@wolf31o2|mobile> FlameBook: sure, except that your only reasoning for removing them is legal
-22:28 <@FlameBook> wolf31o2|mobile, I asked for a reason to keep them, too..
-22:28 <@kingtaco|work> and I gave one
-22:28 <@kingtaco|work> people use them
-22:28 <@wolf31o2|mobile> how about "because they're there already and take 0 maintenance and aren't broken"
-22:29 <@wolf31o2|mobile> same as any package in the tree that may or may not be maintained
-22:29 <+g2boojum> FlameBook: For what it's worth, the trustees hang out in #-trustees, so if you ask in there we'll do what we can to help.  That's something new w/ the new crop of trustees, but it seems to be working.
-22:29 <+g2boojum> FlameBook: (I'm not complaining about you bringing it to the council, I just want to let you know.)
-22:30 -!- wolf31o2|mobile [n=wolf31o2@gentoo/developer/wolf31o2] has left #gentoo-council ["Leaving"]
-22:30 <@FlameBook> again, I don't think that the idea of ignoring the issue and just saying "it's legal issue it's legal issue I don't want to hear NANANANANNANA" is a wrong turn.
-22:30 -!- fmccor is now known as fmccor|away
-22:31 <@kingtaco|work> FlameBook, don't take cheap shots at me just because I don't agree with what you want
-22:31 <@FlameBook> I can understand for things that might be controverse, but I don't really find much controversy in this... besides, the point that people use them... as mike said they are also on the forum
-22:31 <@kloeri> reminds me, I have a somewhat tricky trustees issue but I should probably mail trustees about that :)
-22:31 <@kingtaco|work> that's incredably poor taste
-22:31 <@FlameBook> kingtaco|work, not taking a cheap shot, that's just how I seen your behaviour in this matter
-22:32 <@FlameBook> didn't you want to redirect it to trustees without even considering the issue at all?
-22:32 <@kingtaco|work> I AGREED WITH YOU!
-22:32 <@kingtaco|work> I disagreed that it was something we should do
-22:32 <@kingtaco|work> considering that the trustees didn't look at it
-22:32 <@kingtaco|work> fuck the old trustees
-22:32 <@kingtaco|work> they don't matter
-22:33 <@kingtaco|work> moreover, as soon as you brought it up, they started looking at it
-22:36 <@kingtaco|work> anyone have anything else to add to this meeting?
-22:37 <@kloeri> nope
-22:38 <@kingtaco|laptop> who ran the meeting today?
-22:40 <@kloeri> didn't decide that, just jumped to flameeyes issues
-22:41 <@kingtaco|laptop> oh
-22:41 <@kingtaco|laptop> someone want to close the meeting?
-22:41 <@kloeri> I can mail log + summary fwiw
-22:41 <@kloeri> meeting closed :)
-22:44 <@kingtaco|laptop> ok
-22:45 <+g2boojum> FlameBook: If you're still around, I've just sent an e-mail to neysx requesting that the icons page be pulled.
-22:45 <@FlameBook> g2boojum, was going to ask you about that
-22:46 <+g2boojum> FlameBook: It took a bit of discussion before I knew who could do it.  I'm not sure how the dyn pages work.
-22:46 <@FlameBook> g2boojum, the same applies to me, I asked that beforehand just to be sure, /dyn/ should be under infra's look, and robbat2 confirmed before it was doc guys to handle (thus, neysx)
-22:55 -!- robbat2 [n=robbat2@gentoo/developer/robbat2] has quit [Remote closed the connection]
-22:57 -!- fmccor|home [n=fmccor@gentoo/developer/fmccor] has joined #gentoo-council
-23:10 -!- spb [i=spb@gentoo/developer/spb] has quit ["hooray for new machines"]
-23:15 -!- FlameBook [n=intrepid@gentoo/developer/Flameeyes] has quit ["Leaving"]
-23:16 -!- spb- is now known as spb
-23:26 -!- Flameeyes is now known as FlAFKeyes
-23:35 -!- robbat2 [n=robbat2@gentoo/developer/robbat2] has joined #gentoo-council
-23:35 -!- mode/#gentoo-council [+o robbat2] by ChanServ
-23:49 -!- g2boojum [n=grant@gentoo/developer/g2boojum] has left #gentoo-council []
---- Log closed Fri Dec 15 00:00:38 2006
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070111-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070111-summary.txt
deleted file mode 100644
index a161907e92..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070111-summary.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Summary of the Gentoo Council meeting held 11 January 2007
-----------------------------------------------------------
-(Summary prepared by robbat2).
-
-Roll-call:
-Present: flameeyes (proxied by UberLord), kingtaco, kloeri, kugelfang, robbat2, wolf31o2
-Absent: vapier
-
-No agenda items were raised ahead of time, so we just went in alphabetical
-order.
-- Kugelfang reported that the EAPI0 draft document is not quite complete. spb had
-  hoped to have it ready before the meeting, but didn't manage. It has been
-  restricted thus far to avoid 'large discussions about minor details' while
-  the bigger picture is assembled. It will be open for all input and
-  refinements later.
-- Kugelfang visited the issue of the contents of /usr/libexec. Diego and
-  Vapier had raised it previously, and Kugelfang is working on the document,
-  in a style similar to FHS.
-- Kugelfang wanted to know about the process for council members stepping
-  down. This was prompted by solely by Flameeye's message to the council
-  channel earlier in the day, which implied he was retiring. The point was
-  made moot by Flameeye's later blog post that he was going to take a two week
-  break instead.
-- On the procedural side, both Kugelfang and KingTaco wanted to know what the
-  what the process for a retiring council member was. Should it be the next
-  person on the original ballot results, or should a further election be held?
-  The spirit of the council GLEP was a further election, but some questions
-  were had in this. The issue needs to be raised on the -dev mailing list, and
-  revisited during the next council meeting.
-- Robbat2 reported on the successful bugzilla migration, and the work for the
-  new CVS server. The Bugzilla news was well recieved.
-- Robbat2 brought up the status of the SPF documentation. Kloeri said that he
-  has them in a nearly finished state, but hasn't had a chance lately to
-  complete them. Kloeri will other complete them shortly, or upload the drafts
-  to the bug in the meantime.
-- Robbat2 requested that for helping to get an agenda together in future, all
-  council members should just braindump their potential minor items to the
-  council mailing list a few days ahead of each meeting. Large issues should
-  still be raised on -dev/-core as needed, but the smaller stuff like
-  followups can just be braindumped. Robbat2 promised to rig an automated
-  reminder to the council members.
-- A last call for vapier was made, and since he didn't show, he got his
-  slacker mark for this meeting.
-- Wolf31o2 inquired as to the status of the Reply-To documentation (bug
-  154595). As there was absolutely no progress, Wolf31o2 was going to just
-  write it up and convert it to GuideXML.
-- Wolf31o2 proposed the concept of council-managed projects. These are to be
-  Gentoo-specific projects where the council takes the initiative of defining
-  creating software specifications and requirements, recruits people to
-  work on them (not nessicarily developers), and helps manage the project
-  (leaving people to actually work on it). Some past almost precedents were
-  noted and the council was in favour of the general concept. Wolf31o2 was
-  going to seek out some initial proposals for small projects to test the
-  concept on.
-
-The floor was opened at this point.
-
-- KingTaco jokingly asked if the Gentoo Foundation could afford to buy
-  Sealand, which lead into real queries about the current financial reports.
-  Wolf31o2 located a November 2006 posting in the NFP archives and provided a
-  link to it.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070111.txt b/xml/htdocs/proj/en/council/meeting-logs/20070111.txt
deleted file mode 100644
index 62f26485af..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070111.txt
+++ /dev/null
@@ -1,401 +0,0 @@
-Jan 11 12:00:09 wolf31o2|mobile	heh
-Jan 11 12:00:17 *	robbat2 sets mode +m #gentoo-council
-Jan 11 12:00:56 robbat2	ok, it's time folks
-Jan 11 12:00:57 kingtaco|work	roll-call
-Jan 11 12:01:01 *	kingtaco|work is here
-Jan 11 12:01:11 kloeri	hi all
-Jan 11 12:01:29 *	wolf31o2|mobile is here
-Jan 11 12:01:32 robbat2	Kugelfang, SpanKY, vapier: pingy
-Jan 11 12:01:42 kingtaco|work	no uberlord?
-Jan 11 12:01:45 kingtaco|work	for flameeyes?
-Jan 11 12:01:49 *	You've invited UberLord to #gentoo-council (zelazny.freenode.net)
-Jan 11 12:02:10 *	iluxa (n=anonymou@gentoo/developer/iluxa) has joined #gentoo-council
-Jan 11 12:02:13 *	You've invited Uber to #gentoo-council (zelazny.freenode.net)
-Jan 11 12:02:20 *	antarus (n=antarus@gentoo/developer/antarus) has joined #gentoo-council
-Jan 11 12:02:32 *	kingtaco|work has changed the topic to: Next meeting: NOW
-Jan 11 12:02:40 Kugelfang	orly?
-Jan 11 12:03:16 kingtaco|work	5 of 7
-Jan 11 12:03:31 kingtaco|work	lets get the shindig started
-Jan 11 12:03:33 *	DrEeevil (i=dreeevil@gentoo/user/bonsaikitten) has joined #gentoo-council
-Jan 11 12:03:42 robbat2	anybody got an Agenda? I didn't see one posted
-Jan 11 12:03:50 kingtaco|work	I don't
-Jan 11 12:03:59 Kugelfang	robbat2: i have two thingsw
-Jan 11 12:04:04 Kugelfang	actually, three
-Jan 11 12:04:06 kloeri	there haven't been any agenda posted afaik
-Jan 11 12:04:09 Kugelfang	one minute
-Jan 11 12:04:12 *	Uber (n=uberlord@rsm.demon.co.uk) has joined #gentoo-council
-Jan 11 12:04:20 *	kloeri gives channel operator status to Uber
-Jan 11 12:04:20 wolf31o2|mobile	I have something I would like to propose, too...
-Jan 11 12:04:23 *	Uber waves
-Jan 11 12:04:28 kloeri	welcome Uber
-Jan 11 12:04:29 Kugelfang	hey Roy :-)
-Jan 11 12:04:43 Uber	everyone knows I'm proxy for diego?
-Jan 11 12:04:45 kingtaco|work	da
-Jan 11 12:04:49 kloeri	yup
-Jan 11 12:05:03 robbat2	i don't see g2boojum here today, so I'll do the conducting if nobody else wants to
-Jan 11 12:05:19 kingtaco|work	goforit
-Jan 11 12:05:22 Kugelfang	yes
-Jan 11 12:05:51 robbat2	ok, since there was no agenda, lets just go alpha order down the list, and let each person list their things for the agenda quicly
-Jan 11 12:05:55 robbat2	KingTaco, anything?
-Jan 11 12:06:09 kingtaco|work	not at the moment
-Jan 11 12:06:12 robbat2	kloeri, 
-Jan 11 12:06:23 kloeri	nothing
-Jan 11 12:06:28 robbat2	Kugelfang, your items you mentioned?
-Jan 11 12:06:32 Kugelfang	ok
-Jan 11 12:06:40 Kugelfang	first: EAPI0 document
-Jan 11 12:06:48 kingtaco|work	QA stuff?
-Jan 11 12:06:49 Kugelfang	spb had been asked to do it.
-Jan 11 12:06:52 Kugelfang	kingtaco|work: yes
-Jan 11 12:07:00 kingtaco|work	ok
-Jan 11 12:07:08 Kugelfang	he's done quite some work, it's not yet completely ready
-Jan 11 12:07:21 kingtaco|work	is it posted somewhere?
-Jan 11 12:07:27 Kugelfang	i have access to it, but i may no publish it yet
-Jan 11 12:07:40 Kugelfang	kingtaco|work: nope, there needs to be some work done, it's very promising already though
-Jan 11 12:07:44 kloeri	I have access as well but same conditions
-Jan 11 12:07:46 kingtaco|work	it'd be nice if people could view and comment
-Jan 11 12:07:48 Kugelfang	it's an 30page pdf document right now :-)
-Jan 11 12:07:54 Kugelfang	s/an/a/
-Jan 11 12:08:31 robbat2	does he have a rough timeline for having it more done?
-Jan 11 12:08:33 Kugelfang	i just wanted to mention it, to contradict Diego's statement from planet.gentoo.org
-Jan 11 12:08:36 kingtaco|work	I'm not a fan of the secrecy
-Jan 11 12:08:44 kloeri	I think the idea of keeping it restricted right now is to get the bigger picture finished before getting into large discussions about minor details
-Jan 11 12:08:45 *	ferringb (n=bharring@c-71-236-224-243.hsd1.or.comcast.net) has joined #gentoo-council
-Jan 11 12:08:54 Kugelfang	kingtaco|work: he wants to have it done _completely_ before discussions starts on parts
-Jan 11 12:09:12 kingtaco|work	ok
-Jan 11 12:09:17 robbat2	ok, so long as that doesn't limit input being taken into account later
-Jan 11 12:09:17 Kugelfang	kingtaco|work: once it's done, it'll be as open as anything else.. he just doesn't consider it done yet
-Jan 11 12:09:20 wolf31o2|mobile	as much as I'm all for openness... I can understadn that one
-Jan 11 12:09:21 wolf31o2|mobile	heh
-Jan 11 12:09:33 kingtaco|work	I wont vote on it until it has suitable time in public review
-Jan 11 12:09:41 kloeri	I actually agree with keeping it restricted for now personally
-Jan 11 12:09:49 Kugelfang	he wanted to have a draft ready for tonight, but didn't quite make it as far as i understood
-Jan 11 12:10:01 kloeri	and there'll be plenty of opportunity to comment on it and refine parts later
-Jan 11 12:10:06 Kugelfang	exactly
-Jan 11 12:10:08 kingtaco|work	...ok
-Jan 11 12:10:09 robbat2	ok, thats fine for the moment
-Jan 11 12:10:16 Kugelfang	that was my first point
-Jan 11 12:10:28 Kugelfang	second point: /usr/libexec
-Jan 11 12:10:34 wolf31o2|mobile	heh
-Jan 11 12:10:44 Kugelfang	Diego and vapier had a discussion about that, and i promised to bring up a document for it
-Jan 11 12:10:58 Kugelfang	something that's a standard for where to put things in a gentoo installation
-Jan 11 12:11:11 Kugelfang	i initally wanted to just make a little patch for the devmanual
-Jan 11 12:11:40 Kugelfang	however, i've changed my mind and think that we should have a proper document similar to the FHS document
-Jan 11 12:11:47 *	Calchan (n=Calchan@84.7.124.48) has joined #gentoo-council
-Jan 11 12:12:07 Kugelfang	not as long as that, but one document that says: these files belong here and not there
-Jan 11 12:12:24 Kugelfang	however, i think also that i'm not up to the job, at least not alone
-Jan 11 12:12:38 Kugelfang	this is where Uber comes into the equations, as i was going to ask him
-Jan 11 12:12:56 Kugelfang	Uber: are you interested in helping out on that, as one of the primary baselayout maintainers?
-Jan 11 12:13:02 *	marienz (n=marienz@gentoo/developer/marienz) has joined #gentoo-council
-Jan 11 12:13:47 Kugelfang	(I also take anybody else's help/input on writing such a document :D)
-Jan 11 12:13:49 Uber	Kugelfang: i'm only really interested in keeping / as small as we can - dont't really care where packages put things outside of that
-Jan 11 12:13:57 Kugelfang	nod
-Jan 11 12:14:20 kloeri	I like the idea of a proper document explaining all of that as devs are quite often confused about some details
-Jan 11 12:14:29 Uber	but if you ask where I think something ought to go I'm happy to give an opinion
-Jan 11 12:14:41 Kugelfang	Uber: nod, thank you
-Jan 11 12:15:36 Kugelfang	anybody who wants to help can just contact me after this meeting so we can think on how to set it up
-Jan 11 12:15:51 kingtaco|work	robbat2, at the next break I do have one short thing to bring up
-Jan 11 12:16:07 robbat2	kingtaco|work, ok, after kugelfang's 3rd item
-Jan 11 12:16:10 Kugelfang	i have done some work on /usr/{local,libexec} already, but there is a lot of stuff in the filesystem hierarchy :-(
-Jan 11 12:16:11 kingtaco|work	kk
-Jan 11 12:16:28 Kugelfang	that was point 2, i fnobody has anything to add to it
-Jan 11 12:16:36 robbat2	nope, sounds like a solid plan to me
-Jan 11 12:16:57 Kugelfang	point 3 would be: Diego stepping down as developer and along that: stepping down as council member
-Jan 11 12:17:08 kingtaco|work	Kugelfang, that's my "-point"
-Jan 11 12:17:12 kloeri	Diego isn't retiring yet
-Jan 11 12:17:13 Kugelfang	kingtaco|work: pff
-Jan 11 12:17:35 Kugelfang	kloeri: well, i want to quote him from today earlier in this channel
-Jan 11 12:17:41 kloeri	he's taking a two week vacation from Gentoo right now to sort out his thoughts on all this
-Jan 11 12:17:43 Kugelfang	kloeri: (this might have changed in the meantime though)
-Jan 11 12:17:49 kloeri	it has changed
-Jan 11 12:17:59 Kugelfang	kloeri: 12:17 <@FlAFKeyes> tonight I'll leave uberlord to be my "proxy", as I hope not to be a dev anymore by that time anyway
-Jan 11 12:18:01 kingtaco|work	my only question there is according to the metastructure glep, do we have to hold an election, can we bring someone in, or do we take the #8 spot(uber)
-Jan 11 12:18:03 Kugelfang	kloeri: oh, ok
-Jan 11 12:18:09 Kugelfang	kloeri: that's cool :-)
-Jan 11 12:18:10 robbat2	his blog post earlier clarified it a lot
-Jan 11 12:18:18 kloeri	seemant talked to him and they decided that a vacation + removing commit access meanwhile was the way to go for now
-Jan 11 12:18:31 wolf31o2|mobile	If/when he does... I think we just follow the same guidelines the trustees initiated... go with the next guy in the vote...
-Jan 11 12:18:35 Kugelfang	as i said, i had been taking a nap before this very meeting started, so i'm probably 1.5 hours back :-)
-Jan 11 12:18:39 kloeri	so I've removed his commit access and Diego seems very happy about that decision
-Jan 11 12:18:43 Kugelfang	wolf31o2|mobile: excellent, that was my very point
-Jan 11 12:18:53 Kugelfang	wolf31o2|mobile: incidently, this would be Uber i think
-Jan 11 12:19:00 wolf31o2|mobile	it would be
-Jan 11 12:19:03 kingtaco|work	wolf31o2|mobile, someone should check that that's what the glep proscribes
-Jan 11 12:19:12 kloeri	just don't elect a new council member before he's actually retired :)
-Jan 11 12:19:19 wolf31o2|mobile	kingtaco|laptop: I think you just volunteered.... ;]
-Jan 11 12:19:24 wolf31o2|mobile	kloeri: we aren't
-Jan 11 12:19:31 Kugelfang	kloeri: didn't want that, i just wanted to have everything settled :-)
-Jan 11 12:19:38 kloeri	nod
-Jan 11 12:19:51 Kugelfang	kloeri: i'm not too fond of losing him in the first place :-(
-Jan 11 12:19:57 wolf31o2|mobile	me, either
-Jan 11 12:19:57 kloeri	indeed
-Jan 11 12:20:20 Kugelfang	he's contributions are in the region of vapier's from a monthly base, maybe a bit higher even
-Jan 11 12:20:27 Kugelfang	his
-Jan 11 12:20:29 Kugelfang	not he's
-Jan 11 12:20:33 kloeri	I hope a vacation will relieve some of the stress he's been feeling the past few months and that he'll come back with a fresh view of things
-Jan 11 12:20:45 Kugelfang	ok, there were my things for the table tonight
-Jan 11 12:20:48 Kugelfang	thank you very much
-Jan 11 12:20:59 kloeri	he's the top committer for 2006
-Jan 11 12:21:12 wolf31o2|mobile	Kugelfang: his are higher than vapier, actually... he's over vapier for 2006 by like 4000... heh
-Jan 11 12:21:16 wolf31o2|mobile	kloeri has the stats
-Jan 11 12:21:21 Kugelfang	wolf31o2|mobile: aye
-Jan 11 12:21:35 kloeri	yeah, he's beating vapier by quite a few commits
-Jan 11 12:21:36 kingtaco|work	"If a council member who has been marked a slacker misses any further meeting (or their appointed proxy doesn't show up), they lose their position and a new election is held to replace that person. The newly elected council member gets a 'reduced' term so that the yearly elections still elect a full group."
-Jan 11 12:21:38 Kugelfang	wolf31o2|mobile: you know, this is the kind of thing you deem impossible until you see it
-Jan 11 12:21:56 Kugelfang	kingtaco|work: yes, but this would be a voluntary step down
-Jan 11 12:22:00 Kugelfang	kingtaco|work: if he does it
-Jan 11 12:22:06 kingtaco|work	Kugelfang, the glep doesn't address it
-Jan 11 12:22:20 wolf31o2|mobile	kingtaco|laptop: that covers slackers... not someone leaving, though... we should clarify this and add it explicitly to the document... even if we decide to use the same as the slacker boot
-Jan 11 12:22:22 Kugelfang	anyway, as he's not doing it, i'm all for postponing that discussion, though i started it
-Jan 11 12:22:23 kingtaco|work	that's the closest thing in the glep
-Jan 11 12:22:38 kingtaco|work	Kugelfang, naw, we need to discuss it
-Jan 11 12:22:53 robbat2	it will probably come up in future
-Jan 11 12:22:59 Kugelfang	nod
-Jan 11 12:22:59 wolf31o2|mobile	right
-Jan 11 12:23:03 kingtaco|work	anyway, we need to modify that glep for someone who resigns
-Jan 11 12:23:11 wolf31o2|mobile	definitely
-Jan 11 12:23:14 Kugelfang	kingtaco|work: want to bring up a patch?
-Jan 11 12:23:25 Kugelfang	kingtaco|work: for discussion at next meeting?
-Jan 11 12:23:32 kingtaco|work	I don't have a preference personally, but the glep seems to indicate that a new vote be done for anyone leaving
-Jan 11 12:23:49 robbat2	i think email the question to -dev, and let's put it on the agenda for next month
-Jan 11 12:23:55 kingtaco|work	ok
-Jan 11 12:23:57 wolf31o2|mobile	robbat2: good plan
-Jan 11 12:23:58 kingtaco|work	or -core
-Jan 11 12:24:02 Kugelfang	i would not like to do that, but rather use the people next on the ballot
-Jan 11 12:24:06 kingtaco|work	it doesn't apply to non-gentoo dev
-Jan 11 12:24:06 Kugelfang	the original ballot
-Jan 11 12:24:21 robbat2	i see pros and cons on both ideas
-Jan 11 12:24:36 Uber	we already discussed this before and I think we said we could use the first ballot results
-Jan 11 12:24:40 wolf31o2|mobile	Kugelfang: that's my thought on it, too... because we'd be down a man until the vote is done... which isn't the best solution... but I also think it's a good idea for us to get some discussion on it... likely, people will agree with us
-Jan 11 12:24:49 kingtaco|work	the "spirit" of the glep would be to hold another election
-Jan 11 12:24:50 Kugelfang	wolf31o2|mobile: nod
-Jan 11 12:25:06 Kugelfang	kingtaco|work: that doesn't me we can't change it
-Jan 11 12:25:09 Kugelfang	mean
-Jan 11 12:25:18 kingtaco|work	Kugelfang, no doubt
-Jan 11 12:25:24 kloeri	discussing on -dev or -core is a good idea imo
-Jan 11 12:25:29 kingtaco|work	I think another election is silly
-Jan 11 12:25:29 wolf31o2|mobile	kingtaco|work: yeah... but it might be a good idea to get a finger on the current pulse of Gentoo and decide...
-Jan 11 12:25:29 kingtaco|work	ok
-Jan 11 12:25:31 robbat2	recalling the original ballot, taking the next person down has issues when there are ties
-Jan 11 12:25:32 Kugelfang	robbat2: i return the mic to you
-Jan 11 12:25:35 kingtaco|work	I'll spearhead that
-Jan 11 12:25:41 robbat2	ok, my turn for items now
-Jan 11 12:25:42 kingtaco|work	delayed until next month
-Jan 11 12:26:08 robbat2	1. the bugzilla migration went very well as everybody can see, there's a few minor bits to pick up, but they will be done over the next week or so
-Jan 11 12:26:18 Kugelfang	yeah, very nice work!
-Jan 11 12:26:29 Kugelfang	thanks to all people involved :-)
-Jan 11 12:26:33 wolf31o2|mobile	yeah... can we give kingtaco|laptop/robbat2/everyone else a big woop! woop!
-Jan 11 12:26:35 kloeri	new bugzilla++
-Jan 11 12:26:43 robbat2	2. there's work on a new CVS server after the storm problems at OSU previously, no actual timeline yet
-Jan 11 12:26:45 wolf31o2|mobile	excellent job, guys
-Jan 11 12:26:48 Uber	yeah, maybe jakub will be happy for once - I know I am happy with bugs now :)
-Jan 11 12:26:53 Kugelfang	Big Whoop?
-Jan 11 12:27:02 robbat2	thanks all :-)
-Jan 11 12:27:02 wolf31o2|mobile	Kugelfang: praise
-Jan 11 12:27:15 robbat2	3. the SPF bug....
-Jan 11 12:27:17 Kugelfang	wolf31o2|mobile: pun in regard to monkey island!
-Jan 11 12:27:28 Kugelfang	robbat2: right
-Jan 11 12:27:32 *	Kugelfang looks at kloeri :-P
-Jan 11 12:27:48 wolf31o2|mobile	heh... that was one I was going to bring up... status on SPF/Reply-to docs...
-Jan 11 12:28:23 robbat2	SPF and reply-to are seperate items
-Jan 11 12:28:34 wolf31o2|mobile	yes
-Jan 11 12:28:39 wolf31o2|mobile	I meant there's two items
-Jan 11 12:28:42 wolf31o2|mobile	the status on each
-Jan 11 12:28:47 kloeri	I still have some nearly finished docs sitting on my laptop but have been more busy looking for a new job and taking care flameeyes and the sudden loss of our only apache maintainer
-Jan 11 12:29:03 kloeri	I'll finish my doc after the meeting
-Jan 11 12:29:09 Kugelfang	kloeri: cool
-Jan 11 12:29:14 robbat2	kloeri, could you attach the drafts even to that bug?
-Jan 11 12:29:24 wolf31o2|mobile	kloeri: you've got one week or we take away your swipe card for the soft-serve ice cream machine
-Jan 11 12:29:28 robbat2	if you don't get a chance to finish them that is
-Jan 11 12:29:31 kingtaco|pda	apache?
-Jan 11 12:29:32 kloeri	sure
-Jan 11 12:29:43 Kugelfang	kloeri: i promise to look over it from viewpoint of the user I am :-D
-Jan 11 12:29:46 kloeri	yes, vericgar retired about a week ago
-Jan 11 12:29:53 kingtaco|pda	ah
-Jan 11 12:30:00 kloeri	leaving me (at that point) as the only remaining apache team member
-Jan 11 12:30:29 robbat2	i didn't see any retire notice in the GWN or on the lists?
-Jan 11 12:30:34 kloeri	fortunately chtekk and phreak both stepped up quickly to help me and we're squashing bugs at a very nice rate
-Jan 11 12:30:39 kingtaco|pda	why cant gdp do it
-Jan 11 12:30:56 kloeri	no, he just announced it in #-apache and I haven't sent it to GWN yet
-Jan 11 12:31:41 kloeri	people announce retirement in all kinds of crazy ways - random irc channels, /msg'ing me etc.
-Jan 11 12:31:42 robbat2	ok, just attach them to the bug when you're ready with them
-Jan 11 12:31:52 kloeri	will do
-Jan 11 12:31:54 robbat2	i have one more item on my list
-Jan 11 12:32:02 robbat2	4. Agenda management
-Jan 11 12:32:25 robbat2	could everybody just try and do a braindump on the council ML a day or two ahead of the meeting?
-Jan 11 12:32:41 kingtaco|work	it'd be nice
-Jan 11 12:32:47 Kugelfang	yes, sorry
-Jan 11 12:32:47 robbat2	nothing fancy, just for own notes
-Jan 11 12:32:52 Kugelfang	didn't think about it
-Jan 11 12:33:13 kloeri	agreed, we need to do that
-Jan 11 12:33:19 robbat2	if you think it's a bigger issue, bring it up earlier on -core/-dev, but for simple stuff like today, just braindump to -council
-Jan 11 12:33:49 Kugelfang	somebody volunteering to prod me to it the mondays before we have meeting? :-P
-Jan 11 12:34:02 robbat2	ok, i'll try to send out reminders ;-)
-Jan 11 12:34:18 *	Kugelfang has electrocution prdo-sticks to give away
-Jan 11 12:34:23 Kugelfang	prod-sticks
-Jan 11 12:34:25 robbat2	SpanKY, last call before we mark you as a slacker
-Jan 11 12:34:31 robbat2	vapier ping too
-Jan 11 12:34:45 Kugelfang	3
-Jan 11 12:34:46 Kugelfang	2
-Jan 11 12:34:47 Kugelfang	1
-Jan 11 12:34:50 Kugelfang	-out-
-Jan 11 12:35:18 robbat2	Uber: is there anything you wanted to bring up on behalf of Flameeyes?
-Jan 11 12:35:42 Uber	robbat2: nope. I was kinda ropped into this at the last minute
-Jan 11 12:36:10 kloeri	thanks for stepping up at such short notice
-Jan 11 12:36:25 Uber	np
-Jan 11 12:36:25 robbat2	yeah, many thanks for being able to drop in
-Jan 11 12:36:32 Kugelfang	Uber: nah, you got time for Diego, but when you're going to met me you go for honeymoon instead!
-Jan 11 12:36:38 Kugelfang	Uber: you're a friend! *rant*
-Jan 11 12:36:46 Kugelfang	meet
-Jan 11 12:36:46 robbat2	vapier, i'm not giving your alter-ego a second chance
-Jan 11 12:36:51 wolf31o2|mobile	heh
-Jan 11 12:36:52 robbat2	wolf31o2, your turn
-Jan 11 12:36:55 Uber	heh
-Jan 11 12:36:56 robbat2	you mentioned Reply-To earlier?
-Jan 11 12:37:05 wolf31o2|mobile	yeah... what's the status on that doc?
-Jan 11 12:37:15 robbat2	absolutely nothing according to that bug
-Jan 11 12:37:21 wolf31o2|mobile	heh
-Jan 11 12:37:27 robbat2	bug 154595
-Jan 11 12:37:37 robbat2	hmm, no jeeves in here
-Jan 11 12:37:42 wolf31o2|mobile	should I just write one up and guidexml it? there's not much to it
-Jan 11 12:38:02 robbat2	i wanted to raise question with it
-Jan 11 12:38:08 wolf31o2|mobile	ok
-Jan 11 12:38:08 robbat2	why don't we make more use of Mail-Followup-To?
-Jan 11 12:38:18 wolf31o2|mobile	not a clue
-Jan 11 12:38:27 kingtaco|work	I think it was all covered
-Jan 11 12:38:41 kingtaco|work	one can use procmail to munge the headers however one likes
-Jan 11 12:38:42 *	jeeves (n=jeeves@gentoo/developer/jeeves) has joined #gentoo-council
-Jan 11 12:38:46 *	kingtaco|work gives voice to jeeves
-Jan 11 12:38:49 *	wolf31o2|mobile gives voice to jeeves
-Jan 11 12:39:05 Kugelfang	thanks for solar's quick reaction
-Jan 11 12:39:13 robbat2	jeeves, bug 154595
-Jan 11 12:39:15 jeeves	robbat2: https://bugs.gentoo.org/154595 nor, P2, All, kingtaco@gentoo.org->kloeri@gentoo.org, NEW, pending, Document how to change reply-to headers on gentoo lists
-Jan 11 12:39:41 wolf31o2|mobile	yeah... I munge out the reply-to if it matches the "to:"
-Jan 11 12:40:11 wolf31o2|mobile	so I can "reply to sender" and "reply to list" without having to manually type addresses or remove junk
-Jan 11 12:40:51 wolf31o2|mobile	anyway... if nobody has any objections, I'll draft something up and post it to the bug for discussion
-Jan 11 12:40:56 wolf31o2|mobile	sound good?
-Jan 11 12:40:58 robbat2	sure
-Jan 11 12:41:08 kloeri	fine
-Jan 11 12:41:26 wolf31o2|mobile	ok...
-Jan 11 12:41:35 robbat2	wolf31o2, any more items?
-Jan 11 12:41:41 wolf31o2|mobile	so now my other idea/proposal/whatever...
-Jan 11 12:42:03 Kugelfang	wolf31o2|mobile: ice cream machine for the council lounge?
-Jan 11 12:42:11 wolf31o2|mobile	I was thinking of us starting some projects of our own... that are "council run" for specific tasks... I'll give you a (completely fictional) example
-Jan 11 12:42:13 wolf31o2|mobile	heh
-Jan 11 12:43:52 wolf31o2|mobile	let's say we wanted to create a tool, let's, for the sake of argument, say it is a GUI portage front-end... so, the Council would start the project, and we would "recruit" via the GWN, etc... the people whom we recruit could be devs or not... doesn't matter... they get access to some repo specifically for the project... they work for us, which means they aren't necessarily Gentoo developers... (though they could be... that po
-Jan 11 12:43:52 wolf31o2|mobile	int isn't that important)
-Jan 11 12:44:32 kingtaco|work	how does this differ from what we currently do for things like the installer
-Jan 11 12:44:42 kingtaco|work	and why us as opposed to some other group
-Jan 11 12:44:42 wolf31o2|mobile	anyway... we recruit... we get people... they start writing code... basically, we start managing some new code that is for Gentoo, rather than just packaging up other people's stuff... I'd imagine it would all pretty much be Gentoo-specific, for the most part
-Jan 11 12:44:45 robbat2	and anybody else starting a project for that matter
-Jan 11 12:44:55 wolf31o2|mobile	kingtaco|laptop: it really isn't different than the installer...
-Jan 11 12:45:06 wolf31o2|mobile	and why us? because I don't see anyone else doing it... and we're the elected leaders
-Jan 11 12:45:29 wolf31o2|mobile	I mean, we have installer/scire... which are great examples of this
-Jan 11 12:45:31 kingtaco|work	ok, so we take the initiative, not attempting to exclude others from doing the same
-Jan 11 12:45:36 wolf31o2|mobile	correct
-Jan 11 12:45:38 kingtaco|work	ok
-Jan 11 12:45:46 wolf31o2|mobile	if someone wants to create a project, they're more than welcome to
-Jan 11 12:45:51 robbat2	the only problem I see with that, is people wanting more direction from council on where each project should go
-Jan 11 12:46:07 wolf31o2|mobile	the idea here being is we can identify places where we need improvement
-Jan 11 12:46:20 wolf31o2|mobile	well... that's what we would do... steer the project(s) that we create
-Jan 11 12:46:46 wolf31o2|mobile	like, we would come up with the project, and idea of what we want it to do, etc and try to keep the recruits on task
-Jan 11 12:47:20 Uber	so basically the council is an ideas think tank?
-Jan 11 12:47:33 wolf31o2|mobile	yes... and we can always take ideas from other people
-Jan 11 12:47:45 wolf31o2|mobile	like... let's say you had a great idea, but didn't have time to lead the project
-Jan 11 12:47:50 kingtaco|pda	more of formalizing what we already do
-Jan 11 12:48:02 wolf31o2|mobile	we could do it as a team, rather than letting the great idea die on the vine
-Jan 11 12:48:05 wolf31o2|mobile	yeah
-Jan 11 12:49:07 wolf31o2|mobile	now, antarus brings up a point... he says "in my experience you can't direct a project unless you are actively contributing, so the project members are free to ignore your suggestions/direction"
-Jan 11 12:49:09 robbat2	i do certainly find the concept interesting, however I wonder how this would impact our time availability as it stands
-Jan 11 12:49:44 wolf31o2|mobile	well... there's a solution to that... we "fire" them... I know it sounds a bit rash... but that's the reason why we don't require people be devs... they're "contractors" so to speak... there to do a job (at their own pace, of coure)
-Jan 11 12:50:14 wolf31o2|mobile	robbat2: no clue... but I figure we could try it out... get some ideas for a project that might not be too difficult from the community and try it
-Jan 11 12:50:16 kloeri	time availability would be one of my concerns but I like the idea of more actively steering projects (or helping to steer projects where needed)
-Jan 11 12:50:36 robbat2	so the directions are more of requirements in the project planning scope of things, more formal software development process
-Jan 11 12:51:11 wolf31o2|mobile	robbat2: correct
-Jan 11 12:51:13 kloeri	I'm sometimes doing the same thing with bugday where I hire (more or less) random users to help with a specific project
-Jan 11 12:51:38 kloeri	works fairly well for bugday but that's very small projects though
-Jan 11 12:51:55 wolf31o2|mobile	robbat2: we're recruiting for a task... not a general developer "position"
-Jan 11 12:51:56 robbat2	wolf31o2|mobile, I do have one direct question. how do you ensure these projects don't stagnate?
-Jan 11 12:52:10 wolf31o2|mobile	yeah... as I said... we'd want to find something smaller to see if it is even feasible
-Jan 11 12:52:14 wolf31o2|mobile	might be we simply can't manage it
-Jan 11 12:52:16 robbat2	and how to handle long term maintence too
-Jan 11 12:52:48 wolf31o2|mobile	robbat2: well... as the "management" for it, we try to find new blood if things seem to be stagnating... there's *loads* of people who want to help Gentoo, but don't know how
-Jan 11 12:53:04 robbat2	i'd like to point out that there is a limited precedent for such an idea
-Jan 11 12:53:32 robbat2	back in the day of drobbins, he and releng identified some specific objectives that needed completion
-Jan 11 12:53:41 robbat2	and sought people to complete them
-Jan 11 12:53:48 robbat2	i wrote the genflags package for one of those
-Jan 11 12:54:10 robbat2	code mostly useless now, but it had well defined requirements
-Jan 11 12:54:15 wolf31o2|mobile	heh
-Jan 11 12:54:50 robbat2	1. must run from a minimal livecd (bash only). 2. take all input it can find about a system (cpuinfo etc). 3. spit out recommended CFLAGS/CHOST
-Jan 11 12:55:09 wolf31o2|mobile	yeah... that's the exact kind of thing I mean
-Jan 11 12:55:12 robbat2	that's simplifying it a bit, but the important thing is that there was a precedent
-Jan 11 12:55:21 Kugelfang	i'm no opposed to that, so let's try it out once the first need arises
-Jan 11 12:55:34 wolf31o2|mobile	well... I'm going to suggest we call for ideas on -dev
-Jan 11 12:55:43 wolf31o2|mobile	see what comes up... and try to pick one we think we can attain
-Jan 11 12:55:47 robbat2	note that they should be small ideas
-Jan 11 12:55:50 Kugelfang	this fits very well in the category 'Gentoo Hosted Projects' :-)
-Jan 11 12:55:51 robbat2	not grand projects
-Jan 11 12:55:54 wolf31o2|mobile	yes
-Jan 11 12:56:33 robbat2	wolf31o2|mobile, ok, it's your idea, so if you'd like to spearhead asking for ideas and bringing them back for the next meeting, i'm all game
-Jan 11 12:56:39 robbat2	i don't think it needs a vote at all
-Jan 11 12:56:41 wolf31o2|mobile	cool
-Jan 11 12:56:49 wolf31o2|mobile	yeah... I just wanted feedback on it, really
-Jan 11 12:57:09 kloeri	no, just go ahead
-Jan 11 12:57:15 Kugelfang	jupp
-Jan 11 12:57:32 Kugelfang	vapier: kind-of-last-call!
-Jan 11 12:57:32 robbat2	any further issues from anybody, or shall we open the floor?
-Jan 11 12:58:07 kloeri	no further issues from me
-Jan 11 12:58:10 robbat2	going once
-Jan 11 12:58:10 kingtaco|work	can the foundation afford to buy sealand?
-Jan 11 12:58:11 Kugelfang	nope
-Jan 11 12:58:14 kingtaco|work	:p
-Jan 11 12:58:26 kingtaco|work	</joke>
-Jan 11 12:58:27 wolf31o2|mobile	kingtaco|work: not yet...
-Jan 11 12:58:31 Kugelfang	kingtaco|work: to set up the council's lounge and ice-cream machine?
-Jan 11 12:58:38 robbat2	bug the foundation for financials reports, there haven't been any in a long time
-Jan 11 12:58:38 kingtaco|work	hehe
-Jan 11 12:59:00 kingtaco|work	wolf31o2|mobile, can you have someone over there work on the financial reports?
-Jan 11 12:59:00 robbat2	we should have made a fair mint from our SoC payouts
-Jan 11 12:59:03 Kugelfang	who's going to mark vapier as a slacker?
-Jan 11 12:59:08 wolf31o2|mobile	robbat2: check -nfp archives... we need to clean it up... but there's a fairly recent one there
-Jan 11 12:59:12 kingtaco|work	I'd like to see them too
-Jan 11 12:59:15 kingtaco|work	cool
-Jan 11 12:59:25 wolf31o2|mobile	kingtaco|work: I think there is someone working on it... I can check
-Jan 11 12:59:31 kingtaco|work	kk
-Jan 11 12:59:49 kingtaco|work	nothing from me
-Jan 11 12:59:51 kingtaco|work	open it up
-Jan 11 12:59:59 *	Kugelfang sets mode -m #gentoo-council
-Jan 11 13:00:15 robbat2	wolf31o2|mobile, got a link for that email?
-Jan 11 13:00:18 antarus	wolf31o2|mobile: I'm working on einspect, but I'd probably have to gather more reqs
-Jan 11 13:00:23 robbat2	i don't see it in the public archives at a glance
-Jan 11 13:00:24 *	Kugelfang goes to mark vapier :-/
-Jan 11 13:00:35 wolf31o2|mobile	robbat2: not off the top of my head... let me check
-Jan 11 13:00:38 wolf31o2|mobile	antarus: einspect?
-Jan 11 13:00:40 robbat2	anybody want to volunteer for the summary?
-Jan 11 13:00:40 Kugelfang	i hope it's all good with him
-Jan 11 13:00:57 antarus	wolf31o2|mobile: basically einspect [--local,--profile,--repository] -p sys-apps/portage
-Jan 11 13:01:11 antarus	gives you informatoin like "what about your local configuration affects sys-apps/portage
-Jan 11 13:01:25 antarus	what about your profile affects sys-apps/portage...what about the repo affects sys-apps/portage..
-Jan 11 13:01:36 antarus	Users often get confused because fex, something is in .mask and unmask
-Jan 11 13:01:40 antarus	and this would list that
-Jan 11 13:01:44 antarus	among other things ;P
-Jan 11 13:02:24 kingtaco|work	robbat2, side note, what's the deal with the nagios warnings about mysql on bugs
-Jan 11 13:02:57 wolf31o2|mobile	antarus: ahh... nice
-Jan 11 13:02:57 robbat2	kingtaco|laptop, me working on dunlin after it lost sync, just need to do it properly (read get mylvmbackup into the tree) rather than a hack fix
-Jan 11 13:03:10 kingtaco|work	ok
-Jan 11 13:03:19 kingtaco|work	can we turn off notifications for it in the meantime?
-Jan 11 13:03:49 robbat2	kingtaco|work, if you have access to nagios, please ACK both mysql notifications for dunlin yes
-Jan 11 13:03:54 robbat2	leave the one for peafowl
-Jan 11 13:04:09 wolf31o2|mobile	robbat2: financials start here: http://archives.gentoo.org/gentoo-nfp/msg_01207.xml
-Jan 11 13:04:34 *	Kugelfang gone, have a new recuirt
-Jan 11 13:04:46 kingtaco|work	robbat2, I have access to the host I'm sure(not that I know which one) but I don't know how to ack it
-Jan 11 13:05:01 kingtaco|work	I'll poke lance to train me
-Jan 11 13:05:53 wolf31o2|mobile	kingtaco|laptop: hit it w/ a browser... find the offending host/service by selecting "Service Problems"... then select "Acknowledge this service problem"
-Jan 11 13:10:59 kloeri	no further questions? guess the meeting is finished then
-Jan 11 13:11:05 wolf31o2|mobile	yup
-Jan 11 13:11:09 wolf31o2|mobile	adjourned
-Jan 11 13:11:31 kingtaco|work	done
-Jan 11 13:12:18 Uber	*gone
-Jan 11 13:12:23 *	Uber (n=uberlord@rsm.demon.co.uk) has left #gentoo-council
-Jan 11 13:12:26 robbat2	i'll post the log and summary shortly
-Jan 11 13:12:37 wolf31o2|mobile	=]
-Jan 11 13:12:48 robbat2	but somebody else gets to do it next time
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070208-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070208-summary.txt
deleted file mode 100644
index 813725bfa9..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070208-summary.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-- change to council GLEP 39 to cover when a Council member is no longer part
-  of the Gentoo project (the reason/rhyme is irrelevant).  Idea is to
-  streamline slightly the bureaucracy (even if new wording is more verbose).
-Old wording:
- * If a council member who has been marked a slacker misses any further meeting
-   (or their appointed proxy doesn't show up), they lose their position and a
-   new election is held to replace that person. The newly elected council member
-   gets a 'reduced' term so that the yearly elections still elect a full group.
-New wording:
- * If a council member who has been marked a slacker misses any further meeting
-   (or their appointed proxy doesn't show up), they lose their position.
- * Whenever a member of the Council loses their position (the reason is
-   irrelevant; they could be booted for slacking or they resign or ...), then
-   the next person in line from the previous Council election is offered the
-   position.  If they decline, it is offered to the next person in line, and so
-   forth.  If they accept and the current Council unanimously accepts the new
-   person, they get the position with a 'reduced' term such that the yearly
-   elections still elect a full group.  If the Council does not accept that
-   person, then a new election is held to choose a new member.
-
-- GLEP 23 (ACCEPT_LICENSE) is still valid.  Should have asked genone to show up
-  ahead of time to clarify what was asked.
-
-- GLEP 44 (Manifest2) is looking good and we'll work on getting the remainder
-  packages fixed.  Idea is to have it in place in the 2007.0 timeframe.
-
-- the tr1 issue (how do we support it properly in dependencies) would be
-  researched to see what packages actually need it and a decision would be
-  made at the next meeting.  options include eclass, virtuals, ||(atoms).
-
-- mailing list docs (reply-to and spf) look pretty much done.  need to be
-  converted to guidexml and posted.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070208.txt b/xml/htdocs/proj/en/council/meeting-logs/20070208.txt
deleted file mode 100644
index 0b4f0e0303..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070208.txt
+++ /dev/null
@@ -1,769 +0,0 @@
-Feb 08 12:00:36 kingtaco|work	>>>>> BEGIN LOGGING
-Feb 08 12:00:41 kingtaco|work	ok, rollcall
-Feb 08 12:00:48 *	kingtaco|work here
-Feb 08 12:01:27 *	Flameeyes here (dining)
-Feb 08 12:01:36 kloeri	hi all
-Feb 08 12:01:39 vapier	poop
-Feb 08 12:01:46 kingtaco|work	robbat2|na, ?
-Feb 08 12:01:55 kingtaco|work	spb
-Feb 08 12:02:04 wolf31o2|mobile	present
-Feb 08 12:02:24 kingtaco|work	spb is making food, I guess he'll be here in a minute
-Feb 08 12:02:46 kingtaco|work	anyone have items that I didn't just list?
-Feb 08 12:02:57 Flameeyes	glep44 status
-Feb 08 12:03:02 kingtaco|work	ok
-Feb 08 12:03:10 kloeri	genone wanted us to reconfirm glep 23
-Feb 08 12:03:16 kingtaco|work	got that on the list
-Feb 08 12:03:21 *	amne (n=amne@gentoo/developer/amne) has joined #gentoo-council
-Feb 08 12:03:36 kingtaco|work	Flameeyes, you want to start with 44?
-Feb 08 12:04:18 spb	back
-Feb 08 12:04:47 Flameeyes	kingtaco|work, I'd rather be silent while dining, but if you want to start with 44, fine
-Feb 08 12:05:01 kingtaco|work	ok
-Feb 08 12:05:11 kingtaco|work	lets start with the council member thing then
-Feb 08 12:05:40 kingtaco|work	so, the council glep doesn't say anything about what happens when a dev leaves of his own will
-Feb 08 12:06:06 kingtaco|work	I think we should take the next place in the orig election and then have the council confirm it.
-Feb 08 12:06:07 Flameeyes	nor if it gets removed by devrel
-Feb 08 12:06:17 vapier	s/of his own will/
-Feb 08 12:06:20 kingtaco|work	what I'm not sure of is if majority vote or unanmous vote
-Feb 08 12:06:38 Flameeyes	I would be for unanymous
-Feb 08 12:07:22 kingtaco|work	regardless of how we decide to vote, if the vote fails, it'd be a new election for that one member for a reduced term
-Feb 08 12:07:26 spb	on the other hand, for consistency it makes sense to do the same thing if a dev leaves that is done when the slacker boot is applied
-Feb 08 12:07:58 vapier	http://thread.gmane.org/gmane.linux.gentoo.devel/45517
-Feb 08 12:08:23 kloeri	devrel won't retire council members btw unless they're completely inactive (just like other devs) in which case they'd be marked slackers before that happened
-Feb 08 12:09:02 kingtaco|work	yeah
-Feb 08 12:09:14 Flameeyes	kloeri, what happens in case of complaints?
-Feb 08 12:09:18 spb	kloeri: technically it takes three months for a council member to be booted for slacking, where the activity timeout is two months
-Feb 08 12:09:29 vapier	from the few responses on -dev (mine included), simply taking the next person "in line" until exhausted seems easiest route to get things up and going again
-Feb 08 12:09:29 *	welp (n=welp@gentoo/developer/welp) has joined #gentoo-council
-Feb 08 12:09:46 spb	though i suppose it'll take a bit longer to actually retire inactive people
-Feb 08 12:09:50 kingtaco|work	as long as it's approved by the remaining members
-Feb 08 12:09:53 kingtaco|work	I concur
-Feb 08 12:09:54 vapier	how the council member comes to be no longer a gentoo developer is irrelevant to the topic i think
-Feb 08 12:10:09 kloeri	spb: well, technically I'll probably never get close to two months and there's at least two weeks to file notice against retirement so it should work out I think
-Feb 08 12:10:16 Flameeyes	vapier, agreed
-Feb 08 12:10:24 *	avenj (n=avenj@gentoo/developer/avenj) has joined #gentoo-council
-Feb 08 12:10:49 kloeri	next person in line is fine imo
-Feb 08 12:10:54 spb	i have a slight preference for option 2 in that mail, but taking the next in line works too
-Feb 08 12:11:26 spb	i just don't see why a dev leaving the council and getting booted from the council should have different methods to replace them
-Feb 08 12:11:29 Flameeyes	kloeri, by the way, if the activty is counted on cvs, it's possible that someone is presenting to the council meeting just fine but resulting inactive
-Feb 08 12:11:58 kingtaco|work	ok, lets vote: when a council member leaves his position will be filled by the next candidate in the origional election, subject to unanmious approval of the existing council members
-Feb 08 12:12:00 kloeri	Flameeyes: I check all kinds of development related activities, not just cvs
-Feb 08 12:12:10 kingtaco|work	failing that it's a general election for a reduced term for that spot
-Feb 08 12:12:12 Flameeyes	kloeri, council counting too?
-Feb 08 12:12:17 g2boojum	spb: Would you be happier if the GLEP were amended to permit taking the next on the list (plus confirmation) a possibility for slacker boots, as well?
-Feb 08 12:12:24 kloeri	Flameeyes: of course
-Feb 08 12:12:29 Flameeyes	kingtaco|work, I vote yes
-Feb 08 12:12:31 Flameeyes	kloeri, okay
-Feb 08 12:12:38 spb	g2boojum: either way works for me; i'd just prefer they were consistent
-Feb 08 12:12:52 wolf31o2|mobile	yes
-Feb 08 12:12:53 vapier	i'd just say 'leaving the council'
-Feb 08 12:12:54 kloeri	I vote yes
-Feb 08 12:13:03 kingtaco|work	ok, add "for any reason" to "council member leaves"
-Feb 08 12:13:10 kingtaco|work	I vote yes
-Feb 08 12:13:13 spb	yes
-Feb 08 12:13:39 kingtaco|work	vapier, robbat2|na ?
-Feb 08 12:13:42 wolf31o2|mobile	I'd agree with vapier, etc.  I don't see the need for a new election if the council agrees to have the next person in line take the position unanimously
-Feb 08 12:13:58 vapier	why does the council need to agree
-Feb 08 12:14:15 wolf31o2|mobile	uhh... because that's what we're being asked to vote on
-Feb 08 12:14:15 *	The_Paya (i=the_paya@gentoo/developer/thepaya) has joined #gentoo-council
-Feb 08 12:14:19 wolf31o2|mobile	;]
-Feb 08 12:14:31 kingtaco|work	vapier, you mean agree to the Nth spot?
-Feb 08 12:14:45 vapier	a council member leaves, the next spot is filled by the next person in the list]
-Feb 08 12:14:55 vapier	doesnt matter if the existing council members like that next person
-Feb 08 12:15:06 Flameeyes	vapier, if it happens to be the least preferred member for the council, it would make sense to veto him from joining
-Feb 08 12:15:13 vapier	why
-Feb 08 12:15:17 vapier	it's an elected position
-Feb 08 12:15:18 kingtaco|work	vapier, well, think about it this way
-Feb 08 12:15:43 spb	the alternative to having the council members agree on the replacement is to include 'reopen nominations' on the council ballot and not accept anyone below it
-Feb 08 12:15:46 kingtaco|work	that person that was voted for months ago may not be in the same position when we would put him in the council
-Feb 08 12:15:55 *	rbrown` (n=mynamewa@paludis/contributor/rbrown) has joined #gentoo-council
-Feb 08 12:15:57 kingtaco|work	also note that that person has the right to decline
-Feb 08 12:16:24 wolf31o2|mobile	no they don't
-Feb 08 12:16:27 wolf31o2|mobile	:P
-Feb 08 12:16:29 kingtaco|work	I think having the vote is just a safty clause
-Feb 08 12:16:43 vapier	then it's either we take the next person or we re-open elections
-Feb 08 12:16:49 *	NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-Feb 08 12:16:51 kingtaco|work	oh yres
-Feb 08 12:16:53 vapier	we cant selectively skip
-Feb 08 12:16:56 kingtaco|work	that's what I'm saying
-Feb 08 12:17:21 kingtaco|work	if we decline the next person it would be a election for that position for a reduced term
-Feb 08 12:17:31 wolf31o2|mobile	right
-Feb 08 12:17:31 kingtaco|work	we as in the current council
-Feb 08 12:17:46 vapier	i'll sign off on that
-Feb 08 12:17:52 kingtaco|work	ok
-Feb 08 12:18:01 kingtaco|work	6 yes, 1 abstain(robbat2)
-Feb 08 12:18:05 kingtaco|work	all good?
-Feb 08 12:18:12 spb	looks it
-Feb 08 12:18:19 kingtaco|work	ok, next item
-Feb 08 12:18:20 Flameeyes	yah
-Feb 08 12:18:21 wolf31o2|mobile	WFM
-Feb 08 12:18:30 kingtaco|work	glep 23 or 44 first?
-Feb 08 12:18:34 kingtaco|work	Flameeyes, you pick
-Feb 08 12:18:44 *	Flameeyes sets modes [#gentoo-council +v solar]
-Feb 08 12:18:49 Flameeyes	solar, you around for the status on 44?
-Feb 08 12:18:55 kingtaco|work	I take it it's 44 then :)
-Feb 08 12:19:10 Flameeyes	kingtaco|work, if he's around :) if he's not, let's go with 23 :)
-Feb 08 12:19:14 kingtaco|work	Flameeyes, it's 12:20 here, he's probably on lunch
-Feb 08 12:19:21 kingtaco|work	ok
-Feb 08 12:19:22 Flameeyes	then 23 would do
-Feb 08 12:19:36 kingtaco|work	so genone wants us to re afferm glep 23 because things have changed
-Feb 08 12:19:40 kingtaco|work	anyone want to talk about it?
-Feb 08 12:19:48 spb	what's changed, specifically?
-Feb 08 12:19:48 vapier	changed how
-Feb 08 12:19:53 kingtaco|work	good question
-Feb 08 12:20:35 kingtaco|work	does sources.g.o track glep repo?
-Feb 08 12:20:36 Flameeyes	for context, and people who have no clue about what 23 is, it's "Handling of ACCEPT_LICENSE"
-Feb 08 12:20:38 *	drac (i=drac@gentoo/developer/drac) has joined #gentoo-council
-Feb 08 12:20:39 kingtaco|work	g2boojum, ^^?
-Feb 08 12:21:01 spb	they're in gentoo/xml/htdocs/
-Feb 08 12:21:05 vapier	well genone isnt on and all i see is http://article.gmane.org/gmane.linux.gentoo.devel/45750
-Feb 08 12:21:37 g2boojum	kingtaco|work: I had assumed you folks knew what the issues were.  I haven't talked to genone about it.
-Feb 08 12:21:38 vapier	http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/
-Feb 08 12:21:39 kingtaco|work	bump it to next month so he can tell us what's changed?
-Feb 08 12:21:40 Flameeyes	I think it's the old discussion of a month or two ago
-Feb 08 12:21:55 wolf31o2|mobile	http://bugs.gentoo.org/show_bug.cgi?id=152593
-Feb 08 12:22:01 Flameeyes	but I admit I didn't really follow it
-Feb 08 12:22:13 wolf31o2|mobile	likely it's the solution to that bug that he wants discussed
-Feb 08 12:22:18 g2boojum	spb: paludis folks have any complaints w/ what genone's doing?
-Feb 08 12:22:33 g2boojum	?
-Feb 08 12:22:46 spb	we already have license filtering, so the only issue is with group syntax and how they're defined
-Feb 08 12:23:10 g2boojum	spb: Think you folks, genone, and pkgcore can come to an agreement?
-Feb 08 12:23:30 wolf31o2|mobile	there's also http://bugs.gentoo.org/show_bug.cgi?id=17367
-Feb 08 12:23:37 vapier	what do other package managers have to do with this ?
-Feb 08 12:23:51 kingtaco|pda	shouldnt this be part ogpkg manager spec?
-Feb 08 12:24:14 wolf31o2|mobile	nothing... as I understand it, he simply wants us to re-approve it, since the ideas have changed a bit since the original GLEP was approved
-Feb 08 12:24:35 spb	kingtaco|pda: it should
-Feb 08 12:24:55 vapier	well we can scratch our heads some more or just ask genone for more info
-Feb 08 12:25:06 vapier	and make sure we tag all topics for relevant info before the meeting so we dont do this
-Feb 08 12:25:07 Flameeyes	afk 1 minute
-Feb 08 12:25:14 kingtaco|pda	ok, bump it
-Feb 08 12:25:14 g2boojum	vapier: My view was that if there's a reasonable consensus on how to implement it, then the council probably doesn't really need to get involved except to approve it after the fact.
-Feb 08 12:25:18 wolf31o2|mobile	looks like our best option is to defer
-Feb 08 12:25:29 spb	the only comments i have on the glep as it is are (1) NON-MUST-HAVE-READ is a stupid name, and (2) is it legal to negate a license group?
-Feb 08 12:25:34 solar	Flameeyes: pong
-Feb 08 12:25:48 kingtaco|pda	solar glep 44
-Feb 08 12:25:51 wolf31o2|mobile	but I would recommend everyone check out those two bugs
-Feb 08 12:25:59 vapier	spb: something to post to the list
-Feb 08 12:26:03 Flameeyes	back
-Feb 08 12:26:06 vapier	wolf31o2: you already know my position on * :p
-Feb 08 12:26:07 kloeri	deferring seems to be the best option now I agree
-Feb 08 12:26:17 Flameeyes	yeah deferring is a good idea
-Feb 08 12:26:27 spb	vapier: yeah, hence i say defer
-Feb 08 12:26:40 kingtaco|work	ok, defered
-Feb 08 12:26:50 kingtaco|work	Flameeyes, solar: glep44 time
-Feb 08 12:27:01 solar	KingTaco: it seems to be progressing well. Flameeyes has been really on top of things. In the last few days he took the tree from 10% not ready to 7%. Maybe in a few weeks we will be able to make that cut over
-Feb 08 12:27:17 wolf31o2|mobile	spb: I agree that #1 is stupid... and #2, as I remember it, was that a group could only include licenses, not negate them, but it would be legal syntax to allow a negated group in ACCEPT_LICENSE... so you can --@OSI-APPROVED, but @OSI-APPROVED couldn't have -VMWARE (or something like that)
-Feb 08 12:27:18 Flameeyes	there is one problem though
-Feb 08 12:27:29 kingtaco|work	solar, tbh, I'm not sure what flameeyes wants to talk about so I'll defer to him
-Feb 08 12:28:02 Flameeyes	there are a few packages that are currently unmaintained (officially, or simply because the herd they belong to does not exist anymore)
-Feb 08 12:28:13 Flameeyes	and of those, there are quite a few that misses an upstream package
-Feb 08 12:28:28 Flameeyes	what are we up to do with them?
-Feb 08 12:28:34 wolf31o2|mobile	are they not on our mirrors?
-Feb 08 12:28:38 solar	when you say upstream you are saying they are on the mirrors but the SRC_URI has expired
-Feb 08 12:28:41 Flameeyes	do we consider glep44 an high enough priority to mess with them?
-Feb 08 12:28:47 Flameeyes	solar, yes
-Feb 08 12:29:05 Flameeyes	the quick and dirty solution is to use mirror://gentoo/ for those files
-Feb 08 12:29:07 wolf31o2|mobile	if they're on the mirrors, I would say leave them alone, if they're neither in SRC_URI or the mirrors, they need to be axed
-Feb 08 12:29:16 solar	Well the timeframe was about 1 year. That glep comes from 04-Dec-2005
-Feb 08 12:29:24 kingtaco|work	mess with them how?  isn't it simply regenerating the digests?
-Feb 08 12:29:29 spb	my comment on this is that PMS in its current state only describes Manifest2 and not the old-style digest/manifest
-Feb 08 12:29:45 Flameeyes	kingtaco|work, see the missing SRC_URI url
-Feb 08 12:29:47 wolf31o2|mobile	PMS?
-Feb 08 12:29:50 spb	so it'd be nice to have the tree completely converted by the time that gets implemented
-Feb 08 12:29:54 spb	wolf31o2|mobile: package manager spec
-Feb 08 12:29:57 wolf31o2|mobile	k
-Feb 08 12:29:59 kloeri	just change them to mirror://gentoo/ where possible
-Feb 08 12:30:04 kingtaco|work	if there is no upstream URI then change to mirror://gentoo and if it's not on our mirrors, pull the shit from the tree
-Feb 08 12:30:13 wolf31o2|mobile	agreed
-Feb 08 12:30:41 wolf31o2|mobile	Flameeyes: I'm willing to help you with this if you need it to try to get this done quicker... I'd *love* to be able to make the cut for 2007.0
-Feb 08 12:30:41 *	genstef (n=genstef@gentoo/developer/genstef) has left #gentoo-council
-Feb 08 12:30:56 Flameeyes	if we all agree on that, I'll see to fix the pacakges updating SRC_URI when needed (and opening a reference bug for safety)
-Feb 08 12:31:45 Flameeyes	vapier, there are a few of your packages and base-system packages too
-Feb 08 12:31:59 vapier	when arent there
-Feb 08 12:32:04 kingtaco|work	ok, so we seem to agree on the course of action for these packages, is there anything we need to vote on or discuss more?
-Feb 08 12:32:40 Flameeyes	well, I would ask if I can just go on and fix the tree at once or if I need to clear it up with all the maintainers
-Feb 08 12:32:59 spb	if you're not making substantive changes then i don't see the problem
-Feb 08 12:32:59 *	christel (i=christel@freenode/staff/gentoo.christel) has joined #gentoo-council
-Feb 08 12:33:00 Flameeyes	[considering that the list of packages fixed by me is generated and easily found, as I'm using a standard commit message
-Feb 08 12:33:02 solar	So target deadline is before 2007.0 snapshots begin? Can you give us a rough idea when that is planned for?
-Feb 08 12:33:26 Flameeyes	solar, maybe too soon
-Feb 08 12:33:34 wolf31o2|mobile	it very well might be... the plan in Monday
-Feb 08 12:33:35 kingtaco|work	Flameeyes, can you generate a list of ebuilds that need fixing?
-Feb 08 12:33:42 Flameeyes	kingtaco|work, I have it already
-Feb 08 12:33:55 solar	can you post it for everybody else?
-Feb 08 12:33:57 Flameeyes	http://rafb.net/p/s2xMEr38.html
-Feb 08 12:34:02 Flameeyes	solar, was nopasting it already :)
-Feb 08 12:34:07 kingtaco|work	Flameeyes, lets script emails to the maintainers and give them a week or 2 to fix then fix them ourselves
-Feb 08 12:34:19 Flameeyes	kingtaco|work, that would miss the snapshot
-Feb 08 12:34:30 kingtaco|work	hrm
-Feb 08 12:34:37 wolf31o2|mobile	if that's the consensus, I'm fine with that
-Feb 08 12:34:47 wolf31o2|mobile	but we're not pushing the snapshot >= 2 weeks
-Feb 08 12:34:54 spb	i'm in favour of just doing it
-Feb 08 12:34:58 Flameeyes	me too
-Feb 08 12:34:58 wolf31o2|mobile	as am I
-Feb 08 12:35:06 wolf31o2|mobile	it's just Manifest generation
-Feb 08 12:35:10 kingtaco|work	ok, I'll ride the wagon
-Feb 08 12:35:16 kloeri	yeah, just do it
-Feb 08 12:35:20 spb	it shouldn't involve any substantive ebuild changes
-Feb 08 12:35:27 kingtaco|work	vapier, you game?
-Feb 08 12:35:33 spb	just regenerating stuff that's regenerated on every commit
-Feb 08 12:35:34 wolf31o2|mobile	right
-Feb 08 12:35:36 kloeri	and let ebuild maintainers worry about real bugs
-Feb 08 12:35:51 wolf31o2|mobile	so who's planning on doing this work? us?
-Feb 08 12:36:00 Flameeyes	I can do it overnight
-Feb 08 12:36:02 kingtaco|work	sounds like flameeyes is
-Feb 08 12:36:03 vapier	considering all you're doing is rebuilding digests, just do it now ;p
-Feb 08 12:36:06 wolf31o2|mobile	I volunteer
-Feb 08 12:36:14 wolf31o2|mobile	Flameeyes: I'll do games-*
-Feb 08 12:36:19 kingtaco|work	were I not at scale this weekend I'd help
-Feb 08 12:36:19 wolf31o2|mobile	Flameeyes: I see there's a bunch of them
-Feb 08 12:36:31 vapier	it isnt like you're changing the ebuild
-Feb 08 12:36:38 wolf31o2|mobile	right
-Feb 08 12:36:45 Flameeyes	wolf31o2|mobile, okay, that's really good to hear as there are a few that aren't fetchable to begin with iirc
-Feb 08 12:36:45 kingtaco|work	ok
-Feb 08 12:36:56 kingtaco|work	next topic
-Feb 08 12:37:00 kingtaco|work	if we have them
-Feb 08 12:37:01 wolf31o2|mobile	the only concern I have is there's a possible bug in pycrypto... it hasn't been confirmed yet, though
-Feb 08 12:37:06 kloeri	Flameeyes: I can do dev-python if you like
-Feb 08 12:37:29 wolf31o2|mobile	http://bugs.gentoo.org/show_bug.cgi?id=164462 <---
-Feb 08 12:37:50 kingtaco|work	nothing else on the list, anyone got anything else before the floor opens?
-Feb 08 12:37:58 Flameeyes	wolf31o2|mobile, not the same as last time?
-Feb 08 12:37:59 wolf31o2|mobile	I don't think that should stop us, but if we find it is a bug, it might keep us from doing the switch for 2007.0
-Feb 08 12:38:12 wolf31o2|mobile	Flameeyes: dunno... I haven't verified it just yet
-Feb 08 12:38:23 g2boojum	tr1?
-Feb 08 12:38:25 kingtaco|work	ah
-Feb 08 12:38:39 kingtaco|work	g2boojum, iirc you wanted us to talk about it, but what is there to talk about?
-Feb 08 12:39:03 g2boojum	kingtaco|work: It'd be nice to have an executive decision on how to handle tr1 support in portage.
-Feb 08 12:39:07 Flameeyes	ah, for a note, don't use ebuild .. digest if possible, or it would override the digest check of FEATURES=strict
-Feb 08 12:39:24 Flameeyes	just run echangelog and repoman commit
-Feb 08 12:39:32 g2boojum	There's general agreement that none of the current ideas are fabulous, but something is going to have to be chosen relatively soon.
-Feb 08 12:39:36 kingtaco|work	g2boojum, I don't think most of us have an oppinion as it is
-Feb 08 12:39:41 kingtaco|work	portage doesn't use it
-Feb 08 12:39:42 g2boojum	s/ideas/solutions/
-Feb 08 12:39:49 Flameeyes	I've used "Regenerate digest in Manifest2 format." for all the commits, so that the list is regenerated by grepping for the string
-Feb 08 12:39:58 kloeri	g2boojum: I think the best proposal so far is ciaranms many virtuals
-Feb 08 12:40:10 g2boojum	kingtaco|work: Um, true only because portage is python, and C.
-Feb 08 12:40:22 kingtaco|work	indeed
-Feb 08 12:40:30 kingtaco|work	so it'
-Feb 08 12:40:37 g2boojum	kingtaco|work: It will still affect the portage tree, once people start writing packages that rely on tr1 support in g++.
-Feb 08 12:40:38 spb	kloeri: unfortunately true. which is a pity, because that solution is a pain in the arse
-Feb 08 12:40:48 kloeri	spb: completely agree
-Feb 08 12:40:56 kingtaco|work	so as I see it, tr1 support is a dep of some packages where they can either dep on boost or gcc4
-Feb 08 12:41:05 wolf31o2|mobile	Flameeyes: k
-Feb 08 12:41:22 kingtaco|work	can't we have a simple virtual of boost || gcc-4.1 ?
-Feb 08 12:41:28 Flameeyes	[reason for regenerating the list is that those packages are good candidates for new maintainers and/or removal]
-Feb 08 12:41:30 kloeri	kingtaco|work: gcc-4.1 or boost, yes
-Feb 08 12:41:32 spb	kingtaco|work: the problem is that right now nothing implements all of tr1, and the bits that various things implement are all different
-Feb 08 12:41:37 kingtaco|work	maybe a tr1.eclass that does some sanity checks
-Feb 08 12:42:11 vapier	if we simply forced people to stop being lazy and get their arches onto gcc-4.1, then we'd be set ;)
-Feb 08 12:42:16 kingtaco|work	so upstream is using broken libraries
-Feb 08 12:42:20 spb	vapier: not quite
-Feb 08 12:42:24 g2boojum	kingtaco|work: Not really, because in time there's an expectation that people will remove boost tr1 support in favor of support built-into g++, but removing a c++ lib will break compiled packages.
-Feb 08 12:42:29 *	iluxa (n=anonymou@gentoo/developer/iluxa) has joined #gentoo-council
-Feb 08 12:42:30 spb	if something starts using tr1 regexes you have problems again
-Feb 08 12:42:42 vapier	if it isnt in the compiler then dont use it
-Feb 08 12:42:43 g2boojum	kingtaco|work: So || won't really work well.
-Feb 08 12:42:48 vapier	boost sucks
-Feb 08 12:42:48 *	Flameeyes sets modes [#gentoo-council +v Betelgeuse]
-Feb 08 12:42:51 kingtaco|work	fyi, jokey likes the tr1.eclass idea
-Feb 08 12:42:54 kingtaco|work	(from pm)
-Feb 08 12:42:59 Flameeyes	Betelgeuse has another proposal too
-Feb 08 12:43:16 Betelgeuse	This can be solved by || ( ) deps that lock to the version at compile time
-Feb 08 12:43:18 spb	vapier: 4.2 and 4.3 have bits of tr1 that 4.1 doesn't, as do boost and stlport iirc
-Feb 08 12:43:24 Betelgeuse	But that would be EAPI=1 most likely
-Feb 08 12:43:38 spb	Betelgeuse: it's also a pain in the arse
-Feb 08 12:43:58 spb	what if i use a feature of tr1 that at present is only implemented by boost, but gets support for it in, say, gcc-4.3?
-Feb 08 12:43:59 kingtaco|work	so there is no full implementation of tr1 yet
-Feb 08 12:44:22 Betelgeuse	spb: you would use boost:: any way
-Feb 08 12:44:25 kingtaco|work	I'd say packages that use tr1 type features should hard dep on whatever provides those features
-Feb 08 12:44:28 vapier	how many packages actually leverage tr1
-Feb 08 12:44:28 g2boojum	kingtaco|work: There is, but it's boost, which, as vapier points out, "sucks".
-Feb 08 12:44:29 spb	then with the || ( ) dep thing you'd have to go through and update every ebuild using it for the new dep
-Feb 08 12:44:32 kingtaco|work	I'd still use an eclass for sanity checks
-Feb 08 12:44:40 Betelgeuse	spb: The sources having the wrapper would need mos any way.
-Feb 08 12:45:00 vapier	"every ebuild" isnt a big deal if we're talking a handful of packages
-Feb 08 12:45:00 kingtaco|work	we could hard dep on boost until gcc gets full tr1 support
-Feb 08 12:45:08 Betelgeuse	spb: nothing is saying that we could not have the binding in the virtual
-Feb 08 12:45:22 Flameeyes	how many packages are we talking about?
-Feb 08 12:45:34 Flameeyes	I wouldn't go to something like 10 virtuals if the packages using them are 3 or 4
-Feb 08 12:46:01 spb	Flameeyes: if we go the virtuals route i'd add them one at a time as needed
-Feb 08 12:46:04 kingtaco|work	g2boojum, it might suck today, that doesn't mean it'll suck tomorrow
-Feb 08 12:46:19 Flameeyes	spb, that doesn't stop them from being 10 virtuals even if they are 3 packages
-Feb 08 12:46:21 spb	kingtaco|work: it's sucked for the last five years; no reason to suppose it'll change
-Feb 08 12:46:30 Flameeyes	because they might be using 10 different features of tr1
-Feb 08 12:46:36 spb	at the moment the issue is mainly with tr1-memory
-Feb 08 12:46:47 g2boojum	kingtaco|work: Oh, the code in boost is excellent.  The problem is that you need almost all of it, and it's huge, for tr1.
-Feb 08 12:46:48 spb	which means right now it'll be one or two virtuals
-Feb 08 12:47:12 kingtaco|work	I guess I don't see what the big deal is that an ebuild deps on what it needs, perhaps a eclass to do sanity checks
-Feb 08 12:47:15 Flameeyes	nobody has a figure of how many packages are using tr1?
-Feb 08 12:47:26 spb	kingtaco|work: 11M of source is a hell of a lot for a single shared pointer class
-Feb 08 12:47:35 kingtaco|work	if it only needs gcc tr1 support then it should dep on the minimum gcc
-Feb 08 12:48:06 spb	except that not all archs have that gcc available
-Feb 08 12:48:21 kingtaco|work	spb, I'd argue that the whole concept is crap, and that none of it is ever needed with proper programming, but it's not something that we need to go into now
-Feb 08 12:48:33 kloeri	Flameeyes: don't have any figures on that but grepping the tree for boost deps should give you some idea I guess
-Feb 08 12:48:38 spb	define 'proper programming'
-Feb 08 12:48:43 *	Flameeyes sets modes [#gentoo-council +v jeeves]
-Feb 08 12:48:46 Flameeyes	!ddep boost
-Feb 08 12:48:47 jeeves	yikes 44 pkgs reverse depend on boost! Try digging around here instead. http://tinderbox.dev.gentoo.org/misc/dindex/
-Feb 08 12:48:49 vapier	assuming the boost requirement is for TR1
-Feb 08 12:48:58 kingtaco|work	spb, not difficult to manage your own pointers
-Feb 08 12:48:58 g2boojum	Flameeyes: Probably not.  The worry isn't so much the current number of packages, but there's evidence that a lot of folks are planning to jump on the tr1 bandwagon quite soon.
-Feb 08 12:49:01 vapier	and not just for one of the bajillion other things boost provides
-Feb 08 12:49:04 spb	kingtaco|work: hah
-Feb 08 12:49:10 kloeri	it's going to expand in the future as well
-Feb 08 12:49:16 kingtaco|work	anyway
-Feb 08 12:49:28 kingtaco|work	it doesn't matter what you or I think about those that use this library
-Feb 08 12:49:39 Flameeyes	g2boojum, there are often a lot of evidences that a lot of folks are jumping on a lot of bandwagons.... I don't like to get decisions over those evidences
-Feb 08 12:49:42 kingtaco|work	people are using it so we have to support it
-Feb 08 12:49:57 kingtaco|work	but I still don't know why it has to be treated differently than any other dep
-Feb 08 12:50:01 kloeri	vapier: yes, only a vague idea as some packages might just require >=gcc-4.1 instead of boost etc.
-Feb 08 12:50:06 Flameeyes	vapier, let's say that 1/4 of those packages need tr1 right now? would that make any sense?
-Feb 08 12:50:28 spb	kingtaco|work: if we had a complete implementation of tr1 anywhere then it would be simple
-Feb 08 12:50:59 kingtaco|work	spb, surely upstreams that use tr1 would say "use gcc" or "use boost" or "use libtr1"
-Feb 08 12:51:29 spb	kingtaco|work: most of them will use tr1::shared_ptr and have configure.ac check whether gcc has it and include wrapper code for boost's implementation if it doesn't
-Feb 08 12:51:57 kingtaco|work	ok
-Feb 08 12:52:12 spb	except that if you happen to be using a different STL implementation then the configure check will see it in the standard library and use that version instead of boost or gcc
-Feb 08 12:53:03 kingtaco|work	so, follow me here for a sec
-Feb 08 12:53:14 kingtaco|work	say we made all tr1 ebuilds dep on boost
-Feb 08 12:53:17 *	diox (n=diox@gentoo/developer/diox) has joined #gentoo-council
-Feb 08 12:53:36 kingtaco|work	most of them at compile time would detect that gcc has what they need from tr1 and ignore boost
-Feb 08 12:53:38 kingtaco|work	right?
-Feb 08 12:53:46 spb	but boost is still pulled into the depgraph
-Feb 08 12:53:51 spb	and boost is fucking huge
-Feb 08 12:53:56 kingtaco|work	right
-Feb 08 12:54:05 kingtaco|work	but you only have to compile it once
-Feb 08 12:54:18 spb	except that in most cases you don't have to compile it at all
-Feb 08 12:54:43 kingtaco|work	then why can't the ebuilds for these packages dep on the proper thing?
-Feb 08 12:54:44 spb	it's kinda like saying that vim should always build gvim as well because you only have to compile X once
-Feb 08 12:54:47 Flameeyes	sincerely, I'd just use || ( ) deps until the size of the involved tree is assessed
-Feb 08 12:54:51 kingtaco|work	if it works with gcc 4.1, then dep on it
-Feb 08 12:54:59 kingtaco|work	if it doesn't dep on boost
-Feb 08 12:55:05 Flameeyes	if the packages needing tr1 grew a lot, go with virtuals
-Feb 08 12:55:07 spb	depping on 4.1 doesn't work on platforms that don't have it yet
-Feb 08 12:55:14 kingtaco|work	from what you tell me, noone in their right mind would use boost where gcc is available
-Feb 08 12:55:21 Flameeyes	I wouldn't go with virtuals right away, because we don't know the size
-Feb 08 12:55:56 kingtaco|work	spb, which brings us back to virtual/tr1
-Feb 08 12:56:11 spb	kingtaco|work: except that there is nothing that provides all of tr1
-Feb 08 12:56:17 kingtaco|work	indeed
-Feb 08 12:56:22 kingtaco|work	so there isn't a good solution
-Feb 08 12:56:41 kingtaco|work	other than messy mips?(boost):(gcc-4) type stuff
-Feb 08 12:56:41 Flameeyes	and we have no figure of what's needed, which makes it difficult to get the pro/cons of the various options
-Feb 08 12:56:47 Flameeyes	as none of them is "pro only"
-Feb 08 12:56:48 g2boojum	Which was why ciaranm suggested virtual/tr1-memory, virtual/tr1-...
-Feb 08 12:57:02 spb	g2boojum: which kinda sucks, but is the best option anyone's suggested yet
-Feb 08 12:57:22 Flameeyes	g2boojum, which wouldn't really be good if you had 10 virtuals and 4 packages using them ...
-Feb 08 12:57:40 vapier	so just create virtuals as packages need them
-Feb 08 12:58:00 vapier	whether it be virtuals or a tr1.eclass, it's going to be chunky
-Feb 08 12:58:06 kingtaco|work	Flameeyes, the assumption is that more packages will use tr1 as time goes on
-Feb 08 12:58:13 kingtaco|work	I'm not sure I buy it, but meh
-Feb 08 12:58:18 kingtaco|work	I simply don't know
-Feb 08 12:58:24 Flameeyes	kingtaco|work, and as time goes on, _if_ they are going to do it, we can change the solution
-Feb 08 12:58:32 Flameeyes	it's not like we need to write it in stone once and forever
-Feb 08 12:58:33 spb	they are going to
-Feb 08 12:58:35 kingtaco|work	what's the solution now then?
-Feb 08 12:58:38 spb	it's far too useful not to
-Feb 08 12:58:40 Flameeyes	spb, you a time traveler?
-Feb 08 12:58:57 kingtaco|pda	anyway
-Feb 08 12:58:59 spb	Flameeyes: no; i just know that a lot of people writing C++ code have a vague degree of common sense
-Feb 08 12:59:06 Flameeyes	there are a lot of things that are far too useful not to do, but still not many people do that
-Feb 08 12:59:21 Flameeyes	spb, so? you can still not be sure of what happens
-Feb 08 12:59:28 kingtaco|pda	ahm
-Feb 08 12:59:56 kloeri	tr1 is definitely going to be used much more as it's (an upcoming) part of the standard library
-Feb 08 12:59:59 Flameeyes	you can't _guarantee_ that anybody is going to use it more than now, at least not grow to a size that would make us good to go with virtuals
-Feb 08 12:59:59 spb	i can make an educated guess with reasonable certainty
-Feb 08 13:00:07 kloeri	it's not some random library we're talking about
-Feb 08 13:00:19 kingtaco|pda	flame what do you propose as a immediate replacement for virtuals?
-Feb 08 13:00:45 Flameeyes	kingtaco|pda, well, I would be for first assessing the number of packages that requires the virtuals
-Feb 08 13:00:50 Flameeyes	and the number of required virtuals
-Feb 08 13:00:54 kingtaco|pda	until more stuff starts using tr1
-Feb 08 13:01:16 kingtaco|pda	assume the num doesnt justify virts
-Feb 08 13:01:17 Flameeyes	if you get more virtuals, or a size of virtuals that is more or less the same of the packages, I would just use || ( ) rather than virtuals
-Feb 08 13:01:21 *	djay-il|work (n=alex@bzq-88-152-191-182.red.bezeqint.net) has joined #gentoo-council
-Feb 08 13:01:43 Flameeyes	[which with new-style virtuals is more or less equivalent, just requires peripheral maintainership rather than central]
-Feb 08 13:01:55 Flameeyes	if the size justify the use of virtuals, go for it
-Feb 08 13:02:01 Flameeyes	adding new-style virtuals has a cost on the tree
-Feb 08 13:02:33 spb	if very few packages pick up on tr1 then virtuals have a slight disadvantage
-Feb 08 13:02:46 spb	if lots of packages pick up on tr1 then not doing virtuals now has a big disadvantage
-Feb 08 13:02:51 Flameeyes	right
-Feb 08 13:02:56 spb	the latter is more likely than the former
-Feb 08 13:03:07 spb	which brings it down to a question of expected effort, and virtuals win
-Feb 08 13:03:14 Flameeyes	I wouldn't asses the likelyness on this, as it's quite debatable
-Feb 08 13:03:24 kloeri	out of all the proposed solutions I still prefer the virtuals tbh
-Feb 08 13:03:29 spb	ok, assume they're equally likely if you want
-Feb 08 13:03:39 spb	the virtuals still win on expected effort
-Feb 08 13:03:51 Flameeyes	not for 10 or 20 new virtuals, imho
-Feb 08 13:04:06 spb	noone's asking you to create them
-Feb 08 13:04:18 kingtaco|work	Flameeyes, working on your assumption that it's not useful, whats the disadvantage(other than a few more files in the tree) to using virtuals?
-Feb 08 13:04:47 Flameeyes	spb, I beg you not to get it personal, the council's opinion was asked, I'm saying what I think
-Feb 08 13:05:01 g2boojum	Flameeyes: If I may ask, why do you feel that it's debatable?  I'm finding it hard to believe that people won't use new libraries that will be in the C++ standard, but you may well know something I don't.
-Feb 08 13:05:12 kingtaco|work	spb, and given that different arches will implement tr1 differently(boost vs gcc) how will virtuals help ?
-Feb 08 13:05:32 spb	kingtaco|work: far far easier to put arch? ( ) deps in a virtual than in twelve packages
-Feb 08 13:06:06 kingtaco|work	why not a eclass then?
-Feb 08 13:06:17 spb	what would the eclass do?
-Feb 08 13:06:20 Flameeyes	kingtaco|work, there's at least one bug with virtuals handling right now if you get naming collision, so I wouldn't abuse virtuals too much; the size of the tree is indeed also a concern to me, and more packages you got installed locally more time it takes to create the depgraph
-Feb 08 13:06:40 kingtaco|work	the same thing as virtuals but with more control
-Feb 08 13:06:51 kingtaco|work	you can add to DEPEND in an eclass
-Feb 08 13:06:59 spb	ten virtuals will have zero noticeable impact on the size of the tree
-Feb 08 13:07:02 kloeri	well, name collisions shouldn't be an issue as we already know about that
-Feb 08 13:07:22 kloeri	just avoid silly name collisions
-Feb 08 13:07:23 spb	the chances of someone creating a package named tr1-memory in another category are minimal
-Feb 08 13:07:33 Flameeyes	ten virtuals without need every two weeks will kill us most likely
-Feb 08 13:07:48 kingtaco|work	every 2 weeks?
-Feb 08 13:07:50 kingtaco|work	explain
-Feb 08 13:07:52 spb	ten virtuals once with good justification won't
-Feb 08 13:07:53 kloeri	ehh, we're not talking about every two weeks at all
-Feb 08 13:08:01 Flameeyes	kingtaco|work, just figurative
-Feb 08 13:08:04 kingtaco|work	ok
-Feb 08 13:08:05 kloeri	this is a fairly rare occasion
-Feb 08 13:08:24 Flameeyes	spb, I still have to see the assessment for their justification, I'm not turning them down entirely from the start
-Feb 08 13:08:34 spb	Flameeyes: i gave it above
-Feb 08 13:08:35 kingtaco|work	Flameeyes, also, if a pkg deps on virtual/tr1-foo then where is the collision?
-Feb 08 13:08:44 Flameeyes	I would just assess the number of required packages to be changed before
-Feb 08 13:08:49 Flameeyes	kingtaco|work, binpkg generation
-Feb 08 13:08:50 kingtaco|work	I'm not aware of this bug
-Feb 08 13:08:53 kingtaco|work	ah
-Feb 08 13:09:19 Flameeyes	spb, where? I don't see any number in my backlog?
-Feb 08 13:09:28 spb	Flameeyes: expected effort
-Feb 08 13:09:41 spb	the justification is probabilistic
-Feb 08 13:10:01 Flameeyes	I don't really buy it myself, personal though
-Feb 08 13:10:48 wolf31o2|mobile	how about we let democracy take over and just vote it out?
-Feb 08 13:11:03 spb	i don't see a better option than virtuals
-Feb 08 13:11:03 wolf31o2|mobile	(this meeting is kinda dragging on time-wise)
-Feb 08 13:11:03 Flameeyes	note: you won't make me change idea repeating the same reasoning, like I'm not considering changing your ideas repeating my opinion
-Feb 08 13:11:05 kingtaco|work	I think a TR1_USES="memory pointer"; inherit tr1 would be better than virtuals
-Feb 08 13:11:16 Flameeyes	I said what I thought, and then we can vote
-Feb 08 13:11:24 kingtaco|work	wolf31o2|mobile, da, I'll get there shortly
-Feb 08 13:11:29 kingtaco|work	ok
-Feb 08 13:11:32 spb	kingtaco|work: then you've turned a set of virtuals into a great big select-case statement
-Feb 08 13:11:35 Flameeyes	kingtaco|work, uhm, there's a problem with useflags though
-Feb 08 13:11:51 kingtaco|work	Flameeyes, ?
-Feb 08 13:11:56 kingtaco|work	pick a different env var
-Feb 08 13:12:07 kingtaco|work	or is there something else?
-Feb 08 13:12:14 spb	kingtaco|work: what happens if a package only needs tr1::regex if a given useflag is set?
-Feb 08 13:12:16 Flameeyes	kingtaco|work, I mean, if it needs memory or pointer _only_ if an useflag is enabled or disabled
-Feb 08 13:12:25 Flameeyes	how would you handle that with variables before inherit?
-Feb 08 13:12:31 kingtaco|work	spb, Flameeyes I get ya
-Feb 08 13:12:36 Flameeyes	Maybe a bit better would be having inherit tr1
-Feb 08 13:12:45 Flameeyes	and then set foo? ( ${TR1_MEMORY_DEPS} )
-Feb 08 13:12:57 kingtaco|work	ohh, that looks promising
-Feb 08 13:13:02 kingtaco|work	spb, thoughts?
-Feb 08 13:13:06 spb	except that that's what virtuals were designed to do
-Feb 08 13:13:13 spb	you've just reimplemented the same thing in a different place
-Feb 08 13:13:27 kingtaco|work	with more control and less bugs
-Feb 08 13:13:31 Flameeyes	spb, yes, that's what I said before too anyway, reimplementing through || () the same thing
-Feb 08 13:13:32 spb	not really
-Feb 08 13:13:38 Flameeyes	kingtaco|work, it has one problem anyway
-Feb 08 13:13:54 spb	i don't see how it gives any more control
-Feb 08 13:14:03 Flameeyes	_if_ the packages using tr1 will actually increase, it would become way less performant than new-style virtuals
-Feb 08 13:14:25 spb	that is a point
-Feb 08 13:14:35 spb	changing the eclass invalidates cache for everything using it
-Feb 08 13:14:41 spb	changing a virtual invalidates one cache entry
-Feb 08 13:14:46 kingtaco|work	ok, I guess we vote
-Feb 08 13:14:50 wolf31o2|mobile	I dislike the eclass idea for one simple reason, we have to leave that crap in the tree forever
-Feb 08 13:14:51 Flameeyes	that's why I think we should first get some figures at least on the current tree and maybe maintainer-wanted
-Feb 08 13:14:57 spb	plus what wolf31o2|mobile said
-Feb 08 13:15:12 spb	ok, Flameeyes votes to do nothing for now and look at numbers
-Feb 08 13:15:28 Flameeyes	no.
-Feb 08 13:15:33 Flameeyes	I vote to get the figures, and then decide
-Feb 08 13:15:39 kingtaco|work	we have 3 possible solutions: 1) each ebuild does it all on it's own 2) a dozen virtuals 3) a eclass
-Feb 08 13:15:41 spb	hence do nothing for now
-Feb 08 13:15:51 kingtaco|work	or bump it to next month
-Feb 08 13:15:57 spb	2
-Feb 08 13:16:12 kloeri	my vote is on 2
-Feb 08 13:16:17 kingtaco|work	I wouldn't mind bumping it to next month, seems we have more to discuss
-Feb 08 13:16:40 wolf31o2|mobile	I'm voting 2... we can always remove virtuals easy enough later, where eclasses we can't
-Feb 08 13:16:53 Flameeyes	spb, semantically different, "doing nothing" would also mean not getting the figures
-Feb 08 13:16:57 vapier	i vote 2 and vote spb do the work
-Feb 08 13:16:58 kloeri	wolf31o2|mobile: agreed
-Feb 08 13:17:02 *	hparker has quit (Remote closed the connection)
-Feb 08 13:18:02 kingtaco|work	gah, the eclass is so much more powerful, but the problems around the eclasses in general makes it not attractive
-Feb 08 13:18:29 wolf31o2|mobile	right
-Feb 08 13:18:53 Flameeyes	indeed
-Feb 08 13:19:13 kingtaco|work	I reluctantly choose #2, but I think we should see if we can make eclasses suck less(maybe part of wolfs idea on small projects)
-Feb 08 13:19:56 wolf31o2|mobile	speaking of... we didn't really get a lot of ideas for that... I'll have to query again and try to keep track of everything... seems things kinda got off-track on that
-Feb 08 13:20:22 kingtaco|work	Flameeyes, wanna vote?
-Feb 08 13:20:29 Flameeyes	kingtaco|work, I did my vote already
-Feb 08 13:20:57 Flameeyes	wolf31o2|mobile, maybe you could use bugs.g.o to track the stuff, now that it is usable :)
-Feb 08 13:21:16 kingtaco|work	ok, as I understand it Flameeyes wants to bump to next month so we can do more research
-Feb 08 13:21:23 kingtaco|work	everyone vote yes/no please
-Feb 08 13:21:32 spb	yes/no on bumping it?
-Feb 08 13:21:35 kingtaco|work	da
-Feb 08 13:21:38 wolf31o2|mobile	heh... yeah, that's possible... first, I think we need a good idea on what we should be doing
-Feb 08 13:21:45 wolf31o2|mobile	ok
-Feb 08 13:21:46 wolf31o2|mobile	no
-Feb 08 13:21:49 spb	no point
-Feb 08 13:22:08 kingtaco|work	kloeri, vapier ? (flameeyes I assume is "yes")
-Feb 08 13:22:12 kloeri	no need to defer it imo
-Feb 08 13:22:42 kloeri	if somebody comes up with a better solution we can always migrate to that instead of the virtuals
-Feb 08 13:22:47 vapier	like the one legged man says, bump it
-Feb 08 13:23:13 kingtaco|work	so 3 no, 2 yes
-Feb 08 13:23:24 kingtaco|work	(I've yet to vote)
-Feb 08 13:24:29 kingtaco|work	I'll vote bump too, but note that option #2 is likely to go into effect next month so that's the timeline
-Feb 08 13:24:40 Flameeyes	robbat2 is still missing
-Feb 08 13:24:45 kingtaco|work	we got a month to come up with something better
-Feb 08 13:24:50 kingtaco|work	yes, he's a slacker today
-Feb 08 13:25:04 Flameeyes	kingtaco|work, yeah nothing stops anyone into implementing it out of the tree and be ready to commit it
-Feb 08 13:25:21 kingtaco|work	we all kosher?
-Feb 08 13:25:25 wolf31o2|mobile	ok, I'll say we bump it, too so we don't end up deadlocked
-Feb 08 13:25:25 wolf31o2|mobile	heh
-Feb 08 13:25:29 wolf31o2|mobile	make it all official-like
-Feb 08 13:25:33 kingtaco|work	hehe
-Feb 08 13:25:42 *	spb shrugs
-Feb 08 13:26:12 kingtaco|work	spb, would you start planning the implementation of virtuals please
-Feb 08 13:26:13 kloeri	ok, so is Flameeyes going to come up with some numbers on packages using tr1?
-Feb 08 13:26:18 spb	kingtaco|work: nothing much to plan
-Feb 08 13:26:34 spb	it's all ready to be implemented
-Feb 08 13:26:44 Flameeyes	kloeri, I would have no idea how to extract those numbers, as I don't know what tr1 consists of
-Feb 08 13:26:55 spb	Flameeyes: anything in the std::tr1 namespace
-Feb 08 13:27:03 kingtaco|work	spb, aight, can you post the list of virtuals and the lists of the packages that use them?
-Feb 08 13:27:05 Flameeyes	spb, just that?
-Feb 08 13:27:07 spb	anything using boost::shared_ptr
-Feb 08 13:27:15 kingtaco|work	or flameeyes
-Feb 08 13:27:23 kingtaco|work	if we're going to bump we should make use of it
-Feb 08 13:27:26 spb	anything using hashed containers in C++
-Feb 08 13:27:40 Flameeyes	although, there's no point in doing the redudant job, whoever is going to try changing to virtuals will also provide the numbers by indirection
-Feb 08 13:27:45 kingtaco|work	spb, but how without looking at every source file can we tell what is using it?
-Feb 08 13:28:09 kingtaco|work	I think tha'ts what flameeyes is hinting at
-Feb 08 13:28:15 spb	kingtaco|work: by looking at upstream's stated deps
-Feb 08 13:28:21 kingtaco|work	for every package?
-Feb 08 13:28:37 kingtaco|work	we can't just grep for boost?
-Feb 08 13:28:46 spb	same way as you'd figure out who's using python-2.4 features
-Feb 08 13:29:03 kingtaco|work	for that I'd look at the deps in the ebuild
-Feb 08 13:29:05 kloeri	tr1 isn't any different from other deps in that regard
-Feb 08 13:29:06 kingtaco|work	scriptable
-Feb 08 13:29:14 kingtaco|work	ok, lemme rephrase
-Feb 08 13:29:16 kloeri	you have to look at every single package to determine the deps
-Feb 08 13:29:28 kingtaco|work	what should we search for in the ebuild to determine if it's using some tr1 stuff?
-Feb 08 13:30:32 kingtaco|pda	boost? gcc4?
-Feb 08 13:30:44 kloeri	you can grep for std::tr1 and friends but it source might not always use the std:: qualifier
-Feb 08 13:30:45 spb	the most likely indicator is a dep on || ( gcc-4.1 boost )
-Feb 08 13:31:00 kingtaco|pda	ok
-Feb 08 13:31:25 kingtaco|pda	who's doing that list?
-Feb 08 13:31:43 spb	the list of packages doing it right at this moment is fairly meaningless
-Feb 08 13:32:09 kingtaco|pda	not to some of us
-Feb 08 13:32:27 kingtaco|pda	hence the bump
-Feb 08 13:32:33 spb	someone to whom it has meaning can find the list then
-Feb 08 13:32:49 spb	as far as i'm concerned it's sensible future proofing as much as anything else
-Feb 08 13:33:11 spb	especially since i know that at least one package will continue to use more tr1 features as they become available
-Feb 08 13:33:47 kingtaco|work	sure
-Feb 08 13:33:50 kingtaco|work	we all know this
-Feb 08 13:33:54 kingtaco|work	it's no secret
-Feb 08 13:34:58 kingtaco|work	however, a dozen virtuals for only paludis makes no sense.  if we're going to do all the virtuals, it needs to be for all the packages that use tr1
-Feb 08 13:35:09 spb	right
-Feb 08 13:35:11 kingtaco|work	this is not perl
-Feb 08 13:35:21 kingtaco|work	no 17 ways to do one thing :)
-Feb 08 13:35:30 spb	so implement the virtuals and then as packages are seen to need them they get made to use them
-Feb 08 13:36:01 kingtaco|work	right, and what people want to know is what currently will take advantage of it
-Feb 08 13:36:33 *	g2boojum dashes; Thanks for the discussion, all.
-Feb 08 13:36:59 kingtaco|work	not future intent
-Feb 08 13:37:28 spb	so what you're saying is that there's no point implementing something that will be used in the future if it's not going to be used at the time it's written?
-Feb 08 13:37:33 kingtaco|work	so someone raise their hand to figure it out
-Feb 08 13:37:38 kingtaco|work	I'm not saying that at all
-Feb 08 13:37:44 spb	looks that way
-Feb 08 13:37:50 kingtaco|work	gah
-Feb 08 13:39:22 spb	if it does turn out to be just two or three packages that need it then it'll only be one virtual we need
-Feb 08 13:39:30 spb	which makes it little different from any of the other virtuals in tree
-Feb 08 13:39:30 kingtaco|work	one last time, some people want to know what would currently take advantage of said virtuals
-Feb 08 13:39:45 kingtaco|work	SOMEONE needs to provide a list
-Feb 08 13:39:58 kingtaco|work	who is going to do it?
-Feb 08 13:40:28 spb	http://www.google.com/codesearch?hl=en&q=+std::tr1+-gcc+-boost&sa=N is a start
-Feb 08 13:40:58 Flameeyes	I would just look at the changes needed to implement virtuals, so if spb is going to show a patch to the tree with the changes needed (or even a cvs up list, if he's not going to blatantly cheat), those numbers suffice to me
-Feb 08 13:41:00 kingtaco|work	ebuilds in the tree
-Feb 08 13:41:26 kingtaco|work	cat/pkg one per line plain ASCII
-Feb 08 13:42:08 kingtaco|work	anyway, this shit takes too much time, someone do it in the next 2 weeks, the topic will come up for vote next month
-Feb 08 13:42:22 kingtaco|work	anyone else have any other topic before open floor?
-Feb 08 13:42:30 Flameeyes	nothing here
-Feb 08 13:42:37 wolf31o2|mobile	I have initial reply-to docs, but I need to fix them
-Feb 08 13:43:06 *	avenj (n=avenj@gentoo/developer/avenj) has left #gentoo-council
-Feb 08 13:43:13 kloeri	should we discuss the maintainer timeout thingy that drizzt and betelgeuse both suggested or is everybody happy with relying on common sense?
-Feb 08 13:43:23 kingtaco|work	I prefer common sense
-Feb 08 13:43:27 Flameeyes	common sense goes well for me
-Feb 08 13:43:33 spb	common sense
-Feb 08 13:43:35 Flameeyes	we discussed that on -core not many months ago too
-Feb 08 13:43:57 kloeri	I have spf docs at http://dev.gentoo.org/~kloeri/spf.txt that needs to be guidexml'ified and possibly fixed/expanded upon
-Feb 08 13:44:03 spb	tree devs have access to the whole tree for a reason
-Feb 08 13:44:10 *	kloeri prefers common sense as well
-Feb 08 13:44:12 wolf31o2|mobile	common sense
-Feb 08 13:44:26 kingtaco|work	I'm sure vapier goes along with common sense
-Feb 08 13:44:33 *	Flameeyes sets modes [#gentoo-council -vv Betelgeuse solar]
-Feb 08 13:44:38 *	Flameeyes sets modes [#gentoo-council -v jeeves]
-Feb 08 13:44:43 kloeri	nod
-Feb 08 13:44:46 kingtaco|work	anything else?
-Feb 08 13:44:50 *	Flameeyes sets modes [#gentoo-council -v g2boojum]
-Feb 08 13:44:57 kloeri	nothing from me
-Feb 08 13:45:16 kingtaco|work	ok, open floor time
-Feb 08 13:45:19 *	kingtaco|work sets modes [#gentoo-council -m]
-Feb 08 13:45:46 spb	http://www.google.com/codesearch?hl=en&lr=&q=boost%3A%3Ashared_ptr+gentoo.osuosl.org&btnG=Search <== sources in our distfiles mirrors using shared_ptr
-Feb 08 13:46:00 vapier	nothing from wolf31o2 about reply-to ?
-Feb 08 13:46:06 vapier	err nm i see that comment
-Feb 08 13:46:12 kingtaco|work	vapier, he said he's got a doc (mostly) ready
-Feb 08 13:46:18 *	Flameeyes hands glasses to vapier
-Feb 08 13:46:19 vapier	"council managed projects" ?
-Feb 08 13:46:27 wolf31o2|mobile	http://dev.gentoo.org/~wolf31o2/reply-to.xml
-Feb 08 13:46:41 kingtaco|work	vapier, my suggestion to that is a group of people to fix up eclass suckage
-Feb 08 13:46:58 wolf31o2|mobile	I spoke about that... I didn't really get anything that stood out... so I'm going to pose the question again and tally up the responses, then have us vote on one of them next time around
-Feb 08 13:47:05 vapier	k
-Feb 08 13:47:18 kingtaco|work	maybe define a "persistant" eclass spec, where the eclass would stay in the cache from compile time
-Feb 08 13:47:41 agaffney	are you people still going?
-Feb 08 13:47:44 kingtaco|work	so we can remove them from the tree
-Feb 08 13:47:48 *	agaffney looks at the clock
-Feb 08 13:47:49 kingtaco|work	agaffney, open floor atm
-Feb 08 13:47:52 agaffney	ah
-Feb 08 13:48:00 agaffney	I missed the meeting...anything "interesting"?
-Feb 08 13:48:08 vapier	no
-Feb 08 13:48:13 kingtaco|work	not really, a bunch on tr1
-Feb 08 13:48:28 agaffney	yeah, I completely ignored that thread on -dev, so I have no idea what that even is :P
-Feb 08 13:48:28 kingtaco|work	if noone does the logs I'll send them out when I get home
-Feb 08 13:48:35 kingtaco|work	>>>>> OPEN FLOOR
-Feb 08 13:48:53 agaffney	>>>>> VAPIER'S MOM
-Feb 08 13:49:00 Jokey	another idea that came up more often recently. keywording involves touching the ebuild and thus results in refetch of the whole ebuild just for a change of 1-5 chars.. Proposal: signed separate keywords file per package, syntax like with package.keywords
-Feb 08 13:49:09 vapier	someone forgot to commit the logs for 20070111
-Feb 08 13:49:23 Flameeyes	Jokey, rsync should handle the changes
-Feb 08 13:49:25 kingtaco|work	vapier, iirc that was robbat2, I'll try to get him on it
-Feb 08 13:49:45 Jokey	Flameeyes: not talking about who handles it but the amount of useless traffic for it
-Feb 08 13:49:48 kingtaco|work	Flameeyes, rsync works with blocks, I question if most ebuilds are larger than one block
-Feb 08 13:50:09 vapier	err no, links in index.xml are bokren
-Feb 08 13:50:11 vapier	i'll fix em
-Feb 08 13:50:13 Jokey	Flameeyes: think of a kde stable keywording... how many ebuilds you refetch...
-Feb 08 13:50:17 spb	separating keywords is far more effort than it's worth
-Feb 08 13:50:31 Jokey	Flameeyes: and how often as we have more than one arch
-Feb 08 13:50:31 spb	and i would question whether it's sensible at all
-Feb 08 13:50:55 kingtaco|work	Jokey, the other side to that is it's another block rsync has to fetch
-Feb 08 13:51:02 Flameeyes	Jokey, I mean that in theory it should refetch just the part that changed... of course as kingtaco|work said, it might be that it actually refetch all of it anyway
-Feb 08 13:51:21 kingtaco|work	plus it takes more FS space
-Feb 08 13:51:28 kingtaco|work	for most of the users anyway
-Feb 08 13:51:54 Jokey	KingTaco: won't take more space
-Feb 08 13:52:02 spb	it takes more FS space, you have to transfer the entire keywords file when it changes anyway, the transition would be completely horrible, it makes the package manager's job far harder, ....
-Feb 08 13:52:14 spb	Jokey: "block size"
-Feb 08 13:52:23 kingtaco|work	Jokey, how so?  not all of us use reiser with tail packing
-Feb 08 13:52:25 spb	more files == more inodes and more space
-Feb 08 13:52:27 kingtaco|work	I use ext3
-Feb 08 13:52:27 kloeri	you also have additional problems with keeping the keyword file in sync with the ebuilds
-Feb 08 13:52:36 Flameeyes	what kloeri said
-Feb 08 13:52:51 *	Jokey also notes that we have --whole-file in default portage sync options
-Feb 08 13:53:13 Flameeyes	right now you are sure that if you change a package and someone changed the keywords in the mean time you get a collision
-Feb 08 13:53:38 Flameeyes	if you got keywords and ebuilds split, you cannot guarantee that if you try to change the dependencies, the keywords are fixed
-Feb 08 13:54:33 kingtaco|pda	would require atomic commits
-Feb 08 13:54:59 kingtaco|pda	which cvs doesnt directly do
-Feb 08 13:55:04 Flameeyes	kingtaco|pda, no, won't help
-Feb 08 13:55:34 Flameeyes	atomic commits would help only if you had the keywording file beside the ebuilds
-Feb 08 13:55:42 Flameeyes	which would mean having to add _a lot_ of extra files
-Feb 08 13:55:54 kingtaco|pda	da
-Feb 08 13:55:59 Jokey	11063 atm
-Feb 08 13:55:59 Flameeyes	[okay, less files than the current digests, but still a lot]
-Feb 08 13:56:15 Flameeyes	Jokey, that's at least 11MB then
-Feb 08 13:56:25 Jokey	considering that we are at 145k files already < 10%
-Feb 08 13:56:35 Flameeyes	I would still like to avoid it
-Feb 08 13:56:40 Flameeyes	would probably be slower on rsync anyway
-Feb 08 13:56:51 Flameeyes	as it would still need to resync the keywording file every time
-Feb 08 13:57:05 kloeri	I don't see the benefits at all and I think there's several cons to that idea
-Feb 08 13:57:07 kingtaco|work	jokey, I guess none of us see the advantage
-Feb 08 13:57:08 *	|mpagano| (n=kvirc@pool-70-105-167-163.nwrknj.fios.verizon.net) has joined #gentoo-council
-Feb 08 13:57:09 Flameeyes	and rarely there are more than one ebuild changed per package during keywording
-Feb 08 13:57:15 kingtaco|work	we'd swap transferring one file for another
-Feb 08 13:57:25 Jokey	kingtaco|pda: seems so, have to live with it then
-Feb 08 13:57:31 kingtaco|work	and add a whole other bunch of headaches
-Feb 08 13:57:32 kloeri	a huge amount of additional files, risk of desynchronisation being the primary ones I guess
-Feb 08 13:57:35 Jokey	KingTaco: you have too many aliases in here ;)
-Feb 08 13:57:37 spb	ok, so everyone agrees it's a stupid idea?
-Feb 08 13:57:40 kingtaco|work	but if there are advantages, please say them
-Feb 08 13:57:58 kingtaco|work	we're not mind readers
-Feb 08 13:58:06 Jokey	kingtaco|pda: a) transfer b) easier to "overlay" ebuilds for keywording on alt projects
-Feb 08 13:58:19 kingtaco|work	transfer?
-Feb 08 13:58:25 Flameeyes	I can't see any advantage in transfer
-Feb 08 13:58:26 Jokey	file size
-Feb 08 13:58:26 kingtaco|work	you're swapping one file for another
-Feb 08 13:58:32 Flameeyes	you just change the file to tranfer
-Feb 08 13:58:36 kingtaco|work	a packet is a packet
-Feb 08 13:58:40 Jokey	err no
-Feb 08 13:58:43 Flameeyes	Jokey, and file number to sync
-Feb 08 13:58:50 Jokey	I transfer one file for 3 keyworded ebuilds
-Feb 08 13:58:56 Jokey	(openldap)
-Feb 08 13:59:02 kingtaco|work	so you want one file per pkg
-Feb 08 13:59:07 kingtaco|work	for all the keywords
-Feb 08 13:59:12 Flameeyes	Jokey, how often would you keyword more than one ebuild for package?
-Feb 08 13:59:12 Jokey	being one file with about 2k instead of 3 files each 14k
-Feb 08 13:59:15 spb	and when you roll out the change you have to transfer every ebuild and a keywords file for every package
-Feb 08 13:59:18 kingtaco|work	all versions of that ebuild in one file
-Feb 08 13:59:22 spb	which more than outweighs the saving you'll make
-Feb 08 13:59:25 Jokey	Flameeyes: all slotted packages come to mind
-Feb 08 13:59:32 Flameeyes	Jokey, how many there are?
-Feb 08 13:59:46 kloeri	adding new versions and cleaning out old versions would be a lot more painful that way
-Feb 08 13:59:48 Jokey	kde, gnome, ldap, mysql,.....
-Feb 08 13:59:50 Flameeyes	and that would only work if you keyword them _at the same time_
-Feb 08 14:00:03 ---	robbat2|na is now known as robbat2
-Feb 08 14:00:05 robbat2	argh
-Feb 08 14:00:05 Flameeyes	Jokey, you never keyword more than one kde slot per time
-Feb 08 14:00:06 Jokey	kloeri: if repoman helps on that one
-Feb 08 14:00:08 robbat2	overslept :-(
-Feb 08 14:00:20 kingtaco|work	robbat2, :(
-Feb 08 14:00:28 Flameeyes	robbat2, you didn't lose much
-Feb 08 14:00:32 kingtaco|work	robbat2, btw, you need to upload the last meeting minutes
-Feb 08 14:00:33 *	solar does not think you are a slacker
-Feb 08 14:00:42 *	mpagano has quit (Client Quit)
-Feb 08 14:01:08 Jokey	Flameeyes: would even more speak for it as you still only have to transfer the keyword file and not the ebuild and manifest over and over again
-Feb 08 14:01:16 robbat2	kingtaco|work, huh, the previous ones should be up? I emailed them as well
-Feb 08 14:01:23 Flameeyes	Jokey, you should transfer the manifest too
-Feb 08 14:01:27 kingtaco|work	robbat2, vapier pointed it out
-Feb 08 14:01:30 kloeri	Jokey: so now you need to cvs rm some ebuild and then run repoman fixmess before committing? :)
-Feb 08 14:01:32 Flameeyes	and no it speaks against it
-Feb 08 14:01:32 kingtaco|work	I haven't confirmed
-Feb 08 14:01:48 Jokey	kloeri: you need to do that currently anyway
-Feb 08 14:01:53 Jokey	for redigesting
-Feb 08 14:01:57 Jokey	so no difference
-Feb 08 14:02:01 vapier	robbat2: the link was broken, i fixed it
-Feb 08 14:02:02 Flameeyes	Jokey, repoman commit regenerates manifest, if you didn't know
-Feb 08 14:02:08 vapier	it had two 1's instead of three
-Feb 08 14:02:10 Jokey	Flameeyes: I know
-Feb 08 14:02:19 Flameeyes	then you shouldn't run repoman fix during removal of old ebuilds
-Feb 08 14:02:26 kloeri	no, keeping keywords and ebuilds in sync and managing digests is different problems
-Feb 08 14:03:01 *	kingtaco|pda has quit (Read error: 104 (Connection reset by peer))
-Feb 08 14:03:24 Jokey	well really, I personally don't care as of today I'm on 100 mbit natively at home... but sanchan f.ex is on 56k and he does care about every single byte to transfer as he has to pay for it
-Feb 08 14:04:17 Flameeyes	I think that adding more files is just making the situation worse, as we said you end up swapping one file sent to another
-Feb 08 14:04:39 Flameeyes	plus two files when you're adding a new ebuild
-Feb 08 14:04:40 kingtaco|work	not to sound crass, but I dont think adding this sort of complexity to maybe save a couple bytes is worth it
-Feb 08 14:04:52 Flameeyes	I'd consider more sensible to move toward Manifest2 asap
-Feb 08 14:04:58 kingtaco|work	indeed
-Feb 08 14:05:06 Flameeyes	[and I'm still committing]
-Feb 08 14:05:39 Flameeyes	or maybe someone should see what happens for who are under limited network environments to disable --whole-file
-Feb 08 14:05:40 Jokey	can't recall it atm, does manifest2 force gpg signed files?
-Feb 08 14:05:55 Flameeyes	Jokey, Manifest2 will remove the digest-* files
-Feb 08 14:05:58 kloeri	no
-Feb 08 14:06:19 kloeri	manifest signing and manifest 2 are separate issues
-Feb 08 14:06:29 kingtaco|work	ohh
-Feb 08 14:06:31 Jokey	does manifest signing have a glep?
-Feb 08 14:06:34 kingtaco|work	a topic for next month
-Feb 08 14:06:41 kloeri	not yet
-Feb 08 14:06:41 kingtaco|work	manifest signing
-Feb 08 14:06:49 Jokey	k'
-Feb 08 14:06:51 kloeri	robbat2 needs to finish his tree signing stuff
-Feb 08 14:06:52 robbat2	if I finish the stuff on it before then
-Feb 08 14:07:08 kingtaco|work	last I heard people didn't want to do it because of lack of gpg-agent
-Feb 08 14:07:13 kingtaco|work	but that's no longer the case
-Feb 08 14:07:27 kloeri	looked fairly good the stuff I saw a few weeks ago though
-Feb 08 14:07:27 Jokey	gpg-agent/keychain ++
-Feb 08 14:07:36 Flameeyes	fwiw, zmedico also told me how to increase the timeout of gpg-agent, making its use even more practical
-Feb 08 14:07:41 kingtaco|work	I'm using gpg-agent with my own "keychain"
-Feb 08 14:07:52 Flameeyes	[not that I wasn't using signing before too]
-Feb 08 14:08:15 kingtaco|work	ok, a topic for next month then
-Feb 08 14:08:20 kingtaco|work	anything else?
-Feb 08 14:08:57 kingtaco|work	speak now or wait 28 days ...
-Feb 08 14:09:01 Flameeyes	a second
-Feb 08 14:09:12 Flameeyes	I would like to get rid of the glep about the 4-tuple keywords
-Feb 08 14:09:23 Flameeyes	that's glep22
-Feb 08 14:09:29 Flameeyes	[had to look up the number]
-Feb 08 14:10:40 Flameeyes	last council asked for a new glep to obsolete it, but considering that it has been difficult to address this through a replacement glep (that glep was _never_ put in action as it is written), and that the current status of the tree is already good enough, it might be worth just retire that glep
-Feb 08 14:10:48 kingtaco|work	Flameeyes, I don't think anyone has implemented it
-Feb 08 14:10:54 kingtaco|work	but lets vote on it next month
-Feb 08 14:10:57 Flameeyes	agreed
-Feb 08 14:11:02 kloeri	that will have to wait for next month
-Feb 08 14:11:11 kloeri	we need a little time to consider it I guess
-Feb 08 14:11:13 Flameeyes	kloeri, yes, just saying that I want to bring up that topic :)
-Feb 08 14:11:21 Flameeyes	for next month, that is
-Feb 08 14:11:21 kloeri	nod
-Feb 08 14:11:23 kingtaco|work	ok
-Feb 08 14:11:26 kingtaco|work	anything else?
-Feb 08 14:11:29 kingtaco|work	3
-Feb 08 14:11:32 kingtaco|work	2
-Feb 08 14:11:35 kingtaco|work	1
-Feb 08 14:11:35 kloeri	we'll probably be happy to dump it though :)
-Feb 08 14:11:44 kingtaco|work	>>>>>END MEETING
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070308-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070308-summary.txt
deleted file mode 100644
index fda891b634..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070308-summary.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-- Flameeyes has retired from Gentoo so Uberlord was put into place in
-  accordance with the GLEP changes from last month.
-
-- The Package Manager Spec (PMS) posted by spb looks like a good first
-  draft.  It will be opened up to the public before next council meeting
-  and we'll review the status again at that time.
-
-- The current state of Gentoo's public communication was reviewed.  The
-  frequent fighting among people and irrelevant technical related public
-  posts are disheartening.  Devrel was charged with revamping our current
-  nettiquette documents and policies for getting people to play nice in the
-  cases where they refuse to and to report back the status next meeting.
-  Council members also agreed to lead by example by taking g2boojum's example.
-
-- We've expanded the Council GLEP slightly:
- * Two Council members may (together) make executive decisions which carry the
-   weight of the full Council.  Upon making such a decision, the Gentoo Council
-   mailing list must be notified.  At the next meeting, it must also be noted.
-   Any disagreement from the Gentoo community will be taken to the full Gentoo
-   Council.
-
-- The tr1 issue will be resolved in the short term by new-style virtuals.  As
-  packages need them, they should create them.  Long term, when a sane tr1
-  implementation arises (most likely from GCC itself), the virtuals will be
-  reviewed and probably dissolved.
-
-- The topic of splitting the gentoo-dev mailing list up will be punted to the
-  next month's meeting.
-
-- Gentoo branded hardware was discussed and many ideas thrown about.  This also
-  touched on the concept of "Enterprise Gentoo".
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070308.txt b/xml/htdocs/proj/en/council/meeting-logs/20070308.txt
deleted file mode 100644
index 10d49b5037..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070308.txt
+++ /dev/null
@@ -1,1044 +0,0 @@
-Mar 08 14:59:39 * kingtaco|work sets mode +m #gentoo-council
-Mar 08 14:59:43 * think4urs11 (n=its-me@p5494F109.dip.t-dialin.net) has joined #gentoo-council
-Mar 08 14:59:45 <kingtaco|work> aight, might as well get started
-Mar 08 14:59:50 <kingtaco|work> rollcall
-Mar 08 15:00:05 <Kugelfang> gimem 2 mins please
-Mar 08 15:00:17 <kingtaco|work> I'm here
-Mar 08 15:00:25 <kingtaco|work> robbat2, kloeri wolf31o2|mobile
-Mar 08 15:00:30 <wolf31o2|mobile> present and somewhat here mentally... head cold is killing me
-Mar 08 15:00:31 <kloeri> yo
-Mar 08 15:00:54 <kingtaco|work> aight, so council topics
-Mar 08 15:01:23 <kingtaco|work> I listed on -dev the following: PMS, gentoo certified hardware and gentoo branded hardware
-Mar 08 15:01:23 <robbat2> yo
-Mar 08 15:01:43 <kingtaco|work> we also have appoint uberlord(which is first)
-Mar 08 15:01:52 <kingtaco|work> who else has topics?
-Mar 08 15:02:11 <wolf31o2|mobile> I do...
-Mar 08 15:02:16 <kingtaco|work> ok
-Mar 08 15:02:20 * Kugelfang back
-Mar 08 15:02:26 <wolf31o2|mobile> 2, actually...
-Mar 08 15:02:30 <kloeri> we probably need to discuss the mailinglist problems
-Mar 08 15:02:35 <wolf31o2|mobile> first, on request, the flames
-Mar 08 15:02:37 <wolf31o2|mobile> yup
-Mar 08 15:02:48 <wolf31o2|mobile> second, what power should the council have
-Mar 08 15:02:53 <kingtaco|work> ok
-Mar 08 15:02:55 <robbat2> wasn't there also discussion on the council-managed projects?
-Mar 08 15:03:09 <kingtaco|work> robbat2, my hardware stuff is council projects
-Mar 08 15:03:32 <robbat2> ok
-Mar 08 15:03:33 * welp[lap] has quit (Read error: 104 (Connection reset by peer))
-Mar 08 15:03:42 <kingtaco|work> anything else?
-Mar 08 15:03:47 <kingtaco|work> SpanKY, Kugelfang ?
-Mar 08 15:03:52 <Kugelfang> not  from me
-Mar 08 15:04:22 <kingtaco|work> aight, first item
-Mar 08 15:04:25 <kingtaco|work> uberlord
-Mar 08 15:04:28 <kingtaco|work> who isn't here
-Mar 08 15:04:30 <vapier> [14:50] <vapier> i guess in the future, we just need to make sure that no such retarded restrictions are put into place
-Mar 08 15:04:41 <kingtaco|work> vapier, noted
-Mar 08 15:05:21 <kingtaco|work> last month we decided that we could unanmiously approve the Nth person from the original council vote in for a reduced sentence to fill a vacancy
-Mar 08 15:05:24 * welp[lap] (n=welp@gentoo/developer/welp) has joined #gentoo-council
-Mar 08 15:05:32 <kingtaco|work> uberlord is #8, and flameeyes has quit
-Mar 08 15:05:36 <kloeri> right
-Mar 08 15:05:44 <Kugelfang> i think we can just commence voting, right?
-Mar 08 15:05:59 <kingtaco|work> or we could punt it if people want to ask him questions
-Mar 08 15:06:08 <vapier> UberLord is fine by me and seems the rest of community felt that way when we the vote happened last time
-Mar 08 15:06:11 <wolf31o2|mobile> I'm ready to vote on it
-Mar 08 15:06:15 <Kugelfang> dito
-Mar 08 15:06:25 <kingtaco|work> anyone not want to vote?
-Mar 08 15:06:29 <vapier> KingTaco: questions should have been asked before :p
-Mar 08 15:06:38 <kingtaco|work> vapier, agreed, but meh
-Mar 08 15:06:41 <kingtaco|work> ok
-Mar 08 15:06:46 <Kugelfang> he's a nice guy, capable and has a nice taste regarding beer
-Mar 08 15:06:55 <kingtaco|work> vote: bring uberlord in to replace flameeyes
-Mar 08 15:06:56 <Kugelfang> so let's vorte :-P
-Mar 08 15:07:01 <Kugelfang> yes
-Mar 08 15:07:14 <wolf31o2|mobile> yes
-Mar 08 15:07:15 <robbat2> yes
-Mar 08 15:07:20 <kingtaco|work> yes
-Mar 08 15:07:21 <kloeri> yes
-Mar 08 15:07:33 <Kugelfang> vapier:
-Mar 08 15:07:35 <vapier> <vapier> UberLord is fine by me
-Mar 08 15:07:40 <kingtaco|work> done
-Mar 08 15:07:45 <kingtaco|work> uberlord is accepted
-Mar 08 15:07:51 <kingtaco|work> and now marked as a slacker
-Mar 08 15:07:52 <wolf31o2|mobile> man, if only every topic went like that
-Mar 08 15:07:52 <Kugelfang> wherever he is right now
-Mar 08 15:08:07 <wolf31o2|mobile> would he be a slacker if he wasn't on the council prior to the meeting?
-Mar 08 15:08:14 <Kugelfang> i don't think so
-Mar 08 15:08:23 <kingtaco|work> ok, we let this one slide
-Mar 08 15:08:24 <wolf31o2|mobile> me either
-Mar 08 15:08:26 <wolf31o2|mobile> yup
-Mar 08 15:08:26 <Kugelfang> *g*
-Mar 08 15:08:29 <kloeri> has anybody pinged him about the meeting?
-Mar 08 15:08:32 <kingtaco|work> I did
-Mar 08 15:08:54 <kloeri> ok
-Mar 08 15:09:07 <kingtaco|work> aight
-Mar 08 15:09:09 <kingtaco|work> next business
-Mar 08 15:09:40 <kingtaco|work> anyone want to go first?
-Mar 08 15:09:46 <Kugelfang> PMS?
-Mar 08 15:09:52 <wolf31o2|mobile> go for it... it's your show
-Mar 08 15:09:56 <Kugelfang> is it?
-Mar 08 15:09:57 <Kugelfang> *g*
-Mar 08 15:10:03 <kingtaco|work> ok
-Mar 08 15:10:06 <kingtaco|work> I'll do pms
-Mar 08 15:10:08 <Kugelfang> ok, most council folks have a draft of PMS now
-Mar 08 15:10:08 <kingtaco|work> it's my topic
-Mar 08 15:10:22 <Kugelfang> who hasn't?
-Mar 08 15:10:31 <Kugelfang> robbat2: what about you?
-Mar 08 15:10:33 <robbat2> i haven't, mainly as I don't have time yet
-Mar 08 15:10:38 <Kugelfang> robbat2: want one?
-Mar 08 15:10:38 <robbat2> but an aside on that
-Mar 08 15:10:50 <kingtaco|work> there are a couple perceived problems with how the current PMS was developed
-Mar 08 15:10:54 <robbat2> i'll need to look soon, because i've got a note about tree-signing for later
-Mar 08 15:10:56 * spaetz (n=spaetz@v30439.1blu.de) has joined #gentoo-council
-Mar 08 15:11:02 <robbat2> Kugelfang, yes please
-Mar 08 15:11:02 <Kugelfang> robbat2: nod
-Mar 08 15:11:35 <kingtaco|work> 1. up until now, it's only included people from 2 of the 3 pkgmgrs
-Mar 08 15:11:52 <vapier> you mean 1 of the 3
-Mar 08 15:12:01 <kingtaco|work> apparently zmedico has access
-Mar 08 15:12:08 <vapier> k
-Mar 08 15:12:11 <kingtaco|work> I haven't been able to talk with him yet to confirm
-Mar 08 15:12:18 <kingtaco|work> I'm going to assume that Kugelfang wouldn't lie to me
-Mar 08 15:12:48 <Kugelfang> thanks :-)
-Mar 08 15:12:50 <Kugelfang> yes, he has access
-Mar 08 15:13:02 <wolf31o2|mobile> can we get a list of who has access?
-Mar 08 15:13:08 <Kugelfang> a rough one
-Mar 08 15:13:12 <Kugelfang> one seco
-Mar 08 15:13:15 <wolf31o2|mobile> sure... something close
-Mar 08 15:13:15 <wolf31o2|mobile> ok
-Mar 08 15:13:17 <vapier> regardless, i dont think that's been a detriment to the overall quality as a initial draft
-Mar 08 15:13:35 <vapier> spb/ciaranm know we wouldnt accept bullshit disguised as a spec
-Mar 08 15:13:39 <kingtaco|work> no, however as an accepted standard, it cannot exclude any interested party
-Mar 08 15:13:52 <kingtaco|work> it's not complete yet
-Mar 08 15:14:01 <kingtaco|work> they haven't finished, and there is still time to include pkgcore
-Mar 08 15:14:02 <kloeri> nobody is saying to exclude anybody for the final standard
-Mar 08 15:14:09 <vapier> right, nor is it described as such
-Mar 08 15:14:17 <kingtaco|work> however, it's taken much longer than any of us had initialy though
-Mar 08 15:14:31 <wolf31o2|mobile> +t
-Mar 08 15:14:31 <kingtaco|work> so here's my proposal
-Mar 08 15:14:34 <kloeri> and spb said earlier that it would probably be opened further in a couple of weeks so everybody can comment on it
-Mar 08 15:14:58 <kingtaco|work> why don't we label whatever portage ships with 2007.0 as the final EAPI=0
-Mar 08 15:15:08 <kingtaco|work> people can document it without deadlines
-Mar 08 15:15:16 <kingtaco|work> and we can go forward with EAPI=1
-Mar 08 15:15:31 <kingtaco|work> thoughts?
-Mar 08 15:15:35 <vapier> there's a deficiency or two in portage that i'd disagree with
-Mar 08 15:15:36 <Kugelfang> access: spb, ciaranm, pioto, , me, betelgeuse, all council except diego (no chance to give him)
-Mar 08 15:15:47 <kloeri> because we want the documentation and not some vague notion of whatever is supported at 2007.0 time imo
-Mar 08 15:15:59 <kingtaco|work> kloeri, it's been what, 6 months?
-Mar 08 15:16:00 <Kugelfang> access: zmedico, genone
-Mar 08 15:16:12 <Kugelfang> that's all who i remember right now
-Mar 08 15:16:18 <vapier> KingTaco: about, first discussed 20060914
-Mar 08 15:16:20 <kingtaco|work> it's taking too long and holding up other things
-Mar 08 15:16:31 <Kugelfang> kingtaco|work: PMS documents portage capabilities...
-Mar 08 15:16:38 <kloeri> kingtaco|work: maybe, but just ignoring documentation doesn't solve the lack of documentation and it should be open quite soon so it can be finished
-Mar 08 15:16:42 <kingtaco|work> Kugelfang, I know what it does
-Mar 08 15:16:51 <kingtaco|work> I'm trying to paralellize things
-Mar 08 15:17:00 <Kugelfang> i mean, this thing is almost finished
-Mar 08 15:17:06 <Kugelfang> as you pointed out yourself
-Mar 08 15:17:08 <kingtaco|work> so we're not hostage to ciaranms "priorities" and spbs master thesis
-Mar 08 15:17:45 <Kugelfang> honestly, ciaranm wasn't asked to do this... so why should we be hostage to his priorities?
-Mar 08 15:17:46 <kloeri> I think hostage is a bit strong tbh
-Mar 08 15:18:00 <kingtaco|work> I view EAPI=0as some snapshot
-Mar 08 15:18:03 <g2boojum> kingtaco|work: Perhaps I'm misunderstanding something, but somebody could have said "EAPI-0 is whatever portage does" years ago, but that doesn't docuement anything.  You'd still have to write up what it's doing.
-Mar 08 15:18:04 <Kugelfang> it's his voluntary contribution
-Mar 08 15:18:10 <kloeri> and it should be open soon so that everybody can work on it which is what you want I guess
-Mar 08 15:18:18 <kingtaco|work> g2boojum, yes, and in hindsight we should have
-Mar 08 15:18:21 <Kugelfang> licensed under CC-sa-3.0
-Mar 08 15:18:31 <Kugelfang> kingtaco|work: dude, it has been done
-Mar 08 15:18:34 <kingtaco|work> kloeri, don't second guess me, ask
-Mar 08 15:18:40 <Kugelfang> kingtaco|work: exactly what you say has been done
-Mar 08 15:19:07 <kloeri> kingtaco|work: ok, do you want it to be opened so that everybody can participate?
-Mar 08 15:19:19 <kingtaco|work> yes
-Mar 08 15:19:53 <Kugelfang> christel wants me to point out that she has access, too :-D
-Mar 08 15:20:01 <kingtaco|work> however, more than anything else, I want it to be done
-Mar 08 15:20:11 <kloeri> fine, we've been told that going to happen in a week or two most likely so why make some arbitrary decision about a random portage version shipped with 2007.0 being EAPI0 when we're so close?
-Mar 08 15:20:13 <Kugelfang> kingtaco|work: there is a list of fixmes
-Mar 08 15:20:14 <wolf31o2|mobile> if they say they're two weeks away, then I'm willing to wait those two weeks
-Mar 08 15:20:17 <g2boojum> kingtaco|work: You missed my point.  You'd still have to document it, which would likely take notably more time to do from scratch than waiting for spb's doc to be released, which would then at least serve as a starting point if you want to backtrack to a particular version of portage.
-Mar 08 15:20:23 * UberL (n=uberlord@rsm.demon.co.uk) has joined #gentoo-council
-Mar 08 15:20:35 * vapier gives voice to UberL
-Mar 08 15:20:39 >chanserv< list
-Mar 08 15:20:46 <Kugelfang> hey UberL
-Mar 08 15:20:47 >chanserv< list #gentoo-council
-Mar 08 15:20:48 <kingtaco|work> g2boojum, I don't think that doc is much different from what will be released as 2007.0
-Mar 08 15:20:53 * kingtaco|work gives channel operator status to UberL
-Mar 08 15:20:57 <UberL> soz I'm late guys
-Mar 08 15:21:03 <Kugelfang> slacker
-Mar 08 15:21:16 <wolf31o2|mobile> g2boojum: I think what Mike meant was that we would backtrack to 2.1.2.2 (which is what we're using for 2007.0) and everything beyond that, feature-wise, would be EAPI > 0
-Mar 08 15:21:18 <vapier> KingTaco: it may not be much different, but i think the few differences would make EAPI=0 -> EAPI=1 painful
-Mar 08 15:21:28 >chanserv< access #gentoo-council
-Mar 08 15:21:30 <kingtaco|work> g2boojum, makeing it coencide with a release gives a very nice test case as to if something is eapi0 compliant
-Mar 08 15:21:47 <Kugelfang> i disagree
-Mar 08 15:22:03 <kingtaco|work> known bugs aside
-Mar 08 15:22:20 <Kugelfang> so, how do you decide what is a bug without a spec?
-Mar 08 15:22:38 <kingtaco|work> I think they are all documented in our bugzilla
-Mar 08 15:22:51 <Kugelfang> i'm not sure about that
-Mar 08 15:22:56 <wolf31o2|mobile> nobody said we don't get a spec
-Mar 08 15:23:04 <kingtaco|work> then I have to ask why not?
-Mar 08 15:23:11 <kingtaco|work> if it's not filed as a bug then it's not a damn bug
-Mar 08 15:23:22 <Kugelfang> kingtaco|work: heh, even those bugs which haven't been found yet?
-Mar 08 15:23:28 <Kugelfang> nothgin is bug free
-Mar 08 15:23:54 <vapier> kingtaco|laptop: i think your initial post to the -dev list about deadlines was enough to get the final kick going
-Mar 08 15:23:59 <wolf31o2|mobile> jesus h christ... can we try to not be so damned pedantic for a change?
-Mar 08 15:24:08 <vapier> the current track for this to be opened before next council meeting is sufficient
-Mar 08 15:24:18 <Kugelfang> i think that's doable
-Mar 08 15:24:23 <kingtaco|work> we can't vote next council
-Mar 08 15:24:27 <wolf31o2|mobile> I agree with vapier... if they're on track to have it open by the next council meeting, I'm game
-Mar 08 15:24:32 <wolf31o2|mobile> no, not vote
-Mar 08 15:24:36 <kingtaco|work> it won't have sat for public review long enough
-Mar 08 15:24:41 <wolf31o2|mobile> just make sure it's open for comment before then
-Mar 08 15:24:59 <kingtaco|work> also, I've heard of someone else wanted to write the spec
-Mar 08 15:25:00 <wolf31o2|mobile> we definitely want a longer review period than a couple weeks
-Mar 08 15:25:12 <g2boojum> kingtaco|work: That's a Council-made rule, so the Council can make exceptions.  I'm not saying you should, just that you could.
-Mar 08 15:25:28 * g2boojum butts out, now
-Mar 08 15:25:29 <kingtaco|work> I don't see any vote on that document happening for at least 2 months
-Mar 08 15:25:29 <wolf31o2|mobile> there's nothing wrong with a competing spec
-Mar 08 15:25:34 <wolf31o2|mobile> agreed
-Mar 08 15:25:36 <kloeri> well, we can have competing specifications if we want
-Mar 08 15:25:37 <kingtaco|work> and thats if it went public in 2 weeks
-Mar 08 15:25:49 <kingtaco|work> in the mean time we're still stuck on eapi-0
-Mar 08 15:26:05 <kloeri> council will just have to vote on the final specification (same thing however many specs we have)
-Mar 08 15:26:08 <kingtaco|work> why should we waste 2 months when it's not needed?
-Mar 08 15:26:11 <Kugelfang> i just want to see who's going to write a 48 page spec on the package manager in the same time :-)
-Mar 08 15:26:26 <kingtaco|work> Kugelfang, write it in text and it'll be less than 20
-Mar 08 15:26:28 <robbat2> how about an in-between meeting?
-Mar 08 15:26:42 <robbat2> it's probably going to be a large discussion in council for the spec anyway
-Mar 08 15:26:44 <kloeri> we need the spec to be complete and accurate which takes time
-Mar 08 15:26:48 <kingtaco|work> vapier, wolf31o2|mobile and what happens when they miss their deadline
-Mar 08 15:26:49 <vapier> i think a competing spec is redundant
-Mar 08 15:26:50 <kloeri> no way to avoid that imo
-Mar 08 15:26:58 <kingtaco|work> I hate the idea of a competing spec
-Mar 08 15:27:01 <wolf31o2|mobile> kingtaco|laptop: *we* open it
-Mar 08 15:27:17 <kingtaco|work> but personality problems between the 2 groups almost dictate it
-Mar 08 15:27:18 <vapier> kingtaco|laptop: then we take it over
-Mar 08 15:27:25 <wolf31o2|mobile> kingtaco|laptop: if they're agreeing it can be opened by the next meeting, we just hold them to it
-Mar 08 15:27:32 <Kugelfang> it'S CC-sa-3.0, so i don't see a problem
-Mar 08 15:27:37 <vapier> ive given it a glance over and it looks good
-Mar 08 15:27:47 <kingtaco|work> Kugelfang, then why arn't we able to release it now?
-Mar 08 15:27:55 <Kugelfang> kingtaco|work: they haven't released it yet
-Mar 08 15:28:13 <kingtaco|work> ok, I'
-Mar 08 15:28:16 <Kugelfang> they want it released when all those little "fixmes" are gone
-Mar 08 15:28:23 <kingtaco|work> ok, I'm willing to hold my tounge for 1 more month
-Mar 08 15:28:25 <kingtaco|work> nothing more
-Mar 08 15:28:36 <kingtaco|work> it must be open for public review
-Mar 08 15:28:50 <Kugelfang> oh come one... nobody said it won't be
-Mar 08 15:28:55 <Kugelfang> -e
-Mar 08 15:29:01 <vapier> Kugelfang: before today, no one said it would be
-Mar 08 15:29:03 * The_Paya (i=the_paya@gentoo/developer/thepaya) has joined #gentoo-council
-Mar 08 15:29:09 <Kugelfang> vapier: sure
-Mar 08 15:29:17 <kingtaco|work> vapier, about 55 minutes ago to be exact
-Mar 08 15:29:17 <wolf31o2|mobile> no, nobody gave us a timeframe in which it would be
-Mar 08 15:29:31 <Kugelfang> vapier: spb always stated: "no public draft before they deem it ready, then public review"
-Mar 08 15:29:36 <wolf31o2|mobile> spb gave us a rough estimate today... 2 weeks... we're giving him 4... heh
-Mar 08 15:29:44 <vapier> Kugelfang: and that's too vague
-Mar 08 15:29:55 <Kugelfang> vapier: there's been enough mails on that on -dev
-Mar 08 15:30:10 <vapier> no, most of those e-mails were retarded and unrelated
-Mar 08 15:30:10 <Kugelfang> vapier: the pity is, that it all ended up in the ciaranm-drobbins flamefest
-Mar 08 15:30:21 <kingtaco|work> Kugelfang, the simple fact that there were that many emails shows that there is a very strong divide
-Mar 08 15:30:38 <Kugelfang> kingtaco|work: but not on the contents
-Mar 08 15:30:55 <kingtaco|work> Kugelfang, how could it be on the content?
-Mar 08 15:31:03 <kingtaco|work> the majority haven't seen it
-Mar 08 15:31:13 <Kugelfang> see the point? people discuss a thing they haven't had the chance to read yet..
-Mar 08 15:31:34 <kingtaco|work> see my point? people want to participate and an external group is telling them no
-Mar 08 15:31:36 <Kugelfang> this is the exact reason why i hadn't been published
-Mar 08 15:31:46 <vapier> regardless, i think it's settled for now ... the stuff spb posted looks good and will be opened to the public soonish
-Mar 08 15:32:00 <kingtaco|work> 1 month more
-Mar 08 15:32:02 <kingtaco|work> no more
-Mar 08 15:32:03 <Kugelfang> *g*
-Mar 08 15:32:07 <wolf31o2|mobile> agreed... next topic?
-Mar 08 15:32:16 <kingtaco|work> anyone disagree?
-Mar 08 15:32:22 <vapier> KingTaco: no, i'm with you on that
-Mar 08 15:32:49 <kingtaco|work> while everyones blood pressure is up, we may as well talk about things like devrel, mailing lists and nettiquette
-Mar 08 15:32:51 <kloeri> that's fine
-Mar 08 15:32:56 <wolf31o2|mobile> heh
-Mar 08 15:33:11 <wolf31o2|mobile> I picked the wrong week to quit huffing rubber cement
-Mar 08 15:33:13 <kingtaco|work> first
-Mar 08 15:33:14 <vapier> my blood pressure is throbbing
-Mar 08 15:33:23 <kingtaco|work> I think we need a vote of confidence in devrel
-Mar 08 15:33:31 <Kugelfang> do we?
-Mar 08 15:33:39 <kingtaco|work> I think maybe that'll help them start to enforce our netiquette
-Mar 08 15:33:39 <vapier> along what lines ?
-Mar 08 15:33:40 * windzor_ (n=windzor@82.143.229.82) has joined #gentoo-council
-Mar 08 15:33:47 <kingtaco|work> I worded that wrong
-Mar 08 15:33:54 <vapier> yeah you did ;)
-Mar 08 15:33:57 <kingtaco|work> here's what I want to say
-Mar 08 15:34:08 <kingtaco|work> I want devrel to start enforing netiquette
-Mar 08 15:34:15 <kingtaco|work> I don't care if people scream cabal
-Mar 08 15:34:16 <g2boojum> kingtaco|work: Better would be a notion of what you actually want them to enforce.
-Mar 08 15:34:18 <kloeri> well, there's a reason we don't try to ban people
-Mar 08 15:34:20 <kingtaco|work> I don't care if people leave
-Mar 08 15:34:24 * blubb (n=blubb@gentoo/developer/blubb) has joined #gentoo-council
-Mar 08 15:34:28 <vapier> be our wordstappo
-Mar 08 15:34:29 <kingtaco|work> I want a pleasant gentoo
-Mar 08 15:34:37 <kloeri> devrel doesn't believe it's going to help and it does nothing to solve the real problem imo
-Mar 08 15:34:39 <Kugelfang> vapier: precisely...
-Mar 08 15:34:50 <kingtaco|work> kloeri, and what are we going to do about that
-Mar 08 15:34:55 <kingtaco|work> do you need more people?
-Mar 08 15:35:01 <kingtaco|work> what can we do to help
-Mar 08 15:35:06 <kingtaco|work> it's devrel's job
-Mar 08 15:35:15 <kloeri> it removes people but the real problem is that people don't behave politely/properly/whatever
-Mar 08 15:35:19 * christel holds up hand
-Mar 08 15:35:24 <kingtaco|work> hahah
-Mar 08 15:35:29 <kingtaco|work> talking through +m I see
-Mar 08 15:35:33 * kingtaco|work gives voice to christel
-Mar 08 15:35:34 <Kugelfang> kingtaco|work: nothing... that's freedom of speech and freedom of action. If people want to behave like morons in public there is very little you can do about it
-Mar 08 15:35:40 <christel> thanks kingtaco|work :)
-Mar 08 15:35:47 <wolf31o2|mobile> kloeri: banning people from the lists, not necessarily... but reducing the requirements on devrel to suspend "repeat offenders" might just make them think about their actions before doing them, and that could decrease the flames a bit
-Mar 08 15:35:53 <kloeri> I don't know how to solve this problem as we have a hell of a lot of devs that happily attack other people and then refuses to accept that behaviour is part of the problem
-Mar 08 15:35:58 <kingtaco|work> Kugelfang, you are mistaken if you think there is absolute freedom around here
-Mar 08 15:36:06 <wolf31o2|mobile> kloeri: suspend said devs
-Mar 08 15:36:22 <kingtaco|work> Kugelfang, also your interpitation of free speech is incorrect
-Mar 08 15:36:24 <wolf31o2|mobile> I know on at least one occasion I probably should have been suspended... heh
-Mar 08 15:36:28 <christel> i believe (as devrel and conflict res) that we need more defined chain of command, responsibility and *abilities* for devrel and crp to be able to execute anything at all
-Mar 08 15:36:31 <kloeri> there's some devs that are persistently poisoning the project that I want to deal with but that's not just related to mailinglists
-Mar 08 15:36:37 <kingtaco|work> you're free to say whatever, not you're free to say whatever on my soapbox
-Mar 08 15:36:38 <kloeri> wolf31o2|mobile: and users?
-Mar 08 15:36:48 <Kugelfang> kingtaco|work: so, how do you control non-devs on public mailing lists?
-Mar 08 15:36:52 <Kugelfang> kingtaco|work: banning won't work
-Mar 08 15:36:59 <kingtaco|work> Kugelfang, I have an idea for that
-Mar 08 15:37:05 <Kugelfang> kingtaco|work: moderation?
-Mar 08 15:37:08 <kingtaco|work> no
-Mar 08 15:37:11 <kingtaco|work> I hate moderation
-Mar 08 15:37:16 <Kugelfang> me too
-Mar 08 15:37:22 <kingtaco|work> so
-Mar 08 15:37:24 <kloeri> gentoo being as open as possible is one of our core values imo and one of the things that define our community
-Mar 08 15:37:30 <wolf31o2|mobile> kloeri: I have no answer for users
-Mar 08 15:37:33 <kloeri> I'd rather not do anything to hurt that
-Mar 08 15:37:42 <christel> i believe bans should be a very very last resort, but at the same time i believe that the etiquette policy should be enforced (ie. warn warn suspend or similar)
-Mar 08 15:37:51 <kingtaco|work> kloeri, but it's being hurt none the less
-Mar 08 15:38:04 <vapier> there's also the issue of leading by example
-Mar 08 15:38:21 <Kugelfang> vapier: yeah, seemant had nice blog posts on those
-Mar 08 15:38:32 <wolf31o2|mobile> christel: agreed... I think we need to be a bit more strict on our developers... after all, in the flames involving users, developers are just as much at fault as the users... perhaps if the devs didn't respond in kind, the flames would subside much quicker, etc
-Mar 08 15:38:35 <kloeri> kingtaco|work: yes, but should we hurt it more?
-Mar 08 15:38:42 <vapier> i think if we were all to act like g2boojum ...
-Mar 08 15:38:45 <kingtaco|work> kloeri, I'd argue that you'd hurt it less
-Mar 08 15:38:53 <christel> wolf31o2|mobile: yeah
-Mar 08 15:38:54 * g2boojum blushes
-Mar 08 15:39:14 <christel> one of the things i think is important is that whomever sits at the top of a chain of command plays no favours
-Mar 08 15:39:17 <kingtaco|work> shit, work IRQ, continue discussing, I'll be back in 3
-Mar 08 15:39:39 <wolf31o2|mobile> right
-Mar 08 15:39:39 <g2boojum> christel: Um, the etiquette guide is actually a bit too broad, and possibly insufficiently vague.  You don't really want to ban somebody for messing up the ChangeLog, but that's in that guide.
-Mar 08 15:40:00 <wolf31o2|mobile> so should we work together to have the guide updated?
-Mar 08 15:40:14 <christel> g2boojum: yes, i believe that if it was to be enforced it needs to be revised and be very very very clear on what goes and what doesnt
-Mar 08 15:40:52 * windzor_ has quit (Client Quit)
-Mar 08 15:41:14 <Kugelfang> christel: do you think you could write it up?
-Mar 08 15:41:26 <kloeri> I don't want to ban anybody but I do want to be much harder on devs poisoning things consistently and I'm going to file at least one devrel bug in that regard
-Mar 08 15:41:31 <christel> i can certainly give it a try and come up with a proposal
-Mar 08 15:41:31 <Kugelfang> christel: in say, 14 days? SO we can discuss it next month?
-Mar 08 15:41:55 <kloeri> one of the problems (as always) is that it's damn hard to punish devs due to our policies
-Mar 08 15:42:04 * ndansmith (n=ndansmit@c-67-168-234-215.hsd1.or.comcast.net) has joined #gentoo-council
-Mar 08 15:42:27 <kingtaco|work> http://lwn.net/Articles/224615/
-Mar 08 15:42:27 <vapier> is it ?
-Mar 08 15:42:29 <christel> perhaps in light of the effects our current style has on the project it may be worth revisiting whether our current policies are the best ones for the projects future health
-Mar 08 15:42:30 * kloeri gives voice to seemant
-Mar 08 15:42:31 <wolf31o2|mobile> kloeri: then the policies should be modified... and I think we'd support that
-Mar 08 15:42:32 <vapier> or is it a matter of reluctance
-Mar 08 15:42:35 <kingtaco|work> btw, that's how we're represented
-Mar 08 15:42:38 <seemant> thanks kloeri
-Mar 08 15:42:39 <g2boojum> christel: I actually think you want it to be more vague than specific.  "Don't be a jerk."  Please don't define "jerk", or you get a five-page treatise on why the bahavior doesn't really fit the definition.
-Mar 08 15:42:56 <christel> g2boojum: no, dont worry :)
-Mar 08 15:42:57 <kingtaco|work> something for all of us to chew on
-Mar 08 15:43:04 <seemant> I just wanted to add that ubuntu's code of conduct document seems to be frequently cited as a starting point
-Mar 08 15:43:05 <kloeri> policies are currently aiming at being fair to everybody and not too inefficient
-Mar 08 15:43:22 <seemant> but yes, what I wanted to really say, g2boojum said very nicely :)
-Mar 08 15:43:25 <christel> seemant: yeah, thats one that popped to mind as one to look at before writing a proposal, thanks though :)
-Mar 08 15:43:26 <kloeri> which means it's still likely to take at least a month I guess to process any serious devrel complaint
-Mar 08 15:43:37 <seemant> we really need to be careful in adopting document upon document upon document
-Mar 08 15:43:38 <kingtaco|work> kloeri, your devrel process is too long
-Mar 08 15:43:54 <seemant> honestly, a streamlined doc would go far better, imho
-Mar 08 15:43:57 <Kugelfang> kingtaco|work: that's acutally quite pointy (and a bit funny)
-Mar 08 15:43:59 <kingtaco|work> you need a way to reach a decision in hours or days, not weeks
-Mar 08 15:44:10 <kingtaco|work> Kugelfang, pointy?
-Mar 08 15:44:17 <kloeri> kingtaco|work: yes, I'd probably agree with that but it's hard defining a good policy as we still want to be fair I believe
-Mar 08 15:44:27 <Kugelfang> kingtaco|work: sorry, looking it up
-Mar 08 15:44:33 <christel> i think for the most part it can be made pretty simple..
-Mar 08 15:44:38 <seemant> and, as beandog has mentioned -- the forums are fairly moderated but there isn't a standard set of guidelines for doing so
-Mar 08 15:44:44 <christel> respect, common sense and no asshattery :)
-Mar 08 15:44:51 <Kugelfang> kingtaco|work: poignant
-Mar 08 15:45:03 <seemant> christel: essentially, yes
-Mar 08 15:45:03 <Kugelfang> kingtaco|work: or keen
-Mar 08 15:45:37 <kingtaco|work> Kugelfang, being a devrel member through both of ciaranms firings and a bunch of other shit I've had an in depth look at it
-Mar 08 15:45:48 <kingtaco|work> not saying that dmwaters or fmccor ran it any better
-Mar 08 15:45:50 <Kugelfang> kingtaco|work: hu?
-Mar 08 15:46:00 <Kugelfang> kingtaco|work: i was refering to the lwn thing
-Mar 08 15:46:06 <kingtaco|work> Kugelfang, oh
-Mar 08 15:46:14 <kingtaco|work> Kugelfang, yes, it's a fucking shame
-Mar 08 15:46:18 <robbat2> on the side of devrel not having 'teeth' - kloeri mentioned before that infra previously wasn't very responsive to requests to do things (he cited a userrel request to remove user from the ML)
-Mar 08 15:46:18 <kingtaco|work> but it's true
-Mar 08 15:46:26 <Kugelfang> kingtaco|work: i find it humorous, and i guess the author too
-Mar 08 15:46:37 <kloeri> I think the current policy is much better than what we've had before and devrel is doing much more to stop flames also (even though most of our work isn't public)
-Mar 08 15:46:59 <kloeri> there's still room for quite a bit of improvement though imo
-Mar 08 15:47:33 <kloeri> robbat2: that's one of the problems - it's no use having to wait for infra for 2-3 weeks as has happened in the past
-Mar 08 15:47:45 <wolf31o2|mobile> if infra is the holdup, can we get some scripts to allow devrel to do some of these tasks themselves?
-Mar 08 15:47:45 <kingtaco|work> kloeri, tbh, I haven't seen devrel do anything to cut down the flames
-Mar 08 15:47:52 <kingtaco|work> infra isn't the hold up
-Mar 08 15:47:55 <kingtaco|work> I'm infra
-Mar 08 15:48:06 <kingtaco|work> don't pwn it off on infra
-Mar 08 15:48:07 <wolf31o2|mobile> I did prefix that with an "if"
-Mar 08 15:48:08 <wolf31o2|mobile> :P
-Mar 08 15:48:19 <kingtaco|work> it may have been the problem in the past, it's certainly no longer the case
-Mar 08 15:48:27 * windzor_ (n=windzor@82.143.229.82) has joined #gentoo-council
-Mar 08 15:48:37 <kloeri> infra has been the holdup in the past and several people have simply given up on enforcing things if infra is involved because of past experience
-Mar 08 15:48:47 <kingtaco|work> ok
-Mar 08 15:48:47 <robbat2> kingtaco|work, I think it's more of a problem of previous infra people. Ramereth's TODO list is a few miles long
-Mar 08 15:48:58 <christel> yeah, i must admit ive stopped going to infra due to 'no's :x
-Mar 08 15:49:09 <kingtaco|work> here's me as infra telling you we're waiting for devrel to tell us their enforcement stuff
-Mar 08 15:49:19 <christel> but that is as much my fault (for not fighting it) as anyone elses
-Mar 08 15:49:20 <kingtaco|work> understood?
-Mar 08 15:49:36 <kingtaco|work> let whatever happened in the past lie
-Mar 08 15:49:38 <kloeri> I'm still not going to ban people as I think that's a horrible idea :)
-Mar 08 15:49:45 <Kugelfang> any examples?
-Mar 08 15:50:02 <kloeri> but I'm most certainly going to smack down on devs causing problems all the time
-Mar 08 15:50:02 <christel> kingtaco|work: are infra in a position to act on devrels request or will infra still overrule a devrel decision? :)
-Mar 08 15:50:03 <kingtaco|work> kloeri, we're not asking you to ban people
-Mar 08 15:50:23 <kingtaco|work> kloeri, we're telling you to implement something that will cut down on flaming
-Mar 08 15:50:26 <christel> kingtaco|work: i believe marienz has a couple of things he'd like to say
-Mar 08 15:50:31 * windzor has quit (Read error: 110 (Connection timed out))
-Mar 08 15:50:33 * Kugelfang gives voice to marienz
-Mar 08 15:50:42 <marienz> oh, heh.
-Mar 08 15:50:58 <kingtaco|work> christel, infra has never "overruled" devrel, knock it off.  we've told you that some thing are simply infeasable
-Mar 08 15:51:02 <christel> i have a question, if we are to start enforcing etiquette policy, i think we may want to ensure we have one which also cover users
-Mar 08 15:51:07 <marienz> from a userrel pov instead of a devrel pov: we filed at least one bug against infra that wasn't not acted on because they had no time, but because they thought it was a bad idea.
-Mar 08 15:51:12 <kloeri> kingtaco|work: one possible idea that came up was to delay messages of people contributing to flames instead of banning them but I have no idea if that's possible at all
-Mar 08 15:51:23 <christel> kingtaco|work: actually, i believe it was more 'we think its stupid' :)
-Mar 08 15:51:38 <kingtaco|work> kloeri, I think wolf31o2 can answer that, he's been helping with the ML stuff
-Mar 08 15:51:48 <Kugelfang> marienz: bug #?
-Mar 08 15:51:52 <seemant> christel: just for gentoofication of guidelines, the forums people use these (thanks tomk): https://forums.gentoo.org/viewtopic-t-525.html and https://forums.gentoo.org/viewtopic-t-120351.html
-Mar 08 15:51:54 <marienz> I'm not sure if that has happened to devrel requests or not
-Mar 08 15:52:04 <marienz> Kugelfang: the dev-help ml one, let me look it up...
-Mar 08 15:52:10 <christel> thank you seemant
-Mar 08 15:52:12 <kingtaco|work> christel, what did I just say about letting the past lie?
-Mar 08 15:52:14 <wolf31o2|mobile> I don't think it is
-Mar 08 15:52:27 <marienz> Kugelfang: https://bugs.gentoo.org/show_bug.cgi?id=130886
-Mar 08 15:52:28 <christel> kingtaco|work: i was just correcting you ;)
-Mar 08 15:52:50 <christel> (and im still waiting for you to answer my question)
-Mar 08 15:53:11 <kingtaco|work> which question? infra overruling devrel?
-Mar 08 15:53:15 <christel> kingtaco|work: yeah
-Mar 08 15:53:17 <kingtaco|work> my answer was that we don't
-Mar 08 15:53:19 <seemant> christel: was that from this current generation of infra people or the prior? (just curious)
-Mar 08 15:53:29 <christel> kingtaco|work: excellent, thank you
-Mar 08 15:53:29 <kingtaco|work> we tell you if your requested action is infeasable
-Mar 08 15:53:36 <marienz> (can't tell you if devrel hit this kind of thing too, but figured I'd mention it)
-Mar 08 15:53:39 <christel> seemant: i wasnt aware they had changed :)
-Mar 08 15:53:45 <seemant> (just noting that TNG is palpably different)
-Mar 08 15:53:54 <kingtaco|work> christel, we can't squeeze blood from stone
-Mar 08 15:53:58 <christel> (i know theres a couple of additions to the team, which perhaps makes change for the better)
-Mar 08 15:54:18 <g2boojum> christel: Assume that if you didn't deal w/ kingtaco|work, it's changed.
-Mar 08 15:54:32 <christel> kingtaco|work: im not trying to pick on you, im just wanting to know that if we need to we can
-Mar 08 15:54:44 <seemant> ..pick on them?
-Mar 08 15:54:46 <kingtaco|work> but if you make a request as devrel to infra that we can do, IMO infra is obligated to attempt to do it
-Mar 08 15:54:47 <christel> because that well, makes a fair bit of difference to how devrel can work with issues
-Mar 08 15:55:02 <christel> and it sounds like that is the case, for which i am glad to have clarification :)
-Mar 08 15:55:28 <kingtaco|work> so
-Mar 08 15:55:55 <vapier> what are we looking for to get started then
-Mar 08 15:55:59 <kingtaco|work> do we need to vote that devrel needs to take a more active role in stopping flamewars and whatnot?
-Mar 08 15:56:07 <kingtaco|work> oh
-Mar 08 15:56:09 <kingtaco|work> one last thing
-Mar 08 15:56:11 <wolf31o2|mobile> correct, infra should be doing what devrel recommends, except in cases where it is infeasible
-Mar 08 15:56:23 <kingtaco|work> the "how do we deal with users" question someone asked
-Mar 08 15:56:27 <kingtaco|work> it's quite simple
-Mar 08 15:56:29 <christel> i will wite a proposal for a more clear etiquette policy, and i will aim to have it ready for review in approximately 2 weeks from today
-Mar 08 15:56:36 <kingtaco|work> we don't accept work they contributed to
-Mar 08 15:56:40 <Kugelfang> christel: thx
-Mar 08 15:56:40 <kingtaco|work> even if that hurts us
-Mar 08 15:56:46 <wolf31o2|mobile> I think kloeri agreeing to it would be enough, since he'd be the one pushing it within devrel
-Mar 08 15:56:46 <vapier> while that would be the ultimate goal, i dont want devrel suddenly stomping on everyone's nuts
-Mar 08 15:56:47 <christel> would you prefer me to send it to -dev or -core for peer-review prior to next council meeting?
-Mar 08 15:56:58 <vapier> so a more gentle approach should be implied
-Mar 08 15:56:58 <wolf31o2|mobile> christel: -dev
-Mar 08 15:57:05 <kingtaco|work> vapier, the council explicily monitors devrel
-Mar 08 15:57:13 <kingtaco|work> devrel is responsible to the council
-Mar 08 15:57:14 <christel> vapier: no, i think we'd be careful not to go mad and start chuck norrising all over the place
-Mar 08 15:57:18 <christel> wolf31o2|mobile: ok :)
-Mar 08 15:57:24 <kingtaco|work> so if they fuck up we can stop them
-Mar 08 15:57:28 <wolf31o2|mobile> and the council is the "escalation" point for devrel... not that anybody's ever come to us... heh
-Mar 08 15:57:39 <Kugelfang> wolf31o2|mobile: we can still hide
-Mar 08 15:57:43 <wolf31o2|mobile> heh
-Mar 08 15:57:43 <Kugelfang> wolf31o2|mobile: ;-)
-Mar 08 15:57:54 <vapier> kingtaco|laptop: i'm not worried about oversight, i'm worried about initial reaction
-Mar 08 15:58:06 <christel> wolf31o2|mobile: for the most part things doesnt even come to us (not per the policy type route anyhow)
-Mar 08 15:58:13 <kloeri> heh
-Mar 08 15:58:13 <wolf31o2|mobile> yeah
-Mar 08 15:58:23 <kingtaco|work> vapier, ok, then lets vote to "authorize" devrel to form a plan and then enact it to cut down on the flamwars
-Mar 08 15:58:33 <wolf31o2|mobile> that sounds good
-Mar 08 15:58:35 <christel> vapier: i believe it needs to be a slow and transparent process to put into place rather than a overnight change
-Mar 08 15:58:45 <christel> transparency being important i think
-Mar 08 15:58:54 <vapier> that wording sounds too specific and doesnt address the underlying issue
-Mar 08 15:59:07 <kingtaco|work> ok, vote: devrel is charges with the task of planning and implementing anti flamewar measures
-Mar 08 15:59:09 <vapier> common courtesy to thy fellow developer
-Mar 08 15:59:19 <kingtaco|work> s/charges/charged
-Mar 08 15:59:25 <kingtaco|work> I vote yes
-Mar 08 15:59:26 <wolf31o2|mobile> right... it isn't to cut down on flames, it's to cut down on the overall bad attitudes and actions
-Mar 08 15:59:29 <Kugelfang> i like vapier's wording more
-Mar 08 15:59:32 <wolf31o2|mobile> yes
-Mar 08 15:59:34 <kloeri> devrel is doing a lot of conflict resolution type stuff before things even manages to blow up but a lot of it starts out by devs and/or users contacting me in private using /query and it's usually much easier handling these things in private so that's why you don't generally see a lot of devrel action
-Mar 08 15:59:37 <vapier> if that's seriously what the vote is worded, then i vote no
-Mar 08 15:59:57 <kingtaco|work> ok how do you want to word it?
-Mar 08 16:00:21 <wolf31o2|mobile> s/anti flamewar/common courtesy/ ?
-Mar 08 16:00:32 <kingtaco|work> netiquette?
-Mar 08 16:00:35 <wolf31o2|mobile> sure
-Mar 08 16:00:58 <kingtaco|work> vapier, ?
-Mar 08 16:01:15 <kloeri> I don't think we can force people to follow netiquette in general but we can do more to smack devs up when they're constantly being a pain in the ass
-Mar 08 16:01:44 <kingtaco|work> kloeri, that's up to devrel and for the most part outside of the scope of this meeting
-Mar 08 16:02:00 <kingtaco|work> vapier, ......
-Mar 08 16:02:06 <vapier> did we end up with netique from last time ?
-Mar 08 16:02:06 * musikc has quit (Client Quit)
-Mar 08 16:02:09 <kingtaco|work> don't make me call your mom
-Mar 08 16:02:11 <wolf31o2|mobile> but yes, I agree, kloeri
-Mar 08 16:02:17 <vapier> cant seem to find it in the devrel pages
-Mar 08 16:02:21 <kloeri> one of the problems with the current flames is that quite a few devs think they're doing just fine where as others (me included) think they're just adding to the flames
-Mar 08 16:02:27 <kingtaco|work> vapier, we can call it netiquette
-Mar 08 16:02:43 <wolf31o2|mobile> I have to leave in ~30 ...
-Mar 08 16:02:48 <vapier> kingtaco|work: i'm asking if we have an existing social policy on being nice
-Mar 08 16:02:50 <kloeri> there's an etiquette policy part in the developers handbook
-Mar 08 16:02:54 <kingtaco|work> vapier, sort of
-Mar 08 16:03:02 <vapier> URL ?
-Mar 08 16:03:03 <kingtaco|work> I think it's outdated and incomplete
-Mar 08 16:03:17 <kloeri> covering irc, forums and mail but needing some updates and/or a rewrite I guess
-Mar 08 16:03:22 <g2boojum> vapier: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2
-Mar 08 16:03:23 <kloeri> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2
-Mar 08 16:03:23 <vapier> then we charge devrel with updating it
-Mar 08 16:03:31 <vapier> which christel and kloeri seem to want to do
-Mar 08 16:03:43 <kingtaco|work> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2
-Mar 08 16:03:45 <vapier> and as an addon, if we're to lead by example, we need to start doing so
-Mar 08 16:03:46 <kloeri> yes, I'd be quite happy to work on that
-Mar 08 16:03:51 <wolf31o2|mobile> yeah
-Mar 08 16:03:56 <vapier> aka charge ourselves to rise above
-Mar 08 16:03:57 <kingtaco|work> vapier, yes
-Mar 08 16:04:10 <wolf31o2|mobile> I've been trying to shut up on threads, since I've definitely been a part of the problem in the past
-Mar 08 16:04:11 <Kugelfang> vapier: that will be hard for you, won't it? ;-)
-Mar 08 16:04:22 <vapier> i'm sure you can find plenty of examples of me being petty 
-Mar 08 16:04:27 <kingtaco|work> ok, vote: charge devrel to update it's netiquette policy and start enforcing it
-Mar 08 16:04:31 <kingtaco|work> yes
-Mar 08 16:04:33 <wolf31o2|mobile> yes
-Mar 08 16:04:40 <UberL> yes
-Mar 08 16:04:42 <Kugelfang> vapier: *cuddle*
-Mar 08 16:04:44 <vapier> ... and for us to do better by example ;p
-Mar 08 16:04:48 <Kugelfang> yes
-Mar 08 16:04:51 <kloeri> enforce it how?
-Mar 08 16:04:55 <christel> i plead guilty and accept the charge :)
-Mar 08 16:04:57 <UberL> suspension?
-Mar 08 16:05:02 <kingtaco|work> kloeri, that's up to you
-Mar 08 16:05:05 <christel> kloeri: in what means we see necessary i'd say
-Mar 08 16:05:06 <kloeri> I'm all for enforcing it if I knew how
-Mar 08 16:05:08 <kingtaco|work> infra is willing to work with you
-Mar 08 16:05:15 <wolf31o2|mobile> kloeri: depends on what you do w/ the policy... we have faith in you... I'd say suspension
-Mar 08 16:05:19 <kingtaco|work> kloeri, you could also put out a RFC
-Mar 08 16:05:22 <christel> im still thinking warn warn suspend/time-out is doable
-Mar 08 16:05:32 <kloeri> suspension can only be applied to devs though
-Mar 08 16:05:37 <kingtaco|work> personally I like christels idea
-Mar 08 16:05:43 <kingtaco|work> kloeri, non devs is easy
-Mar 08 16:05:44 <kloeri> which I'm quite happy to do
-Mar 08 16:05:51 <Kugelfang> kloeri: non-devs is the hardest part
-Mar 08 16:05:58 <kingtaco|work> if they are in violation, don't accept any contributions from them
-Mar 08 16:05:59 <Kugelfang> sorry, kingtaco|work ^^^
-Mar 08 16:06:01 <vapier> include it as part of the revamp and to get input on
-Mar 08 16:06:04 <kloeri> heh, glad you agree :)
-Mar 08 16:06:06 <Kugelfang> too many ^k.* in here
-Mar 08 16:06:12 <kingtaco|work> yeah
-Mar 08 16:06:16 <wolf31o2|mobile> right... but remember that in *all* of these flamewars/problems, devs are usually involved... it's never really a case of two users going at it, that I've ever seen
-Mar 08 16:06:24 <Kugelfang> vote: renamed kingtaco to tacoking
-Mar 08 16:06:24 <kingtaco|work> ok, I think this is settled for now
-Mar 08 16:06:26 <kloeri> wolf31o2|mobile: agreed
-Mar 08 16:06:27 <Kugelfang> -d
-Mar 08 16:06:30 * kingtaco|work is now known as tacoking
-Mar 08 16:06:46 * tacoking is now known as kingtaco|work
-Mar 08 16:06:57 <vapier> so we're in agreement on that final wording + addon ?
-Mar 08 16:06:57 <kingtaco|work> alreadt took
-Mar 08 16:07:01 <kingtaco|work> yes
-Mar 08 16:07:20 <kingtaco|work> ok, next item on agenda
-Mar 08 16:07:27 <kloeri> ok, lets see if we can revamp etiquette policy and hopefully come up with some reasonable way of enforcing it
-Mar 08 16:07:28 <kingtaco|work> I'll hold my hardware stuff til last
-Mar 08 16:07:37 <kingtaco|work> as we can deal with it next month if needed
-Mar 08 16:07:57 <kingtaco|work> wolf31o2, "power the council should have"
-Mar 08 16:08:11 * kingtaco|work removes voice from christel marienz seemant
-Mar 08 16:08:13 * YosWinK (n=yoswink@gentoo/developer/yoswink) has joined #gentoo-council
-Mar 08 16:08:29 <Kugelfang> back in a min
-Mar 08 16:08:40 <kingtaco|work> wolf31o2|mobile, you got the floor
-Mar 08 16:09:07 <wolf31o2|mobile> yeah... earlier I suggested a concept where each member of the Council is able to make decisions as if they were the sole "leader" of Gentoo... we would need to come up with a couple exceptions, new GLEPs come to mind... but basically, each council member can act alone...
-Mar 08 16:09:16 <wolf31o2|mobile> and the council as a whole is the appeals board for anything
-Mar 08 16:10:27 <wolf31o2|mobile> I think it would keep us from burning out a single leader, yet still give us the ability to make fast decisions without them having to go through committee
-Mar 08 16:10:39 <Kugelfang> which can be revoked
-Mar 08 16:10:46 <Kugelfang> i favour that
-Mar 08 16:11:02 <UberL> should only be for things that can be revoked
-Mar 08 16:11:28 <robbat2> i don't like a single person being able to do that, but I wouldn't object to having two council members that agree on it
-Mar 08 16:11:33 <robbat2> also adds a slight sanity check
-Mar 08 16:11:41 <Kugelfang> less bureaucracy is a good thing
-Mar 08 16:11:41 <wolf31o2|mobile> I'm fine with it being two
-Mar 08 16:11:45 <kingtaco|work> I like having 2 as well
-Mar 08 16:11:47 * The_Paya has quit (Read error: 110 (Connection timed out))
-Mar 08 16:11:49 <wolf31o2|mobile> main point being it allows for much quicker decisions
-Mar 08 16:11:50 <Kugelfang> nod
-Mar 08 16:11:59 <kloeri> two people sounds good
-Mar 08 16:12:22 <vapier> and the requirement that any such decisions be noted at the next meeting
-Mar 08 16:12:29 <Kugelfang> it's similar to the romans' consuls
-Mar 08 16:12:38 <kingtaco|work> documented immedatly to council@ and next meeting
-Mar 08 16:12:39 <kloeri> vapier: agreed
-Mar 08 16:12:49 <wolf31o2|mobile> agreed
-Mar 08 16:12:52 <kingtaco|work> if you invoke uber powers, you should document it as soon as reasonable
-Mar 08 16:13:05 <vapier> do we have a council mailing list ?
-Mar 08 16:13:07 * UberL flexes his UberPowers
-Mar 08 16:13:20 <robbat2> there was one that is gathering dust somewhere
-Mar 08 16:13:23 <Kugelfang> vote: 2 council member my decide on their own w/o council in between meetings. decission need to be mailed to council@g.o immediately and can be revoked by the whole council
-Mar 08 16:13:23 <vapier> then immediate action is to drop a line on the council mailing list and to bring it up at next meeting
-Mar 08 16:13:31 <Kugelfang> may
-Mar 08 16:13:35 * UberL nods
-Mar 08 16:13:37 <vapier> i'd prefer we use the alias less
-Mar 08 16:13:40 <kingtaco|work> vapier, I think we do
-Mar 08 16:13:45 <vapier> maybe even subscribe it to the mailing list ;)
-Mar 08 16:13:47 <kloeri> list is better imo
-Mar 08 16:13:49 <kingtaco|work> it may have been disbanded
-Mar 08 16:13:53 <vapier> it hasnt
-Mar 08 16:13:55 <kingtaco|work> we could use list
-Mar 08 16:14:00 <kingtaco|work> I have no preference
-Mar 08 16:14:22 <wolf31o2|mobile> list is fine
-Mar 08 16:14:23 <Kugelfang> list is public... so list instead of alias
-Mar 08 16:14:29 <robbat2> can we keep the alias for the private bits? (eg sharing our contact information when we started)
-Mar 08 16:14:29 <wolf31o2|mobile> I'd have to subscribe to it
-Mar 08 16:14:29 <kingtaco|work> Kugelfang, only chair may call the vote :p
-Mar 08 16:14:40 <wolf31o2|mobile> right, alias for private, list for everything else
-Mar 08 16:14:40 <Kugelfang> kingtaco|work: do we have one?
-Mar 08 16:14:47 <kingtaco|work> Kugelfang, I'm chair this month
-Mar 08 16:14:50 <Kugelfang> kingtaco|work: haha
-Mar 08 16:14:57 <kingtaco|work> it's whomever leads the meeting
-Mar 08 16:14:59 <vapier> so stop talking and ask for it
-Mar 08 16:15:01 * robbat2 sits on kingtaco|work 
-Mar 08 16:15:02 <kingtaco|work> ok
-Mar 08 16:15:10 <robbat2> he said he was the chair!
-Mar 08 16:15:12 <Kugelfang> kingtaco|work: primus inter pares, hm?
-Mar 08 16:15:27 <kingtaco|work> vote: 2 council members may act with executive authority with the understanding that they must document immediatlly to council ML
-Mar 08 16:15:36 <kingtaco|work> Kugelfang, I don't know latin :)
-Mar 08 16:15:53 <wolf31o2|mobile> ... and appeals go to the council as a whole
-Mar 08 16:15:55 <Kugelfang> kingtaco|work: first among equals
-Mar 08 16:15:58 <robbat2> it means "first among equals"
-Mar 08 16:15:58 <kingtaco|work> ah
-Mar 08 16:16:12 <kingtaco|work> Kugelfang, you can be it next month if you like
-Mar 08 16:16:17 <kingtaco|work> I just like leading meetings
-Mar 08 16:16:18 <Kugelfang> no thanks
-Mar 08 16:16:44 <wolf31o2|mobile> so, vote on what taco said + addendum ?
-Mar 08 16:16:44 * The_Paya (i=the_paya@gentoo/developer/thepaya) has joined #gentoo-council
-Mar 08 16:16:53 <Kugelfang> yes
-Mar 08 16:16:55 <kloeri> yes
-Mar 08 16:16:56 <kingtaco|work> yes
-Mar 08 16:16:58 <UberL> yes
-Mar 08 16:17:00 <robbat2> yes
-Mar 08 16:17:07 <wolf31o2|mobile> yes
-Mar 08 16:17:16 <vapier> yes
-Mar 08 16:17:22 <Kugelfang> nice
-Mar 08 16:17:24 <kingtaco|work> ok
-Mar 08 16:17:26 <wolf31o2|mobile> very
-Mar 08 16:17:26 <kingtaco|work> passed
-Mar 08 16:17:34 <kingtaco|work> oh, one more thing real quick
-Mar 08 16:17:41 <kingtaco|work> the tr1 virtuals from last month
-Mar 08 16:17:51 <wolf31o2|mobile> ooh... almost forgot about that one
-Mar 08 16:18:13 <kingtaco|work> and maybe one more thing after that
-Mar 08 16:18:19 <kingtaco|work> anyone have anything on the tr1 stuff?
-Mar 08 16:18:29 <kingtaco|work> I'll call the same vote I did last month
-Mar 08 16:18:57 <Kugelfang> that was? (I wasn't there if you recall)
-Mar 08 16:19:00 <kingtaco|work> vote: have tr1-{memory,pointer,foo,bar,blah} virtuals until there is a sane implementation
-Mar 08 16:19:23 <kloeri> I still think the virtuals are the best solution currently
-Mar 08 16:19:30 <kingtaco|work> as the virtuals are clearly a work around for 2 sucky ijmplementations
-Mar 08 16:19:56 <kingtaco|work> I vote yes(I still wish we could use a eclass)
-Mar 08 16:20:14 <wolf31o2|mobile> yes
-Mar 08 16:20:21 <kloeri> yes
-Mar 08 16:20:23 <robbat2> yes
-Mar 08 16:20:24 <vapier> yes
-Mar 08 16:20:32 <kingtaco|work> Kugelfang, UberL
-Mar 08 16:20:56 <UberL> i don't have an opinion on that sorry
-Mar 08 16:20:57 * aballier (n=alexis@dra13-1-82-232-126-136.fbx.proxad.net) has joined #gentoo-council
-Mar 08 16:21:12 <Kugelfang> hrm
-Mar 08 16:21:25 <kingtaco|work> well, we already have a majority
-Mar 08 16:21:40 <vapier> why dont you just tell them their opinion doesnt matter
-Mar 08 16:21:42 <kingtaco|work> so you can exclude yourself if you like
-Mar 08 16:21:46 <Kugelfang> yes
-Mar 08 16:21:53 <kingtaco|work> ok, accepted
-Mar 08 16:22:21 <kingtaco|work> Kugelfang, since its you paludis type who want the virtuals, you're in charge of getting them setup in a way that doesn't piss off everyone
-Mar 08 16:22:25 <Kugelfang> i was reading the february log... wanted to know why this has been postponed
-Mar 08 16:22:33 <Kugelfang> kingtaco|work: haha
-Mar 08 16:22:38 <Kugelfang> kingtaco|work: will do
-Mar 08 16:22:42 <kingtaco|work> so flameeyes could find out how many packages would use them
-Mar 08 16:22:52 <Kugelfang> ah
-Mar 08 16:23:00 <kingtaco|work> but that no longer applies
-Mar 08 16:23:08 <kingtaco|work> ok, 2 more things
-Mar 08 16:23:23 <kingtaco|work> it was pointed out to me that people want us to discuss splitting of mailing lists
-Mar 08 16:23:35 <kingtaco|work> the id is  <45EC8028.4010004@gentoo.org>
-Mar 08 16:23:54 <kingtaco|work> we should probably kick it to next month as it relates to the devrel stuff from before
-Mar 08 16:23:59 <wolf31o2|mobile> agreed
-Mar 08 16:24:06 <vapier> splitting ?
-Mar 08 16:24:08 <wolf31o2|mobile> (and I'm running out of time and kinda brought up the subject)
-Mar 08 16:24:13 <kingtaco|work> splitting
-Mar 08 16:24:14 <Kugelfang> i think we should do it right now
-Mar 08 16:24:17 <wolf31o2|mobile> having an announce list
-Mar 08 16:24:23 <kingtaco|work> gentoo-dev-announce and whatnot
-Mar 08 16:24:31 <kingtaco|work> gentoo-dev-user
-Mar 08 16:24:34 <kingtaco|work> stuff like that
-Mar 08 16:24:40 <vapier> sounds redundant
-Mar 08 16:24:48 <vapier> we have an announce and a user list
-Mar 08 16:24:55 <kingtaco|work> yes
-Mar 08 16:25:01 <kingtaco|work> lets kick it til next month
-Mar 08 16:25:04 <robbat2> ok
-Mar 08 16:25:08 <Kugelfang> hrm
-Mar 08 16:25:12 <kingtaco|work> kloeri, you could look at that discussion when doing your devrel stuff
-Mar 08 16:25:14 <robbat2> so that leaves the gentoo hardware item that kingtaco had?
-Mar 08 16:25:18 <kloeri> sure
-Mar 08 16:25:18 <kingtaco|work> yes
-Mar 08 16:25:27 <kingtaco|work> do we have time to discuss that now?
-Mar 08 16:25:32 <Kugelfang> sure
-Mar 08 16:25:38 <kingtaco|work> anyone gotta leave before 15 minutes?
-Mar 08 16:25:41 <wolf31o2|mobile> me
-Mar 08 16:25:46 <wolf31o2|mobile> but you know my vote on it
-Mar 08 16:25:52 <wolf31o2|mobile> we already discussed it and I'm for it
-Mar 08 16:25:52 <wolf31o2|mobile> heh
-Mar 08 16:25:56 <kingtaco|work> heh
-Mar 08 16:26:11 <kingtaco|work> will you others accept wolfs abscentee vote of yes?
-Mar 08 16:26:48 <Kugelfang> that only matters if we have a draw, but yes
-Mar 08 16:27:00 <kingtaco|work> anyone who won't?
-Mar 08 16:27:09 <kingtaco|work> speak now or hold your tacos
-Mar 08 16:27:10 <kloeri> yes, if he already discussed it
-Mar 08 16:27:15 <kingtaco|work> we did
-Mar 08 16:27:16 <kingtaco|work> fosdem :)
-Mar 08 16:27:21 <kingtaco|work> and then amsterdam
-Mar 08 16:27:42 <UberL> i am un-aware of the debate
-Mar 08 16:27:49 * kingtaco|work pokes UberL vapier robbat2 
-Mar 08 16:28:02 <robbat2> yes i'll accept an absentee vote of yes by wolf31o2, but I want to know the details myself
-Mar 08 16:28:12 <vapier> that's fine
-Mar 08 16:28:16 <kingtaco|work> UberL, it hasn't happened yet, wolf has to leave so our choices are to punt it til later or accept his vote of yes
-Mar 08 16:28:21 <kingtaco|work> ok
-Mar 08 16:28:25 <kingtaco|work> lets discuss
-Mar 08 16:28:29 <UberL> i will accept his vote of yes
-Mar 08 16:28:47 <kingtaco|work> so, people have been clamoring for the council to give some direction
-Mar 08 16:28:51 <kingtaco|work> to gentoo
-Mar 08 16:29:05 <kingtaco|work> this is where my 2 projects come in
-Mar 08 16:29:31 <wolf31o2|mobile> I've got a couple projects myself, but I'll hold them off until next time so I can formulate them a bit better
-Mar 08 16:30:02 <kingtaco|work> what I'd like to do is the following: gentoo branded hardware and gentoo certified hardware
-Mar 08 16:30:12 <kingtaco|work> they are similar, but slightly different
-Mar 08 16:30:25 <kingtaco|work> the rational is the same for both, but not the implementation
-Mar 08 16:30:41 * avenj (n=avenj@gentoo/developer/avenj) has left #gentoo-council
-Mar 08 16:30:45 <kingtaco|work> so lets talk about certified hardware first
-Mar 08 16:31:21 <kingtaco|work> it would benefit gentoo greatly if OEMs gave an option to consumers to buy their product with gentoo preinstalled
-Mar 08 16:31:54 <kingtaco|work> not only would we probably receive some sort of revenue stream(a item for the trustees) but it would help get our name out there
-Mar 08 16:32:14 <kingtaco|work> it is also a stepping stone to "enterprise" gentoo
-Mar 08 16:32:23 <kingtaco|work> or perhaps the result of that
-Mar 08 16:32:28 <UberL> what would the revenue stream be used for?
-Mar 08 16:32:35 <kingtaco|work> thats up to the trustees
-Mar 08 16:32:38 <Kugelfang> up to the trustees
-Mar 08 16:32:52 <kingtaco|work> I'd like to think it'd be used for furthering gentoo and linux development
-Mar 08 16:33:09 <kingtaco|work> my goal is to get gentoo on more boxes
-Mar 08 16:33:17 <kingtaco|work> not to make money
-Mar 08 16:33:31 <robbat2> question here, as I see it already, there is nothing that stops anybody from shipping a box with Gentoo preinstalled
-Mar 08 16:33:43 <kingtaco|work> nothing at all except they don't
-Mar 08 16:33:52 <kingtaco|work> why do they ship redhat, suse, and ubuntu?
-Mar 08 16:34:02 <kingtaco|work> I've even seen debian on the list beofre
-Mar 08 16:34:24 <UberL> kingtaco|work: probably because you can buy 24x7 support contracts for them?>
-Mar 08 16:34:26 <vapier> i think it'd be the other way around ... binary/enterprise Gentoo first, then shipping with Gentoo ...
-Mar 08 16:34:39 <Kugelfang> i agree with UberL and vapier
-Mar 08 16:34:56 <kingtaco|work> UberL, there are groups of developers offering that
-Mar 08 16:34:58 <wolf31o2|mobile> later guys
-Mar 08 16:35:03 <kingtaco|work> later wolf31o2
-Mar 08 16:35:19 <Kugelfang> especially as (even portage devs say) current binary package support is not bug free
-Mar 08 16:35:26 <kingtaco|work> I see a point in what vapier says
-Mar 08 16:35:36 <kingtaco|work> Kugelfang, all the more reason to put eapi-0 behind us
-Mar 08 16:35:46 <Kugelfang> nothing to do with EAPI=ß
-Mar 08 16:35:54 * wolf31o2|mobile has quit (Remote closed the connection)
-Mar 08 16:36:05 <kingtaco|work> anyway
-Mar 08 16:36:48 <kingtaco|work> for any of this to happen we have to start cleaning up our tree
-Mar 08 16:36:54 <kingtaco|work> specificly stable
-Mar 08 16:37:12 <kingtaco|work> at the same time, we need to make sure we don't become debian
-Mar 08 16:37:55 <kingtaco|work> I think many peoples focus here has been getting stuff into the tree as quickly as possible and then not doing a very good job maintaining said packages
-Mar 08 16:38:00 <kingtaco|work> I'd like that to change
-Mar 08 16:38:57 <kingtaco|work> so what I'd like to see gentoo do is stop focusing on putting every package under the sun into the tree and move towards security and stability in the main tree
-Mar 08 16:39:04 <kingtaco|work> punt everything else to overlays
-Mar 08 16:39:26 <kingtaco|work> I see that as the first step towards convincing OEMs to ship our distro
-Mar 08 16:39:46 <robbat2> sorry, had work IRQ for a moment. there are some small vendors providing Gentoo out-of-the-box (and support for it), but basically they all have some connection to Gentoo already
-Mar 08 16:39:57 <kingtaco|work> right
-Mar 08 16:39:59 <UberL> i would rather the packages improved than punted. I dislike overlays
-Mar 08 16:40:02 <kingtaco|work> I'm talking larger ones
-Mar 08 16:40:04 <kloeri> I think that's a good idea but don't see how you can convince the developers of that
-Mar 08 16:40:04 <kingtaco|work> like dell
-Mar 08 16:40:13 <kingtaco|work> dell is looking for distros to certify their hardware
-Mar 08 16:40:25 <kingtaco|work> kloeri, I'll just ask devrel to fire them
-Mar 08 16:40:29 <vapier> i dont think it'll matter so long as there are no binaries shipping
-Mar 08 16:40:32 <kloeri> heh
-Mar 08 16:40:58 <kingtaco|work> kloeri, I'm serious, people want a direction and this is one.
-Mar 08 16:40:59 <Kugelfang> overlays have a weak point
-Mar 08 16:41:15 <Kugelfang> you can't properly defined deps on other overlays/repositories
-Mar 08 16:41:18 <Kugelfang> -d
-Mar 08 16:41:21 <kingtaco|work> eapi=1
-Mar 08 16:41:25 <robbat2> i'm against punting stuff, because I see a LOT of stuff in the tree has been added because somebody had a short-time interest in a package
-Mar 08 16:41:34 <Kugelfang> kingtaco|work: dude, EAPI is not a solution to all problems
-Mar 08 16:41:45 <Kugelfang> kingtaco|work: remember genone's talk at fosdem?
-Mar 08 16:41:50 <robbat2> even I'm guilty of that
-Mar 08 16:41:53 <kingtaco|work> robbat2, punt it to an overlay or other divided section
-Mar 08 16:42:18 * YosWinK has quit (Connection reset by peer)
-Mar 08 16:42:19 <kingtaco|work> Kugelfang, ok, redefine the entire package manager that we use
-Mar 08 16:42:19 <Kugelfang> kingtaco|work: you have to move whole trees of packages into overlays
-Mar 08 16:42:21 * yoshi_ (n=yoswink@177.Red-83-60-94.dynamicIP.rima-tde.net) has joined #gentoo-council
-Mar 08 16:42:25 <kingtaco|work> I don't care what you call it
-Mar 08 16:42:35 <Kugelfang> i don't call it anything
-Mar 08 16:42:38 <kloeri> kingtaco|work: I'd love to see developers pay more attention to stable packages, I'm just not sure how to convince others of it
-Mar 08 16:42:42 <Kugelfang> EAPI is on ebuild level
-Mar 08 16:42:44 <kingtaco|work> though I disagree that we can't change depend syntax with a eapi change
-Mar 08 16:42:58 <Kugelfang> kingtaco|work: ok, example:
-Mar 08 16:43:23 <Kugelfang> kingtaco|work: you use the proposed "::repository" suffix for deps as proposed by EAPI=1-foo
-Mar 08 16:43:25 <kingtaco|work> kloeri, what I'd like to do is form a team of gentoo developers to investigate and document what changes should be made
-Mar 08 16:43:56 <kingtaco|work> s/should/will
-Mar 08 16:43:57 <Kugelfang> kingtaco|work: so libbar has DEPEND="libfoo::gentoo-overlay-a"
-Mar 08 16:43:59 <kloeri> yup, we'd probably need a dedicated "stable" team I guess
-Mar 08 16:43:59 <kingtaco|work> this is direction
-Mar 08 16:44:15 <kingtaco|work> all developers would follow the direction
-Mar 08 16:44:22 <kingtaco|work> it most certainly needs a glep
-Mar 08 16:44:23 <Kugelfang> kingtaco|work: that will disabled you from using that package from any other overlays
-Mar 08 16:44:51 <Kugelfang> kingtaco|work: do you see that this is no ebuild level problem but a repository level problem?
-Mar 08 16:45:02 <robbat2> then there's breakage when a package moves from an overlay to the main tree?
-Mar 08 16:45:03 * hparker has quit (Client Quit)
-Mar 08 16:45:04 <kingtaco|work> Kugelfang, that's one implementation, yes.  I don't have an answer for you off the top of my head, though I've had many thoughts on how to partition the tree
-Mar 08 16:45:21 <kingtaco|work> one is simply to define tree priority
-Mar 08 16:45:33 <kingtaco|work> so try to resolve in a first, then in b, then c, and so on
-Mar 08 16:45:44 <Kugelfang> that doesn't hit the point
-Mar 08 16:46:29 <Kugelfang> how do you tell people that "if you want packages from overlay B, you need to sync overlays A, too"?
-Mar 08 16:46:31 <kingtaco|work> I'm clearly missing your point, but it doesn't matter, we're not here to talk about those details, we're talking about if this is a direction we want to set for gentoo
-Mar 08 16:46:46 <Kugelfang> that's not solvable by EAPI imho
-Mar 08 16:46:54 <kingtaco|work> oppinion noted
-Mar 08 16:47:01 <Kugelfang> and i'm on line with genone here i think, as he had that in his talk at fosdem
-Mar 08 16:47:17 <kingtaco|work> so again I ask you, is this a direction we want to set for gentoo?\
-Mar 08 16:47:23 <kingtaco|work> after glep and all that
-Mar 08 16:47:28 <kingtaco|work> or am I wasteing my time
-Mar 08 16:47:42 <Kugelfang> tree partioning? i doubt
-Mar 08 16:47:47 <kingtaco|work> dude
-Mar 08 16:47:51 <kingtaco|work> get off that already
-Mar 08 16:47:52 <robbat2> i'd agree that picking stuff that is for more stable yes, but not the means you're going about it
-Mar 08 16:48:05 <kingtaco|work> lemme define it in a sentence
-Mar 08 16:48:09 <Kugelfang> please
-Mar 08 16:48:26 <kingtaco|work> vote: gentoo's direction is security, stability, and then everything else
-Mar 08 16:48:44 <Kugelfang> i'd say "stability, security and then everything else", in that order
-Mar 08 16:48:46 * pilla (n=pilla@gentoo/developer/pilla) has joined #gentoo-council
-Mar 08 16:48:52 <robbat2> no
-Mar 08 16:49:08 <Kugelfang> what is a secure but broken system good for?
-Mar 08 16:49:12 <kingtaco|work> no to what, the vote or danny?
-Mar 08 16:49:17 <robbat2> stability shouldn't block progress. temporarily delay maybe.
-Mar 08 16:49:19 <kingtaco|work> Kugelfang, a doorstop
-Mar 08 16:49:23 <kingtaco|work> :p
-Mar 08 16:49:30 <robbat2> KingTaco, that's a no vote to your statement
-Mar 08 16:49:53 <kingtaco|work> ok
-Mar 08 16:50:03 <robbat2> else we risk the debian stability issue of everything getting slow
-Mar 08 16:50:04 <Kugelfang> kingtaco|work: *g*
-Mar 08 16:50:30 <kingtaco|work> vapier, UberL kloeri
-Mar 08 16:50:35 <UberL> no
-Mar 08 16:50:42 <Kugelfang> i have a different proposal
-Mar 08 16:50:53 <kingtaco|work> Kugelfang, wait a sec until mine is voted down
-Mar 08 16:50:57 <Kugelfang> will do
-Mar 08 16:51:05 <kloeri> I'd like it to be one direction and not the only direction
-Mar 08 16:51:06 <kingtaco|work> and you have to vote too
-Mar 08 16:51:22 <Kugelfang> i don't
-Mar 08 16:51:31 <Kugelfang> what's the proper term for that?
-Mar 08 16:51:36 <kloeri> so have a stable/enterprise tree and then the current more uptodate tree
-Mar 08 16:51:38 <kingtaco|work> er, you can abstain sure
-Mar 08 16:51:42 <Kugelfang> abstain?
-Mar 08 16:51:45 <Kugelfang> yes
-Mar 08 16:51:46 <Kugelfang> i abstain
-Mar 08 16:51:48 <kingtaco|work> it's the same as voting no though
-Mar 08 16:51:57 <kingtaco|work> one more no?
-Mar 08 16:52:27 <kingtaco|work> Kugelfang, rather, it has the same effect as voting no
-Mar 08 16:52:27 <kloeri> my vote is no if it's to be _the_ direction
-Mar 08 16:52:39 <kingtaco|work> ok, vote fails
-Mar 08 16:52:48 <kingtaco|work> Kugelfang, you had an idea?
-Mar 08 16:53:00 <Kugelfang> I'd like to propose to compilation of a list of essential packages
-Mar 08 16:53:18 <kingtaco|work> for what purpose and how would you define essential
-Mar 08 16:53:19 <Kugelfang> packages that should be treated with high care
-Mar 08 16:53:24 <kingtaco|work> plus keep in mind wolf isn't here
-Mar 08 16:53:26 <Kugelfang> and that should have two active maintainers
-Mar 08 16:53:39 <kingtaco|work> Kugelfang, you mean stuff that's in sys-* ?
-Mar 08 16:53:44 <Kugelfang> similar
-Mar 08 16:53:53 <Kugelfang> kde-base and gnome-base is as important
-Mar 08 16:53:56 <kingtaco|work> that's what I define as essential
-Mar 08 16:54:10 <kingtaco|work> Kugelfang, I completely disagree with you there
-Mar 08 16:54:10 <Kugelfang> ok, maybe essential is the wrong wording
-Mar 08 16:54:15 <kingtaco|work> yeah
-Mar 08 16:54:22 <kingtaco|work> popular would be better
-Mar 08 16:54:27 <Kugelfang> you proposed to move out "the cruft" to overlays
-Mar 08 16:54:32 <kingtaco|work> widely used perhaps
-Mar 08 16:54:47 <Kugelfang> i would like to have all of them in one reposository, but have higher standards for a subset
-Mar 08 16:55:06 <kingtaco|work> Kugelfang, hrm
-Mar 08 16:55:21 <kingtaco|work> I don't like the ideas of different standards but go on
-Mar 08 16:56:05 <Kugelfang> in short: not all packages have two maintainers, and fixing bugs can be a pain when people don't want "strangers" to work on it
-Mar 08 16:56:28 * yoshi_ has quit (Connection reset by peer)
-Mar 08 16:56:29 <Kugelfang> but for a well-defined list of packages, every dev could fix open bugs after a latency of (e.g.) 2 days
-Mar 08 16:56:40 <kingtaco|work> so you want to require herds with 2 active members for popular packages
-Mar 08 16:56:49 <Kugelfang> jupp
-Mar 08 16:56:56 <Kugelfang> and opt in for non-herd members
-Mar 08 16:57:03 * mpagano has quit (Client Quit)
-Mar 08 16:57:15 <Kugelfang> for a very well defined - read listed - set of packages
-Mar 08 16:57:25 <kingtaco|work> what do you mean opt in?
-Mar 08 16:57:28 <Kugelfang> i don'T want to step on maintainers' toes though
-Mar 08 16:57:31 <kingtaco|work> for non herd members
-Mar 08 16:57:32 <robbat2> i think some herds might have objections to that - per short-term fixes leading to long-term troubles
-Mar 08 16:57:49 <g2boojum> Kugelfang: People not wanting "strangers" to work on packages is a flaw, in my opinion.  As long as people don't break the packages, they should get over it.
-Mar 08 16:57:58 <Kugelfang> g2boojum: correct
-Mar 08 16:58:28 <Kugelfang> robbat2: yeah, we'd need to define that latency very well
-Mar 08 16:58:55 <Kugelfang> robbat2: and it would probably lead to better coordination between herd members / maintainers
-Mar 08 16:59:09 <kingtaco|work> guys, I think this is outside of the context of what wolf would have voted for, so we no longer have 7
-Mar 08 16:59:30 <kingtaco|work> can we open this up to public discussion and punt any vote to next month?
-Mar 08 16:59:35 * windzor_ has quit (Client Quit)
-Mar 08 16:59:35 <robbat2> in the meantime, could you tell us how the "branded" hardware differed from the certified hardware?
-Mar 08 16:59:47 <robbat2> just an overview quickly
-Mar 08 17:00:03 <kingtaco|work> branded hardware is a platform we design and market, as well as build the software
-Mar 08 17:00:10 <kingtaco|work> I'm thinking purpose built hardware
-Mar 08 17:00:19 <kingtaco|work> stuff with the efika is an obvious example
-Mar 08 17:00:26 <kingtaco|work> like a gentoo media center
-Mar 08 17:00:32 <kingtaco|work> or gentoo metrowifi access point
-Mar 08 17:00:52 <kingtaco|work> we would partner with OEMs, but the case badge would be gentoo
-Mar 08 17:01:04 <Kugelfang> that sounds very nice.. we'd need to get info from one of those OEMs first, but i'm all for that idea
-Mar 08 17:01:17 <kingtaco|work> Kugelfang, I've already talked to gensei
-Mar 08 17:01:24 <kingtaco|work> they are somewhat interested
-Mar 08 17:01:32 <robbat2> sure, i'm down with that concept
-Mar 08 17:01:34 <UberL> i need to go guys. is there anything else we're voting on?
-Mar 08 17:01:42 <kingtaco|work> nope, no votes
-Mar 08 17:01:55 <UberL> kk, cyas
-Mar 08 17:01:56 <Kugelfang> open floor?
-Mar 08 17:02:01 <Kugelfang> UberL: see you
-Mar 08 17:02:01 * UberL (n=uberlord@rsm.demon.co.uk) has left #gentoo-council
-Mar 08 17:02:02 <kingtaco|work> ok, we're down to 5, lets open floor
-Mar 08 17:02:06 * kingtaco|work sets mode -m #gentoo-council
-Mar 08 17:02:18 <kingtaco|work> who's doing logging + summ today?
-Mar 08 17:02:22 * blubb has quit (Remote closed the connection)
-Mar 08 17:02:27 * kingtaco|work looks at Kugelfang or robbat2 
-Mar 08 17:02:30 <robbat2> a quick note on something I mentioned early
-Mar 08 17:02:37 <robbat2> no, i'm not doing it. i need more sleep
-Mar 08 17:03:01 <kingtaco|work> Kugelfang, can you take care of the logs and summary?
-Mar 08 17:03:02 <Kugelfang> i have no loggin on
-Mar 08 17:03:05 <kingtaco|work> or you vapier
-Mar 08 17:03:09 <Kugelfang> give me a log and i'll do the summary though
-Mar 08 17:03:19 <kingtaco|work> I can email you logs in about 5 hours
-Mar 08 17:03:23 <Kugelfang> nod
-Mar 08 17:03:28 <kingtaco|work> my home box logs
-Mar 08 17:03:36 <robbat2> for tree-signing stuff, as of the very latest gnupg-2.0.3, upstream has make a design change in response to a possible security flaw, and it has a nice side effect of making the tree-signing (specifically the high-speed verification) possible in a different way
-Mar 08 17:03:36 <kingtaco|work> ok, I'll send out logs and you do the summ
-Mar 08 17:03:37 <kloeri> I have logs
-Mar 08 17:03:40 <marienz> (I have an irssi autolog if you need one, it's not exactly pretty though)
-Mar 08 17:03:53 <kingtaco|work> kloeri, ok, you work with danny then :)
-Mar 08 17:03:57 <kingtaco|work> robbat2, hows that
-Mar 08 17:04:04 <kloeri> nod
-Mar 08 17:04:04 <Kugelfang> i take everything, as long as it's in ASCII
-Mar 08 17:04:23 <solar> robbat2: the fd handling?
-Mar 08 17:04:43 <robbat2> the --status-fd and the issue of prepended text yes
-Mar 08 17:05:02 <robbat2> it didn't used to be able to seperate it easily, but it is now
-Mar 08 17:05:06 <kloeri> Kugelfang: my irssi log should be fine
-Mar 08 17:05:18 <NeddySeagoon> kingtaco|work, 'Own label' hardware is an expensive thing to do in the EU. The brand takes on liability for all regulatory compliance
-Mar 08 17:05:26 <Kugelfang> kloeri: :-)
-Mar 08 17:05:57 <Kugelfang> NeddySeagoon: he doesn't mean "Gentoo's metrowifi AP"
-Mar 08 17:06:01 * pauldv has quit ("KVIrc 3.2.5 Anomalies http://www.kvirc.net/")
-Mar 08 17:06:10 <Kugelfang> NeddySeagoon: he means "Foo Corporation's metrowifi AP, powered by Gentoo"
-Mar 08 17:06:16 <solar> robbat2: here is a new core advisory about it if you missed it. http://www.coresecurity.com/?action=item&id=1687
-Mar 08 17:06:32 <NeddySeagoon> Kugelfang, Ah ... thats a little different
-Mar 08 17:06:48 <kingtaco|work> NeddySeagoon, that's one of the things we'd have to investifate, but tbh, it would be a us company
-Mar 08 17:06:58 <kingtaco|work> as we're a US foundation
-Mar 08 17:07:03 <robbat2> solar: I know about it. Werner Koch released his patch before the advisory was out, because the advisory guys got delayed in releasing
-Mar 08 17:07:04 <Kugelfang> kingtaco|work: that's doesn't remove the liability ;-)
-Mar 08 17:07:18 <kingtaco|work> Kugelfang, perhaps it removes our ability to sell in the EU
-Mar 08 17:07:31 <kingtaco|work> but other companies have worked around it, we need to find out what they've done
-Mar 08 17:07:47 <Kugelfang> well, selling stuff or preparing that is not our task... that's up to the trustees
-Mar 08 17:07:55 <kingtaco|work> indeed
-Mar 08 17:08:10 <Kugelfang> i though you meant "powered by gentoo" brands?
-Mar 08 17:08:17 <kingtaco|work> but it's a direction we as developers can work towards while the trustees work out the legal mumbojumbo
-Mar 08 17:08:35 <kingtaco|work> Kugelfang, in my mind it's the same thing
-Mar 08 17:08:37 <solar> robbat2: i know taviso is not so very happy about it. more or less core regurgutated his previous research as thier own
-Mar 08 17:08:44 <kingtaco|work> we wouldn't be designing board and making the pcbs
-Mar 08 17:08:53 * ndansmith (n=ndansmit@c-67-168-234-215.hsd1.or.comcast.net) has left #gentoo-council
-Mar 08 17:09:07 <Kugelfang> kingtaco|work: nope!
-Mar 08 17:09:14 <robbat2> solar: ok, that makes him the 4th person I know of to indepentantly raise it
-Mar 08 17:09:23 <kingtaco|work> we would select the hardware, work with oems and develop a "product" based on their hardware
-Mar 08 17:09:33 <kingtaco|work> we provide the IP, they provide the hardware
-Mar 08 17:09:33 <Kugelfang> kingtaco|work: as long as we're not selling them and only get small revenues from the producer/Seller, we're save
-Mar 08 17:09:37 <kingtaco|work> more of a partnership
-Mar 08 17:09:59 <solar> KingTaco: I think that should fall under a Enterprise Gentoo. (an internal fork one might say..)
-Mar 08 17:10:05 <kingtaco|work> Kugelfang, we'd probably do it similar to how we "sell" the gensei workstations
-Mar 08 17:10:05 <NeddySeagoon> kingtaco|work, IF you buy some bits and screw them together, in the EU you are liable for safety, EMC, low voltage directive, CE marking etc. ... The low cost routes are still very expensive
-Mar 08 17:10:41 <robbat2> NeddySeagoon, physical bits or does it count per electron too?
-Mar 08 17:10:48 <kingtaco|work> NeddySeagoon, like I said, we would provide the hardware design specs and IP, the OEM would do the actual hardware
-Mar 08 17:10:59 <Kugelfang> we don't do hardware, we shouldn't do, and before going enterprise binary packages should be have less bugs than they have now
-Mar 08 17:11:10 <Kugelfang> -be
-Mar 08 17:11:21 <kingtaco|work> solar, it's the direction I'd like us to work towards
-Mar 08 17:11:29 <jmbsvicetto> kingtaco|work: Are you thinking only on enterprise hardware? Or are you talking about things like end-user laptops?
-Mar 08 17:11:32 <robbat2> some of the targeted hardware stuff has less tree requirements than an entire stable tree
-Mar 08 17:11:32 <NeddySeagoon> kingtaco|work, Physical bits ... liek screwing a PC together
-Mar 08 17:11:39 <kingtaco|work> NeddySeagoon, we wouldn't do that
-Mar 08 17:11:45 <solar> binary packages are quite stable. It's the ebuild-maintainers which are at fault for usually doing the wrong thing.
-Mar 08 17:12:03 <kingtaco|work> jmbsvicetto, the 2 initial markets I'm thinking of are embedded and server, but laptop is certainly an area where we could explore
-Mar 08 17:12:12 <kingtaco|work> I *don't* want to do desktop
-Mar 08 17:12:22 * tove (n=tove@smtp.gentoo.org) has left #gentoo-council
-Mar 08 17:12:28 <kingtaco|work> ubuntu and suse already have the lions share there
-Mar 08 17:12:43 <jmbsvicetto> kingtaco|work: I ask, because the tree for the laptop and the embedded/server market are substantially different ;)
-Mar 08 17:13:03 <kingtaco|work> jmbsvicetto, hence the overlays stuff I was talking about before
-Mar 08 17:13:10 <Kugelfang> solar: 14:09 < genone> well, I still think we need to redesign the whole binary package stuff from scratch at some point
-Mar 08 17:13:22 <Kugelfang> solar: i think other portage devs are disgreeing there
-Mar 08 17:13:44 <solar> Kugelfang: yeah well thats what he thinks. I know I've worked with the format more than anybody else.
-Mar 08 17:13:55 <solar> it could use some improvments but does not need an overhaul
-Mar 08 17:14:22 <jmbsvicetto> kingtaco|work: Personally, I'm very interested in the server market, for work. But as Kugelfang was saying, if that's *the* priority, we take the risk of sending away a great number of users
-Mar 08 17:14:26 <marienz> spaetz: eep
-Mar 08 17:14:30 <marienz> spaetz: sorry, wrong channel
-Mar 08 17:14:43 <spaetz> :-)
-Mar 08 17:14:55 <kingtaco|work> jmbsvicetto, and my proposal was voted down
-Mar 08 17:15:16 <kingtaco|work> I'll be doing some more work on it next month and see if I can come up with something better
-Mar 08 17:15:22 <jmbsvicetto> I noticed, but that doesn't mean that the issue isn't relevant
-Mar 08 17:15:55 <kingtaco|work> tbh, I don't want those users who only stick around for the rice
-Mar 08 17:15:59 <Kugelfang> kingtaco|work: you said you'd move cruft out of gentoo-x86 to overlays
-Mar 08 17:16:00 <marienz> I think you'll have to come up with a bit more technical details before this makes sense though
-Mar 08 17:16:01 <kingtaco|work> we have so much more to offer
-Mar 08 17:16:05 <Kugelfang> kingtaco|work: can you compile a list of those packages?
-Mar 08 17:16:10 <Kugelfang> kingtaco|work: need not be complete
-Mar 08 17:16:15 <Kugelfang> kingtaco|work: but some examples would be nice
-Mar 08 17:16:24 * armin76 (n=armin@gentoo/developer/armin76) has left #gentoo-council ("Leaving")
-Mar 08 17:16:28 <kingtaco|work> Kugelfang, find /usr/portage | grep -v sys-* would be a start
-Mar 08 17:16:35 <robbat2> there are also a lot of users that are here for the flexibility itself, not the ricing
-Mar 08 17:16:36 <Kugelfang> huh?
-Mar 08 17:16:39 <marienz> I think a lot of us don't want the rice users, but it'd be kinda annoying if I'm not allowed to stick around as desktop user :)
-Mar 08 17:16:42 <kingtaco|work> an example is my spca5xx stuff
-Mar 08 17:16:51 <kingtaco|work> that has no reason being in the primary tree
-Mar 08 17:17:08 <kingtaco|work> other than we don't have a good way of having supplimentary trees
-Mar 08 17:17:16 <solar> without a proper stats project you will never really know.
-Mar 08 17:17:20 <Kugelfang> !meta spca5xx
-Mar 08 17:17:21 <jeeves> Kugelfang: Package: media-video/spca5xx Herd: no-herd Maintainer: kingtaco@gentoo.org
-Mar 08 17:17:34 <kingtaco|work> it's a drive for shitty usb webcams
-Mar 08 17:18:01 <jmbsvicetto> kingtaco|work: The way you're putting it, I wonder if you're thinking in Ubuntu
-Mar 08 17:18:23 <Kugelfang> world vs universe?
-Mar 08 17:18:24 <jmbsvicetto> kingtaco|work: I have one of those shitty usb webcams, so thank you for putting it in ;)
-Mar 08 17:18:27 <kingtaco|work> jmbsvicetto, tbh, I haven't installed ubuntu in almost 2 years
-Mar 08 17:18:50 <jmbsvicetto> kingtaco|work: I've never installed it myself. I just helped a few people looking into it
-Mar 08 17:19:04 <robbat2> with maintaining stuff for stable, there's one thing I've run into, and i'm sorry that I was the one that came up with the idea in the first place
-Mar 08 17:19:10 <jmbsvicetto> Kugelfang: I think that's what they call them. IIRC, they have several trees as well, right?
-Mar 08 17:19:18 <robbat2> and that was ebuilds where the majority of functionality has moved to the eclass
-Mar 08 17:19:21 <robbat2> eg php and mysql
-Mar 08 17:19:54 <robbat2> simple because it's becoming harder and harder to accurately say emerge foo-$ver-$rev  will get you an exact set of behavior
-Mar 08 17:23:11 <Pylon> Make sure having a search engine for all packages in all available overlays.  That's the cool thing currently having one big tree.
-Mar 08 17:23:40 <welp[lap]> Pylon, eix already does that with overlays in layman
-Mar 08 17:23:51 <robbat2> you have to have the overlays on your system for that
-Mar 08 17:23:57 <welp[lap]> nope
-Mar 08 17:24:02 <welp[lap]> there's a remote-sync thnigie
-Mar 08 17:24:04 <welp[lap]> *thingie
-Mar 08 17:24:13 <welp[lap]> isn't there?
-Mar 08 17:24:14 <Pylon> welp[lap]: Only those which you added locally.  But how can you find out the overlay where your desired package is in?
-Mar 08 17:24:17 <Kugelfang> there's still the problem of inter-overlay frpd
-Mar 08 17:24:32 <Kugelfang> and portage doesn't support more than 3 hardcoded repositories
-Mar 08 17:24:37 * doc|home has quit ("Connection reset by Peer-Directed Projects Center")
-Mar 08 17:24:49 <Kugelfang> actually, it's exactly 3 hardcodede repositories iirc
-Mar 08 17:25:03 <welp[lap]> Pylon, what about update-eix-remote?
-Mar 08 17:25:49 <Kugelfang> welp[lap]: uhm, th epoint of multiple overlays is to not need to sync them all
-Mar 08 17:26:04 <Pylon> welp[lap]: Seems like an inaccurate description of this tool in it's --help output ;)
-Mar 08 17:27:22 <jokey> Pylon: update-eix-remote
-Mar 08 17:27:23 <jokey> ;)
-Mar 08 17:27:54 <jokey> then you have all layman'ed overlays available for searching
-Mar 08 17:27:59 <Pylon> jokey: Yes.  Now I know what it does.  But the description is irritating.
-Mar 08 17:28:08 <welp[lap]> the eix database on my machine has info on over 65(?) overlays
-Mar 08 17:28:14 <welp[lap]> i think
-Mar 08 17:28:29 <Pylon> 88
-Mar 08 17:28:47 <Pylon> In the current eix-caches.tbz2
-Mar 08 17:29:18 <welp[lap]> hmm, 13644 packages.
-Mar 08 17:29:25 <Pylon> Well, that's a start.  But I know many people who only use the websearch on packages.gentoo.org.  Or even some non-official websites.
-Mar 08 17:29:50 <welp[lap]> like gentoo-portage.com?
-Mar 08 17:30:00 <Pylon> I didn't want to name it ;-)
-Mar 08 17:30:05 <welp[lap]> hehe
-Mar 08 17:30:12 * welp[lap] has it bookmarked :o
-Mar 08 17:30:28 <Pylon> Probably because the design is better…
-Mar 08 17:30:47 <kingtaco|work> I never liked gentoo-portage
-Mar 08 17:30:48 <Pylon> And more Web2.0-like.
-Mar 08 17:30:51 <welp[lap]> but it has too much info imo
-Mar 08 17:30:55 <kingtaco|work> packages is easier on the eyes
-Mar 08 17:30:57 <welp[lap]> may as well just look at the build
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070315-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070315-summary.txt
deleted file mode 100644
index 8991e63707..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070315-summary.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Summary of special council meeting 2007/March/15, for the Gentoo CoC
---------------------------------------------------------------------
-* wolf31o2 posted a temporary version to his devspace, containing suggestions
-  and clarifications from the Q&A session.
-
-* vapier has some further modifications, including: 
-- dropping the all caps to regular case text (accepted)
-- rewording of wanting everybody to be ready to apologize to rather taking
-  responsibility for your actions (accepted)
-- wanting to involve the ombudsman in the consequences section (not accepted,
-  as the ombudsman is for inter-developer conflict).
-
-* robbat2 brought up a set of five conditions to apply to the CoC, given the
-  other input on the mailing lists and the Q&A session.
-- Conditions #1 (that the document is fluid) and #5 (that council may not be
-  proctors) were added directly to the CoC.
-- Conditions #2 (working on a more final version) and #4 (regular review of
-  proctor actions by the council) were included in the vote.
-- Condition #3 (to find a better name than proctors) was not agreed upon, as
-  it was realized that no single title would ever fit.
-
-* The motion was called for accepted the CoC with the above modifications, as
-  well as revisiting it next council meeting, and reviewing the actions of
-  proctors during every council meeting.
-- Passed 6 votes for yes, and 1 for abstain (vapier).
-- The document was commited to the council project space temporarily,
-  until a better location is found for it:
-  http://www.gentoo.org/proj/en/council/coc.xml
-
-
-* There was an initial discussion about who the initial group of proctors, are
-  and kloeri and kingtaco agreed to work together on finding them. wolf31o2 and
-  kugelfang were too busy with their work in the 2007.0 release to get involved
-  there.
-- seemant and g2boojum were mentioned as potential initial candidates,
-  combined with the forums moderators and the #gentoo ops focusing on their own
-  areas of specialization.
-
-* robbat2 is working on the implementation of mailing-list stuff from the
-  infrastructure side, linking his implementation plan, and asked for any
-  short-term needs to be brought to him directly until the initial application
-  is ready to go in a few hours.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070315.txt b/xml/htdocs/proj/en/council/meeting-logs/20070315.txt
deleted file mode 100644
index d761062bf9..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070315.txt
+++ /dev/null
@@ -1,228 +0,0 @@
-Mar 15 13:59:49 Kugelfang	*bling bling bling*
-Mar 15 13:59:52 *	wolf31o2|mobile has changed the topic to: Code of Conduct Q&A session at March 14th, 2100UTC ; Voting on CoC @ March 15th, 2100UTC ; http://dev.gentoo.org/~wolf31o2/coc.xml
-Mar 15 13:59:54 Kugelfang	meeting time?
-Mar 15 14:00:11 wolf31o2|mobile	yup
-Mar 15 14:00:17 wolf31o2|mobile	http://dev.gentoo.org/~wolf31o2/coc.xml
-Mar 15 14:00:45 wolf31o2|mobile	here's an update to the coc that was written, including some suggestions and clarifications from yesterday
-Mar 15 14:01:00 kloeri	just read it 5 seconds ago :)
-Mar 15 14:01:35 *	wolf31o2|mobile sets mode +m #gentoo-council
-Mar 15 14:01:40 Kugelfang	wolf31o2|mobile: s/Respect someones/Respect someone's/
-Mar 15 14:01:51 Kugelfang	wolf31o2|mobile: 3rd paragraph
-Mar 15 14:01:57 wolf31o2|mobile	Kugelfang: typographical... doesn't change content... but thanks
-Mar 15 14:01:58 Kugelfang	wolf31o2|mobile: first bulletpoint
-Mar 15 14:02:06 Kugelfang	nod... i'm a nitpicker ;-)
-Mar 15 14:02:08 wolf31o2|mobile	dont' address me
-Mar 15 14:02:13 wolf31o2|mobile	I didn't write/edit it
-Mar 15 14:02:17 wolf31o2|mobile	I just uploaded it
-Mar 15 14:02:18 wolf31o2|mobile	:P
-Mar 15 14:03:01 robbat2	hi
-Mar 15 14:03:21 robbat2	kingtaco|work, get in here
-Mar 15 14:03:22 *	expose has quit (Nick collision from services.)
-Mar 15 14:03:26 kingtaco|work	I am
-Mar 15 14:03:40 kingtaco|work	jeez, can't a guy have a smoke or 20 ?
-Mar 15 14:03:45 wolf31o2|mobile	heh
-Mar 15 14:03:48 *	expose_ (n=nobody@82.139.196.236) has left #gentoo-council
-Mar 15 14:03:58 *	expose (n=nobody@82.139.196.236) has joined #gentoo-council
-Mar 15 14:04:35 kloeri	who's missing? vapier and uber?
-Mar 15 14:05:05 kingtaco|work	should probably link robbat2's stuff as well
-Mar 15 14:05:10 kingtaco|work	robbat2, ?
-Mar 15 14:06:10 robbat2	one sec
-Mar 15 14:06:13 vapier	?
-Mar 15 14:06:34 vapier	http://rafb.net/p/qrNRyr49.html
-Mar 15 14:06:42 *	nightmorph (n=nightmor@gentoo/developer/nightmorph) has joined #gentoo-council
-Mar 15 14:07:10 *	Chainsaw (n=chainsaw@gentoo/developer/Chainsaw) has joined #gentoo-council
-Mar 15 14:07:12 robbat2	http://dev.gentoo.org/~robbat2/coc-conditions.txt
-Mar 15 14:08:03 *	phreak`` (n=phreak``@gentoo/developer/phreak) has joined #gentoo-council
-Mar 15 14:08:06 robbat2	ok, so we've all gone off and done this seperately it seems :-(
-Mar 15 14:08:24 kloeri	I haven't :)
-Mar 15 14:08:53 *	hoffie (n=hoffie@e.rootservers.org) has joined #gentoo-council
-Mar 15 14:09:15 wolf31o2|mobile	vapier: look at the updated version in my dev space, pelase
-Mar 15 14:09:37 vapier	too many
-Mar 15 14:09:47 robbat2	there's only 3 things in vapier's that aren't addressed in your update
-Mar 15 14:09:50 vapier	someone start combining them
-Mar 15 14:09:59 robbat2	i'll point them out quickly
-Mar 15 14:10:00 Kugelfang	i love the name "proctors"
-Mar 15 14:10:05 *	windzor (n=windzor@82.143.229.82) has joined #gentoo-council
-Mar 15 14:10:12 robbat2	diffences between vapier/wolf31o2 versions:
-Mar 15 14:10:14 robbat2	1. drop caps
-Mar 15 14:10:30 robbat2	2. "If you screw up, apologize sincerely" vapier calls it lame
-Mar 15 14:10:54 robbat2	3. "ombudsman should probably be more involved" in consequences
-Mar 15 14:11:24 robbat2	vapier: read my conditions link, as those are seperate to wolf31's changes
-Mar 15 14:11:44 *	dev-zero (n=TizianoM@gentoo/developer/dev-zero) has joined #gentoo-council
-Mar 15 14:13:09 wolf31o2|mobile	give me like 5 and I'll update
-Mar 15 14:13:16 wolf31o2|mobile	(and they weren't my changes, dammit)
-Mar 15 14:15:03 *	blackace (n=blackace@gentoo/developer/blackace) has joined #gentoo-council
-Mar 15 14:17:18 wolf31o2|mobile	bleh... this is fun
-Mar 15 14:17:51 Kugelfang	what happened?
-Mar 15 14:18:08 wolf31o2|mobile	how about s/apologize sincerely/take responsibility for your actions/ ?
-Mar 15 14:18:16 wolf31o2|mobile	Kugelfang: sorry... I'm editing
-Mar 15 14:18:26 Kugelfang	:-)
-Mar 15 14:18:36 kloeri	wolf31o2|mobile: I like that
-Mar 15 14:18:45 robbat2	+1 here for now
-Mar 15 14:18:48 wolf31o2|mobile	vapier: can you look at it (updated it) and see if you have anything else to add that isnt' in robin's comments ?
-Mar 15 14:18:56 kingtaco|work	wfm
-Mar 15 14:19:35 Kugelfang	wolf31o2|mobile: someone's ;-)
-Mar 15 14:19:36 robbat2	wolf31o2|mobile, err, did you miss vapier's ombusdman bit?
-Mar 15 14:19:45 robbat2	ombudsman
-Mar 15 14:19:51 Kugelfang	wolf31o2|mobile: and there is still one capital "RESPECTFULLY"
-Mar 15 14:19:58 Kugelfang	wolf31o2|mobile: in the 3 paragraph
-Mar 15 14:20:08 Kugelfang	+rd
-Mar 15 14:20:26 wolf31o2|mobile	somebody write something for it
-Mar 15 14:20:34 wolf31o2|mobile	don't leave it all to me
-Mar 15 14:20:34 wolf31o2|mobile	heh
-Mar 15 14:20:47 robbat2	one sec then
-Mar 15 14:20:52 Kugelfang	i don't think the ombudsman is involved there
-Mar 15 14:21:00 robbat2	"appeals should be addressed to the ombudsman and the Gentoo Council via email at council@gentoo.org"
-Mar 15 14:21:04 Kugelfang	the ombudsman is for dev<->dev problems
-Mar 15 14:21:14 Kugelfang	this is about communication problems
-Mar 15 14:22:21 robbat2	hmm, point there
-Mar 15 14:22:36 wolf31o2|mobile	ok... updated
-Mar 15 14:23:35 wolf31o2|mobile	if anyone has anything, let me know... but this should be good enough to cover us until the next meeting... also, you'll notice that nowhere does it define what proctors can/can't be (other than council members) meaning that for the interim, I think that forums mods and #gentoo ops could be considered fillign that capacity, so long as there's a few others to do oversight for the next meeting
-Mar 15 14:24:01 *	pusling (i=pusling@195.215.29.124) has left #gentoo-council
-Mar 15 14:24:09 Kugelfang	i want grant in there, too
-Mar 15 14:24:14 Kugelfang	if he volunteers
-Mar 15 14:24:20 wolf31o2|mobile	that's fine
-Mar 15 14:24:21 Kugelfang	g2boojum: ping?
-Mar 15 14:24:33 kloeri	I'm fine with that
-Mar 15 14:24:47 robbat2	points 2,3,4 from mine are still valid, but apply directly to the document rather than being changes that need to be in it
-Mar 15 14:24:55 kingtaco|work	yeah
-Mar 15 14:25:03 robbat2	in specific, and for the log of this meeting:
-Mar 15 14:25:10 kingtaco|work	are we selecting the first round of people?
-Mar 15 14:25:13 robbat2	2. people need to work together and bring us a revised CoC
-Mar 15 14:25:16 kingtaco|work	I'd rather that
-Mar 15 14:25:29 robbat2	3. people need to find another name than proctors
-Mar 15 14:25:37 wolf31o2|mobile	kingtaco|work: in addition to the forums/#gentoo guys, you mean?
-Mar 15 14:25:40 g2boojum	Kugelfang: I'm not really around until next week.  (I also haven't read back, so I've no idea what I'm being pinged about just yet.)
-Mar 15 14:25:56 robbat2	4. council should reguarlly review actions taken by proctors
-Mar 15 14:26:18 Kugelfang	g2boojum: i want you to be part of the proctors group if you afree
-Mar 15 14:26:20 Kugelfang	agree
-Mar 15 14:26:26 kingtaco|work	wolf31o2|mobile, I think we should include some of those people because they have experence, but not necessarly all of them
-Mar 15 14:26:36 wolf31o2|mobile	I definitely agree with 2 and 4... I think 3 is kinda one of those things where nothing will ever fit, so what't the point in changing the title, as it gains us nothing anyway
-Mar 15 14:26:39 kingtaco|work	Kugelfang, no fair, I wanted him first
-Mar 15 14:26:48 Kugelfang	kingtaco|work: hah... never!
-Mar 15 14:26:49 kingtaco|work	NASA love triangle!
-Mar 15 14:27:02 wolf31o2|mobile	kingtaco|work: for the permanent list, sure... but for the interim (as in, until next council meeting when we can get everything hashed out ahead of time)
-Mar 15 14:27:57 kingtaco|work	wolf31o2|mobile, lemme rephrase, the forums and #gentoo people have done a good job at this in their places, but I don't feel comfortable with solely them doing the other mediums
-Mar 15 14:28:12 kingtaco|work	so I'd like a couple more people
-Mar 15 14:28:21 kingtaco|work	seemant, g2boojum in particular
-Mar 15 14:28:39 g2boojum	Kugelfang: Okay.  If I end up too busy, I'll let the council know.  I'm rarely likely to be good at "rapid response" right now, though.
-Mar 15 14:28:47 wolf31o2|mobile	kingtaco|work: definitely... I thought I'd made that clear... sorry... and I agree that we should have a better list for the next meeting, including people from both groups
-Mar 15 14:29:09 Kugelfang	g2boojum: noted
-Mar 15 14:29:11 kingtaco|work	aight
-Mar 15 14:29:22 *	rullzer has quit (Client Quit)
-Mar 15 14:29:24 robbat2	did Uber show up yet?
-Mar 15 14:29:30 Kugelfang	nope
-Mar 15 14:30:05 *	wolf31o2|mobile pokes Uber a couple more times for effect
-Mar 15 14:32:06 Uber	sorry, here
-Mar 15 14:32:10 Kugelfang	ahh
-Mar 15 14:32:14 Kugelfang	so we can vote now?
-Mar 15 14:32:28 kingtaco|work	let's be clear on what version we're voting on
-Mar 15 14:32:31 kingtaco|work	wolfs ?
-Mar 15 14:32:33 Kugelfang	wolf's
-Mar 15 14:32:37 kingtaco|work	anything added to that
-Mar 15 14:32:44 kingtaco|work	like stuff from robbat2 ?
-Mar 15 14:32:55 Kugelfang	see above^^^
-Mar 15 14:33:39 kingtaco|work	Kugelfang, not to be pedantic, but I'd rather just list everything we're voting on all at once
-Mar 15 14:33:51 wolf31o2|mobile	well, I say this... we vote on the version on my dev space right now, with the addition that we *will* revisit this document at the next regular council meeting, will have a list of suggested proctors (and have gotten their approval), and will review the proctors actions each council meeting
-Mar 15 14:33:56 wolf31o2|mobile	^^^^
-Mar 15 14:33:57 wolf31o2|mobile	there
-Mar 15 14:34:04 wolf31o2|mobile	so, vote ?
-Mar 15 14:34:22 Kugelfang	yes please
-Mar 15 14:34:30 *	kingtaco|work yes
-Mar 15 14:34:31 wolf31o2|mobile	ok...
-Mar 15 14:34:32 robbat2	yes
-Mar 15 14:34:32 wolf31o2|mobile	yes
-Mar 15 14:34:33 kloeri	yes
-Mar 15 14:34:41 *	windzor has quit (Client Quit)
-Mar 15 14:34:48 Uber	yes
-Mar 15 14:34:58 kingtaco|work	Kugelfang, your vote was yes or "yes, let's vote"
-Mar 15 14:34:59 *	Uber has just read it and it looks good
-Mar 15 14:35:08 Kugelfang	yes
-Mar 15 14:35:13 Kugelfang	kingtaco|work: :-)
-Mar 15 14:35:19 kingtaco|work	aight
-Mar 15 14:35:20 wolf31o2|mobile	slacker^Wspanky ? *grin*
-Mar 15 14:35:31 robbat2	vapier, ^^^
-Mar 15 14:35:36 kingtaco|work	vapier, you wanna play along with the other kids?
-Mar 15 14:36:12 *	MinnieBannister (n=roy@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-Mar 15 14:36:18 kingtaco|work	I'd also like to see christel involved in the begining
-Mar 15 14:36:21 wolf31o2|mobile	also, where should we stick this for the time being?
-Mar 15 14:36:32 kingtaco|work	I think she has a lot of good ideas about stuff like this
-Mar 15 14:36:32 Kugelfang	wolf31o2|mobile: council project space
-Mar 15 14:36:38 wolf31o2|mobile	that's what I was thinking
-Mar 15 14:36:40 kingtaco|work	yeah, proj/en/council
-Mar 15 14:37:16 kingtaco|work	aight
-Mar 15 14:37:19 wolf31o2|mobile	ok... added now
-Mar 15 14:37:25 Kugelfang	excellent
-Mar 15 14:37:33 g2boojum	She's going to be a tad busy.  We got into GSOC again.
-Mar 15 14:37:49 kingtaco|work	g2boojum, I know, I'm trying to get you guys a bok this year :)
-Mar 15 14:37:53 kingtaco|work	*box
-Mar 15 14:38:03 wolf31o2|mobile	<CIA-1> wolf31o2 * gentoo/xml/htdocs/proj/en/council/coc.xml: Initial approved version of the Code of Conduct, to be reviewed at the next Council meeting.
-Mar 15 14:38:22 g2boojum	kingtaco|work: gracias
-Mar 15 14:38:35 robbat2	ok, i'll do the logs+summary for this meeting
-Mar 15 14:38:45 kingtaco|work	g2boojum, however, she can also manage to herd some insane group of 15k women or something with similar rules
-Mar 15 14:38:59 *	cshields (n=cshields@osuosl/staff/cshields) has joined #gentoo-council
-Mar 15 14:39:05 kingtaco|work	so
-Mar 15 14:39:06 wolf31o2|mobile	did anybody do logs/summary from the last one?
-Mar 15 14:39:12 kingtaco|work	yeah, vapier did
-Mar 15 14:39:14 wolf31o2|mobile	k
-Mar 15 14:39:21 wolf31o2|mobile	I didn't know he did a summary
-Mar 15 14:39:42 kingtaco|work	so I think it's best that a couple of us council types take charge in getting the initial group going
-Mar 15 14:40:07 kingtaco|work	probably kloeri, myself || robbat2 and one mroe
-Mar 15 14:40:26 robbat2	err, initial group of proctors?
-Mar 15 14:40:28 wolf31o2|mobile	well, you and robin have the infra-fu to make it happen
-Mar 15 14:40:29 kingtaco|work	no
-Mar 15 14:40:31 kingtaco|work	no
-Mar 15 14:40:46 kingtaco|work	just getting the initial group together
-Mar 15 14:40:50 robbat2	ah, ok
-Mar 15 14:40:57 kingtaco|work	forums, #gentoo, seemant, g2boojum, christel
-Mar 15 14:41:09 kingtaco|work	just so we don't all have to take up time on it
-Mar 15 14:41:10 kloeri	I'd be happy to help get the initial group together
-Mar 15 14:41:18 vapier	maybe some wikipedia links for trolling/flaming
-Mar 15 14:41:28 kingtaco|work	wolf31o2|mobile, that's why I suggested one of us :)
-Mar 15 14:41:43 kingtaco|work	and kloeri because it's sorta his turf
-Mar 15 14:42:02 robbat2	ok, for implementation wise, if you want to block somebodies posts right now, grab me in infra, the initial app is an hour or 3 away from being completed
-Mar 15 14:42:05 kingtaco|work	vapier, indeed
-Mar 15 14:42:23 kingtaco|work	or me, after robbat2 shows me how it works
-Mar 15 14:42:35 kingtaco|work	who's the 3rd?
-Mar 15 14:42:37 vapier	i'd prefer to abstain from vote for now until i get back to review current list
-Mar 15 14:42:42 kingtaco|work	and robbat2 you want to or shall I?
-Mar 15 14:42:44 kingtaco|work	vapier, so noted
-Mar 15 14:42:54 robbat2	kingtaco|work, you take it please, so I can finish the app
-Mar 15 14:43:00 kingtaco|work	robbat2, you got it
-Mar 15 14:43:06 kingtaco|work	we need one more person
-Mar 15 14:43:12 kingtaco|work	Uber, ?
-Mar 15 14:43:12 robbat2	here's my implementation plan - http://dev.gentoo.org/~robbat2/coc-ml-impl.txt
-Mar 15 14:43:22 kingtaco|work	Kugelfang, ?
-Mar 15 14:43:39 kingtaco|work	I'm excluding wolf as I want him for releng and trustees :)
-Mar 15 14:43:49 Kugelfang	kingtaco|work: huh?
-Mar 15 14:43:55 wolf31o2|mobile	heh... I was about to say I won't have time until after release
-Mar 15 14:44:03 kingtaco|work	Kugelfang, 3 of us are going to get the ball rolling
-Mar 15 14:44:03 *	expose has quit (Connection timed out)
-Mar 15 14:44:15 kingtaco|work	Kugelfang, it's me and kloeri so far, won't you join us?
-Mar 15 14:44:24 Kugelfang	kingtaco|work: all i want is grant in the group... i'm busy with release as well
-Mar 15 14:44:31 Kugelfang	kingtaco|work: so no
-Mar 15 14:44:35 kingtaco|work	Uber, join us
-Mar 15 14:44:45 kingtaco|work	or it's just me and kloeri
-Mar 15 14:44:49 kingtaco|work	we can do that
-Mar 15 14:44:53 kloeri	I'm only busy with releng work for two archs :)
-Mar 15 14:44:59 kingtaco|work	haha
-Mar 15 14:45:04 kingtaco|work	and I'm busy with infra
-Mar 15 14:45:08 kingtaco|work	we're all busy
-Mar 15 14:45:18 Kugelfang	i still say no :-P
-Mar 15 14:45:29 kingtaco|work	aight, me and kloeri it is
-Mar 15 14:45:38 kingtaco|work	Uber, if you want to help, please let us know
-Mar 15 14:45:46 kingtaco|work	and I think we're done
-Mar 15 14:45:50 kingtaco|work	any other business?
-Mar 15 14:46:05 robbat2	nope
-Mar 15 14:46:13 kloeri	nope
-Mar 15 14:46:17 Kugelfang	so let's finish this :-)
-Mar 15 14:46:27 Uber	kingtaco|work: I'm a little busy right now, sorry
-Mar 15 14:46:31 kingtaco|work	we just did
-Mar 15 14:46:38 kingtaco|work	class dismissed
-Mar 15 14:46:42 *	kingtaco|work sets mode -m #gentoo-council
-Mar 15 14:46:50 robbat2	kingtaco|work, maybe ask amne to help you get a group together too?
-Mar 15 14:46:51 Uber	kingtaco|work: huh, helping out how?
-Mar 15 14:46:52 impulze	heh
-Mar 15 14:47:07 kingtaco|work	Uber, just orginizing the initial people
-Mar 15 14:47:09 kloeri	wee! /me runs off to beat the weaker guys
-Mar 15 14:47:29 kingtaco|work	robbat2, aalready in pm with him
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070412-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070412-summary.txt
deleted file mode 100644
index 316f26d8b2..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070412-summary.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-CoC:
-	- amne has been doing a good job putting the group together
-	- ask proctors to address these two issues for next meeting:
-		- add a "mission" statement
-		- fix wording to have a positive spin
-sync Social Contract with Gentoo Foundation (external entities):
-	- trustees will review the statement to clarify things and then
-	  we'll look again at syncing
-documentation for mail servers:
-	- they are supposed to be finished in terms of content
-	- wolf will look at getting them actually committed
-PMS:
-	- current status looks good in getting issues resolved
-	- should be up and running on Gentoo infra by next meeting
-	- let the devs sort out the todo as the current work flow seems
-	  to be getting things done finally
-splitting gentoo-dev mailing lists:
-	- no real favorable backing for this
-	- people dont like -dev because of the crap, splitting the lists
-	  will just move the crap else where, not really solving anything
-	- let proctors do their thing and if need be, review this again
-limiting of council powers:
-	- doesnt seem to be real backing for this from dev community or
-	  the council itself
-	- if a majority of developers are truly upset/disturbed by a
-	  council decision, it should show easily
-	- if you dont like a council member, dont vote for them next time
-moving gentoo-core to public archives:
-	- many people dislike this moving forward
-	- use -dev over -core for most things
-	- not going to happen at this time
-	- look into getting a dev-only archive finally
-surveys:
-	- robbat2 will look at getting user/dev surveys in place after the
-	  release of 2007.0
-	- probably try and take fresh surveys after each bi-annual release
-	  from now on to see if we're meeting many of users' desires
-new metastructure proposal:
-	- doesnt seem to address any of the problems it proposes to
-	- a large majority of developers and users prefer the single tree
-	  development style that Gentoo has versus many smaller trees
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070412.txt b/xml/htdocs/proj/en/council/meeting-logs/20070412.txt
deleted file mode 100644
index 9c90c615cb..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070412.txt
+++ /dev/null
@@ -1,606 +0,0 @@
-[15:59] <vapier> get things rolling ?  or we want to wait until exactly 2000UTC
-[15:59] <solar> heh. odd. I just /msg taco asking him what time the meeting way
-[15:59] <solar> was
-[16:00] <kingtaco|work> I'm here
-[16:00] --> UberLord (n=uberlord@gentoo/developer/UberLord) has joined #gentoo-council
-[16:00] --- ChanServ sets modes [#gentoo-council +o UberLord]
-[16:00] <wolf31o2|mobile> I'm semi-here
-[16:00] <UberLord> I'm semi here - only just got home
-[16:00] <vapier> anyone feel like chairing it ?  if not i can do it up doggy style
-[16:01] <wolf31o2|mobile> I think you just volunteered
-[16:01] <vapier> err, that wasnt meant to be
-[16:01] <Kugelfang> vapier: tell sejo to sod of till after the meeting
-[16:01] <Kugelfang> vapier: you can't be humped right now
-[16:01] <vapier> fine, roll call
-[16:01] <vapier> i need a kloeri and a robbat2
-[16:02] <robbat2> hi
-[16:02] <vapier> kloeri: wake up
-[16:02] <vapier> we can start with http://article.gmane.org/gmane.linux.gentoo.devel/47673
-[16:02] --- vapier sets modes [#gentoo-council +m]
-[16:02] <vapier>  - documentation for mail servers still pending i believe (SPF / reply-to)
-[16:03] <Kugelfang> king of tacos wanted to commit it
-[16:03] <Kugelfang> kingtaco|work: right?
-[16:03] <vapier> wolf31o2 / KingTaco / robbat2: ?
-[16:03] <robbat2> i think the docs on those are done, just not commited yet
-[16:03] --> YosWinK (n=yoswink@gentoo/developer/yoswink) has joined #gentoo-council
-[16:03] <wolf31o2|mobile> vapier: someone from infra was to commit it... if it hasn't been done, I can take the lead on doing the commit... since /proj is free game to everyone anyway
-[16:04] <Kugelfang> do it!
-[16:04] <Kugelfang> :-)
-[16:04] <vapier> yeah, do it
-[16:05] <vapier> people keep saying their done
-[16:05] <vapier> proooove it and post em
-[16:05] <robbat2> i'm not sure who's got the latest revisions of them, so just grab those and commit :-)
-[16:05] <vapier> if they arent up by next meeting, you guys die
-[16:05] <vapier> no that isnt a joke
-[16:05] --> frangor (n=frangor@unaffiliated/frangor) has joined #gentoo-council
-[16:05] <vapier> next topic
-[16:05] <wolf31o2|mobile> robbat2: well, I did reply-to, so I know I have the latest there, and kloeri has latest spf
-[16:05] <Kugelfang> vapier: the can still appeal before execution
-[16:05] <vapier>  - sync Social Contract with Gentoo Foundation statement (external entities)
-[16:06] <vapier> anyone against that ?  need that be moved to trustees ?
-[16:06] <wolf31o2|mobile> what exactly did you mean by that one?
-[16:06] <wolf31o2|mobile> well, here's what I think... the social contract applies to what we *make*
-[16:06] <vapier> http://www.gentoo.org/foundation/en/#doc_chap2
-[16:06] <wolf31o2|mobile> anything regarding what we *use* should be directed to the trustees
-[16:06] <vapier> last part "Gentoo is independent"
-[16:07] <vapier> social contract is a promise to the people who use Gentoo
-[16:07] <vapier> it just largely covers what we make as that is largely how people use Gentoo
-[16:07] <wolf31o2|mobile> that doesn't change what I said... :P
-[16:07] <vapier> me neither !
-[16:07] <robbat2> err, which direction are you wanting to sync things in?
-[16:07] <vapier> foundation -> social contract
-[16:07] <robbat2> as they seem orthagonal atm
-[16:08] <wolf31o2|mobile> right... I guess I just see no point in duplicating those statements... though it might make more sense to have the foundation page clarified more
-[16:08] <kloeri> hi guys
-[16:08] <vapier> the rest of the principles are duped
-[16:08] <vapier> more or less
-[16:08] --> welp (n=welp@gentoo/developer/welp) has joined #gentoo-council
-[16:09] <Kugelfang> vapier: do you have a patch against the social contract?
-[16:09] <Kugelfang> i'm all for taking it in, but i need to read the diff first before i make up my mind
-[16:09] <vapier> copy and paste the part from the foundation
-[16:09] <vapier> wrap it in <p> </p>
-[16:09] <vapier> profit
-[16:10] <Kugelfang> s/Gentoo Foundation/Gentoo/
-[16:10] <Kugelfang> by all means, do it
-[16:10] <robbat2> kloeri, you had the SPF document somewhere? commit it please?
-[16:10] <wolf31o2|mobile> robbat2: I'll get it... it needs to be guidexml'd
-[16:10] <vapier> anyone else have an opinion ?
-[16:10] <wolf31o2|mobile> yeah, I think it is pointless to duplicate it
-[16:10] <kloeri> yeah, http://dev.gentoo.org/~kloeri/spf.txt
-[16:10] <wolf31o2|mobile> I'd much prefer see the trustees qualify those statements more
-[16:10] <vapier> wolf31o2: you dont fall into the "else" category
-[16:11] <wolf31o2|mobile> heh
-[16:11] <vapier> wolf31o2: sure, we can do that first
-[16:11] <vapier> i'd insert like "outside" before "organization"
-[16:11] <vapier> and fix the spelling so it reads "organization"
-[16:12] <robbat2> vapier, I agree in concept, but i'd like to see the diff first
-[16:12] * UberLord agrees with robbat2
-[16:12] --> diox (n=diox@gentoo/developer/diox) has joined #gentoo-council
-[16:12] <vapier> you guys really cant use your imagination huh
-[16:13] * UberLord has none :(
-[16:13] <vapier> the content is unchanged, the diff would only show formatting
-[16:13] <UberLord> i gotta split for a few minutes
-[16:13] <vapier> we can simply slack and ask the trustees to tweak it a bit
-[16:13] <vapier> then chat more next time
-[16:14] <robbat2> just bounce it in the -council mailing list after you hear from them?
-[16:14] <Kugelfang> no, -dev
-[16:14] <Kugelfang> just like all the other stuff we vote on
-[16:14] <vapier> i say we make wolf31o2 do it
-[16:14] <Kugelfang> if somebody wants to give input then i'd like to hear it
-[16:14] <robbat2> vapier, could we let him put out the 2007 release first?
-[16:14] <wolf31o2|mobile> it doesn't really belong on either, since the social contract is really something that pre-dates the foundation and should be completely superseded by the foundation now
-[16:15] <wolf31o2|mobile> robbat2: heh... that's what I'm working on right now... which is why I said I am only "semi-here"
-[16:16] <vapier> then let the trustees do their thing and we'll talk about syncing once they have
-[16:16] <vapier> that work for everyone ?
-[16:16] <robbat2> yup
-[16:16] <kingtaco|work> sure
-[16:16] <kloeri> yup
-[16:16] <wolf31o2|mobile> wfm
-[16:16] <Kugelfang> yes
-[16:16] <-- JaysonB has quit (Client Quit)
-[16:17] <vapier> wolf31o2: it's on your head then kthx
-[16:17] <vapier> up next, CoC
-[16:17] --- vapier sets modes [#gentoo-council +vv christel amne]
-[16:17] <kingtaco|work> CoC is building up proctors
-[16:17] --- kingtaco|work sets modes [#gentoo-council -v christel]
-[16:17] <vapier> pwnt
-[16:18] <kingtaco|work> she removed herself
-[16:18] <vapier> i missed that
-[16:18] <wolf31o2|mobile> quick CoC suggestion... we discuss changes here, then write them up and send them to -dev for discussion... as far as changes to the actual document
-[16:18] <vapier> amne is heading it up now then ?
-[16:18] <kingtaco|work> yes
-[16:18] --> Blacksito (i=koko@unaffiliated/blacksito) has joined #gentoo-council
-[16:19] <kingtaco|work> he is building up proctors in different timezones, seemed to be a bit heavy on #gentoo people at first, but that's subsided
-[16:19] <kingtaco|work> they've done nothing other than that
-[16:19] <vapier> what else is there for them to do now other than recruit their foot soldiers
-[16:19] <kingtaco|work> not much else
-[16:20] <vapier> so the notes i posted were based on e-mails no one responded to in the big CoC thread
-[16:20] <vapier> mainly kevinquinn and g2boojum
-[16:20] <kingtaco|work> not sure what you're refering to
-[16:20] <vapier>  - add a "mission" statement
-[16:20] <vapier>  - fix wording to have a positive spin
-[16:20] <kingtaco|work> I think most of us stopped reading that after the trolls invaded
-[16:20] <vapier> i dont have the gmane links atm to the specific e-mails
-[16:20] <robbat2> on the infra end, they've got the first tool they need to block stuff that they need to, the second one is taking longer than I thought due to upstream bits with mlmmj, but i'm working on it still
-[16:21] <Kugelfang> good
-[16:21] <kingtaco|work> vapier, can you send that to proctors@ so they can work on it?
-[16:21] <Kugelfang> what's the second tool supposed to do?
-[16:21] <robbat2> i thought the "positive spin" comment was meant against the initial version, before we revised it?
-[16:21] <vapier> robbat2: i dont feel like any of our revisions addressed that
-[16:21] --> beu (n=beu@foreignvoid.co.uk) has joined #gentoo-council
-[16:21] <vapier> it's still an angry document
-[16:22] <robbat2> Kugelfang, see the original implementation plan - the second tool will provide proper consensus support for proctors
-[16:22] <Kugelfang> i see
-[16:22] <vapier> i'm not sure we want to redraft it, just have the proctors do it and bring it back
-[16:23] <kingtaco|work> you want it to look more like the ubuntu stuff?
-[16:23] <Kugelfang> not everything needs to have sugar on-top
-[16:23] <vapier> i'd prefer we were one big amoeba
-[16:23] <Kugelfang> na... i don't want to share one cell with you!
-[16:24] <vapier> but until then, i feel that the way ubuntu's is written and the way ours is written are different polls
-[16:24] <vapier> i can live with middle ground
-[16:25] <robbat2> Kugelfang, keep your puesdopods to yourself?
-[16:25] <Kugelfang> puesdopods?
-[16:25] <Kugelfang> ah, pseudopods!
-[16:25] <Kugelfang> gotcha
-[16:25] <vapier> anywho
-[16:26] <vapier> any opinions ?
-[16:26] <Kugelfang> amne: any input from your side?
-[16:26] <robbat2> nope. - after the PMS stuff, I've got one other quick question for council before the open floor
-[16:26] <kingtaco|work> I think it's worded fine, but I don't care one way or the other'
-[16:27] <vapier> you're an angry man, this i know
-[16:27] <-- frangor (n=frangor@unaffiliated/frangor) has left #gentoo-council
-[16:27] <kingtaco|work> haha
-[16:27] --> Fieldy (i=S55UT4Nw@gentoo/contributor/Fieldy) has joined #gentoo-council
-[16:28] <vapier> amne: you awake ?  or you just mostly for show ?
-[16:28] <Kugelfang> vapier: well, this is to vague... as with the social contract, show me a diff and i say something
-[16:28] <wolf31o2|mobile> Kugelfang: I think the point is to assign making the diff to someone
-[16:28] <Kugelfang> ahh
-[16:28] <kingtaco|work> arn't we off that topic?
-[16:29] <wolf31o2|mobile> kingtaco|laptop: the CoC updates, we mean
-[16:29] <wolf31o2|mobile> and if nobody else steps up... I can do it... not like I have anything else to do
-[16:29] <vapier> you can work with amne on it
-[16:29] <Kugelfang> wolf31o2|mobile: let amne handle it... i don't think council should be any more involved than saying yay or nay to it
-[16:29] <vapier> and by work with amne i mean have amne do it but tell us you helped
-[16:29] <wolf31o2|mobile> Kugelfang: sure
-[16:30] <wolf31o2|mobile> vapier: sounds like a plan
-[16:30] <vapier> anyone else ?  UberLord / kloeri / robbat2 ?
-[16:30] <kingtaco|work> where is kloeri?
-[16:30] <robbat2> no problems with that
-[16:30] <kingtaco|work> is he a slacker?
-[16:30] <Kugelfang> no
-[16:30] <vapier> [16:07] <kloeri> hi guys
-[16:30] <kingtaco|work> ok
-[16:30] <robbat2> he pasted the spf link too
-[16:30] <robbat2> 20 minutes back
-[16:31] <kingtaco|work> okok
-[16:31] <Kugelfang> robbat2: keep kingtaco|work's lack of short-time memory in mind
-[16:31] <Kugelfang> :-P
-[16:31] <vapier> they can chime in later but i'm pretty sure they'll be ok with that
-[16:31] <vapier> moving on to hopefully a quickie
-[16:31] <vapier>  - splitting gentoo-dev mailing lists ?
-[16:31] <kingtaco|work> I think it's a stupid idea
-[16:31] <Kugelfang> -dev-announce and -dev?
-[16:31] <vapier> i think people were generally against this
-[16:31] <vapier> dont post crap to -dev is the answer ?
-[16:31] <Kugelfang> it comes up everytime we have a flamewar
-[16:32] <kingtaco|work> I think we should clean up the current lists instead
-[16:32] <Kugelfang> when the proctors work we don't need the split
-[16:32] <kingtaco|work> it puts more load on infra boxes and doesn't solve anything
-[16:32] <robbat2> yeah, don't post crap to -dev.
-[16:32] <vapier> seems like splitting the lists just moves the problem around
-[16:32] <Kugelfang> vapier: agreed
-[16:32] <vapier> and when the problem surfaces elsewhere, people will split that
-[16:32] <kingtaco|work> if anything, I'd like to see lists removed
-[16:32] <kingtaco|work> consolidated with other lists
-[16:32] <UberLord> back
-[16:33] <kingtaco|work> we have a plethora of lists that are meaningless
-[16:33] <vapier> hmm i think the lists of lists is outdated
-[16:33] <robbat2> yeah, I was looking at list stuff the other day, there's at least a dozen lists we should declare closed
-[16:33] <vapier> ive had some of the embedded ones killed off and consolidated
-[16:33] <robbat2> because nobody has used them for more than a year
-[16:33] --> Uber (n=uberlord@gentoo/developer/UberLord) has joined #gentoo-council
-[16:33] --- ChanServ sets modes [#gentoo-council +o Uber]
-[16:33] <robbat2> i'll take point on that if you want
-[16:33] <vapier> robbat2: can you compile said list and post to dev ?
-[16:34] <robbat2> yeah, will do
-[16:34] <Kugelfang> Uber: flakey connection?
-[16:34] <-- UberLord (n=uberlord@gentoo/developer/UberLord) has left #gentoo-council
-[16:34] <vapier> i think he has multiple computers
-[16:34] <Uber> multiple locations - am now at home
-[16:34] <kloeri> sorry, my internet connection dropped out - been on and off all evening
-[16:35] <vapier> "I think some people are arguing that splitting gentoo-dev and *requiring* devs to follow a list with only announcements, would reduce the stress to devs"
-[16:35] <vapier> yeah / neah ?
-[16:35] <Kugelfang> nay
-[16:35] <kingtaco|work> nay
-[16:35] <robbat2> a lot don't follow -dev already
-[16:36] <wolf31o2|mobile> I think it would... but I'd say nay for now... let's see what the proctors do for the situation before enacting any further measures
-[16:36] <robbat2> so it's a pointless request
-[16:36] <Kugelfang> wolf31o2|mobile: agreed with the later
-[16:36] <robbat2> who here didn't mark at least some part of the flamewars threads as read without reading the entire thing?
-[16:36] <vapier> sounds like a plan man
-[16:36] * wolf31o2|mobile didn't
-[16:36] <vapier> kmail has an option to mark a thread as read automatically
-[16:36] <Kugelfang> robbat2: i can claim i read it all
-[16:36] <wolf31o2|mobile> though I probably should have
-[16:36] <kingtaco|work> I mark a thread as spam as soon as ciaranm has more than 3 posts in it
-[16:37] <vapier> usually a safe bet
-[16:37] <Uber> i can claim that I bined most of them. Probably not the best thing but they waste my time.
-[16:37] <robbat2> Kugelfang, wolf31o2|mobile: and how many hours of your life would you like back?
-[16:37] <vapier> any other input or shall we close out here ?
-[16:37] <Kugelfang> robbat2: several
-[16:37] <robbat2> nothing more for this topic I think
-[16:37] <kloeri> I'm happy to see what the proctors and CoC can do to help clean the lists up for now
-[16:37] <vapier> moving on
-[16:37] <robbat2> PMS next, then my short item (surveys)
-[16:38] <Kugelfang> excellent
-[16:38] --- vapier sets modes [#gentoo-council +v spb]
-[16:38] --- Kugelfang sets modes [#gentoo-council +v spb]
-[16:38] <vapier>  - PMS:
-[16:38] <vapier>  - status update from spb
-[16:38] <vapier>  - moving it to Gentoo svn
-[16:38] <vapier>  - schedule for getting remaining issues settled
-[16:38] <Kugelfang> darn
-[16:38] <Kugelfang> spb: are you here?
-[16:38] <spb> yes
-[16:38] --> Betelgeuse (n=betelgeu@gentoo/developer/Betelgeuse) has joined #gentoo-council
-[16:39] <vapier> you're in the spotlight bub
-[16:40] <spb> status: you presumably saw my latest -dev mail
-[16:40] <spb> plus http://tinyurl.com/2z58xn
-[16:40] <vapier> http://thread.gmane.org/gmane.linux.gentoo.devel/47944
-[16:40] <spb> yes, that one
-[16:40] <Kugelfang> i count 15 open bugs of 50
-[16:40] <Kugelfang> nice work
-[16:41] <vapier> i dont think the buglist covers all the TODO's that are in the src ?
-[16:41] <vapier> i havent checked recently
-[16:41] <Kugelfang> ahn, and i think some of those bugs are already fixed in SVN
-[16:41] <Kugelfang> vapier: i think ciaranm made sure they are in sync some days ago...
-[16:41] <spb> vapier: probably not; there's at least one TODO that says "write dohtml"
-[16:41] <spb> or was
-[16:42] <vapier> now that we have proper bugzilla tracking, no more TODO's in the src
-[16:42] <vapier> at least none w/out a bug #
-[16:42] <spb> but the general idea is to resolve the current round of bug reports and TODOs, then repeat the process until new ones stop appearing
-[16:42] <vapier> sure
-[16:42] <vapier> KingTaco: ?
-[16:42] <kingtaco|work> vapier, ?
-[16:43] <vapier> just making sure you're happy with current status
-[16:43] <vapier> dont want any blue balls
-[16:43] <kingtaco|work> it's following the timelines we decided last month, I don't have any complaints on that
-[16:44] <vapier> k, so getting it moved to gentoo infra
-[16:44] <Kugelfang> robbat2 has a plan for it
-[16:44] <vapier> robbat2: ?
-[16:44] <spb> will happen once gentoo infra can offer what the project needs
-[16:44] <Kugelfang> that allows both solar and ciaran do contribute to it
-[16:44] <robbat2> I didn't heard a solid yes on spb from that when we discussed it in -infra
-[16:44] <vapier> frankly i dont think external entities should hold up any move
-[16:45] <wolf31o2|mobile> agreed
-[16:45] <Kugelfang> vapier: but moves shouldn't be rushed either
-[16:45] <robbat2> the plan there was since infra won't allow outside people to commit to SVN, was everybody happy if they could commit to GIT instead
-[16:45] <robbat2> (and yes, that includes ciaranm)
-[16:45] <vapier> via proxy which git allows trivially, sure
-[16:45] <spb> if git can work with the central repository model without introducing extra overhead
-[16:45] <Kugelfang> vapier: plan was: people commit to git, spb pulls from git and commits to svn
-[16:46] <spb> that sounds like a pita to me
-[16:46] <robbat2> no
-[16:46] <robbat2> that wasn
-[16:46] <robbat2> 't it
-[16:46] <Kugelfang> robbat2: mail?
-[16:46] <Kugelfang> robbat2: i'm sorry
-[16:46] <robbat2> it was that it was moving to git directly, and those that spb wanted, could direct-commit for the moment, but that there would be a reviewed branch that only spb could commit to
-[16:46] <Kugelfang> i see
-[16:47] <vapier> where are we moving the EAPI project here ?  sub project of portage ?
-[16:47] <Kugelfang> vapier: QA
-[16:47] <Kugelfang> vapier: it is already a QA subproject
-[16:47] <robbat2> because spb wasn't compromising on wanting ciaranm to have direct-commit to it at the moment
-[16:47] <vapier> well no external entities should have direct access to gentoo infra
-[16:48] <vapier> that's why you become a developer
-[16:48] <Kugelfang> vapier: not true
-[16:48] <Kugelfang> vapier: see overlays
-[16:48] <vapier> true
-[16:48] <Kugelfang> vapier: it's the very same process
-[16:48] <robbat2> it depends how you define direct access
-[16:48] <Kugelfang> people commit, but it needs to be reviewed
-[16:48] <vapier> but i consider this a little more important than overlays
-[16:48] <Kugelfang> which spb does
-[16:48] <vapier> k
-[16:49] <robbat2> infra won't give any access to non-devs that needs SSH keys.
-[16:49] <vapier> put a timeframe on it to be done by next meeting then ?
-[16:49] <spb> and if you look at the sort of changes that have been going in, it's easy for me to look over them and say "yes, ok"
-[16:49] <spb> it would however be a complete pita to proxy each commit
-[16:49] <robbat2> spb: you don't have to proxy each one with git
-[16:49] <vapier> depends on the scm
-[16:49] <robbat2> you can just do: 'git pull foo-from-ciaranm && git push ...'
-[16:49] <robbat2> done
-[16:50] <spb> if git lets him commit to one branch and have me pull all updates since i last did in one command then that works for me
-[16:50] <robbat2> where foo-from-ciaranm is the tree of all his changes
-[16:50] <vapier> i think here we just need to agree on a time frame
-[16:50] <vapier> you guys can hash it out in -infra
-[16:50] <robbat2> ok, then that's solved without any extra access :-)
-[16:50] <spb> this also relies upon him being able and willing to use git
-[16:50] <robbat2> since the merging is easier than you thought
-[16:51] --> ferringb (n=bharring@c-67-171-130-60.hsd1.or.comcast.net) has joined #gentoo-council
-[16:52] <vapier> eh eh eh ?
-[16:52] <vapier> get the infra stuff resolved by next meeting ?
-[16:52] <spb> i'm willing to try it, but there are other parties than me involved
-[16:52] <robbat2> yeah, i'll have a git tree for people to suck down before the weekend is over
-[16:52] <vapier> thats the other parties problem
-[16:52] <vapier> not ours
-[16:52] <kingtaco|work> it's not just him that gets a say
-[16:52] <kingtaco|work> it's our devs
-[16:53] * Uber nods
-[16:53] <spb> 'our devs' has to include the people actually working on pms
-[16:53] <vapier> no it doesnt
-[16:53] <spb> because i'm not going to move if it means losing those contributions
-[16:53] <spb> basically
-[16:54] <vapier> well either it gets moved voluntarily or not so much voluntarily
-[16:54] <vapier> you guys can hash it out in #-infra and post notes to the council alias as "significant" issues arise
-[16:55] <robbat2> council ML, not the alias
-[16:55] <vapier> err yes, sorry
-[16:55] <Kugelfang> nod
-[16:55] <robbat2> anything more on PMS?
-[16:55] <vapier> do we want to talk about a timeframe for EAPI-0 ?
-[16:56] <vapier> or let the current round of feedback go through and assume that it'll work itself out in the next month
-[16:56] <kingtaco|work> I think it's best to let the devs figure it out
-[16:56] <Kugelfang> it is
-[16:56] <vapier> k
-[16:57] <wolf31o2|mobile> agreed
-[16:57] <kloeri> agreed
-[16:57] <Kugelfang> robbat2: can you write some lines for me on your implementation plan?
-[16:57] <robbat2> yeah, let it work itself out in the next month
-[16:57] <Kugelfang> robbat2: per mail or /msg?
-[16:57] <robbat2> Kugelfang, I will later, I have to go out after this meeting
-[16:57] <Kugelfang> robbat2: re PMS on gentoo infra that is
-[16:57] <Kugelfang> robbat2: sure, sure!
-[16:57] <robbat2> ok, the one last item I had, just as a quick show of hands from council
-[16:58] <vapier> sure
-[16:58] <vapier> i think the last checklist items i have will get knocked out quickly
-[16:58] <robbat2> AFTER the 2007.0 release is out, I feel we should redo the original user survey
-[16:58] <robbat2> that lead to the releases being bi-annual
-[16:58] <kingtaco|work> I vote yes
-[16:58] <robbat2> to see what users consider of the various directions of Gentoo
-[16:58] <vapier> how were the previous ones handled ?
-[16:58] <vapier> i didnt know we had a survey until it was completed
-[16:59] <robbat2> we've only done one before
-[16:59] <vapier> but yes, a new survey posted to frontpage and such sounds good
-[16:59] <wolf31o2|mobile> robbat2: that survey had nothing to do with the releases being bi-annual, by the way
-[16:59] <robbat2> wolf31o2|mobile, oh, the way it read there was overwelming support for bi-annual releases
-[16:59] <wolf31o2|mobile> agreed... I wouldn't mind seeing a new survey done... and hopefully, done on a regular basis
-[17:00] <vapier> we should do a survey after each release ;P
-[17:00] <wolf31o2|mobile> robbat2: sure it does... but it was after we'd already switched... heh
-[17:00] <vapier> bi annual surveys
-[17:00] <vapier> slashdot poll style
-[17:00] <robbat2> and on a second part of surveying, could we add a specific developer survey, to help identify the demographics and activity level of developers?
-[17:01] <wolf31o2|mobile> sounds good
-[17:01] <robbat2> i'm willing to take on both of these items
-[17:01] <vapier> could make that part of the recruitment process
-[17:01] <vapier> and leave it open all the time ...
-[17:01] <robbat2> vapier: no, just annually, closer to a census
-[17:01] <vapier> so you have "up-to-date" numbers all the time ...
-[17:01] <vapier> pfft
-[17:01] <vapier> Kugelfang / kloeri / Uber ?
-[17:02] * Uber votes yes
-[17:02] <Kugelfang> moment
-[17:02] <vapier> http://staff.osuosl.org/~cshields/gentoosurvey/#doc_chap8
-[17:02] <Kugelfang> annual: yes
-[17:03] <vapier> s/annual/doing surveys/ :p
-[17:03] <vapier> robbat2: i think that shows we like the idea of surveys
-[17:03] <vapier> cshields' previous one would prob be a good starting point, but we'll leave that to you
-[17:03] <vapier> do it under the pr project ?
-[17:03] <vapier> userrel ?
-[17:03] <robbat2> yeah, i'll look at them for after the 2007.0 release is completed, since I want releng's help on some of the user questions
-[17:04] <robbat2> PR probably
-[17:04] <vapier> just wanting the surveys on gentoo.org/ rather than random dev space
-[17:04] <vapier> a few quickies i think
-[17:04] <robbat2> yeah, definetly. we previously used survey.gentoo.org
-[17:05] <vapier> nattfodd: limiting ourselves
-[17:05] <vapier> http://article.gmane.org/gmane.linux.gentoo.devel/47683
-[17:05] <vapier> i think the response seemed to be "if you dont like actions, then let us know on -dev and/or vote the bums out"
-[17:06] <robbat2> i agree there, if we overstep our bounds, more than just the usual vocal minority will complain
-[17:06] <vapier> i'm big on g2boojum in general and his opinion was that the original structure was designed this way on purpose
-[17:06] <vapier> so i'm happy to defer to him
-[17:07] <-- pioto has quit (Client Quit)
-[17:07] <wolf31o2|mobile> I'd agree
-[17:07] <vapier> anyone else ?  KingTaco kloeri Kugelfang Uber ?
-[17:07] <Kugelfang> we are elected for one year. the next council can revert anything we do
-[17:07] <vapier> true
-[17:07] <Kugelfang> i don't see a problem there
-[17:07] --> |mpagano| (n=mpagano@pool-70-105-167-17.nwrknj.fios.verizon.net) has joined #gentoo-council
-[17:07] <Uber> i'm fine
-[17:07] <kingtaco|work> this still about surveys?
-[17:08] <Uber> yes
-[17:08] <vapier> heh
-[17:08] <kingtaco|work> I still vote yes
-[17:08] <vapier> KingTaco: limiting council's power
-[17:08] <kingtaco|work> eh?
-[17:08] <vapier> http://article.gmane.org/gmane.linux.gentoo.devel/47683
-[17:08] <kingtaco|work> limiting to what or how
-[17:08] <wolf31o2|mobile> I agree... about the only thing I would see would be adding a provision allowing for reopening nominations/voting if >=50% of the entire developer pool votes to do so... since that would mean we majorly screwed the pooch
-[17:08] <kingtaco|work> oh, I think that's stilly
-[17:08] <kingtaco|work> *silly
-[17:09] <vapier> k
-[17:09] <kingtaco|work> you don't like it, don't vote for those people next time
-[17:09] <vapier> wolf31o2: you mean a vote of no confidence ?
-[17:10] <wolf31o2|mobile> vapier: right... just currently there's nothing in place for such a thing to occur... I tend to agree with taco that it should just wait for the next elections... but a compromise could be to add that specific wording to allow a >=50% vote
-[17:10] <wolf31o2|mobile> and this wouldn't be on a specific issue
-[17:10] <vapier> we dont have any real way of measuring that
-[17:10] <wolf31o2|mobile> I mean on the whole council... just like a vote of no confidence
-[17:10] <wolf31o2|mobile> we know how many devs we have
-[17:10] <vapier> right
-[17:11] <robbat2> we don't have an accurate take on how many of them are active
-[17:11] <vapier> but do you e-mail them all ?  post to -core ?
-[17:11] <kingtaco|work> devs could already do a vote of no confidence
-[17:11] --> pioto (n=pioto@gentoo/developer/pioto) has joined #gentoo-council
-[17:11] <wolf31o2|mobile> vapier: *we* don't do anything...
-[17:11] <vapier> we dont have anything on dev.g.o to count it up
-[17:11] <kingtaco|work> I'd accept it if they had 50% of devs with gpg sigs
-[17:11] <robbat2> if 20% are really inactive, that means the remaining 80% needs more than 50% in favour
-[17:11] <kingtaco|work> make that 51%
-[17:12] <kingtaco|work> but I still think the entire thing is silly
-[17:12] <wolf31o2|mobile> ok... let's simplify this
-[17:12] <vapier> i think generally if there's a majority of the dev base who want us out, we'd see the reaction
-[17:12] <Kugelfang> agreed
-[17:12] <wolf31o2|mobile> do we think we need to write specific wording into the council glep to allow for a vote of no confidence, or is that implied? yes or no
-[17:12] <robbat2> no
-[17:12] <kingtaco|work> no
-[17:12] <wolf31o2|mobile> no here
-[17:13] <Kugelfang> no
-[17:13] <Uber> no
-[17:13] <vapier> you had two questions and expected a yes/no :p
-[17:13] <wolf31o2|mobile> I agree, if all of a sudden devs all over the place are ripping us a new one, it'll be obvious
-[17:13] <wolf31o2|mobile> heh
-[17:13] <wolf31o2|mobile> vapier: eat it
-[17:13] <vapier> i dont think we need to expand the GLEP
-[17:13] <wolf31o2|mobile> thanks
-[17:13] <vapier> as you say, we'd get ripped
-[17:13] <wolf31o2|mobile> sorry, that was what I meant to ask
-[17:13] <vapier> tag it and bag it then
-[17:13] <wolf31o2|mobile> k
-[17:13] <robbat2> FYI, I have to leave in ~10 minutes for a work meeting
-[17:13] <vapier>  - a time frame on moving gentoo-core to public archives
-[17:14] <wolf31o2|mobile> <-- never
-[17:14] <vapier> i think people we generally against this with some for it
-[17:14] <robbat2> i agree with never
-[17:14] <kingtaco|work> vapier, while I wouldn'
-[17:14] <vapier> but some noted that they would be less forth coming on -core if this happened
-[17:14] <robbat2> never, and be more proactive on telling people to move stuff to -dev
-[17:14] <kingtaco|work> vapier, while I wouldn't oppose doing it from this point forward, we can't leak out old stuff on -core
-[17:15] <vapier> i tend to be on the extreme where i have no problem with people reading anything/everything i say/do
-[17:15] <vapier> except for the man
-[17:15] <vapier> Kugelfang / Uber / kloeri ?
-[17:15] <kingtaco|work> that said, I'm pretty sure it leaks out anyway
-[17:15] <vapier> true, but as long as people have that warm fuzzy
-[17:16] <Uber> i have no issue with future stuff being publically avaiable
-[17:16] <Kugelfang> vapier: 1 year frame
-[17:17] <vapier> while i would post my stuff freely, i dont feel comfortable forcing others who feel they would not use the list anymore if it were moved publically
-[17:18] <kingtaco|work> I think that's a majority
-[17:18] <vapier> robbat2: any idea when we could at least get a dev-only archive of -core ?
-[17:18] <kingtaco|work> that said, most of those people don't post to -core
-[17:18] <vapier> that's still a critical missing archive
-[17:18] <kingtaco|work> so it's more of a hypothetical
-[17:19] <vapier> anyone want to pursue this further ?  otherwise we'll stick with the status quo
-[17:19] <Kugelfang> robbat2: what about a readonly maildir?
-[17:19] <robbat2> i have a -core archive that is complete as of a few months before I joined Gentoo
-[17:20] <kingtaco|work> Kugelfang, that still breaks the privateness of the list
-[17:20] <kingtaco|work> perceived or otherwise
-[17:20] <Kugelfang> huh?
-[17:20] <vapier> ive been deleting mine so i only go back to late 2005
-[17:20] <Kugelfang> i mean on dev-only right now
-[17:20] <kingtaco|work> Kugelfang, I know
-[17:20] <Uber> i purge mine on a regular basis
-[17:21] <robbat2> the problem with that is that it still doesn't help cases where the -core stuff leaks out
-[17:21] <wolf31o2|mobile> I mostly purge mine... keep important stuff
-[17:21] <vapier> that's unaddressable
-[17:21] <vapier> robbat2: i imagine there's people who have more extensive ones if infra lacks it
-[17:21] <kingtaco|work> don't use lists for things that need to be private
-[17:21] <vapier> robbat2: can we push that on you too to at least look into if not implement ?
-[17:21] <kingtaco|work> history has shown us time and time again if there are more than 2 people involved then there will be leaks
-[17:21] <robbat2> vapier: it's not the existence of archives, I put a lot of working into building up the private archive I do have of it
-[17:22] <robbat2> since I built the archive originally while studying the tree signing issue
-[17:22] <kingtaco|work> my first core message is from 7/28/03
-[17:23] <vapier> i think that's about all the topics i have ... unless we want to open the floor for qa/metastructure talks
-[17:23] <kingtaco|work> then nothing until 11/18/04
-[17:23] <robbat2> that's it
-[17:23] <robbat2> and I have to leave in 2 minutes
-[17:24] <vapier> k k
-[17:24] --- vapier sets modes [#gentoo-council -m]
-[17:25] <vapier> on the topic of nattfodd's metastructure proposal, i dont think it was a proper solution for any issues he proposed it'd solve
-[17:25] <Kugelfang> speak now or remain silent forever!
-[17:25] <robbat2> i'm leaving now
-[17:25] <robbat2> thanks guys
-[17:25] <vapier> and in the process cause more issues that Gentoo generally doesnt want to address (split trees and such)
-[17:26] --- robbat2 is now known as robbat2|na
-[17:26] <kingtaco|work> vapier, I don't think there is anything positive in that proposal
-[17:26] <Uber> i read it seems to divide up more, which is bad imo
-[17:26] <amne> btw, i'm here now, sorry for being late
-[17:27] <marienz> (floor is open now, right?)
-[17:27] <eroyf> looks like it
-[17:27] <marienz> (just checking you didn't go unmoderated and then brought up a point you forgot)
-[17:28] <vapier> we're not voting on metastructure
-[17:28] <vapier> open discussion
-[17:28] <marienz> think it's a bit of a hybrid of mainly massive tree management/infrastructure changes and organizational changes that aren't *that* far from where we are now.
-[17:28] <Jokey> imho he's proposing something debian did in the past and lead to their current situation
-[17:28] <-- Blacksito has quit ("http:\\www.tekkenbolivia.net")
-[17:28] <Kugelfang> i don't consider the fragmentation of gentoo a good plan
-[17:28] <Kugelfang> that's about all i will comment on it :-)
-[17:28] <Jokey> neither do I
-[17:28] <marienz> having somewhat autonomous projects may be worthwhile but splitting up the tree in the process seems like a bad idea to me.
-[17:29] <Jokey> the "you fetch one and get all" principle is one big plus point for gentoo
-[17:29] * beandog agrees with vapier
-[17:29] <marienz> both because it's inconvenient from an end user pov and because the infra changes required are pretty massive.
-[17:29] <marienz> (I mean we still haven't moved from cvs to svn or git or something at all yet, and this is a considerably bigger change than that...)
-[17:29] <beandog> if the workload to dev ratio is too high, then get rid of some of the workload.
-[17:32] <marienz> also re: splitting the -dev list into -dev and -dev-announce: I think some devs not reading -dev at all is a reason for that split, not against it.
-[17:33] <marienz> if there is a separate -announce list those devs may start reading that list again, which would be good imho
-[17:33] <vapier> we didnt say that was a reason against it
-[17:33] <jmbsvicetto> marienz: agreed
-[17:33] <marienz> I agree entirely to delay the decision and see if the proctors project can change the atmosphere on -dev though.
-[17:33] <wolf31o2|mobile> beandog: IMO, the workload to dev ratio isn't high... the workload to active dev ratio is, maybe... though I'd say the solution is more people that are willing to do a *ton* of work, versus more people maintaining a very tiny number of packages
-[17:34] <jmbsvicetto> I think there's also another point, people not reading -dev are actually violating gentoo policy!
-[17:34] <beandog> yah
-[17:34] <jmbsvicetto> The devmanual states that all gentoo devs *must* follow -dev
-[17:34] <beandog> follow or subscribe?
-[17:34] <jmbsvicetto> beandog: well subscribe, but I would say that also implies knowing what's going on
-[17:34] <beandog> nope, no implications! :)
-[17:34] <jmbsvicetto> hehe
-[17:35] <beandog> wolf31o2|mobile: although Id settle for more people willing to do a moderate amount of work versus none.
-[17:35] <wolf31o2|mobile> beandog: agreed
-[17:35] <beandog> My point though was that cutting out cruft might make the workload less.  amd64 for instance  has been stagnant forever, but nobody wants to jump on until its gotten back to managable level.
-[17:36] <kingtaco|work> careful there
-[17:36] <beandog> my idea would be to kick off the cruft that has no dependencies itself, and isn't maintained and/or used
-[17:36] <beandog> kingtaco|work: speaking on terms of stable bugs, primarily.
-[17:36] * beandog clarifies
-[17:37] <beandog> we'd need gentoo-stats though before we have a good idea of what's used, what's not ... so .. yah.
-[17:37] <kingtaco|work> have you talked to genone?
-[17:37] <beandog> not recently
-[17:37] <kingtaco|work> iirc he did some stats project for last years SoC
-[17:38] <vapier> he did ... it's in svn
-[17:38] <christel> he still occasionally works on it, i dont think its completed fully as of yet
-[17:38] <vapier> sad that we still havent seen deployment of anything though
-[17:39] * beandog nods
-[17:40] <welp> what?!
-[17:40] <welp> i'm violating gentoo policy because i don't read -dev?
-[17:40] <welp> uh
-[17:40] * welp shuts up
-[17:42] * jmbsvicetto covers welp with red tape
-[17:42] <solar> vapier: I mailed you a qstats.c before.
-[17:42] <wolf31o2|mobile> dev really is required reading... it really sucks that so many people don't read it
-[17:42] <wolf31o2|mobile> of course, we might change that if we manage to get the signal/noise ratio improved
-[17:42] <marienz> it's too highvolume for me to actually fully read each and every mail
-[17:43] <marienz> I don't ignore whole threads but I sort of speedread some of them.
-[17:43] * kloeri all mail on -dev and -core
-[17:43] <kloeri> I do understand that it can be hard to keep up with the volume however
-[17:43] <wolf31o2|mobile> well, at least reading the first email of a thread is usually good enough to determine if it is something you'll need to follow... so long as people quit hijacking threads for new ideas
-[17:43] <wolf31o2|mobile> heh
-[17:44] <wolf31o2|mobile> yeah... I get about 3,000 emails a day on my g.o account, at last count
-[17:44] <jmbsvicetto> ouch
-[17:44] <wolf31o2|mobile> luckily, bunches of that is spam and tons of it is the same messages, due to being on arch teams
-[17:45] <-- YosWinK has quit (Read error: 104 (Connection reset by peer))
-[17:45] <vapier> marienz: well, i'm not so sure
-[17:45] <vapier> for any e-mail client that does threading
-[17:46] <vapier> if you snipe the first few e-mails in a thread, that covers you for most stuff i think
-[17:46] <beandog> I just read it in knode now, through gmane.
-[17:46] <vapier> i'm outs
-[17:46] <marienz> that's what I usually end up doing, skipping most of the rest of the thread unless someone hijacks it :)
-[17:47] <amne> speaking of hijacking, anything left the council folks want to talk to me about?
-[17:47] <amne> or do you just want me to reword the CoC and then tell everyone you guys did it? :-P
-[17:48] <wolf31o2|mobile> amne: we can work on it... feel free to write up any changes and I'll make some suggestions, too... then we can throw it to -dev in a couple weeks (if not sooner)
-[17:48] <Uber> nn guys
-[17:48] <solar> bye Uber
-[17:48] <welp> nn Uber m'dear
-[17:48] <Kugelfang> nn Uber , i'm gone to bed now to
-[17:48] <Kugelfang> +o
-[17:49] <amne> wolf31o2|mobile: by we you mean yourself or the council?
-[17:49] <amne> bye Uber + Kugelfang
-[17:49] <wolf31o2|mobile> amne: myself... I got the short straw
-[17:49] <wolf31o2|mobile> ;]
-[17:49] <amne> wolf31o2|mobile: haha. :-P perhaps it's a good idea to add you to the proctors alias then as i usually run stuff through there anyway
-[17:50] <amne> wolf31o2|mobile: otherwise i'll end up forgetting to cc: you on the relevant mails
-[17:51] <wolf31o2|mobile> anmsure
-[17:51] <wolf31o2|mobile> amne: sure
-[17:51] <amne> wolf31o2|mobile: good, now we just need to find someone from infra to poke
-[17:51] <wolf31o2|mobile> KingTaco: ^^^
-[17:52] * amne gets the 10 foot pole
-[17:59] <-- TheCoop has quit (Client Quit)
-[18:16] <kingtaco|work> eh?
-[18:16] <kingtaco|work> just send me an email or file a bug for stuff like that
-[18:16] <kingtaco|work> I'm not doing non-emergency stuff at work anymore
-[18:18] <amne> kingtaco|work: done
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070424-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070424-summary.txt
deleted file mode 100644
index a3660ffa94..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070424-summary.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-A subset of council members decided today that multiple version suffixes 
-are illegal in the tree pending further notice. This decission can be 
-appealed at the next Council meeting. If there is sufficient public 
-demand, an earlier meeting can be held.
-
-This decission has been made to prevent sufficient precedence for 
-unilateral changes to the tree structure. So far the following package 
-versions are considered illegal:
-
-  media-viode/mplayer-1.0_rc2_pre20070321-r4
-  media-video/transcode-1.0.3_rc2_p20070310-r1
-
-An illegal version specification of media-sound/alsa-driver has already 
-been removed from the tree.
-
-I would like to ask the affected package maintainers to move these 
-versions to sane version specifications as soon as possible. Thanks in 
-advance for this.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070424.txt b/xml/htdocs/proj/en/council/meeting-logs/20070424.txt
deleted file mode 100644
index 78315ebb45..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070424.txt
+++ /dev/null
@@ -1,130 +0,0 @@
---- Log opened Tue Apr 24 00:00:49 2007
-01:04 -!- FuzzyRay|work [n=pvarner@gentoo/developer/FuzzyRay] has quit [Remote closed the connection]
-02:43 -!- robbat2 is now known as robbat2|na
-03:40 -!- mpagano [n=mpagano@pool-70-105-167-17.nwrknj.fios.verizon.net] has joined #gentoo-council
-03:55 -!- mpagano [n=mpagano@pool-70-105-167-17.nwrknj.fios.verizon.net] has quit [Client Quit]
-07:34 -!- KingTaco [n=kingtaco@gentoo/developer/kingtaco] has quit ["brb"]
-07:36 -!- KingTaco [n=kingtaco@gentoo/developer/kingtaco] has joined #gentoo-council
-07:36 -!- mode/#gentoo-council [+o KingTaco] by ChanServ
-13:19 -!- onox [n=onox@kalfjeslab.demon.nl] has joined #gentoo-council
-14:18 -!- fmccor|home [n=fmccor@gentoo/developer/fmccor] has quit [Read error: 110 (Connection timed out)]
-14:22 -!- fmccor|home [n=fmccor@209.249.182.18] has joined #gentoo-council
-15:52 -!- FuzzyRay|work [n=pvarner@gentoo/developer/FuzzyRay] has joined #gentoo-council
-19:51 -!- Calchan|Home [n=Calchan@gentoo/developer/calchan] has joined #gentoo-council
-20:14 -!- robbat2|na is now known as robbat2
-20:16 <@Kugelfang> rest-of-council: ping
-20:18 < Jokey> KingTaco kloeri robbat2 SpanKY wolf31o2 ping
-20:18 <@Kugelfang> :-)
-20:18 < Jokey> highlight++
-20:18 <@Kugelfang> thanks Jokey
-20:20 <@kloeri> hiya Kugelfang, Jokey 
-20:20 <@Kugelfang> kloeri: heya...
-20:21  * Jokey passes kloeri a beer
-20:21 <@Kugelfang> kloeri: i'm a bit fed up about the mplayer version problem
-20:21 <@kloeri> me too
-20:21 <@Kugelfang> kloeri: i was planning to contact lu_zero so he moves it to a proper revision
-20:22 <@kloeri> sounds good
-20:22 <@Kugelfang> kloeri: as we need at least to council members do decide on that, i'd like a proper "yes" :-)
-20:22 <@robbat2> yo
-20:23 <@Kugelfang> robbat2: you also think it should be moved?
-20:23 <@kloeri> well, is it really neccessary to have a council decision on that issue?
-20:23 <@robbat2> i'm not aware of the problem (i don't pay attension to video stuff, and I haven't read my mail for the last 18 hours)
-20:23 <@Kugelfang> robbat2: no recent problem... it's in for 4 weeks already
-20:23 <@Kugelfang> http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/mplayer/
-20:23 <@Kugelfang> robbat2: have a look at that last version
-20:24 < spb> the short answer is that mplayer is using an invalid version spec
-20:24 <@Kugelfang> QA demanded to remove it already
-20:24 <@Kugelfang> (iirc)
-20:24 < zlin> bug #166522
-20:24 < jeeves> zlin: https://bugs.gentoo.org/166522 nor, P2, All, vapier@gentoo.org->dev-portage@gentoo.org, REOPENED, pending, portage should only accept one version suffix
-20:25 < Jokey> hrm, wasn't there some announcement that portage added support for it?
-20:25 < spb> Jokey: none that i saw
-20:25 < spb> and portage gaining support in some version doesn't mean you can use it in the tree
-20:25 <@robbat2> make him covert it to "_rc%04d%04d%02d%02d",$RC,$YEAR,$MONTH,$DAY
-20:26 <@robbat2> or some useful variation if they want the dang date
-20:27 <@kloeri> that would be much better imo
-20:28 <@kloeri> _alpha_beta and whatever else is allowed by portage now doesn't make any sense imo (and neither does _rc_alpha or a thousand other combinations)
-20:29 <@Kugelfang> so can we conclude that multiple version suffixes are illegal in the tree?
-20:29 <@Kugelfang> until council says otherwise?
-20:29 < spb> imo yes
-20:29 <@Kugelfang> robbat2, kloeri?
-20:30 <@robbat2> yeah, i'm good with that
-20:30 <@Kugelfang> me too
-20:30 <@robbat2> in my above example, i can't recall if portage cares about leading zeros on the rc number or not
-20:30 <@Kugelfang> kloeri?
-20:30 <@kloeri> yes
-20:31 <@Kugelfang> okies
-20:31 <@Kugelfang> I'll draft a mail and file bugs
-20:34 < solar> alsa-something was doing the same thing a little while ago also.
-20:36 < solar> media-video/transcode-1.0.3_rc2_p20070310-r1 <-- there is the other. alsa seems to be ok now.
-20:36 <@Kugelfang> solar: nod, thanks for the heads up
-20:50 <@Kugelfang> kloeri, robbat2: http://rafb.net/p/1vVpR133.html
-20:51 <@Kugelfang> 'council member' -> 'council members' already done
-20:52 <@Kugelfang> 'considere' -> '&d' done, too
-20:53  * Kugelfang prods kloeri 
-20:55 <@kloeri> Kugelfang: looks good
-20:55 <@Kugelfang> cool
-20:55 <@Kugelfang> sending it
-20:55 <@Kugelfang> done
-20:56 <@kloeri> k
-21:06 -!- weckle247 [n=weckle@p57B1BC7E.dip0.t-ipconnect.de] has joined #gentoo-council
-21:15 < tove> Kugelfang: "Upon making such a decision, the Gentoo Council mailing list must be notified." --> CC: gentoo-council@
-21:16 <@Kugelfang> sorry, i read alias somehow
-21:16 <@robbat2> and s/viode/video/
-21:16 <@Kugelfang> will correct that now
-21:16 <@Kugelfang> it is sent already
-21:16 <@robbat2> yeah, I was afk
-21:17 <@Kugelfang> tove: thanks for the heads up!
-21:17 <@Kugelfang> tove: i corrected my mistake
-21:25 -!- mpagano [n=mpagano@pool-70-105-167-17.nwrknj.fios.verizon.net] has joined #gentoo-council
-21:32  * fmccor notices that someone has problems counting ("as few as one council member ...") :)
-21:32  * fmccor hides
-21:34  * agaffney notices that some people see conspiracies everywhere and will bitch about anything
-21:34 < spb> someone has a problem not being a twit
-21:34 < agaffney> wtf was up with the paludis conspiracy theory?
-21:34 < agaffney> people--
-21:34 < agaffney> I'm not a paludis groupie, and *I* think that's completely fscking retarded
-21:35 <@Kugelfang> see my response
-21:35 < spb> please to reply to him and say so
-21:36 <@Kugelfang> please don't
-21:41 <@kloeri> the conspiracy theory is a bit much but replying will probably just lead to further silliness and/or flames
-21:43 < solar> robbat2: The $RC$YYYY$MM$DD solution you proposed is not exactly ideal either. atom numerics probably will need to be limited to 8 numeric chars in the future.
-21:43 -!- weckle247 [n=weckle@p57B1BC7E.dip0.t-ipconnect.de] has quit [Remote closed the connection]
-21:44 <@Kugelfang> $RC$YY$MM$DD should be sufficient
-21:44 < solar> as long as $RC does not exceed 99
-21:45 <@Kugelfang> nod
-21:45 <@Kugelfang> and -r$REV doesn't exceed 99999999 :-)
-21:46 <@kloeri> heh
-21:46 < solar> that is not set in stone yet. But should probably be an item for later discussions to set that in stone
-21:47 <@Kugelfang> solar: definitely
-21:48  * solar has one offending package right now.
-21:48 <@Kugelfang> that is?
-21:49 < solar> gradm
-21:49 <@Kugelfang> cat?
-21:50 < solar> !meta gradm
-21:50 < jeeves> solar: Package: sys-apps/gradm Herd: hardened Maintainer: solar@gentoo.org
-21:50 <@Kugelfang> nod
-21:50 < solar> on a 64bit arch these compare as equals. x-200602141801111111111111111111111111111111111111111111111111111111 == x-20060214180999999999
-21:51 < solar> well I guess it's not 64bit per say but rather sizeof int
-21:52 -!- zxy_64 [n=ziga@89.212.157.253] has joined #gentoo-council
-22:10 <@Kugelfang> nod
-22:21 < fmccor> sigh.  We have a new important thread, it seems.
-22:21 < agaffney> ugh
-22:25 < agaffney> wow, wtf is Cardoe's problem?
-22:25 < fmccor> My question exactly.
-22:26 < agaffney> did a paludis dev rape his mother?
-22:27 < fmccor> He could join this channel and ask directly, rather than providing all the entertainment on -dev :)
-22:27 < spb> he likes to cause drama
-22:28 < fmccor> Or he could work in gentoo-council@ for that matter (I think).
-22:28 < fmccor> Or he could go do something useful. :)
-22:39 <@kloeri> heh
-22:40 <@Kugelfang> did my mail arrive at gentoo-council@l.g.o?
-22:41 <@kloeri> no idea, I kill repeats based on msgid
-22:41 <@kloeri> so I only got it on -dev in this case
-22:41 <@Kugelfang> i forwarded it later on
-22:42 <@kloeri> don't think I've got that yet
-22:42 <@kloeri> but MLs can be quite slow sometimes
-22:57 -!- onox [n=onox@kalfjeslab.demon.nl] has quit ["baselayout-2 \o/"]
-22:57 -!- rbrown` [n=mynamewa@gentoo/developer/paludis.rbrown] has joined #gentoo-council
-23:42 -!- FuzzyRay|work [n=pvarner@gentoo/developer/FuzzyRay] has quit [Remote closed the connection]
---- Log closed Wed Apr 25 00:00:51 2007
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070510-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070510-summary.txt
deleted file mode 100644
index 8a857122f7..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070510-summary.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-- Documentation for mail servers are on gentoo.org
-  now in infrastructure project
-
-- Social contract changes are waiting on the trustees
-  to clarify the Foundation statement
-  http://bugs.gentoo.org/177966
-
-- proctors have been working on requested CoC updates
-  but has not yet finished
-
-- multiple version suffixes are valid and free to be
-  used in the tree
-
-- PMS git repo is being finalized by robbat so it can
-  be moved over
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070510.txt b/xml/htdocs/proj/en/council/meeting-logs/20070510.txt
deleted file mode 100644
index bafd628494..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070510.txt
+++ /dev/null
@@ -1,576 +0,0 @@
-[16:01] * fmccor is here representing Kugelfang
-[16:01] * wolf31o2 is mostly here
-[16:01] <KingTaco> I'm here
-[16:02] <KingTaco> kloeri, robbat2|na SpanKY vapier Uber
-[16:02] <vapier> moo moo mr cow
-[16:02] <kloeri> hiya all
-[16:02] <KingTaco> anyone have the agenda for today?
-[16:03] <wolf31o2> that would be nice
-[16:03] <vapier> none were posted
-[16:03] <Uber> I'm here sort of.
-[16:03] <vapier> so i figured we just go over things from last
-[16:03] <vapier> unless someone saw something i didnt
-[16:03] * KingTaco defers to vapier 
-[16:03] <vapier> i meant to post something, but i didnt get a chance ... been busy at work
-[16:03] <KingTaco> only new thing I know of is the multiple suffixes stuff
-[16:04] <KingTaco> from that adhoc meeting
-[16:05] <kloeri> I've been pretty busy as well
-[16:05] <Uber> brb 5 mins
-[16:06] <vapier> was a log posted from said adhoc meeting ?
-[16:06] <vapier> http://thread.gmane.org/gmane.linux.gentoo.devel/48381
-[16:07] <KingTaco> I don't recall a log
-[16:07] <KingTaco> iirc it was Kugelfang, kloeri and robbat2|na
-[16:08] <kloeri> I don't think the log was ever posted, just the notice kugelfang sent to -dev and following discussion
-[16:08] <vapier> that'd be useful to have ... i dont think the decision made sense and the logic for banning it didnt cut it for me
-[16:08] <kloeri> yup
-[16:08] <vapier> but let's start on something simpler first
-[16:08] <vapier> anyone voluntering to run this meeting ?
-[16:09] <wolf31o2> since Danny isn't here, I say we make Ferris do it
-[16:09] <wolf31o2> *grin*
-[16:09] <Uber> gets my vote :P
-[16:09] --> bazik (n=bazy@gentoo/developer/bazik) has joined #gentoo-council
-[16:09] <vapier> fmccor: you want to take it ?
-[16:09] <kloeri> heh
-[16:09] --- vapier sets modes [#gentoo-council +m]
-[16:10] --- vapier sets modes [#gentoo-council +v fmccor]
-[16:10] --- vapier sets modes [#gentoo-council +v fmccor|home]
-[16:10] <vapier> help if he could speak huh :)
-[16:10] <wolf31o2> guess not... ok... how about I do it
-[16:10] <fmccor> :)
-[16:11] <wolf31o2> now I just have to find last month's
-[16:11] <vapier> http://www.gentoo.org/proj/en/council/meeting-logs/20070412-summary.txt
-[16:11] <wolf31o2> ok... let's go over that stuff, then tove reminded me that we have grobian's keywording glep
-[16:11] <wolf31o2> http://article.gmane.org/gmane.linux.gentoo.devel/48017
-[16:12] <vapier> you get your docs merged ?
-[16:12] <kloeri> k, the log from that impromptu meeting is available at http://dev.gentoo.org/~kloeri/multiple_suffix.log now
-[16:12] <wolf31o2> so... let's start with the old stuff...
-[16:12] <wolf31o2> vapier: thought robin was taking care of the actual commits
-[16:13] <wolf31o2> crap
-[16:13] <wolf31o2> it was me
-[16:13] <wolf31o2> I apologize
-[16:13] <wolf31o2> I guess that makes it a no.  I didn't.
-[16:14] <wolf31o2> did we ever decide where exactly they were to go?
-[16:14] <kloeri> my spf doc is all xml'ed up and available on infrastructure.g.o
-[16:14] <kloeri> have been for a while now
-[16:14] <vapier> under the infra project
-[16:14] <vapier> since they manage the mail
-[16:15] <wolf31o2> yes, but were we just putting them up as-is or were we adding it into another doc?
-[16:16] <vapier> for now, as is
-[16:16] <wolf31o2> k
-[16:16] <vapier> let em be folded back as infra deems they care enough to do so
-[16:17] <wolf31o2> done, then... heh
-[16:17] <KingTaco> what doc is this?
-[16:18] <vapier> mail server docs
-[16:18] <vapier> spf and reply to
-[16:18] <wolf31o2> ok... everything is committed
-[16:18] <KingTaco> I thought robbat2 put those up somewhere
-[16:18] <KingTaco> we're all good right?
-[16:18] <wolf31o2> are now
-[16:18] <KingTaco> ok
-[16:18] <-- ian (i=need_hel@gentoo/developer/pdpc.active.ian) has left #gentoo-council
-[16:19] <wolf31o2> I think we should file a bug for the trustees
-[16:19] <KingTaco> a bug for what purpose?
-[16:19] <wolf31o2> for the social contract thing
-[16:19] --> rbu (n=rbu@gentoo/developer/rbu) has joined #gentoo-council
-[16:19] <g2boojum> I saw the comment in the last summary, but I wasn't sure exactly what was needed.
-[16:20] <wolf31o2> basically, the two should be in sync and things should be clarified... I can't comment further since I didn't see what needed to be changed, personally
-[16:21] <vapier> sync Social Contract with Gentoo Foundation (external entities)
-[16:21] <vapier> the Gentoo Foundation statement has a section about external entities influence
-[16:21] <vapier> the Social Contract does not
-[16:21] <g2boojum> vapier: Oh, that helps enormously.  Thanks.
-[16:22] <vapier> i proposed that we sync the wording from Foundation to Social Contract, but wolf31o2 wanted to clarify the Foundation statement first
-[16:22] <vapier> i'm guessing he hasnt had a chance to drop an e-mail to the trustee list, so he'll file a bug instead for tracking
-[16:23] <wolf31o2> yeah... it's another of those cases where what was written is so generic it has no real meaning
-[16:23] <g2boojum> wolf31o2: Yeah.  Especially since the Foundation _is_ reigned by a company, the Gentoo Foundation, Inc.  In any event, we'll take care of it.  Thanks.
-[16:24] <wolf31o2> right
-[16:25] <wolf31o2> bug #177966
-[16:26] <wolf31o2> ok... about the CoC... I poked amne earlier, but didn't get a response... I think he's away at the moment
-[16:27] <wolf31o2> I'm not aware of any actual changes to the document, but do know that the proctors were working on it
-[16:27] <vapier> yeah they posted a few status tidbits previously
-[16:27] <fmccor> wolf31o2, On the bug, could you please give a reference to the document in question?
-[16:27] <kloeri> amne couldn't be around for tonights meeting but they don't have any updates yet
-[16:27] <KingTaco> I don't think anything has changed
-[16:27] * fmccor is behind here.
-[16:27] --> ferringb (n=bharring@c-67-171-130-60.hsd1.or.comcast.net) has joined #gentoo-council
-[16:30] <wolf31o2> KingTaco: robbat2|na: any word on a dev-only archive for -core?
-[16:30] <KingTaco> wolf31o2, I'm not involved in that
-[16:30] <wolf31o2> right, but do you know anything about it?
-[16:30] <KingTaco> nope
-[16:30] <wolf31o2> k
-[16:30] <KingTaco> the people to talk to are probably robbat2|na and solar
-[16:30] <wolf31o2> alright...
-[16:31] <wolf31o2> also, 2007.0 is out now, so we can get to working on the survey... Robin said he would look at it
-[16:31] <wolf31o2> just wanted to note that
-[16:32] <wolf31o2> so I guess all that is left is PMS unless someone has something else
-[16:32] <Uber> grobians glep is what's left
-[16:32] <wolf31o2> right... sorry
-[16:33] <wolf31o2> so PMS then the GLEP?
-[16:33] <KingTaco> I think ferringb had something too
-[16:33] <wolf31o2> ok
-[16:33] --- KingTaco sets modes [#gentoo-council +v ferringb]
-[16:33] <KingTaco> ferringb, what were you riding me about last week?
-[16:33] <wolf31o2> heh
-[16:33] <KingTaco> he was
-[16:34] * ferringb will get out the sadle again damn it :P
-[16:35] <ferringb> KingTaco: multiple suffix; few things... 1) suggestion to block further usage, instead of forcibly punting whats there now for the future... 2) actually discuss it, since right now it's completely blocked
-[16:36] <KingTaco> aight
-[16:36] <ferringb> opinion on it's a wee bit divided to say the least, but have seen enough weird versions from upstreams that it's useful as a general mechanism- not all permutations necessarily are sane, which is really what the discussion ought be about
-[16:36] <KingTaco> anyone disagree with what Kugelfang kloeri and robbat2|na did the other week?
-[16:36] <kloeri> the point was to block usage so we could discuss it on -dev instead of tree policy just randomly changing
-[16:36] <KingTaco> anyone want to talk about it?
-[16:36] <vapier> and the proposal to workaround it by leveraging -r### is plain wrong
-[16:36] <fmccor> ++ to that.
-[16:36] <wolf31o2> well, there's two things... first, *should* we limit the suffixes, and if so, how...
-[16:37] <wolf31o2> so I guess we'll start simple... should we limit the number/usage of multiple suffixes?
-[16:37] <vapier> i agree that some combinations are weird and dont generally make sense, but i dont see any real logic as to what should be kept and what should be tossed
-[16:37] <kloeri> I'm all for multiple suffixes where it makes sense as long as we actually work that out first
-[16:37] <KingTaco> I don't see a valid case for ever having multiple suffixes
-[16:38] <vapier> KingTaco: using _p to track upstream date patches against upstream rc/beta/etc...
-[16:38] <fmccor> How does what kloeri propose differ from ferringb?
-[16:38] --> ahf (n=eroyf@gentoo/developer/paludis.minion.eroyf) has joined #Gentoo-Council
-[16:38] <wolf31o2> some upstreams suck... so anything we do without multiple suffixes is diverging from upstream versioning
-[16:38] <KingTaco> but it did remind me of an idea I had the other day
-[16:38] <KingTaco> I'll talk about it after this
-[16:39] <wolf31o2> ok... like I said, let's keep it simple...
-[16:39] <vapier> as genone said, there is no technical reason for limiting the combinations
-[16:39] <wolf31o2> vote: should we allow multiple suffixes?
-[16:39] <vapier> which is true ... if you support one combination of suffixes, you might as well make it completely arbitrary
-[16:40] <wolf31o2> I tend to agree that there's no reason to restrict it... the minute we do, somebody will make a version that does something we didn't expect and we're back to where we are now
-[16:40] <wolf31o2> and I vote yes, we should allow multiple suffixes
-[16:40] <vapier> right, i'm for it
-[16:40] * Uber votes yes also
-[16:40] <fmccor> I'll vote Kugelfang yes.
-[16:40] <KingTaco> if we're going to do multiple suffixes then we need to document the order
-[16:40] <wolf31o2> sure
-[16:40] <vapier> the order is documented
-[16:40] <fmccor> Yes.
-[16:40] <kloeri> the thing about restricting it isn't technical but users should be able to look at 5 ebuilds and see what's newest which can get rather complex with multiple suffixes imo
-[16:41] <vapier> i dont understand that argument at all
-[16:41] <KingTaco> I vote no
-[16:41] <wolf31o2> kloeri: robbat2|na: ?
-[16:41] <vapier> if a > b > c, then why do you need to document a > a.b > a.c > b
-[16:41] <kloeri> I think some cases might make sense but I don't think we should allow arbitrary combinations
-[16:41] <wolf31o2> well, I guess it goes in anyway... so now... should we limit what suffix combinations are allowed?
-[16:41] <wolf31o2> heh
-[16:42] <kloeri> imo we should
-[16:43] <vapier> i'm with genone on this ... since there is no technical limitation, imposing our own arbitrary rules on an arbitrary system seems pointless to me
-[16:43] <Uber> i'm with vapier, we shouldn't restrict needlessly
-[16:43] <wolf31o2> I agree with you/genone... I see no reason to limit it when it isn't a technical limitation we have to worry about
-[16:44] <wolf31o2> KingTaco: fmccor: robbat2|na: ?
-[16:44] <KingTaco> wolf31o2, I already voted no to multiple suffixes
-[16:44] <wolf31o2> ok...
-[16:45] <fmccor> Conditional agree.  As someone mentioned, they need to be human-decipherable without too much effort.
-[16:45] <fmccor> (Agree with vapier Uber etc)
-[16:45] <wolf31o2> ok.. that makes a majority
-[16:45] <vapier> so when someone uses a silly suffix, you let them know
-[16:45] <KingTaco> fmccor, it's a simple yes/no
-[16:46] <vapier> "hey you, stop being stupid"
-[16:46] <wolf31o2> exactly
-[16:46] <fmccor> Then yes :)
-[16:46] <KingTaco> I think that's silly
-[16:46] <KingTaco> just inviting flamewars and more infighting
-[16:47] <wolf31o2> any more than any other decision we make?
-[16:47] <KingTaco> probably not
-[16:47] <wolf31o2> no matter what, somebody isn't going to be happy, or else we wouldn't have to discuss/decide on it
-[16:47] <wolf31o2> ok... keywording GLEP...
-[16:47] <vapier> yeah, we wouldnt need to exist in the first place
-[16:47] * fmccor would consider a flamewar over multiple suffixes to be proctor bait.
-[16:48] <ferringb> *cough* raised two points above actually :)
-[16:48] <vapier> ferringb: got more to add ?
-[16:48] <ferringb> 1) what to do with multi-suffix, 2) how to handle such a decision in the future
-[16:48] <KingTaco> answer to 2 is -dev
-[16:48] <vapier> right
-[16:48] <ferringb> moreso, refering to the "outlaw further usage" vs "it has to be cleaned out of the tree now"
-[16:48] <vapier> multi-suffix predates pms
-[16:48] <wolf31o2> ferringb: ehh.. we said multi-suffix is allowed... meaning it isn't blocked anymore
-[16:49] <vapier> so if you have something that doesnt exist in portage now and requires a change in pms -> gentoo-dev
-[16:49] <ferringb> wolf31o2: again, difference between blocked for further usage, and making people change their versioning scheme for a 2 week window
-[16:49] <kloeri> that's actually my biggest complaint about the multiple suffix stuff that tree policy was just changed with no -dev discussion at all - no discussion I'm aware of at least
-[16:49] <KingTaco> kloeri, why did you vote for it then?
-[16:50] <KingTaco> at that meeting
-[16:50] <kloeri> KingTaco: I'm talking about allowing it in the first place without any discussion
-[16:50] <wolf31o2> ferringb: what exactly do you want us to discuss... we reversed the previous decision and allowed it... I'm not following what you want
-[16:50] <ferringb> wolf31o2: basically asking that in the future, when putting the breaks on something like this, block rather then punt while waiting for a full decision.
-[16:50] <kloeri> we blocked it to have that discussion
-[16:50] <ferringb> punted
-[16:50] <vapier> kloeri: it was added by any other means; feature request long ago in bug tracker when portage was the only real solution
-[16:50] <vapier> so complaining about a breakage in policy when a policy didnt exist is wrong
-[16:50] <ferringb> look at the original email, and the lack of multi-suffix in the tree now- it's usage was outlawed and folks had to change over right then/there
-[16:50] <wolf31o2> ferringb: ahh... ok... so nothing to do with this decision, but rather future ones...
-[16:50] <ferringb> yep
-[16:51] <kloeri> vapier: yes but we tree policy changes should be discussed on -dev ML imo
-[16:51] <wolf31o2> I see no problem with not requiring things be punted... we probably should have done that anyway...
-[16:51] <kloeri> and it's always been that way
-[16:51] <vapier> breakage has historically been discussed, not new features
-[16:51] <vapier> new features have been generally filed in bugzilla and then implemented as portage devs seen fit
-[16:52] <kloeri> in that case I want portage commit access so I can make some new features without discussing it :)
-[16:52] <ferringb> features != ebuild support changes :)
-[16:52] <ferringb> (might want to be specific there)
-[16:52] <vapier> just because you're not watching the portage alias and seeing the discussion doesnt mean it didnt happen :P
-[16:52] <kloeri> ok, so the few devs watching the portage alias decides tree policy?
-[16:52] <vapier> ferringb: where do you draw the line ?  FEATURES ? RESTRICT ? USE ?
-[16:53] <vapier> kloeri: the guys maintaining portage were deciding portage policy
-[16:53] <vapier> that's how it has always been
-[16:53] <vapier> you cant apply current view of the Gentoo world retroactively and take offense
-[16:54] <kloeri> important policy changes (and I count multiple suffixes as important) should be discussed on -dev imo
-[16:54] <wolf31o2> ok... I've got to run... on the GLEP, I totally agree with it
-[16:54] <kloeri> we've always required important policy changes to be discussed
-[16:54] <ferringb> vapier: just pointing out that misc. portage enhancements just affect that manager, not the others
-[16:55] <vapier> ferringb: this change was made pre-others
-[16:55] <ferringb> vapier: well aware; was just correcting terms kloeri was using is all :)
-[16:55] <vapier> so again, you cant take the current state of how things are handled and apply it retroactively
-[16:55] <wolf31o2> the GLEP reverses GLEP 22 and actually changes the keywording to match current practice, which I think is a good idea... and that's all I have time for, folks...
-[16:56] <kloeri> ok, I give up on this as nobody seems to agree that it should have been discussed
-[16:57] <wolf31o2> no, it definitely should have been discussed before being put in the tree, but not before it was put into portage
-[16:57] <wolf31o2> that make sense?
-[16:57] <vapier> it's a moot point
-[16:57] <vapier> we've decided going forward
-[16:57] <kloeri> wolf31o2: that's all I want
-[16:57] <wolf31o2> right
-[16:57] <wolf31o2> so glep
-[16:57] <wolf31o2> heh
-[16:58] <vapier> it doesnt account for kbsd
-[16:58] <vapier> but do we care
-[16:58] <wolf31o2> it doesn't explicitly list everything, just examples
-[16:58] <fmccor> How does it not?
-[16:59] <fmccor> (Like wolf31o2 said)
-[16:59] <vapier> it doesnt account in the same way as the old glep
-[16:59] <vapier> kbsd is half way between "x86" and "x86-fbsd"
-[16:59] <KingTaco> I don't like it at all
-[17:00] <fmccor> And?
-[17:00] <KingTaco> it creates confusion and work for almost all of the ebuild maintainers while only giving benefit to fringe arches
-[17:00] <Uber> vapier: isn't that x86-kbsd ?
-[17:00] <wolf31o2> KingTaco: huh? go read it again... -linux is implied if missing
-[17:01] <Uber> right, it just ratifies what we're currently doing
-[17:01] <wolf31o2> right... and now I really have to go... doorbell
-[17:01] <KingTaco> oh, I missed that
-[17:01] <wolf31o2> been fun
-[17:01] <KingTaco> sure
-[17:01] <KingTaco> it's already being done
-[17:01] --- robbat2|na is now known as robbat2
-[17:01] <fmccor> Uber, that's how I read it, too.
-[17:02] <robbat2> arr my head :-( sucky to get a cold now
-[17:02] <robbat2> sorry for being an hour late
-[17:02] <KingTaco> robbat2, Kugelfang already used that excuse
-[17:02] <fmccor> robbat2, It's OK, you got all the action items.
-[17:03] <robbat2> lol
-[17:03] <wolf31o2> ok... got a free second... yeah, it's already being done... main thing is it reverses glep 22 and applies current practice as policy
-[17:04] <KingTaco> I vote yes
-[17:04] <fmccor> yes for Kugelfang
-[17:04] <wolf31o2> yes
-[17:04] <Uber> yes
-[17:04] <robbat2> this is grobian's glep? yes on that from me
-[17:04] <Uber> robbat2: yes, his glep
-[17:06] <kloeri> yes
-[17:07] <Uber> vapier?
-[17:08] <-- Jokey has quit (Client Quit)
-[17:09] <Uber> well, it's got enough votes anyway
-[17:10] <Uber> so that's it then? the chair (wolf31o2) has gone, so meeting closed?
-[17:10] <KingTaco> heh
-[17:10] <KingTaco> nope
-[17:10] <KingTaco> vapier had something about PMS
-[17:11] <fmccor> Not if he's not here, he doesn't. :)
-[17:11] <kloeri> heh
-[17:11] <KingTaco> ok....
-[17:11] <KingTaco> anything else?
-[17:12] <fmccor> Thanks to the PMS authors for a splendid job?
-[17:12] <KingTaco> hahah
-[17:12] <ferringb> PMS vcs
-[17:13] <ferringb> still was up in the air from last time around
-[17:13] * KingTaco points to robbat2 
-[17:13] * Uber is away for 30 mins or so
-[17:14] <robbat2> ciaranm seemed to want to reject anything other than his own SVN
-[17:14] <KingTaco> fuck ciaranm
-[17:14] <robbat2> if he's altered his position since then, there's a git repo waiting on stork
-[17:14] <robbat2> i just need to hook up whoever's going to be the main person handling it if we are doing an LKML model
-[17:15] <robbat2> or multiple people if desired
-[17:15] <KingTaco> supposedly that's spb
-[17:16] <ferringb> also... EAPI1, might want to figure out how that'll be managed.  basically, if it's ad hoc, doc writers get to force the format (sane or otherwise manager wise), potentially desired, potentially not
-[17:17] <ferringb> mainly pointing it out since discussion of each tidbit would be wise- pythons pep approach for example would work well once EAPI=0 is locked down imo
-[17:17] <ferringb> either way, ad hoc sucks. :)
-[17:17] <vapier> sorry
-[17:17] <vapier> work IRQ
-[17:18] <vapier> i think the PMS state is still broken
-[17:18] <vapier> i wont be happy until it's been moved to proper Gentoo hosting with proper teams behind it
-[17:19] <vapier> i can let it sit until next meeting since people have taken off
-[17:19] <robbat2> vapier, see above, i've got a git repo on stork now, just need to give people access to it once they agree on the commit model
-[17:19] <robbat2> if they're all up with spb being the person to accept commits, then i'll give him write access when he's around, and read for everybody else
-[17:21] <fmccor> No objection that I can think of.
-[17:21] <ferringb> robbat2: seems moot dependant on how the EAPI discussions from above are managed frankly; if it's ad hoc, means spb/whoever controls that repo controls the format
-[17:21] <vapier> other than git is a lame solution, it does satisfy my current requirements
-[17:21] <KingTaco> robbat2, I don't think that'll satisfy vapier
-[17:21] <kloeri> no objection from me
-[17:21] <KingTaco> doesn't sit well with me either
-[17:22] <vapier> the latex format really makes PMS unaccessible for many to contribute to
-[17:22] <robbat2> KingTaco, which, git or ferringb's problem?
-[17:22] <KingTaco> robbat2, 1 rw * ro
-[17:22] <vapier> unfortunately that's the only way git will actually work here
-[17:22] <KingTaco> I *love* latex, but if it's going to be a gentoo thing, it should be xml like everything else
-[17:22] <vapier> grafting a dscm solution into a scm solution
-[17:23] <KingTaco> we made a mistake with the devmanual
-[17:23] <robbat2> no, it can work for $N rw * ro too
-[17:23] <vapier> who was working on xmlifying it ?
-[17:23] <KingTaco> dunno
-[17:23] <KingTaco> I don't think it ever got farther than chitchat
-[17:24] <fmccor> Does it matter until it's final?
-[17:24] <KingTaco> yes
-[17:24] <KingTaco> wait
-[17:24] <KingTaco> fmccor, what are you refering to?
-[17:25] <fmccor> latex --> xml
-[17:25] <KingTaco> ah
-[17:25] <KingTaco> ignore my yes
-[17:25] <fmccor> With latex, I can actually work with the document.
-[17:25] <vapier> like everything else, you can say "it'll be done later" but it wont be :p
-[17:25] <KingTaco> I agree with vapier
-[17:26] <fmccor> Actually, that's a test of whether it matters, too. :)
-[17:26] <KingTaco> *shrug*
-[17:26] <vapier> depends on who you ask
-[17:27] <KingTaco> I don't want to have to host more special content
-[17:27] <vapier> i think KingTaco has a point with the "Gentoo has settled on xml as a standard for documentation"
-[17:27] <KingTaco> xml is easy as infra can push it to the www nodes
-[17:27] <KingTaco> it can also be branded the same way most of our other content is
-[17:28] <fmccor> I don't have an opinion one way or the other --- my question should be read exactly as I wrote it, and I think the answer was "yes"
-[17:29] <KingTaco> the answer is yes
-[17:29] <KingTaco> if you expect the majority of gentoo people to contribute
-[17:29] <KingTaco> most of us know gentoo xml
-[17:29] <KingTaco> the same statement can not be made about latex
-[17:29] <robbat2> weird observation on the site that had the PMS SVN - a bunch of revisions are missing now - i pulled the git when it was r164, but now the SVN only goes to r129
-[17:29] <kloeri> you could also say that lots of ebuilds devs hate xml though.. :p
-[17:30] <vapier> robbat2: yes, that was a pretty big concern i had as well
-[17:30] <KingTaco> robbat2, either someone got pissy or svn broke for them too
-[17:30] <KingTaco> I've had problems with svn like that at work
-[17:30] <vapier> btw is this meeting offically over or what ? :)
-[17:31] <KingTaco> vapier, PMS was your topic
-[17:32] <vapier> i got the feeling that people had peaced out and PMS was happening post
-[17:32] <KingTaco> we can table it
-[17:32] <vapier> i think that's best
-[17:32] <KingTaco> I don't think anything is going to get done today
-[17:32] <KingTaco> ok
-[17:32] <KingTaco> any thing else?
-[17:32] <KingTaco> speak no or wait 30 days
-[17:32] <vapier> i dont believe so
-[17:32] <KingTaco> going
-[17:32] <KingTaco> going
-[17:32] <KingTaco> gone
-[17:33] --- KingTaco sets modes [#gentoo-council -m]
-[17:33] <fmccor> KingTaco, I thought everyone spoke latex. :)
-[17:33] <KingTaco> I wish
-[17:33] <ahf> latex is neat
-[17:34] <welp> but gentoo's official docs are all in xml
-[17:35] <welp> (lets convert all of gentoo's docs to latex! ;))
-[17:35] <ahf> you're saying that guidexml is neat?
-[17:35] <welp> no
-[17:35] <ahf> good.
-[17:35] <welp> i never said that, or even implied it...
-[17:36] <ahf> thus people has to use something that they don't like, just because everyone else is using it?
-[17:36] <dostrow> ahf: the answer to that is yes
-[17:36] <vapier> wtf is ahf ?
-[17:37] <ahf> eroyf.
-[17:37] <vapier> dont be a tool
-[17:37] <vapier> stay in school
-[17:37] <ahf> sorry, on my workstation
-[17:37] <vapier> and shut your word hole
-[17:37] <ahf> okdad.
-[17:37] <vapier> the usefulness of guidexml has been discussed on the gentoo-dev mailing list
-[17:37] <vapier> yes, it's xml ... yes, many people think xml is the devil
-[17:38] <ahf> and developers are enforced to write every technical document in it?
-[17:38] <ahf> forced*
-[17:38] <vapier> however it's done us a huge service
-[17:38] <ahf> indeed it has
-[17:38] <ahf> for simple pages
-[17:38] <ahf> i agree on that
-[17:38] <vapier> ahf: if you want to write your own technical document for your own stuff, have at it
-[17:38] <vapier> Gentoo wide things there's a standard
-[17:38] <KingTaco> dont ask infra to host it
-[17:38] <ahf> but if it has to be official gentoo documentation it has to be guidexml?
-[17:39] <vapier> i'm not making an argument saying PMS needs to be converted to guidexml right now
-[17:39] <vapier> i'm saying that it has to be seriously considered and have a good reason for it to not be done
-[17:39] <ahf> no. why not finish it then see if you accept it at all
-[17:39] <vapier> PMS isnt some random Gentoo document
-[17:39] <ahf> then start the converting job if you have to
-[17:39] <ahf> i know that.
-[17:39] <welp> fewl
-[17:39] <vapier> if i wasnt planning on accepting it, i would have punted spb already
-[17:40] <ahf> nod
-[17:40] <ahf> i actually need to talk to you about something else but let's take that in query
-[17:40] <vapier> that's what she said
-[17:41] <ahf> i'll be her for today
-[17:41] <vapier> hawt
-[17:41] <ahf> read your query god dammit!
-[17:41] <ahf> stop yapping
-[17:42] <dostrow> ahf: YAP! YAP! YAP!
-[17:43] <ahf> *meh*
-[17:43] <KingTaco> dostrow, how big is that TV you brought to scale?
-[17:43] <dostrow> 32"
-[17:43] <KingTaco> bah
-[17:43] <robbat2> fyi, i shot ciaranm an email to ask if his SVN broken
-[17:43] <dostrow> KingTaco: por que?
-[17:43] <KingTaco> I just got mine (32") and it isn't as big as I remember
-[17:44] <dostrow> aha
-[17:44] <ahf> it's not his asfaik
-[17:44] <zlin> robbat2: I think it moved
-[17:44] <-- FuzzyRay|work has quit (Remote closed the connection)
-[17:44] <robbat2> zlin, no, that repo had r164 before, and now it only has r129
-[17:45] <ferringb> diff'ed them?
-[17:45] <ahf> i think they moved server
-[17:45] * ferringb just assumed that when svn broke they cut off his access to be annoying :)
-[17:45] <ahf> i had to change planetpaludis a lot of times and i think they're on the same server
-[17:46] <robbat2> ahf, got a newer URL then?
-[17:46] <kloeri> vapier: btw, I've set you up on this hot new alpha box contingent on you helping with some binutils problems :p
-[17:46] <ahf> i don't know
-[17:46] <ahf> haven't followed pms discussion lately
-[17:46] <zlin> http://svn.repogirl.net/pms
-[17:47] <ahf> oh, it's on repogirl now
-[17:47] <ahf> i didn't know that.
-[17:47] <robbat2> tjat
-[17:47] <robbat2> that is still r164 that I have already
-[17:47] <robbat2> unless they re-did some commits, i'll check
-[17:49] <-- bazik (n=bazy@gentoo/developer/bazik) has left #gentoo-council
-[17:50] <robbat2> nope, it matches my existing r164, last commit 2007-04-17 16:29:24 -0700
-[17:50] <zlin> I don't think there have been any commits after that
-[17:51] <ferringb> robbat2: curious, have you already converted the data into git?
-[17:51] <ferringb> just wondering from a backup standpoint
-[17:52] <robbat2> yes I have
-[17:52] <-- Calchan|Home has quit ("Leaving")
-[17:52] --- KingTaco sets modes [#gentoo-council -vvo fmccor|home ferringb fmccor]
-[17:52] <robbat2> that's why I had an existing r164 to compare repogirl against :-)
-[17:52] --- KingTaco sets modes [#gentoo-council -v fmccor]
-[17:53] --- robbat2 has changed the topic to: Next meeting June 14th, 2000UTC (1600EDT)
-[18:01] <fmccor|home> Hmph.  Back to commoner status. :)
-[18:12] <KingTaco> fmccor|home, sorry, you only get to play god for an hour
-[18:12] <KingTaco> :p
-[18:19] <-- ahf has quit ("bedse")
-[18:28] <-- xhub has quit (Remote closed the connection)
-[18:52] <-- rbu has quit (Remote closed the connection)
-[19:13] <jmbsvicetto> fmccor|home: You don't even get to keep the silly hat ;)
-[19:15] * Uber gives fmccor|home a very very silly hat :P
-[19:16] <kloeri> Uber: I've hopefully fixed your *bsd linking problem in latest python-2.5.1-r1 btw
-[19:17] <Uber> kloeri: huh, it was already fixed I thought? export LDFLAGS="-L." ?
-[19:17] <kloeri> LDFLAGS="-L." wasn't in before -r1
-[19:18] <kloeri> hmm, looks like it was
-[19:18] <Uber> darn, I'm sure I added it to 2.5
-[19:18] <Uber> darn, I'm sure I added it to 2.5.1
-[19:18] <Uber> heh
-[19:19] <kloeri> yeah, I'm just confused about the thousand python updates the last few days I guess
-[19:20] <ferringb> kloeri: thanks btw, mainly didn't want it spreading via 07.1 unstable installs :)
-[19:20] <Uber> kloeri: drink more coffee!
-[19:20] <kloeri> Uber: good idea :)
-[19:21] <Uber> kloeri: and spread the updates around instead of doing 6 months worth of fixes in a few days ;)
-[19:21] <Uber> i bug you less then too - bonus!
-[19:21] <kloeri> yeah well, find somebody else to do the alpha and ia64 releases then
-[19:21] <ferringb> or find someone to do python :)
-[19:22] <kloeri> and as an added bonus find a new devrel lead too :p
-[19:22] <kloeri> in fact, find somebody to do all my work while you're at it :)
-[19:23] <ferringb> kloeri: who is active in the python herd these days btw?
-[19:23] <ferringb> you/dev-zero seem to be the two not derailed by rl atm
-[19:23] <kloeri> yup
-[19:23] <ferringb> exempting marienz, who else has on occasion shown signs of life?
-[19:23] <kloeri> lucass and pythonhead are also somewhat active
-[19:24] <ferringb> afaik, they're just python pkgs rather then the toolchain bits however, right?
-[19:24] <kloeri> liquidx is busy with his phd or whatever it is he's doing
-[19:24] <kloeri> yes
-[19:24] <kloeri> I'm doing the core python stuff
-[19:24] <ferringb> phd?
-[19:24] <Uber> see, you do too much
-[19:25] <ferringb> assumed he was just off sculpting a replica of devils peak out of potatoes
-[19:25] <kloeri> Uber: really? hadn't noticed :)
-[19:25] <Uber> :P
-[19:26] <Uber> seriously, pass some crap onto other people
-[19:26] <ferringb> kloeri: whats the usual flow for core python pkgs?
-[19:26] <ferringb> bursty, sporadic, etc?
-[19:26] <Uber> 6 monthly
-[19:26] <kloeri> bursty as long as it depends on me
-[19:27] * Uber ducks
-[19:27] <kloeri> heh
-[19:27] <kloeri> I tend to take care of devrel/council and related stuff on a more or less daily basis
-[19:28] <KingTaco> it's a daily job
-[19:28] <kloeri> and then do burst of alpha/ia64/mips/python/$other activity
-[19:28] <ferringb> kloeri: asking about if someone was doing just that
-[19:28] <ferringb> generally, upstream is massively farking slow about fixing bugs in my experience
-[19:28] <kloeri> yeah, no way to do random bursts of devrel activity except for some of the docs stuff
-[19:28] <ferringb> looks of it, aren't diverging too far from their fixes
-[19:29] <ferringb> kloeri: that sitedirs patch in 2.5 really needed btw?  already have the env.d addition
-[19:30] <kloeri> not sure, there's still a bunch of python work I need to do
-[19:30] <kloeri> cleaning out old versions is probably at the top of the list
-[19:31] <kloeri> 2.1 and 2.2 have been masked for a very long time so I could just kill those
-[19:31] <kloeri> killing 2.3 would also be nice
-[19:31] <kloeri> I'll probably see if I can do that around the time I unmask 2.5
-[19:31] <ferringb> kloeri: 08_all_crosscompile.patch has tabs/spaces intermixed btw for 2.5.1 patchset
-[19:31] <ferringb> last hunk, the 'return' addition
-[19:32] <ferringb> killing 2.3 you'll have problems with I suspect
-[19:33] <ferringb> 2.2 is getting up there age wise, but lotsa folks still use 2.3
-[19:33] <kloeri> haven't looked at kill 2.3 yet but it's on my wishlist
-[19:33] <kloeri> 2.2 have been masked forever so I have absolutely no problem killing that
-[19:34] <ferringb> an overlay exist for python crap offhand?
-[19:34] <ferringb> would shove it there personally
-[19:34] <kloeri> # Alastair Tse <liquidx@gentoo.org> (15 Jul 2006)
-[19:34] <kloeri> # Python 2.1 and 2.2 have reported vunerabilities. Masked pending
-[19:34] <kloeri> # removal, along with net-zope/zope-2.6. (GLSA: 200509-08, 200502-09,
-[19:34] <kloeri> # 200510-20)
-[19:34] <kloeri> <dev-lang/python-2.3
-[19:34] * ferringb nods
-[19:34] <kloeri> no
-[19:34] <ferringb> mmm.  sources.g.o it is I guess then
-[19:34] <kloeri> well, the entire point of killing that crap is to avoid any maintaining
-[19:35] <ferringb> basically is unmaintained anyways
-[19:35] <ferringb> (upstream specifically)
-[19:35] <kloeri> if people want the ebuilds they can grab them from sources.g.o or whatever they want as long as I don't have to ever look at them again :)
-[19:35] <ferringb> can't recall the last time I saw a 2.2 minor with bugfixes
-[19:35] <kloeri> 2.3 and 2.4 is unmaintained by upstream except for security issues
-[19:35] <ferringb> eh, personally I'd rather see >=2.3 since 2.2 -> 2.3 had the mro tweak
-[19:35] <ferringb> yep
-[19:36] <ferringb> that said, there still are people interested in tweaking 2.4 if needed (it's still heavily used)
-[19:36] <ferringb> 2.2 completely lacks that afaik
-[19:36] <kloeri> not going to kill 2.4 anytime soon
-[19:37] <ferringb> given
-[19:37] <kloeri> but given my complete lack of time for maintaining python I'd like to reduce python to only two major version if it can reasonably be done
-[19:37] <ferringb> eh... delegate
-[19:37] <ferringb> 4, no, 3, dunno :)
-[19:38] <kloeri> delegate would be a lot easier if there were actually some people willing to do the work
-[19:39] <ferringb> well
-[19:39] <ferringb> no offense meant, but that little python mishap of the last few days was enough to get me thinking about it
-[19:40] <ferringb> seems I'm semi touchy about the python toolchain.  who would've guessed. :)
-[19:40] <kloeri> well, that accident happened after lots of devs had tested the update and hadn't reported any issues
-[19:41] <kloeri> can't really avoid something like that completely
-[19:41] <ferringb> eh
-[19:41] <ferringb> wrote extensions that specifically would've been broke by it, and have cursed in the past about the api macro trick there so...
-[19:42] <ferringb> aware of it.  really wish they'd do something there since the trick they're using is rather ugly anyways
-[19:42] <kloeri> and? my point is that no matter how much you test package updates you can always break things and not notice it soon enough
-[19:44] <ferringb> aware, moreso was commenting that cpy extension authors would know about that one causing hell if they've done gil release at all
-[19:44] <kloeri> I'm generally extremely careful with python updates and in this case I asked all archs to test carefully and rekeyword the ebuilds due to the somewhat massive changes I made
-[19:44] <ferringb> admittedly corner case- moreso that you have to know the macro trick sucks to see it coming rather then testing for that case
-[19:44] <kloeri> well, it could have been a thousand other bugs instead
-[19:45] <ferringb> well aware, just was a nasty gotcha is what I'm saying
-[19:46] <kloeri> just like so many other possible gotchas that you'll run into from time to time no matter what
-[19:46] <ferringb> either way... upshot at least for py3k they're cleaning up the cpy extension writing a bit- mainly looking forward to removal of the -fno-strict-aliasing req
-[20:15] --> rbrown` (n=mynamewa@gentoo/developer/paludis.rbrown) has joined #gentoo-council
-[20:19] <-- rbrown`_ has quit (Read error: 60 (Operation timed out))
-[20:38] <-- robbat2 has quit (Remote closed the connection)
-[20:57] --> rbrown`_ (n=mynamewa@gentoo/developer/paludis.rbrown) has joined #gentoo-council
-[21:08] <-- rbrown` has quit (Read error: 110 (Connection timed out))
-[21:20] --> beandog (n=sdibb@gentoo/developer/beandog) has joined #gentoo-council
-[21:20] --> robbat2 (n=robbat2@gentoo/developer/robbat2) has joined #gentoo-council
-[21:20] --- ChanServ sets modes [#gentoo-council +o robbat2]
-[21:42] <-- dostrow has quit ("Your Mom!")
-[22:58] <-- beandog has quit (Remote closed the connection)
-[00:10] --> FuzzyRay|work (n=pvarner@gentoo/developer/FuzzyRay) has joined #gentoo-council
-[00:15] --- robbat2 is now known as robbat2|na
-[00:16] <-- ferringb (n=bharring@c-67-171-130-60.hsd1.or.comcast.net) has left #gentoo-council
-[01:45] <-- christel has quit (Read error: 104 (Connection reset by peer))
-[01:45] <-- masterdriverz has quit (Read error: 104 (Connection reset by peer))
-[01:45] --> masterdriverz (i=masterdr@dev.gentooexperimental.org) has joined #gentoo-council
-[02:06] --- robbat2|na is now known as robbat2
-[02:45] <-- FuzzyRay|work has quit (Remote closed the connection)
-[02:59] <-- welp has quit ("Leaving")
-[03:41] --> Jokey (n=jokey@gentoo/developer/jokey) has joined #gentoo-council
-[04:07] --- rbrown`_ is now known as rbrown`
-[05:38] <Kugelfang> fmccor: once again, my thanks
-[05:38] <Kugelfang> fmccor: you and council@ got a mail that explains my absence yesterday
-[06:51] <fmccor> Kugelfang, You are quite welcome.
-[07:06] <Uber> boring! Next excuse should be "kidnapped by nymphomaniacs"
-[07:08] <masterdriverz> Uber: excuse? you mean that hasn't happened to you yet?
-[07:08] <Uber> no, I'm waiting for the nymphomaniacs to show up :/
-[07:37] <-- mpagano_ (n=mike@pool-70-105-167-248.nwrknj.fios.verizon.net) has left #gentoo-council
-[07:49] <Kugelfang> Uber: :-)
-[07:53] <Kugelfang> KingTaco: devmanual is xml
-[07:55] --- robbat2 is now known as robbat2|na
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070614-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070614-summary.txt
deleted file mode 100644
index fa68c7f275..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070614-summary.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-- Council vote approves jaervosz replacing kloeri.
-
-- robbat2 to write a doc on using Git to access the PMS repo (which presently
-  just mirrors the SVN). spb to bug robbat2 if he doesn't get said doc.
-
-- Large discussion about handling of mailing lists, including proctors and
-  moderation. Vote is proposed for:
-  1. Having a seperate unmoderated -project (in the fashion of Debian's -project). 
-  2. -dev becoming moderated for non-@gentoo, as well as any @gentoo that with
-  to be moderated, or have flamish tendancies.
-  3. Moderaters are a seperate and more open group from proctors. Mainly devs,
-  and are expected to show good judgement (see Catalyst item).
-- Decision is made to send the above to -dev list for discussion, and have an
-  intermediate meeting in 2 weeks. Non-binding vote by council gets 4 yes
-  votes and one no.
-  
-- Musikc had sent an email to council about the proctors process and the CoC.
-  This leads into a discussion of the FreeNode Catalyst system, which was a
-  partial basis for the CoC. Rough agreement that in an ideal work, all
-  developers should act as positive catalysts, but this is a lot harder than
-  it seems.
-  1. The moderation discussion needs to be integrated into musikc's document.
-  2. More catalyst material into the CoC per Proctor's revisions.
-  3. Musikc needs to send her mail to the lists in a week.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070614.txt b/xml/htdocs/proj/en/council/meeting-logs/20070614.txt
deleted file mode 100644
index a01d6855dc..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070614.txt
+++ /dev/null
@@ -1,689 +0,0 @@
-Jun 14 13:02:47 *	kingtaco|work sets mode +m #gentoo-council
-Jun 14 13:02:55 kingtaco|work	lets get the party started
-Jun 14 13:03:00 kingtaco|work	roll-call
-Jun 14 13:03:11 kingtaco|work	agaffney for wolf31o2
-Jun 14 13:03:12 *	agaffney is here for wolf31o2
-Jun 14 13:03:20 kingtaco|work	Flameeyes for uberlord
-Jun 14 13:03:26 *	Flameeyes here
-Jun 14 13:03:32 kingtaco|work	I'm of course here
-Jun 14 13:03:36 SpanKY	yep
-Jun 14 13:03:40 robbat2	yo
-Jun 14 13:03:42 kingtaco|work	Kugelfang, robbat2 ?
-Jun 14 13:03:51 Flameeyes	robbat2 was here a moment ago
-Jun 14 13:04:03 robbat2	am I chopped liver?
-Jun 14 13:04:07 kingtaco|work	yes!
-Jun 14 13:04:15 kingtaco|work	ok, first round, jaervosz
-Jun 14 13:04:23 robbat2	Kugelfang, where are ya?
-Jun 14 13:04:40 kingtaco|work	robbat2, I haven't seen him around in weeks
-Jun 14 13:05:32 kingtaco|work	last I heard he was working on his thesis
-Jun 14 13:05:34 agaffney	he's 11 hours idle
-Jun 14 13:05:38 agaffney	same here
-Jun 14 13:05:43 agaffney	no idea what that's done with
-Jun 14 13:05:49 kingtaco|work	nor I
-Jun 14 13:05:49 agaffney	s/what/when/
-Jun 14 13:05:53 kingtaco|work	so we'll continue
-Jun 14 13:06:03 kingtaco|work	anyone have questions for jaervosz before we vote?
-Jun 14 13:06:22 robbat2	on him becoming council - no
-Jun 14 13:06:28 robbat2	no questions I mean
-Jun 14 13:06:31 agaffney	heh
-Jun 14 13:06:31 Flameeyes	erm vote on what?
-Jun 14 13:06:36 *	Flameeyes needs to be filled in a bit
-Jun 14 13:06:40 kingtaco|work	both wolf and uber have indicated that they approve
-Jun 14 13:06:48 kingtaco|work	jaervosz is to fill kloeris spot
-Jun 14 13:06:54 Flameeyes	no questions
-Jun 14 13:06:55 SpanKY	and myself
-Jun 14 13:06:59 kingtaco|work	yes
-Jun 14 13:07:05 kingtaco|work	so, any nos?
-Jun 14 13:07:29 *	Cardoe (n=cardoe@gentoo/developer/Cardoe) has joined #gentoo-council
-Jun 14 13:07:33 kingtaco|work	1
-Jun 14 13:07:34 kingtaco|work	2
-Jun 14 13:07:36 kingtaco|work	3
-Jun 14 13:07:38 *	Jokey (n=jokey_mo@gentoo/developer/jokey) has joined #gentoo-council
-Jun 14 13:07:45 kingtaco|work	welcome to the club jaervosz
-Jun 14 13:07:53 jaervosz	thanks :)
-Jun 14 13:08:06 agaffney	you say that now... :P
-Jun 14 13:08:08 kingtaco|work	the only agenda item I'm aware of is proctors
-Jun 14 13:08:12 *	genone_ (n=genone@gentoo/developer/genone) has joined #gentoo-council
-Jun 14 13:08:19 kingtaco|work	anyone else have anything?
-Jun 14 13:08:53 SpanKY	status of pms repo
-Jun 14 13:08:58 kingtaco|work	k
-Jun 14 13:09:03 kingtaco|work	anything else?
-Jun 14 13:09:42 robbat2	nope
-Jun 14 13:09:51 kingtaco|work	ok, lets do pms first
-Jun 14 13:10:05 kingtaco|work	SpanKY, you got the floor
-Jun 14 13:10:23 *	kingtaco|work gives voice to spb
-Jun 14 13:10:35 SpanKY	robbat2 has the status
-Jun 14 13:11:26 robbat2	the git repo is alive and up to r164 of their SVN - which is the last commit that seems to be present, which is concerning as it was 2 months ago
-Jun 14 13:11:37 robbat2	unless they moved the SVN again
-Jun 14 13:11:49 SpanKY	so it's ready for use on our side
-Jun 14 13:11:59 kingtaco|work	latest svn that I've heard of was repogirl.net
-Jun 14 13:12:03 robbat2	ya
-Jun 14 13:12:20 kingtaco|work	ok
-Jun 14 13:12:24 kingtaco|work	what's the next step?
-Jun 14 13:12:25 SpanKY	spb: your turn
-Jun 14 13:12:37 robbat2	on the side of accessing it, it's dev-only at the moment, and there's related git stuff going on with me and infra as there's other demand for non-dev users to write to git repos
-Jun 14 13:13:31 SpanKY	so it's not done yet on infra's side
-Jun 14 13:13:46 robbat2	devs can access it, but not non-dev
-Jun 14 13:13:57 SpanKY	non-dev's should have anon access
-Jun 14 13:14:04 *	peper (n=peper@gentoo/developer/paludis.lackey.peper) has joined #gentoo-council
-Jun 14 13:14:04 robbat2	i meant for write
-Jun 14 13:14:14 kingtaco|work	I think they demanded commit writes for that person
-Jun 14 13:14:21 SpanKY	the point of using git is so that there is no need
-Jun 14 13:14:26 SpanKY	it'd be pushing to spb
-Jun 14 13:14:47 SpanKY	if the repo has non-dev access, then it might as well be svn shouldnt it
-Jun 14 13:15:08 kingtaco|work	except we simply won't give non-dev svn write access
-Jun 14 13:15:13 kingtaco|work	at svn.gentoo.org
-Jun 14 13:15:20 kingtaco|work	could do it on overlays or something
-Jun 14 13:15:22 SpanKY	but you'd give non-dev access to git
-Jun 14 13:15:43 kingtaco|work	it's more a logistical problem than anything
-Jun 14 13:15:45 SpanKY	i'm asking, i dont really know what the infra policy is now
-Jun 14 13:15:52 kingtaco|work	our ACLs arn't setup for that
-Jun 14 13:16:06 kingtaco|work	I'm assuming robbat2 has solved the problem with git
-Jun 14 13:16:21 robbat2	the other non-dev git-write work to git were for overlays already
-Jun 14 13:16:57 robbat2	if there's one thing that's lacking, it's me writing a doc on how folks can access it
-Jun 14 13:16:59 kingtaco|work	robbat2, so from an infra POV are we ready or not?
-Jun 14 13:17:14 robbat2	it works yes, but I need to show folk how
-Jun 14 13:17:24 kingtaco|work	all that's left is docs?
-Jun 14 13:17:33 robbat2	for dev-only-write and world-read yes
-Jun 14 13:17:47 SpanKY	then that's the status
-Jun 14 13:18:04 kingtaco|work	ok, docs can be written this month?
-Jun 14 13:18:14 robbat2	if nothing else blows up, ya
-Jun 14 13:18:17 kingtaco|work	k
-Jun 14 13:18:23 robbat2	(work's been a pita the last while)
-Jun 14 13:18:26 kingtaco|work	table for next month then?
-Jun 14 13:18:33 kingtaco|work	get a doc dev to do it for you
-Jun 14 13:18:43 kingtaco|work	that's what they're here for
-Jun 14 13:18:46 *	arkanoid (n=arkanoid@8-255-173-213.static.dsl.webpartner.net) has joined #gentoo-council
-Jun 14 13:18:47 robbat2	and spb to contact me in 2 weeks or so for a walk-thru of using it
-Jun 14 13:19:12 *	windzor (n=windzor@82.143.229.82) has joined #gentoo-council
-Jun 14 13:19:17 Flameeyes	robbat2, if you have any raw notes to be translated in something humanly readable, feel free to mail this way
-Jun 14 13:19:24 kingtaco|work	k, anything else on this topic?  anyone oppose to moving to next month?
-Jun 14 13:19:30 Flameeyes	I don't have much to do lately, and I know my way around guidexml
-Jun 14 13:19:35 robbat2	ok
-Jun 14 13:20:05 kingtaco|work	aight, next topic
-Jun 14 13:20:13 *	kingtaco|work removes voice from spb
-Jun 14 13:20:18 kingtaco|work	proctors
-Jun 14 13:20:34 kingtaco|work	whomever is here for the proctors, please PM me so I can voice you
-Jun 14 13:20:53 kingtaco|work	wolf had called to disban them
-Jun 14 13:21:18 *	kingtaco|work gives voice to musikc marienz
-Jun 14 13:21:34 *	kingtaco|work gives voice to NeddySeagoon
-Jun 14 13:21:41 kingtaco|work	aight then
-Jun 14 13:22:33 kingtaco|work	I feel that the proctors haven't done what we initially intended
-Jun 14 13:22:45 robbat2	is the email that musikc to council sent 3 hours before the council meeting on for discussion at the moment?
-Jun 14 13:23:03 kingtaco|work	we can, but I must admit to not reading most of it
-Jun 14 13:23:05 *	hlieberman (n=hlieberm@gentoo/developer/hlieberman) has joined #gentoo-council
-Jun 14 13:23:15 jaervosz	I haven't seen it either
-Jun 14 13:23:22 kingtaco|work	I think I have a solution to the flamewars on -dev
-Jun 14 13:23:32 kingtaco|work	that makes the proctors less needed
-Jun 14 13:23:35 *	Flameeyes can't see it either
-Jun 14 13:23:43 robbat2	and I think it's timing is such that our proxied council members haven't read it either
-Jun 14 13:23:47 kingtaco|work	robbat2, can you forward that to the 2 people please
-Jun 14 13:24:03 kingtaco|work	here is my idea:
-Jun 14 13:24:23 kingtaco|work	infra makes a gentoo-project list, which would be a "copy'
-Jun 14 13:24:27 kingtaco|work	infra makes a gentoo-project list, which would be a "copy" of -dev
-Jun 14 13:25:00 kingtaco|work	then we make -dev moderated for non gentoo posters.  all the flamewars and bitching I've seen for quite a while have involved at least one non-dev at the begining
-Jun 14 13:25:25 kingtaco|work	I think if we can stop them from starting then we have a much less chance of a full flamewar
-Jun 14 13:25:27 kingtaco|work	thoughts?>
-Jun 14 13:25:41 NeddySeagoon	Who will do the moderation ?
-Jun 14 13:25:44 kingtaco|work	this would remove the main need for proctors
-Jun 14 13:25:45 robbat2	who moderates, and under what policies?
-Jun 14 13:25:47 kingtaco|work	good question
-Jun 14 13:25:58 *	genone has quit (Read error: 110 (Connection timed out))
-Jun 14 13:26:02 Flameeyes	yep who moderates (and how) is the main problem to solve here
-Jun 14 13:26:04 agaffney	my questions exactly
-Jun 14 13:26:17 kingtaco|work	I think we've made enough policies, I'd make it so any dev could moderate if they want, but hild them responsible for what they pass through
-Jun 14 13:26:22 Flameeyes	[going on the pessimistic rule, whoever will be to moderate will be said to apply censorship, and flames will restart]
-Jun 14 13:26:24 kingtaco|work	and no wussy 24 hour bans
-Jun 14 13:26:38 kingtaco|work	if someone fucks up, make it a month ban or something
-Jun 14 13:26:59 agaffney	yeah, the 24 hour bans were somewhat ineffective
-Jun 14 13:27:04 robbat2	i think musikc's email is definetly relevant here
-Jun 14 13:27:13 agaffney	because chances are the flame will still be going then, and they can just start right back in
-Jun 14 13:27:17 Flameeyes	maybe something changed since I left, but weren't some people totally against banning at any level?
-Jun 14 13:27:23 musikc	devrel would like the opportunity to help with the proctor project
-Jun 14 13:27:30 marienz	(interrupting: I think the council really needs to decide what the goal of the -dev list *is*, and then decide how and by who the list is kept used only for that goal)
-Jun 14 13:27:44 kingtaco|work	Flameeyes, some people didn't like it, yes, but things are continually out of hand
-Jun 14 13:27:53 NeddySeagoon	Makr -dev moderated for everyone. In a short time, the flames would die out. It would need fair sized team for 24/7 coverage
-Jun 14 13:28:14 kingtaco|work	marienz, the goal is simply development related topic
-Jun 14 13:28:16 kingtaco|work	+s
-Jun 14 13:28:22 Flameeyes	kingtaco|work, so am I fine to suppose that almost nothing changed in the background since I left?
-Jun 14 13:28:24 NeddySeagoon	agaffney, the 24 hour bans were never really applied
-Jun 14 13:28:24 marienz	you still need to decide on moderators for that. I fear that if any dev can let posts through they'll restart again fairly quickly.
-Jun 14 13:28:33 agaffney	NeddySeagoon: that was my thought, but it's not very practical
-Jun 14 13:28:43 agaffney	NeddySeagoon: I thought that 2 people were banned in the last big thread
-Jun 14 13:28:46 robbat2	could I ask for a slight modification on KingTaco's original?
-Jun 14 13:28:50 *	kingtaco|work gives voice to jmbsvicetto blackace hlieberman
-Jun 14 13:28:54 kingtaco|work	robbat2, sure
-Jun 14 13:28:59 robbat2	rather than banning, those that show poor judgement can also be moderated
-Jun 14 13:29:00 kingtaco|work	my idea is raw
-Jun 14 13:29:01 NeddySeagoon	agaffney, they were restored at wolfs insistance
-Jun 14 13:29:03 agaffney	ah
-Jun 14 13:29:05 *	Flameeyes reading the forward, give me a minute or two
-Jun 14 13:29:06 robbat2	rather than directly blocked
-Jun 14 13:29:18 kingtaco|work	robbat2, that works for me, assuming it's easy from the infra side
-Jun 14 13:29:21 agaffney	robbat2: did you forward it to me? I haven't gotten it yet
-Jun 14 13:29:22 robbat2	yup
-Jun 14 13:29:27 *	cla (i=claudius@gentoo/developer/cla) has joined #gentoo-council
-Jun 14 13:29:28 marienz	and how do you decide "who shows poor judgment"?
-Jun 14 13:29:43 musikc	who decides 'who shows poor judgment'?
-Jun 14 13:29:52 kingtaco|work	the council does I suppose
-Jun 14 13:29:54 hlieberman	I've got an idea, if you'd like to hear it.
-Jun 14 13:29:54 marienz	it sounds to me like you'll still need a group of people (devrel? proctors? council?) who decide who crosses the line here, and that'll likely lead to the same "censorship" claims we're seeing now.
-Jun 14 13:30:02 robbat2	musikc, i'm saying moderation as one of the things in your proctors actions email
-Jun 14 13:30:07 blackace	so if everyone can let posts through, what's to stop someone from letting their own post through, and then who decides to ban them?  it seems to me, you have to trust that to someone, be it proctors or devrel or whatever
-Jun 14 13:30:08 NeddySeagoon	robbat2, has that been implemented now ?  last time it was needed there was only bans
-Jun 14 13:30:09 kingtaco|work	marienz, that can't be helped
-Jun 14 13:30:13 hlieberman	That's a layer above all of these concerns - a higher level.
-Jun 14 13:30:16 jmbsvicetto	kingtaco|work: I would just like to remember those listening to this proposal, that at this moment, the moderation as robbat2 is suggesting isn't still possible (at least it wasn't last Friday)
-Jun 14 13:30:31 kingtaco|work	but frankly, participating in gentoo is a privilage, not a right
-Jun 14 13:30:43 robbat2	NeddySeagoon, it's been available always, from the dropdown in the access.cgi, but the problem is that we don't have any moderators defined
-Jun 14 13:30:44 Flameeyes	I agree with marienz on this
-Jun 14 13:30:48 marienz	kingtaco|work: agreed, but I thought it was obvious the same thing would happen to proctors, and that didn't work out too well. Don't want a rerun of that the first time this new approach leads to an unpopular decision.
-Jun 14 13:30:54 *	impulze (i=impulze@2001:6f8:10ae:0:217:31ff:fe81:8c8) has joined #gentoo-council
-Jun 14 13:31:13 kingtaco|work	first off, council, is this something we want to persue?
-Jun 14 13:31:16 hlieberman	In fact, it's a solution that is working on a network larger than gentoo.
-Jun 14 13:31:17 Flameeyes	whoever will be the moderators they _will_ be told to be censors, and nothing will stop this from happening
-Jun 14 13:31:34 marienz	no matter how you approach this, if there's any kind of moderation/blocking/whatever there's going to be a group making unpopular decisions, and you need to trust that group
-Jun 14 13:31:34 jmbsvicetto	robbat2: sorry, but I hadn't understood that from our talks
-Jun 14 13:31:37 robbat2	it isn't the consensus moderation, it's any-mod-is-god
-Jun 14 13:31:42 kingtaco|work	Flameeyes, my proposal was that *any* dev could be a moderator
-Jun 14 13:31:49 hlieberman	I think we're approaching this thing the entirely wrong way.
-Jun 14 13:32:01 hlieberman	We're looking at dealing with the flames by moderation - which raises the 'temperature'.
-Jun 14 13:32:03 kingtaco|work	that way if people want to claim playing favorites, they can get off their lazy asses and moderate themselves
-Jun 14 13:32:12 hlieberman	I think we need to all take a long hard look at the Catalyst model that Freenode runs off of.
-Jun 14 13:32:24 Flameeyes	kingtaco|work, as once a mail passes it's passed, I fail to see how this would help
-Jun 14 13:32:32 marienz	Flameeyes: exactly
-Jun 14 13:32:32 Flameeyes	it's not like the flames comes _only_ from users
-Jun 14 13:32:40 blackace	first off...can I ask why the council thinks proctors won't work?  one instance where a council member acted inappropriately and started this discussion?
-Jun 14 13:32:54 Flameeyes	if all the devs were able to decide NOT to let flames pass to the mailing list, they would never post on the mailing list when a flame thread starts
-Jun 14 13:32:55 musikc	kingtaco|work: so youre saying that every dev could moderate the ML, either blocking or allowing what they saw fit?
-Jun 14 13:32:59 kingtaco|work	blackace, the proctors have so far failed at their task
-Jun 14 13:33:01 marienz	if anyone can let posts through it won't *work*. You'll need to stop some people from letting obviously inflammatory posts through if you go that route.
-Jun 14 13:33:04 kingtaco|work	musikc, not blocking, allowing
-Jun 14 13:33:10 blackace	kingtaco|work: how?
-Jun 14 13:33:23 agaffney	blackace: in multiple instances, the proctors' actions have just served to further fuel the flames, usually turning them in another direction...against the proctors
-Jun 14 13:33:24 kingtaco|work	blackace, by failing to stop the flamewars and fighting
-Jun 14 13:33:48 *	marienz is not convinced this means the proctors should be *disbanded*
-Jun 14 13:33:53 SpanKY	agaffney: which really is to be expected
-Jun 14 13:33:56 kingtaco|work	we're not voting on that
-Jun 14 13:34:00 SpanKY	you tell a jackass he's a jackass and he's going to flame you
-Jun 14 13:34:02 marienz	they're not working *yet*, but I don't believe disbanding entirely will help either.
-Jun 14 13:34:03 blackace	kingtaco|work: specific instances please, because if all you have is this last one, it doesn't count, we _stopped_ after wolf's post, when we really wanted to continue banning people in order to stop the flamewar
-Jun 14 13:34:03 kingtaco|work	or ever talking about that this moment
-Jun 14 13:34:07 hlieberman	How many of you have read this: http://freenode.net/catalysts.shtml
-Jun 14 13:34:10 Flameeyes	SpanKY hit the problem
-Jun 14 13:34:21 marienz	we need to adjust a few things, mainly get people to complain to/about proctors on some other place than the -dev list
-Jun 14 13:34:22 Flameeyes	whoever will try to apply moderation in any form _will_ get a flame back
-Jun 14 13:34:26 kingtaco|work	anyway
-Jun 14 13:34:27 NeddySeagoon	kingtaco|work, The proctors gave up on the last thread in the face of wolfs insistance as a council member
-Jun 14 13:34:54 kingtaco|work	the fact that we're getting into an argument here is proof that it isn't a good deal
-Jun 14 13:35:03 kingtaco|work	now, back to the task
-Jun 14 13:35:09 hlieberman	Tell me when you're done with this train of discussion, and are ready to listen. :)
-Jun 14 13:35:12 blackace	no, it isn't.
-Jun 14 13:35:14 kingtaco|work	council, what do you think about the idea?
-Jun 14 13:35:16 agaffney	SpanKY: yes, but usually it was everyone else that was flaming the person calling the original person a jackass
-Jun 14 13:35:33 NeddySeagoon	Lets here hlieberman
-Jun 14 13:35:41 *	kingtaco|work removes voice from NeddySeagoon
-Jun 14 13:35:44 *	kingtaco|work removes voice from blackace
-Jun 14 13:36:09 kingtaco|work	again, council, what do you think about the idea of moderating?
-Jun 14 13:36:16 jaervosz	I think we should give the proctors some more time to show results
-Jun 14 13:36:17 Flameeyes	as I said, I feel like it won't change much
-Jun 14 13:36:20 kingtaco|work	apply robbat2s idea to mine
-Jun 14 13:36:42 musikc	kingtaco|work: can you recap robbat2s idea?
-Jun 14 13:36:57 agaffney	kingtaco|work: I think the idea of moderating non-devs has merit, however, it would likely work better if *everyone* was moderated, but it wouldn't be as practical
-Jun 14 13:37:07 robbat2	my idea was including moderation of a specific user in musikc's list of proctor actions
-Jun 14 13:37:09 Flameeyes	I agree with jaervosz, I'd be for giving them the chance; just allowing any dev to be the moderator would expect any dev to be able to moderate himself, which, if true, wouldn't have let us come to this point in the first place
-Jun 14 13:37:14 kingtaco|work	robbat2 was my idea but instead of a long ban for someone passing in crap, they would become moderated themselves
-Jun 14 13:37:29 *	RiverRat (n=me@gentoo/contributor/riverrat) has joined #gentoo-council
-Jun 14 13:37:45 jaervosz	if we should turn to moderation all devs should be able to moderate other devs but not themselves i guess
-Jun 14 13:37:53 kingtaco|work	keep in mind right now it's a pita for infra to find out who passed in crap, so we're not likely to want to go easy
-Jun 14 13:38:33 robbat2	jaervosz, that causes problems when two folk agree to mod each others flames
-Jun 14 13:38:34 Flameeyes	just adding a "moderate single user" option to proctors' capabilities sounds a nice compromise between doing nothing and banning right away
-Jun 14 13:38:49 kingtaco|work	Flameeyes, it's already there
-Jun 14 13:38:53 kingtaco|work	they haven't used it
-Jun 14 13:38:57 jaervosz	robbat2: aye, but at least we have two fools to discuss at the next council meeting :)
-Jun 14 13:39:05 kingtaco|work	in fact, the ONLY time they've done something was the latest flamewar
-Jun 14 13:39:08 Flameeyes	robbat2, there's no need for that, whatever the argument, you'll find at least five people agreeing, and as many disagreeing
-Jun 14 13:39:23 *	avenj (n=avenj@gentoo/developer/avenj) has joined #gentoo-council
-Jun 14 13:39:26 Flameeyes	kingtaco|work, wasn't just said that the mailing list has no moderators? and thus nobody can actually take care of the moderation?
-Jun 14 13:39:50 jmbsvicetto	kingtaco|work: just for the record, the proctors team wasn't aware of that ability
-Jun 14 13:39:53 musikc	Acknowledging what kingtaco|work said, I think we can all agree that the proctor project would need guidance, is that option completely off the table?
-Jun 14 13:39:54 kingtaco|work	not from what I understand
-Jun 14 13:40:01 jaervosz	but as i originally said i think proctors should be given more time, i think it's far better to have a human "face" to ensure a nice working enviornment than moderation
-Jun 14 13:40:05 robbat2	moderation is possible from a technical perspective, but was not used, because it was a single-mod-is-god level
-Jun 14 13:40:11 kingtaco|work	ok, I'm not talking about the proctors
-Jun 14 13:40:18 kingtaco|work	so knock it off
-Jun 14 13:40:21 robbat2	not the consensus moderation from 2 meetings ago
-Jun 14 13:40:27 *	windzor has quit (Client Quit)
-Jun 14 13:40:31 Flameeyes	kingtaco|work, I wasn't aware of moderation being an option for proctors either
-Jun 14 13:40:45 kingtaco|work	Flameeyes, what did I just say?
-Jun 14 13:40:54 Flameeyes	kingtaco|work, I was just finishing my phrase above :)
-Jun 14 13:40:55 robbat2	jmbsvicetto, go and hit the access.cgi page, you'll see a 'moderate' option in the dropdown
-Jun 14 13:41:11 kingtaco|work	anyway
-Jun 14 13:41:30 kingtaco|work	does any council member have anything to add to my little proposal or any questions?
-Jun 14 13:42:02 Flameeyes	would the headers show who allowed a mail in?
-Jun 14 13:42:07 kingtaco|work	eventually
-Jun 14 13:42:15 kingtaco|work	for the moment, infra has to dig through logs
-Jun 14 13:42:21 kingtaco|work	which means a pissed off infra
-Jun 14 13:42:32 Flameeyes	I would consider that a technical requirement
-Jun 14 13:42:43 kingtaco|work	which means someone is getting their ass banned or moderated
-Jun 14 13:42:59 Flameeyes	although a pissed off infra is more likely to act, if you get enough noise to make the dig up a big waste of time, you have anyway got your effect
-Jun 14 13:43:13 hlieberman	I think we're looking too far down at the discussion. Down into the technical elements. I have a much more higher level idea that I think bears consideration.
-Jun 14 13:43:18 *	kingtaco|work removes voice from hlieberman
-Jun 14 13:43:22 kingtaco|work	I told you to be quiet
-Jun 14 13:43:50 *	tove (n=tove@smtp.gentoo.org) has left #gentoo-council
-Jun 14 13:44:29 robbat2	hlieberman, to finish your catalyst stuff off, integrate it into the CoC, which is not the present subject of discussion.
-Jun 14 13:44:59 kingtaco|work	ok
-Jun 14 13:45:27 kingtaco|work	this being independent of proctors, does anyone want to continue that discussion before we vote on this?
-Jun 14 13:46:55 kingtaco|work	I take that as a no
-Jun 14 13:47:00 jaervosz	just to be sure I understand it correctly: -dev will be moderated and -project and unmoderated version?
-Jun 14 13:47:05 kingtaco|work	yes
-Jun 14 13:47:16 robbat2	moderated for non-developers
-Jun 14 13:47:26 jaervosz	so you post to -project and it might be moderated?
-Jun 14 13:47:30 kingtaco|work	no
-Jun 14 13:47:38 kingtaco|work	-project becomes what -dev is now
-Jun 14 13:47:56 robbat2	and -dev gets moderated for non-@gentoo.org
-Jun 14 13:48:00 kingtaco|work	the hidden bonus of this is that core can almost go away
-Jun 14 13:48:05 agaffney	will devs be "required" to subscribe to -project?
-Jun 14 13:48:08 kingtaco|work	no
-Jun 14 13:48:20 kingtaco|work	announcements will go to -dev like always
-Jun 14 13:49:10 agaffney	how can this get rid of -core? we still want a list that's only readable by devs, right?
-Jun 14 13:49:28 kingtaco|work	it doesn't get rid of it, it makes it (almost) unnecessary
-Jun 14 13:49:48 robbat2	i believe kingtaco means that some discussions are going to core at the moment when people don't want the noise involved of a discussion on the present -dev
-Jun 14 13:49:55 agaffney	ah
-Jun 14 13:50:07 kingtaco|work	there is very very little traffic that has to be kept internal
-Jun 14 13:50:14 kingtaco|work	and even then I believe people leak it out
-Jun 14 13:50:41 agaffney	it does seem that way
-Jun 14 13:50:42 SpanKY	s/I believe//
-Jun 14 13:50:46 Flameeyes	that's for sure a-hem
-Jun 14 13:50:54 agaffney	sad that we can't trace the leak
-Jun 14 13:51:11 kingtaco|work	such is a closed mailing list
-Jun 14 13:51:14 agaffney	but that's an entirely different discussion
-Jun 14 13:51:20 Flameeyes	right
-Jun 14 13:51:20 kingtaco|work	yes
-Jun 14 13:51:59 kingtaco|work	so, all in favor of -dev becoming non-moderated for !gentoo.org and gentoo.org that have flamed/passed in flames?
-Jun 14 13:52:21 kingtaco|work	or rather
-Jun 14 13:52:21 agaffney	s/non-// right?
-Jun 14 13:52:30 kingtaco|work	any other questions before the vote
-Jun 14 13:52:33 robbat2	still, who are the moderators? proctors?
-Jun 14 13:52:38 kingtaco|work	nopoe
-Jun 14 13:52:45 kingtaco|work	any dev who isn't currently moderated
-Jun 14 13:52:50 kingtaco|work	and chooses to be
-Jun 14 13:53:16 robbat2	so to clarify
-Jun 14 13:54:02 robbat2	moderators are seperate from proctors, and the proctors still exist here in that they can make flaming devs be moderated, but proctors are needed a LOT less
-Jun 14 13:54:23 Flameeyes	robbat2, (hopefully)
-Jun 14 13:54:51 kingtaco|work	I see the proctors as a seperate thing
-Jun 14 13:54:55 jaervosz	and a lot of time is wasted moderating instead of developing
-Jun 14 13:55:09 kingtaco|work	jaervosz, not really, most posts are from gentoo devs
-Jun 14 13:55:18 kingtaco|work	not a lot of non-gentoo posters there anymore
-Jun 14 13:55:22 *	avenj (n=avenj@gentoo/developer/avenj) has left #gentoo-council
-Jun 14 13:55:29 Flameeyes	jaervosz, I doubt that whoever would moderate would be developing otherwise
-Jun 14 13:56:11 jaervosz	ok, my point is that time spend moderating could perhaps be spend better elsewhere
-Jun 14 13:56:12 kingtaco|work	this does reduce or possibly eliminate the need for proctors on this list
-Jun 14 13:56:27 kingtaco|work	jaervosz, the options we have is either moderate or flame
-Jun 14 13:56:29 Flameeyes	jaervosz, it's not far different from the flaming
-Jun 14 13:56:45 kingtaco|work	the difference is that it only wastes 1 persons time
-Jun 14 13:57:39 *	jaervosz has quit (Read error: 104 (Connection reset by peer))
-Jun 14 13:57:41 Flameeyes	and one person's face if someone proactively lets flames begin
-Jun 14 13:57:52 musikc	kingtaco|work: will devs moderate other devs on -dev, or only moderate users?
-Jun 14 13:58:19 kingtaco|work	all non devs and those devs who have either flamed or allowed a flame in
-Jun 14 13:58:34 kingtaco|work	default policy is to accept any dev
-Jun 14 13:58:55 musikc	kingtaco|work: then wouldnt it make the -project ML an unnecessary redundancy?
-Jun 14 13:59:00 kingtaco|work	nope
-Jun 14 13:59:08 kingtaco|work	that's more of a anything goes place
-Jun 14 13:59:17 kingtaco|work	-dev is for development related discussion **ONLY**
-Jun 14 13:59:24 robbat2	folks should direct anything political to -project, just like debian's -project
-Jun 14 13:59:37 kingtaco|work	and if we decide to keep the proctors I see them having a active role on that list
-Jun 14 13:59:40 musikc	kingtaco|work: then -project will still incite flames, etc, and wouldnt THAT ML need some form of moderation?
-Jun 14 13:59:50 kingtaco|work	musikc, yes
-**** BEGIN LOGGING AT Thu Jun 14 14:00:15 2007
-
-Jun 14 14:00:15 kingtaco|work	the difference is that people don't have to be subscribed and they won't miss out on the important announcements that come on -dev
-Jun 14 14:01:10 musikc	kingtaco|work: i think i follow you now, it would make -project a necessary evil essentially. acknowledging a place where such behaviour may exist, but not requiring an individual to read it or partake
-Jun 14 14:01:20 agaffney	ok, so the -project thing isn't arbitrary...it's based on debian's list of the same name
-Jun 14 14:01:37 agaffney	also explains the name :)
-Jun 14 14:01:48 kingtaco|work	no, the bahavior isn't accepted, but since we know it's going to happen, we may as well move it to a place where people can ignore and not miss something important
-Jun 14 14:02:09 kingtaco|work	-project is what was requested
-Jun 14 14:02:15 kingtaco|work	don't really care what it's called
-Jun 14 14:02:32 kingtaco|work	and the -project side is mainly kumbas idea
-Jun 14 14:03:24 kingtaco|work	so anything else before we pt this to vote?
-Jun 14 14:03:29 musikc	kingtaco|work: sorry, not saying the behaviour would be accepted on -project. of course that would bring us round to the discussion of future of "proctors"
-Jun 14 14:03:41 kingtaco|work	which is next on the list
-Jun 14 14:03:49 *	je_fro (n=unknown@gentoo/developer/je-fro) has joined #gentoo-council
-Jun 14 14:04:12 agaffney	after this vote, I'll still be around, but I'll be paying a lot less attention
-Jun 14 14:04:24 robbat2	ok, so I think all the questions have been resolved here, i'll try summarize quickly
-Jun 14 14:04:25 kingtaco|work	I have to fix dev.g.o soon
-Jun 14 14:04:27 robbat2	and we can vote
-Jun 14 14:04:30 kingtaco|work	so we need to hurry up
-Jun 14 14:04:58 robbat2	1. -dev becomes moderated for non-@gentoo.org AND any @gentoo.org that wishes to be moderated or has flamed
-Jun 14 14:05:10 robbat2	2. -project is created as an open list for the flames of which -dev presently sees
-Jun 14 14:05:56 robbat2	3. moderators are a seperate and more open group than proctors. they are mainly devs and are expected to show good judgement (more on this in a bit, re hlieberman's)
-Jun 14 14:06:20 robbat2	did I miss anything?
-Jun 14 14:06:35 kingtaco|work	that's it in a nutshell
-Jun 14 14:06:52 robbat2	anybody else think I missed anything? speak or PM me
-Jun 14 14:06:58 robbat2	you have 60 seconds
-Jun 14 14:07:16 *	jaervosz (n=jaervosz@gentoo/developer/jaervosz) has joined #gentoo-council
-Jun 14 14:07:59 Flameeyes	jaervosz, you want a summary?
-Jun 14 14:08:19 robbat2	ok, here are some Qs
-Jun 14 14:08:23 Flameeyes	jaervosz, http://rafb.net/p/spFw0Q11.html
-Jun 14 14:08:28 robbat2	<tomk> what about devs who have let a flamewar start?
-Jun 14 14:08:44 robbat2	<mariez> how is "has flamed" decided?
-Jun 14 14:08:45 kingtaco|work	robbat2, you take over chair please, I gotta take a piss
-Jun 14 14:09:32 robbat2	<tomaw> Can the gentoo council declare, create and enforce a requirement all in one meeting?
-Jun 14 14:09:58 agaffney	brb...bathroom break as well
-Jun 14 14:10:04 *	dang (n=dang@gentoo/developer/pdpc.active.dang) has joined #gentoo-council
-Jun 14 14:10:23 robbat2	ok, that's all the really clear questions for now
-Jun 14 14:11:41 robbat2	some initial answers from me on them
-Jun 14 14:12:01 kingtaco|work	the answer to the last one is yes
-Jun 14 14:12:02 robbat2	tomk, that's going to be a proctors/devrel thing, more on that in the next agenda item
-Jun 14 14:12:58 kingtaco|work	as far as marienz Q, I say let the proctors decide that.  they have shown themselves to be a reactive group and not proactive, and the decision for a "flame" is certainly a reactive one
-Jun 14 14:13:24 kingtaco|work	I honestly don't know if we could have a proactive group
-Jun 14 14:13:40 *	igli (n=igli@unaffiliated/igli) has left #gentoo-council
-Jun 14 14:13:53 robbat2	tomaw, as jmbsvicetto points out to me, there has definetly been much discussion in the list already, but also that we're discussing a moving target here. evolution of requrements happens
-Jun 14 14:14:00 agaffney	without precognition, it's pretty difficult
-Jun 14 14:14:10 musikc	kingtaco|work: such proactive behaviour would likely incite more flames
-Jun 14 14:14:21 kingtaco|work	maybe
-Jun 14 14:14:27 kingtaco|work	it seems to have in the past
-Jun 14 14:15:47 robbat2	are there any council members that think more public discussion is needed before such an action is undertaken?
-Jun 14 14:16:06 robbat2	I personally think no, as it's an evolution of the present proctors stuff
-Jun 14 14:16:17 *	phreak`` has quit (Client Quit)
-Jun 14 14:16:35 Flameeyes	I think it should be at least left as a proposal for the community to examine, maybe not for a month, but reschedule an extra meeting in, say, two weeks time
-Jun 14 14:16:50 agaffney	kingtaco|work: hlieberman is asking if there will be an open floor before the vote
-Jun 14 14:17:37 kingtaco|work	well, considering we've never done that before and I think the only reason he's interested is because it affected him, I'd say no.  but I gave my chair up to robbat2
-Jun 14 14:18:04 robbat2	hlieberman, has already asked me that, because he wanted to present the Freenode Catalyst idea (http://freenode.net/catalysts.shtml)
-Jun 14 14:18:12 *	avenj (n=avenj@gentoo/developer/avenj) has joined #gentoo-council
-Jun 14 14:18:29 robbat2	i stated no, because we're going to visit it in the next agenda item
-Jun 14 14:18:58 kingtaco|work	robbat2, I'm forced to point out I've a screen full of people wanting us to not vote on this today
-Jun 14 14:19:10 kingtaco|work	wanting more discussion
-Jun 14 14:19:37 robbat2	ok, for the moment then, lets send this to the list, for a meeting in 2 weeks time AND continue with the next agenda item
-Jun 14 14:19:43 robbat2	since that's still relevant to the rest of the matter
-Jun 14 14:19:47 kingtaco|work	ok
-Jun 14 14:19:51 robbat2	could we still have a prelinary vote by council?
-Jun 14 14:19:55 robbat2	non-binding
-Jun 14 14:20:26 *	rangerpb (i=baude@gentoo/developer/rangerpb) has joined #gentoo-council
-Jun 14 14:20:27 kingtaco|work	sure
-Jun 14 14:20:37 *	nightmorph (n=nightmor@gentoo/developer/nightmorph) has joined #gentoo-council
-Jun 14 14:20:40 robbat2	ok, for voting for the matter as I outlined in the 3 points above
-Jun 14 14:20:42 robbat2	yes for me
-Jun 14 14:21:03 kingtaco|work	yes
-Jun 14 14:21:22 robbat2	agaffney, Flameeyes, Kugelfang, SpanKY, jaervosz
-Jun 14 14:21:28 *	robbat2 gives channel operator status to jaervosz
-Jun 14 14:21:30 Flameeyes	mostly yes here
-Jun 14 14:21:47 agaffney	yes
-Jun 14 14:22:13 kingtaco|work	SpanKY, Kugelfang jaervosz
-Jun 14 14:22:31 jaervosz	atm i tend to say no, giving the proctors more time to show results
-Jun 14 14:22:35 kingtaco|work	ok
-Jun 14 14:23:37 robbat2	SpanKY, we're waiting
-Jun 14 14:24:05 kingtaco|work	robbat2, we have 4 yeses and it's non binding, I think we can move on
-Jun 14 14:24:11 robbat2	eh, it's non-binding anyway.
-Jun 14 14:24:12 robbat2	moving on
-Jun 14 14:24:15 kingtaco|work	we can record his vote later if he agrees
-Jun 14 14:24:33 robbat2	next is proctors, and relevant is musikc's email
-Jun 14 14:24:42 *	[equilibrium] (n=equilibr@gentoo/contributor/equilibrium) has joined #gentoo-council
-Jun 14 14:24:45 robbat2	to summarize for those non-council that didn't recieve it
-Jun 14 14:24:55 robbat2	(and I do think a revised version should go out to all)
-Jun 14 14:25:02 kingtaco|work	remember that wolf called for the project to be disbanded
-Jun 14 14:25:32 robbat2	it discusses both the development and processes that should be involved in proctors
-Jun 14 14:26:23 kingtaco|work	robbat2, you should probably voice all those proctors at the moment, most of them wanted to keep talking when I cut them off
-Jun 14 14:26:39 robbat2	ok, will do in one sec
-Jun 14 14:27:24 musikc	robbat2: if we can agree to continue proctors, we can sort out the specific details later
-Jun 14 14:27:27 robbat2	the core of the processes email is laying out why proctors should take the course of action (including ignoring) that they do
-Jun 14 14:28:03 *	robbat2 gives voice to hlieberman NeddySeagoon blackace
-Jun 14 14:28:12 *	robbat2 gives voice to pilla
-Jun 14 14:28:37 *	blackace would like to nominate marienz to speak for proctors
-Jun 14 14:28:43 *	robbat2 gives voice to marienz
-Jun 14 14:28:52 robbat2	anybody else for voice? i've got a few things to state first
-Jun 14 14:28:59 *	marienz thinks that's a silly idea 'cause he's a slacker and only recently got involved with proctors at all, but will try
-Jun 14 14:29:09 SpanKY	yeah
-Jun 14 14:29:24 robbat2	ok, nobody else coming up yet. so to quickly cover the other thing
-Jun 14 14:29:41 robbat2	hlieberman, brings up the Catalyst concept from FreeNode
-Jun 14 14:29:47 kingtaco|work	SpanKY, yeah to that prelim vote?
-Jun 14 14:29:55 SpanKY	yeah
-Jun 14 14:30:00 kingtaco|work	k
-Jun 14 14:30:15 robbat2	and I believe that all of the items in there should be applied to every developer. _all_ of us should hold ourselves to that level of behavior
-Jun 14 14:30:32 hlieberman	robbat2, Tell me when you want me to speak.
-Jun 14 14:31:00 musikc	robbat2: it sounds like you presume everyone else has read it. perhaps you could summarize it?
-Jun 14 14:31:18 robbat2	i'll link again
-Jun 14 14:31:24 robbat2	http://freenode.net/catalysts.shtml
-Jun 14 14:31:48 robbat2	it reads a lot like the second half of Christel's original CoC proposal (not the punishment half)
-Jun 14 14:31:58 kingtaco|work	it's good in concept, I don't see how it applies to us
-Jun 14 14:32:18 kingtaco|work	it's really just "be a decent person and lead by example"
-Jun 14 14:32:25 hlieberman	If I may?
-Jun 14 14:32:31 kingtaco|work	by all means
-Jun 14 14:32:45 robbat2	hlieberman, go for it
-Jun 14 14:33:11 *	rangerpb has quit (Client Quit)
-Jun 14 14:33:18 hlieberman	Thank you. So, the catalyst concept.
-Jun 14 14:33:55 hlieberman	Now one very important thing to realize about this concept is that it is meant to diffuse the situation.
-Jun 14 14:33:59 hlieberman	For example.
-Jun 14 14:34:10 hlieberman	Someone starts ranting in #gentoo about how Gentoo sucks.
-Jun 14 14:34:22 hlieberman	Well, setting a ban is the easiest thing to do.
-Jun 14 14:34:30 hlieberman	Shuts them up. Done.
-Jun 14 14:34:45 hlieberman	But whenever someone exercises their power over other people, it increases the temperature of the discussion.
-Jun 14 14:35:27 hlieberman	The catalyst way would be to be calm, and to try and nudge them onto a productive track.
-Jun 14 14:35:44 kingtaco|work	I'll point out that it's been tried by many people many times
-Jun 14 14:35:49 hlieberman	Frequently (though there are exceptions), people who burn up and start flames are pissed about something.
-Jun 14 14:35:51 robbat2	hlieberman, why shouldn't every developer be expected to act under the catalyst model?
-Jun 14 14:35:53 kingtaco|work	I've only had a positive effect doing that once
-Jun 14 14:36:00 hlieberman	In #gentoo with users, it's frequently because they broke something.
-Jun 14 14:36:18 hlieberman	And if you figure out what it is, and guide them through the solution...
-Jun 14 14:36:25 Flameeyes	I don't think this would apply for the in-fighting between devs
-Jun 14 14:36:26 hlieberman	You just lowered the temperature in the channel.
-Jun 14 14:36:45 hlieberman	Now, please, don't mistake this for saying no one should be banned ever. Nyah, censorship, nyah.
-Jun 14 14:36:48 NeddySeagoon	hlieberman, proctors already try to do this in private
-Jun 14 14:36:49 kingtaco|work	from experence, it's helped once out of the dozen times I've tried
-Jun 14 14:36:55 hlieberman	I'm saying that it shouldn't be a first step.
-Jun 14 14:37:17 hlieberman	Example from the mailing lists.
-Jun 14 14:37:31 hlieberman	The bubble letter.
-Jun 14 14:37:40 kingtaco|work	bubble?
-Jun 14 14:37:45 musikc	robbat2 has a point, since the role of catalyst has no authority, its really parrellel to the CoC and an expectation of every dev
-Jun 14 14:37:54 hlieberman	It was titled Living in a Bubble.
-Jun 14 14:37:57 kingtaco|work	oh
-Jun 14 14:37:58 Flameeyes	"Living in a bubble", beejay's mail which started one of the latest flames
-Jun 14 14:37:58 kingtaco|work	right
-Jun 14 14:38:01 kingtaco|work	yeah
-Jun 14 14:38:02 hlieberman	A user complaining about the developer mailing list.
-Jun 14 14:38:11 hlieberman	The first reactions to those were to flame right back.
-Jun 14 14:38:44 hlieberman	It was a joke, bla, bla, bla.
-Jun 14 14:38:47 hlieberman	Escalating, escalating.
-Jun 14 14:39:03 hlieberman	People got (perhaps rightly) pissed off, and responded as such.
-Jun 14 14:39:50 hlieberman	And once that cycle starts, it's hard to stop.
-Jun 14 14:40:06 robbat2	that is exactly why every developer should act as a catalyst
-Jun 14 14:40:19 robbat2	and not respond in kind
-Jun 14 14:40:23 hlieberman	Exactly.
-Jun 14 14:40:32 agaffney	am I needed for anything else?
-Jun 14 14:40:40 hlieberman	Moderators aren't needed if developers don't help fan the flames. They should be there just in case, but..
-Jun 14 14:40:41 agaffney	I'll be leaving work in <10 minutes
-Jun 14 14:40:51 agaffney	and I won't be back near a computer until late tonight
-Jun 14 14:40:57 hlieberman	The decision to ban, or to exercise authority should be used as a last resort.
-Jun 14 14:41:12 blackace	How do you plan to get rid of developers who do not act as catalysts?
-Jun 14 14:41:23 hlieberman	You don't need to.
-Jun 14 14:41:28 hlieberman	There are three hundred something developers.
-Jun 14 14:41:36 blackace	...
-Jun 14 14:41:40 hlieberman	If half of them, or a quarter of them start acting responsibly.
-Jun 14 14:41:47 hlieberman	And not fanning the flames.
-Jun 14 14:41:52 blackace	So...magic then?
-Jun 14 14:41:59 jaervosz	~99% do that already..
-Jun 14 14:42:01 hlieberman	They will die out on their own.
-Jun 14 14:42:22 hlieberman	I mean responsibly as in responsible catalysts.
-Jun 14 14:42:26 kingtaco|work	hlieberman, the CoC mimics the same idea
-Jun 14 14:42:30 hlieberman	It does.
-Jun 14 14:42:34 musikc	hlieberman: this is all covered under the CoC, and has not been demonstrated effective as the only resource (that being refer to the CoC and be have)
-Jun 14 14:42:43 *	jaervosz has quit (Read error: 104 (Connection reset by peer))
-Jun 14 14:42:45 Flameeyes	hlieberman, as jaervosz said, most of the devs already do that, it's a so-called "vocal minority" that creates the flames, and I doubt that just telling people to be nice once again will help
-Jun 14 14:42:46 jmbsvicetto	hlieberman: If you look at the mls stats, you'll notice that the majority of posts are from half a dozen devs and users.
-Jun 14 14:42:47 hlieberman	But I think where the CoC fell down a bit was that we jumped to moderation too quickly.
-Jun 14 14:42:53 kingtaco|work	some of us do it, more often than not we're ignored, we should all continue to di it, but I don't see where you're going with this?
-Jun 14 14:43:25 robbat2	yes, more people should certaining have clamped down in the catalyst sense on the Bubble email
-Jun 14 14:43:36 robbat2	they didn't, and it got out of control
-Jun 14 14:43:44 hlieberman	robbat2 has the idea.
-Jun 14 14:43:55 musikc	robbat2: hence the need for ... $insert some role$
-Jun 14 14:44:02 hlieberman	No, no.
-Jun 14 14:44:07 *	agaffney waves goodbye
-Jun 14 14:44:09 hlieberman	The solution isn't adding more people with power.
-Jun 14 14:44:22 robbat2	hlieberman, how do you get people to act as catalysts then?
-Jun 14 14:44:31 blackace	agaffney: thanks, take care :)
-Jun 14 14:44:45 musikc	hlieberman: and how to do get others to abide by something another dev acting as a catalyst says?
-Jun 14 14:44:59 marienz	hlieberman: if half a dozen people decide to flame each other to a crisp in spite of dozens of catalysts telling them not to in private mail, the -dev ml *still* won't be a usable thing.
-Jun 14 14:45:22 hlieberman	marienz, Agreed. And that's a circumstance where a restriction is necessary. When the catalyst system fails.
-Jun 14 14:45:54 robbat2	which returns us to the past debate on, who decides at when a system has failed and something more severe is needed
-Jun 14 14:45:54 hlieberman	But in many circumstances, the catalyst system will work before that's necessary.
-Jun 14 14:46:02 *	Cardoe has quit (Client Quit)
-Jun 14 14:46:32 NeddySeagoon	hlieberman, the lag on a mailing list makes it very difficult to stop a flameware, the catalyst approach works for some other things
-Jun 14 14:46:53 dmwaters	hlieberman: the catalyst system works for freenode because most of the staff is trained for that, doing it with 300 devs is much harder
-Jun 14 14:46:54 hlieberman	Agreed - the lag makes it much more difficult.
-Jun 14 14:46:58 marienz	oh, the catalyst thing is *very* important, and as others have pointed out the coc is in places very similar in spirit at least
-Jun 14 14:47:01 kingtaco|work	guys, we're not getting anywhere
-Jun 14 14:47:15 Flameeyes	as agaffney is already gone, it's getting late (and we're stuck at the same point as... 20 minutes ago?) I think I'll take the opportunity to go a bit AFK myself.. for what concerns disbanding the proctors, as jaervosz said before, I'd like to give them a bit more time
-Jun 14 14:47:17 kingtaco|work	if there are no further items we need to vote on, I move to open the floor
-Jun 14 14:47:36 hlieberman	dmwaters, I can imagine. Perhaps some people (christel) familiar with the system could write up a "How to" so to speak and put that on the list.
-Jun 14 14:47:37 marienz	but even before we had the CoC, people were supposed to act as catalysts already, and we need a system in place for when they *don't*
-Jun 14 14:47:47 marienz	this "people should act as catalysts" isn't new
-Jun 14 14:47:48 musikc	kingtaco|work: what of the issue of the future of the proctors?
-Jun 14 14:47:53 hlieberman	That's all I'm here to say. :)
-Jun 14 14:47:55 robbat2	council: quick vote, who in favour of giving proctors more time?
-Jun 14 14:47:56 *	jaervosz (n=jaervosz@gentoo/developer/jaervosz) has joined #gentoo-council
-Jun 14 14:47:59 musikc	hlieberman: they've done that, its called CoC
-Jun 14 14:48:02 robbat2	vs. disbanding
-Jun 14 14:48:10 robbat2	I say more time, flameyes does too
-Jun 14 14:48:17 hlieberman	musikc, That's listing what you need - not how to do it.
-Jun 14 14:48:28 kingtaco|work	I'd say more time only because we're changing the scope of what they are doing
-Jun 14 14:49:16 marienz	I have some proctor-related thoughts but I should've brought them up on the list earlier, so I'll mention them once the floor is opened instead. Unless someone has questions now, of course :)
-Jun 14 14:49:19 musikc	council: can we further the decision to include allowing devrel to assist in this new opportunity for proctors?
-Jun 14 14:49:33 kingtaco|work	I can't reiterate enough that I'm unhappy with the current direction the proctors have taken
-Jun 14 14:50:03 robbat2	ok, quick summary, then open floor
-Jun 14 14:50:12 musikc	kingtaco|work: and devrel would like nothing more than the opportunity to assist
-Jun 14 14:50:17 marienz	musikc: can't speak for the rest of proctors, but I'm all for more cooperation/integration there
-Jun 14 14:50:23 robbat2	1. from the previous item, adding somebody to moderation needs to go into musikc's email
-Jun 14 14:50:33 robbat2	2. catalyst stuff goes into CoC
-Jun 14 14:50:52 robbat2	3. musikc: make your email public after editing more?
-Jun 14 14:51:00 *	robbat2 gives channel operator status to jaervosz
-Jun 14 14:51:19 robbat2	anything more before opening the floor?
-Jun 14 14:51:20 musikc	robbat2: 3) give us time to hash it out further and we will, say one week?
-Jun 14 14:51:28 robbat2	musikc, ok with me
-Jun 14 14:51:46 jmbsvicetto	I would suggest taking that discussion to the #gentoo-proctors ml - that's one of the reasons it was created
-Jun 14 14:51:47 NeddySeagoon	musikc, please do
-Jun 14 14:51:55 *	hlieberman (n=hlieberm@gentoo/developer/hlieberman) has left #gentoo-council ("Leaving")
-Jun 14 14:52:06 robbat2	ok, so opening the floor then
-Jun 14 14:52:12 *	robbat2 sets mode -m #gentoo-council
-Jun 14 14:52:27 *	kingtaco|work removes voice from blackace
-Jun 14 14:52:31 *	kingtaco|work removes voice from jmbsvicetto
-Jun 14 14:52:34 *	kingtaco|work removes voice from marienz
-Jun 14 14:52:36 *	[equilibrium] has quit (Client Quit)
-Jun 14 14:52:38 *	kingtaco|work removes voice from musikc
-Jun 14 14:52:42 *	kingtaco|work removes voice from NeddySeagoon
-Jun 14 14:52:44 *	robbat2 removes voice from NeddySeagoon pilla
-Jun 14 14:52:45 *	kingtaco|work removes voice from pilla
-Jun 14 14:53:04 jmbsvicetto	kingtaco|work: Can you please elaborate what's wrong on the proctors direction and what would you like to see being done differently?
-Jun 14 14:53:06 robbat2	bah, now hlieberman has left
-Jun 14 14:53:32 jaervosz	robbat2: he's still around somewhere
-Jun 14 14:53:35 *	You've invited hlieberman to #gentoo-council (zelazny.freenode.net)
-Jun 14 14:54:01 kingtaco|work	jmbsvicetto, when I brought up the idea I envisioned a proactive group that would attempt to diffuse a potential flamewar before it became one
-Jun 14 14:54:09 kingtaco|work	to date that hasn't been done
-Jun 14 14:54:21 kingtaco|work	but I've come to realize that I had a unrealistic expectation
-Jun 14 14:54:33 marienz	kingtaco|work: we've *tried* but it's rather hard, especially because of the time lag thing I mentioned.
-Jun 14 14:54:42 *	hlieberman (n=hlieberm@gentoo/developer/hlieberman) has joined #gentoo-council
-Jun 14 14:54:44 kingtaco|work	I don't believe any group can be proactive in this case
-Jun 14 14:54:56 kingtaco|work	so now we work around my faulty assumption
-Jun 14 14:55:12 marienz	not unless we apply massive amounts of moderation, which would encounter a lot of resistance from people claiming it's censorship.
-Jun 14 14:55:25 jmbsvicetto	kingtaco|work: ki
-Jun 14 14:55:37 robbat2	every developer should be proactive in apply Catalyst/CoC to their email before they hit send
-Jun 14 14:55:49 robbat2	but that's a pipe dream too
-Jun 14 14:55:55 marienz	anyway, I think one obvious thing we need to fix is that we need a different place than the -dev ml to direct complaints about proctor decisions.
-Jun 14 14:55:58 jmbsvicetto	kingtaco|work: ok
-Jun 14 14:56:10 robbat2	marienz, -project ;-)
-Jun 14 14:56:16 NeddySeagoon	kingtaco|work, there are two cases.  When thisng develop slowly, there is time to send private emails and nip them. When things develop quickly, the mail lag prevents that
-Jun 14 14:56:24 marienz	because every time we do something unpopular we morph the discussion into an anti-proctors one instead of really stopping it.
-Jun 14 14:56:38 jmbsvicetto	marienz: We have -proctors, but I see little interest in using it
-Jun 14 14:56:59 kingtaco|work	NeddySeagoon, the moderate idea that we discussed convers it
-Jun 14 14:57:02 marienz	if we set up a separate list (could be -project, but I think it should actually be a publically-archived separate list) and *heavily* enforce all complaints have to go to that list, I think that'd help.
-Jun 14 14:57:05 kingtaco|work	you no longer need to be proactive
-Jun 14 14:57:11 kingtaco|work	at least not on -dev
-Jun 14 14:57:48 marienz	I also think that if we keep proctors around council needs to decide what proctors should and shouldn't be able to do, and keep in mind that proctors will actually *use* whatever "powers" you give it :)
-Jun 14 14:58:09 marienz	if you don't want us to give temporary ml bans, don't give us that ability, or make it very obvious under what circumstances the ability should be used
-Jun 14 14:58:29 marienz	and if you decide we overuse that ability, complain to *us*, not straight to the -dev list
-Jun 14 14:58:37 musikc	marienz: a lot of what you are discussing was addressed in the proposal devrel sent to council
-Jun 14 14:58:56 marienz	musikc: just to council, right, or did I miss a mail?
-Jun 14 14:58:57 musikc	and its been agreed that devrel and proctors can work on this together
-Jun 14 14:59:06 jmbsvicetto	kingtaco|work: Another problem that I see getting more serious on the -dev ml is personal discussions escalating into "gang" confrontations - sorry for the strong word
-Jun 14 14:59:06 kingtaco|work	marienz, wish I could agree, but we looked at the logs, the proctors have not used their "special powers"
-Jun 14 14:59:17 marienz	so far I don't think we've been getting in each others way, but that'd be good :)
-Jun 14 14:59:22 musikc	marienz: just council thus far, we need to hash out the details and THEN send it to everyone
-Jun 14 14:59:36 blackace	musikc: so you can't really expect marienz to know about it
-Jun 14 14:59:42 marienz	musikc: perhaps you could send it to the proctors alias before that (but I don't know what's in it, so perhaps that doesn't make sense)
-Jun 14 14:59:53 musikc	blackace: i didnt say i did
-**** BEGIN LOGGING AT Thu Jun 14 15:00:04 2007
-
-Jun 14 15:00:04 musikc	only said what i did to inform him
-Jun 14 15:00:11 marienz	kingtaco|work: mainly referring to wolf's mail demanding we immediately drop a block
-Jun 14 15:00:13 fmccor	It can go to proctors, I think.
-Jun 14 15:00:19 blackace	musikc: ah ok, gotcha, from my perspective it looked like you were
-Jun 14 15:00:19 musikc	marienz: i propose devrel work with proctors on this, not do it for proctors
-Jun 14 15:00:25 kingtaco|work	anyway, you guys should get with devrel, they have a bunch of ideas that could help you
-Jun 14 15:00:30 marienz	great
-Jun 14 15:00:50 fmccor	devrel is here to serve.
-Jun 14 15:01:16 musikc	splendid. so we're agreed to go into this further with proctors and will have a revised proposal by the end of next week.
-Jun 14 15:02:34 musikc	are we in fact agreed or am i just making that up?
-Jun 14 15:02:46 *	marienz blinks
-Jun 14 15:02:57 marienz	I think you and fmccor are agreeing, at least :)
-Jun 14 15:03:44 musikc	i also appear to have agreement from robbat2 and NeddySeagoon a few minutes ago, or so it seemed
-Jun 14 15:04:20 NeddySeagoon	musikc, I agree that devrel and proctors need to work closely
-Jun 14 15:05:02 marienz	proctors can't really agree or disagree since we haven't read whatever it is you're proposing (other than that we should work together, which I think is obviously a good idea since our scopes somewhat overlap)
-Jun 14 15:05:14 musikc	so shall we continue this conversation in #gentoo-proctors?
-Jun 14 15:05:18 marienz	oh, ok
-Jun 14 15:05:21 NeddySeagoon	kingtaco|work, proctors still need to work behind the scenes to point out to posters that they could have phrased things better
-Jun 14 15:05:43 musikc	marienz: im not asking that you agree blankly, just that you agree to work on developing it with devrel so we can take this discussion else where and let everyone get back to whatever they need to be doing
-Jun 14 15:05:48 kingtaco|work	robbat2, I suppose we should put out our proposal
-Jun 14 15:05:56 kingtaco|work	who's doing logs and summary?
-Jun 14 15:06:16 kingtaco|work	NeddySeagoon, I don't really have any more input for the proctors today
-Jun 14 15:06:59 christel	i know im late, but just a heads up, if council goes for what was proposed by devrel, i think we can very much swing this around by doing it as intended :_
-Jun 14 15:07:02 christel	:)
-Jun 14 15:07:07 NeddySeagoon	kingtaco|work, ok.  What of the councils keeping an eye on the proctors - we have lost the council members that used to do that
-Jun 14 15:07:10 christel	(sorry, ikea ate up my evening)
-Jun 14 15:07:17 robbat2	hlieberman, btw still on the issue of Catalyst, i'm all ears to hear how you can get more people to act sensibly under it
-Jun 14 15:07:31 kingtaco|work	NeddySeagoon, it has always been, and for the next 3 months it will always be me
-Jun 14 15:07:42 hlieberman	I'll put it on my list of things to try and figure out. :)
-Jun 14 15:07:43 NeddySeagoon	kingtaco|work, Fine
-Jun 14 15:07:51 kingtaco|work	others are welcome to watch
-Jun 14 15:07:54 marienz	christel: ikea is eeeeeevil
-Jun 14 15:07:56 jeeves	dooooooork
-Jun 14 15:08:03 christel	robbat2: on freenode making people catalyze is pretty easy, however, it does take a fair chunk on one on one time with individuals to encourage them to behave in a manner appropriate :)
-Jun 14 15:08:05 *	kingtaco|work gives voice to jeeves
-Jun 14 15:08:12 hlieberman	jeeves++
-Jun 14 15:08:33 christel	marienz: yes! but i have so much new stuff :D (and ive just been informed that im banned from going to ikea for 12 months)
-Jun 14 15:08:43 marienz	christel: you should be, that's for sure
-Jun 14 15:08:45 hlieberman	christel, By... the store?
-Jun 14 15:08:48 *	solar wonders how much karma jeeves would have
-Jun 14 15:08:59 hlieberman	christel, What did you do!?
-Jun 14 15:09:40 jakub	hlieberman: she painted the whole store pink :P
-Jun 14 15:09:46 fmccor	Hi, christel ; bye, christel
-Jun 14 15:10:05 jmbsvicetto	jakub: :)
-Jun 14 15:12:54 christel	perhaps this isn't the place for this discussion :)
-Jun 14 15:13:07 *	jakub snickers
-Jun 14 15:13:38 robbat2	christel, in the catalyst document you mention formal training
-Jun 14 15:13:43 robbat2	what form does that presently take?
-Jun 14 15:14:09 marienz	nonexistant, afaik
-Jun 14 15:14:21 marienz	training, yes, formal, no
-Jun 14 15:14:30 marienz	(christel: correct me if I lie)
-Jun 14 15:16:15 *	dang has quit ("Leaving.")
-Jun 14 15:17:36 christel	marienz: we havent done much in the way of formal training for a while, however, next batch is upcoming when we finish the appraisals
-Jun 14 15:17:40 christel	:)
-Jun 14 15:18:36 kloeri	good luck solving these problems everybody - in particular devrel and council that I left a bit abruptly :)
-Jun 14 15:18:57 christel	robbat2: i dont think freenodes catalyst idea can be made to work for gentoo that easily really, its different fora. however, the idea of empowering people to be helpful and respectful is always a good one, and can be adapted pretty much anywhere
-Jun 14 15:19:12 christel	kloeri: bitch
-Jun 14 15:19:18 christel	:P
-Jun 14 15:19:42 robbat2	christel, as I noted, it would work fine if every developer held themselves to it before hitting send on their email
-Jun 14 15:20:25 robbat2	but that's a pipe dream with the present attitudes and behavior
-Jun 14 15:20:33 kloeri	christel: now now, be a good catalyst :)
-Jun 14 15:21:00 spb	remember your high school chemistry, everyone
-Jun 14 15:21:04 spb	catalysts speed up reactions
-Jun 14 15:21:28 robbat2	spb, lol!
-Jun 14 15:21:33 hlieberman	spb++
-Jun 14 15:22:47 christel	spb: ;)
-Jun 14 15:23:39 christel	robbat2: yeah, however, it is something we (you) are in a position to demand :)
-Jun 14 15:24:23 *	think4urs11 (n=think4ur@gentoo/developer/think4urs11) has left #gentoo-council ("see ya")
-Jun 14 15:28:15 *	desultory (n=dean@gentoo/developer/desultory) has left #gentoo-council
-Jun 14 15:29:21 robbat2	spb, am I correct in noting that nobody has commited to PMS in the last 2 months?
-Jun 14 15:29:47 spb	entirely possible
-Jun 14 15:30:32 robbat2	ok, please bug me in two weeks if you don't hear from me about how to access Git ;-)
-Jun 14 15:33:54 armin76	robbat2: http://cia.vc/stats/project/PMS
-Jun 14 15:34:21 robbat2	armin76, yup, that ties up with what I know
-Jun 14 15:34:26 robbat2	r164 two months ago
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070712-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070712-summary.txt
deleted file mode 100644
index 18b3951eb0..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070712-summary.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-- Council noted the lack of pre-prepared agenda items, and tried to see what
-  outsanding issues from previous months were still running. jaervosz and
-  vapier were marked as slackers for non-attendance.
-
-- On the Musikc's proposal from the June meeting that was to be assembled and
-  discussed by proctors, no progress had been made due to real-life issues and
-  timing conflicts. The previously existing document was not agreed upon by
-  existing proctors either.
-
-- The issues of -project, and moderation of email were brought up the
-  counterproposal to the proctors, as they had been discussed in the June 2007
-  meeting.
-
-- Kingtaco wanted a vote to cancel the proctors. robbat2 wanted them to just
-  die quietly if no material was forthcoming. Others called for a definate
-  stand rather than the "die quietly". All 5 attending council members voted
-  in favour of dropping the proctors.
-
-- More discussion was put into the -project and moderation issue and the state
-  of proctors.
-
-- nightmorph aske the council questions about how much time council work takes
-  up and the like.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070712.txt b/xml/htdocs/proj/en/council/meeting-logs/20070712.txt
deleted file mode 100644
index dfcb6ba173..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070712.txt
+++ /dev/null
@@ -1,406 +0,0 @@
-**** BEGIN LOGGING AT Thu Jul 12 13:00:31 2007
-Jul 12 13:00:31 *	kingtaco|work sets mode +m #gentoo-council
-Jul 12 13:00:34 *	kingtaco|work gives voice to spb
-Jul 12 13:00:46 wolf31o2	ok... I'm here and I've got (at most) 1 hour before a meeting here
-Jul 12 13:01:10 kingtaco|work	I've work to do today too
-Jul 12 13:01:16 kingtaco|work	no 6 hour long meetings
-Jul 12 13:01:40 kingtaco|work	erm
-Jul 12 13:01:44 kingtaco|work	we're missing some people
-Jul 12 13:02:19 wolf31o2	yeah
-Jul 12 13:02:19 kingtaco|work	SpanKY, vapier: ping
-Jul 12 13:03:02 robbat2	ok, I _just_ got the summary of the previous meeting completed
-Jul 12 13:03:34 *	nightmorph (n=nightmor@gentoo/developer/nightmorph) has joined #gentoo-council
-Jul 12 13:03:45 wolf31o2	do we even have an agenda this meeting?
-Jul 12 13:03:57 wolf31o2	nobody sent anything out, so I'm not really even sure what we're discussing
-Jul 12 13:04:14 kingtaco|work	proctor shit from last month
-Jul 12 13:04:20 kingtaco|work	ML shit from last month
-Jul 12 13:04:30 robbat2	that was dependant on musikc's email
-Jul 12 13:04:36 robbat2	which I didn't see go out at all
-Jul 12 13:04:43 kingtaco|work	we could talk about the pms/eapi stuff, but that seems pointless
-Jul 12 13:04:51 robbat2	there's nothing there either
-Jul 12 13:04:57 wolf31o2	right
-Jul 12 13:05:14 robbat2	spb, pingy
-Jul 12 13:05:18 spb	hi
-Jul 12 13:05:34 robbat2	do you have anything to bring up while you are standing in for Kugelfang?
-Jul 12 13:05:42 spb	not that i can think of
-Jul 12 13:05:58 *	robbat2 gives voice to musikc
-Jul 12 13:06:26 *	Uber (n=uberlord@gentoo/developer/UberLord) has joined #gentoo-council
-Jul 12 13:06:27 *	ChanServ gives channel operator status to Uber
-Jul 12 13:06:34 Uber	hi
-Jul 12 13:06:47 robbat2	hi Uber
-Jul 12 13:06:52 robbat2	do you have any council business to bring up?
-Jul 12 13:06:54 spb	you're late grumble grumble
-Jul 12 13:06:59 robbat2	else this is looking like a very short meeting
-Jul 12 13:07:16 Uber	no and sorry. rl stuff :/
-Jul 12 13:07:20 spb	it is rather
-Jul 12 13:07:47 robbat2	yeah, it seems a lot of folks hit RL keeping them busy
-Jul 12 13:08:11 robbat2	that's eaten a lot of my time this last month, my commit stats on CIA are dismal
-Jul 12 13:08:35 spb	heh, try mine
-Jul 12 13:08:37 Uber	I'm doing a load of out of normal hours stuff atm :/
-Jul 12 13:08:57 Uber	the curse of a month long honeymoon I guess!
-Jul 12 13:09:10 spb	slacker
-Jul 12 13:09:34 Uber	pot meet kettle :P
-Jul 12 13:09:43 wolf31o2	1 messages so far this month, 30 messages last month
-Jul 12 13:09:46 wolf31o2	wow... I'm slack
-Jul 12 13:10:11 robbat2	ok, so open floor just to see if anybody else has anything?
-Jul 12 13:10:18 spb	go for it
-Jul 12 13:10:34 musikc	wrt the proctors, the only thing i can speak on first hand is that a proposal was not put together and agreed upon by the remaining five members. from what i have heard the proctors had issues with various members being absorbed by real life or conflicts in timing. bottom line, the only proposal document has not been agreed upon by all existing members.
-Jul 12 13:10:38 Uber	well, all my projects are ticking along nicely :)
-Jul 12 13:10:45 *	robbat2 sets mode -m #gentoo-council
-Jul 12 13:10:51 kingtaco|work	I think the proctor business is a waste of time
-Jul 12 13:11:19 robbat2	could somebody please send a email proposing the -project list with moderation stuff to the -dev ML?
-Jul 12 13:11:26 musikc	im not sure if any of them are present :-|
-Jul 12 13:11:28 robbat2	anybody else out there got anything they want to raise?
-Jul 12 13:11:31 spb	proctors aren't likely to go anywhere without starting from scratch imo
-Jul 12 13:11:43 Uber	kingtaco|work: heh, we have someone doing a talk on that on saturday - The Proctors
-Jul 12 13:11:51 kingtaco|work	Uber, huh?
-Jul 12 13:11:59 wolf31o2	at GUK07
-Jul 12 13:12:02 Uber	at gentoo uk meeting
-Jul 12 13:12:04 spb	gentoo-uk event type thing on saturday
-Jul 12 13:12:10 *	Uber nods
-Jul 12 13:12:12 spb	neddyseagoon is talking about them apparently
-Jul 12 13:12:12 kingtaco|work	I'd love to see what they claim they do
-Jul 12 13:12:28 kingtaco|work	frankly, they have failed
-Jul 12 13:12:33 wolf31o2	ok... so... open floor?
-Jul 12 13:12:33 kingtaco|work	the concept is flawed
-Jul 12 13:12:45 kingtaco|work	wolf31o2, you're too late, it's already there
-Jul 12 13:12:45 fmccor	I've worked with the protcors for a month.  I highly reccomd them without any doubt.
-Jul 12 13:12:47 Uber	yeah, open floor. brb, 15 mins
-Jul 12 13:12:48 musikc	will a decision be made about the proctors today?
-Jul 12 13:13:02 Philantrop	I'm probably rather well known for agreeing that proctors are not needed. They *do* have some better ideas this time, I think. The pressure put on them to produce "something" which they didn't know about exactly probably prevented them to come up with a coherent document.
-Jul 12 13:13:31 wolf31o2	musikc: the meeting is essentially over... we didn't have anything to discuss
-Jul 12 13:13:47 kingtaco|work	wolf31o2, not true, just pointless to discuss anything
-Jul 12 13:13:53 robbat2	anybody got any status notes they want to drop in?
-Jul 12 13:13:57 wolf31o2	whatever
-Jul 12 13:13:58 wolf31o2	same diff
-Jul 12 13:14:09 wolf31o2	robbat2: I think my CIA stats speak well enough on my status notes
-Jul 12 13:14:10 wolf31o2	heh
-Jul 12 13:14:19 wolf31o2	1 commit this month
-Jul 12 13:14:29 robbat2	jaervosz, vapier: last chance before you get marked AWOL
-Jul 12 13:14:41 Philantrop	musikc: They mailed you their notes for forwarding to the council, didn't they?
-Jul 12 13:15:02 robbat2	wolf31o2, the last several months for me were: 93, 82, 17, 9
-Jul 12 13:15:07 *	Betelgeuse (n=betelgeu@gentoo/developer/Betelgeuse) has joined #gentoo-council
-Jul 12 13:15:13 nightmorph	robbat2: isn't this the last month for the current council anyway?
-Jul 12 13:15:18 wolf31o2	robbat2: ouch...
-Jul 12 13:15:24 wolf31o2	no, next meeting is the last one
-Jul 12 13:15:27 robbat2	nightmorph, no, I think we have one more
-Jul 12 13:15:28 nightmorph	ah, k
-Jul 12 13:15:32 robbat2	since that is during the voting period
-Jul 12 13:15:32 *	steev64 (n=steev@gentoo/developer/steev) has joined #gentoo-council
-Jul 12 13:15:43 musikc	fmccor mailed me a bunch of documents, not a coherent proposal. in conversation with neddy, he said the documents were out of date so together we worked on a new one but the other members have not commented on it so its only approved by one member.
-Jul 12 13:15:57 wolf31o2	well, if anyone needs me, ping me... I'm off
-Jul 12 13:15:59 nightmorph	wrt the proctors, i hear some negative sentiment, but no concrete reasons why they are bad/ineffective, especially considering it was the current council that created them in the first place
-Jul 12 13:16:11 *	Ingmar^ (n=ingmar@d51A487D7.access.telenet.be) has joined #gentoo-council
-Jul 12 13:16:30 nightmorph	anyone else have any counterproposals for something newer/better than the proctors?
-Jul 12 13:16:40 robbat2	kingtaco|work, can you put together the -project + moderation email when you get home and send it to the -dev list?
-Jul 12 13:16:42 wolf31o2	yes, and it was brought up last month
-Jul 12 13:16:46 robbat2	nightmorph, the -project + moderation stuff
-Jul 12 13:16:53 nightmorph	i don't recall that from last month's logs, sorry
-Jul 12 13:16:58 kingtaco|work	vote: cancel this proctor nonsense
-Jul 12 13:17:12 robbat2	kingtaco|work, just leave it to die quietly
-Jul 12 13:17:28 musikc	nightmorph: if the proctor project is revoked, the mailing list idea is a good start, and any proctor members are welcome to talk to devrel regarding conflict resolution if they are interested.
-Jul 12 13:17:29 robbat2	see if the -project+moderation has more take up
-Jul 12 13:17:48 kingtaco|work	robbat2, do me a favor and pull those htpasswds then
-Jul 12 13:18:14 musikc	seriously council, can you guys decide one way or the other for the proctors. its only fair to resolve the matter than keep them wondering if it'll be just revoked later.
-Jul 12 13:18:23 wolf31o2	ok... fine...
-Jul 12 13:18:27 Philantrop	Let the proctors stuff "die quietly" would rather unfair. You should really decide.
-Jul 12 13:18:34 fmccor	proctors are doing fine.
-Jul 12 13:18:36 wolf31o2	I vote the project is dropped
-Jul 12 13:18:40 nightmorph	at least before neddyseagoon give his presentation
-Jul 12 13:18:44 kingtaco|work	I vote to drop it
-Jul 12 13:18:46 *	wolf31o2 sets mode +m #gentoo-council
-Jul 12 13:18:56 wolf31o2	if we're back to voting, we don't need input from non-council
-Jul 12 13:19:09 wolf31o2	ok... so are we voting?
-Jul 12 13:19:12 robbat2	Uber, vapier, spb?
-Jul 12 13:19:22 spb	re proctors?
-Jul 12 13:19:30 kingtaco|work	yes\
-Jul 12 13:19:32 wolf31o2	correct... disbanding the project entirely
-Jul 12 13:19:33 spb	either drop it or start over
-Jul 12 13:19:40 kingtaco|work	that's not your choice
-Jul 12 13:19:46 spb	so as far as its current incarnation is concerned, disband it
-Jul 12 13:19:54 robbat2	for me, conditional yes, to be replaced by the -project + moderation stuff
-Jul 12 13:20:18 kingtaco|work	you really can't place a condition on your vote
-Jul 12 13:20:25 wolf31o2	yeah, it's yes or no
-Jul 12 13:20:26 wolf31o2	heh
-Jul 12 13:20:45 robbat2	fine, yes, but somebody DOES still need to send that -project proposal stuff to -dev
-Jul 12 13:20:51 spb	rephrase it then as "yes, on the understanding that the other stuff is being done"
-Jul 12 13:21:14 robbat2	Uber, SpanKY: we need one of you guys
-Jul 12 13:21:30 wolf31o2	not anymore, we don't
-Jul 12 13:21:40 wolf31o2	spb is filling in for danny so we've got 4/7 voted yes
-Jul 12 13:22:01 wolf31o2	or do we need 5/7 for the vote itself?
-Jul 12 13:22:04 *	beandog (n=sdibb@gentoo/developer/beandog) has joined #gentoo-council
-Jul 12 13:22:12 spb	simple majority, no?
-Jul 12 13:22:34 wolf31o2	true
-Jul 12 13:23:02 robbat2	"Council decisions are by majority vote of those who show up (or their proxies)."
-Jul 12 13:23:15 wolf31o2	k
-Jul 12 13:23:18 robbat2	we have 5 attending, and 4/5 said yes
-Jul 12 13:23:22 wolf31o2	then we're good...
-Jul 12 13:23:22 robbat2	so I guess it's solid
-Jul 12 13:24:39 kingtaco|work	robbat2, email sent
-Jul 12 13:24:43 kingtaco|work	we vote next month
-Jul 12 13:24:52 robbat2	ok
-Jul 12 13:24:59 robbat2	open floor again
-Jul 12 13:25:03 wolf31o2	so are we done?
-Jul 12 13:25:03 *	robbat2 sets mode -m #gentoo-council
-Jul 12 13:25:06 robbat2	i think so
-Jul 12 13:25:18 fmccor	you suck.
-Jul 12 13:25:36 kingtaco|work	thanks
-Jul 12 13:25:39 Philantrop	kingtaco|work: I may be dumb but what are you going to vote about next month? :)
-Jul 12 13:25:41 steev64	seconded?
-Jul 12 13:25:44 fmccor	proctors are fine.
-Jul 12 13:25:50 kingtaco|work	Philantrop, see -dev email
-Jul 12 13:25:55 kingtaco|work	about changes to the list
-Jul 12 13:26:10 Philantrop	kingtaco|work: Ah, ok, thanks.
-Jul 12 13:26:16 wolf31o2	fmccor: no, they're disbanded... ;]
-Jul 12 13:26:24 steev64	huge surprise there
-Jul 12 13:27:09 fmccor	wolf31o2,  If comment, I suck, too.
-Jul 12 13:27:22 Philantrop	fmccor: Well, I'm not too pleased about the way the notes were handled. Neddy should probably have handed them on himself. I think they finally started to show some constructive progress. But that's over now, I guess.
-Jul 12 13:27:57 musikc	Philantrop:  you may wish to speak with Neddy. when we spoke yesterday he referred to the notes as having out of date and inaccurate information.
-Jul 12 13:28:20 Philantrop	musikc: I will.
-Jul 12 13:28:43 blackace	ah, cool, disbanded, you guys try moderating thousands of asshats, or making a council meeting after pulling an all-nighter moderating IRC and working a real job that requires you to work during another timezone's work day
-Jul 12 13:28:48 fmccor	Philantrop, you have now idea how hard we have been working.
-Jul 12 13:29:11 steev64	had
-Jul 12 13:29:11 Philantrop	fmccor: That was not really directed at you or the proctors. :)
-Jul 12 13:29:19 tsunam	I take it I missed the meeting?
-Jul 12 13:29:24 nightmorph	kingtaco|work: i think i'm just the slightest bit confused by your email. proposal is that -dev is closed to everyone but an @gentoo email, right? then why would "any dev could moderate a non-dev post" if non-devs can't post to it in the first place?
-Jul 12 13:29:25 blackace	tsunam: yeah
-Jul 12 13:29:31 tsunam	well that was short
-Jul 12 13:29:35 musikc	tsunam: yes, 13:00 our time
-Jul 12 13:29:39 tsunam	well yes
-Jul 12 13:29:48 tsunam	I knew it was 1300 but its 13:30
-Jul 12 13:29:51 nightmorph	kingtaco|work: maybe i'm just reading it wrong
-Jul 12 13:29:52 tsunam	figured it'd run that long ~_~
-Jul 12 13:29:53 robbat2	past meetings tending to be getting into the 90 minute length
-Jul 12 13:29:53 *	blackace notes normal people have to work at 13:00
-Jul 12 13:30:29 tsunam	and from the sounds of what I see..protors are poof
-Jul 12 13:30:35 Uber	back
-Jul 12 13:30:35 kingtaco|work	nightmorph, everyone can sub and read
-Jul 12 13:30:35 robbat2	blackace, the time was a collective agreement by the council as to when all of them are able to attend it
-Jul 12 13:30:37 steev64	this council knows what they want, and they get it done
-Jul 12 13:30:47 nightmorph	kingtaco|work: k...
-Jul 12 13:31:00 blackace	robbat2: good for them, do they plan to do anything about -dev?
-Jul 12 13:31:02 tsunam	steev64: not really, they've backed down when people complained :-P
-Jul 12 13:31:03 Philantrop	wolf31o2: On a much less problematic :) subject: Any ETA for the next GWN?
-Jul 12 13:31:06 *	Uber reads up
-Jul 12 13:31:14 kingtaco|work	nightmorph, any dev who's not been moderated for shitty stuff in the past can choose to moderate
-Jul 12 13:31:29 robbat2	blackace, you mean the #-dev channel? 
-Jul 12 13:31:30 blackace	robbat2: and I mean personally
-Jul 12 13:31:30 nightmorph	kingtaco|work: you mean, allow a non-dev not just +r, but +rw?
-Jul 12 13:31:32 steev64	wouldn't that currently be nobody since moderation hasn't ahppened yet?
-Jul 12 13:31:39 musikc	Philantrop: we're planning on releasing again starting 7/16 (this coming monday)
-Jul 12 13:31:40 blackace	robbat2: I mean #gentoo-dev and the -dev ML
-Jul 12 13:31:44 TFKyle	nightmorph: I think it's pretty much the same as discussed in last months council meeting, where devs can post unmoderated, but non-devs can post too if a dev lets the post in
-Jul 12 13:31:48 fmccor	Philantrop, I started out hating the whole idea.  Then I met the proctors, and talked with them.
-Jul 12 13:31:49 kingtaco|work	nightmorph, no, typical ML moderation
-Jul 12 13:31:52 TFKyle	(could be wrong though)
-Jul 12 13:32:04 blackace	robbat2: not, find something they can shovel off to infra, because we all know how effective that is
-Jul 12 13:32:05 Philantrop	musikc: Ah, thanks. Then back to the regular schedule?
-Jul 12 13:32:11 tsunam	here's the simple question. Who enforces the coc?
-Jul 12 13:32:11 kingtaco|work	it is exactly what I said last month
-Jul 12 13:32:12 nightmorph	kingtaco|work: i guess i just haven't ever really seen ML moderation of any sort
-Jul 12 13:32:20 musikc	Philantrop: thats the plan
-Jul 12 13:32:32 nightmorph	i must just be translating your message into my own special english so that it makes no sense only to me, kingtaco|work :)
-Jul 12 13:32:42 kingtaco|work	tsunam, devrel does
-Jul 12 13:32:49 TFKyle	(I agree though, the post is a bit ambiguous about that)
-Jul 12 13:32:53 fmccor	Now, what about Roy's ppresentation?
-Jul 12 13:32:56 tsunam	kingtaco|work: k good enough for me
-Jul 12 13:32:57 blackace	haha
-Jul 12 13:32:59 blackace	hahahahaha
-Jul 12 13:33:10 nightmorph	fmccor: someone prolly better mention today's outcome to him pretty quick
-Jul 12 13:33:23 blackace	hfwt folks
-Jul 12 13:33:35 nightmorph	hfwt?
-Jul 12 13:33:39 nightmorph	oh. "have fun with that"?
-Jul 12 13:33:39 Philantrop	fmccor: I didn't like the idea, I didn't like the first active *public* attempts but the "work less in public" concept (or what I glimpsed about it) looked much better to me. I think that might have worked.
-Jul 12 13:33:49 robbat2	blackace, i'm sorry, you just moved from complaining about everybody having different times on #-dev + -dev ML, to infra not seeming to get stuff done?
-Jul 12 13:33:51 kingtaco|work	fmccor, I don't see how it changes anything.  further, if they come up with something they can bring it to the next council
-Jul 12 13:33:51 Uber	for the record i vote the proctors dropped too in their current form
-Jul 12 13:34:00 fmccor	He's scheduled, I think.
-Jul 12 13:34:12 wolf31o2	robbat2: he's just complaining... period... heh
-Jul 12 13:34:32 tsunam	Basically, yes there was an overreaction in public due to complaints that proctors were doing nothing. Instead of explaining what was actually occuring
-Jul 12 13:34:36 tsunam	simple as that
-Jul 12 13:34:53 steev64	tsunam: and vice versa
-Jul 12 13:35:07 blackace	robbat2: no, I complained about the unrealistic meeting time, and now I want to know what the council is going to DO seeing as they've disbanded the only group of people willing to do the dirty work.
-Jul 12 13:35:08 steev64	there were complaints that the proctors were doing too much
-Jul 12 13:35:09 tsunam	steev64: yes, there were problems on all sides
-Jul 12 13:35:09 nightmorph	kingtaco|work: i'll take your word for it. just...the first time what you're talking about happens on the list, nudge me so that i'm aware of it and can study it while it's happening :)
-Jul 12 13:35:11 *	zmedico (n=zmedico@ip68-4-152-120.oc.oc.cox.net) has joined #gentoo-council
-Jul 12 13:35:12 fmccor	wolf31o2, you have no idea what I'm about.
-Jul 12 13:35:55 wolf31o2	fmccor: who was talking about you?
-Jul 12 13:36:08 robbat2	blackace, all previous councils have come up with a meeting time that works for them as the council, because they NEED to attend, otherwise they are booted from said council
-Jul 12 13:36:35 robbat2	for doing something now, that's the email to -dev about -project+moderation, which was discussed in extreme depth in the last council meeting
-Jul 12 13:36:37 musikc	fmccor: wolf was referring to blackace if you scroll back
-Jul 12 13:36:59 wolf31o2	and was joking... note the "heh"
-Jul 12 13:37:14 blackace	wolf31o2: I've met you, you don't joke very much :P
-Jul 12 13:37:20 nightmorph	zing!
-Jul 12 13:37:30 tsunam	steev64: I never heard of doing too much personally. All I can say is that personally when I acted I was thanked by those I told to behave. As a group the proctors failed. However as long as the idea that was the aim continues that is the most important thing
-Jul 12 13:37:34 blackace	nightmorph: hey now, no batman sound effects
-Jul 12 13:37:37 wolf31o2	blackace: you'd be surprised... all my friends back east keep telling me how chill I am now...
-Jul 12 13:38:07 wolf31o2	I'm sure it has pretty much everything to do with the change in employment
-Jul 12 13:38:09 nightmorph	blackace: i've got a *biff* for you the next time i see you in #gentoo
-Jul 12 13:38:18 steev64	tsunam: *shrug* since you suggested i just killfile, its been pretty good and relaxing on my end
-Jul 12 13:38:26 blackace	wolf31o2: really that much better huh?
-Jul 12 13:38:31 nightmorph	tsunam: how many proctors were left though before today?
-Jul 12 13:38:35 musikc	blackace: you have no idea
-Jul 12 13:38:37 wolf31o2	blackace: night and day
-Jul 12 13:38:40 musikc	heh
-Jul 12 13:38:41 blackace	cool
-Jul 12 13:38:43 tsunam	nightmorph: 4-5
-Jul 12 13:39:03 wolf31o2	anyway...
-Jul 12 13:39:11 *	wolf31o2 is out... if you need me, ping me
-Jul 12 13:39:11 tsunam	what's done is done
-Jul 12 13:39:16 robbat2	i need to go as well
-Jul 12 13:39:20 musikc	nightmorph: neddy, marienz, blackace, mark_alec and tsumam was the info i had
-Jul 12 13:39:21 tsunam	simple as that
-Jul 12 13:39:26 tsunam	the council has make its decision
-Jul 12 13:39:44 tsunam	we elected these people to guide the direction of gentoo..and need to believe in them to make the right choices
-Jul 12 13:39:49 tsunam	as we did elect them
-Jul 12 13:40:02 tsunam	something that they've not really gotten much of from the developers as a whole
-Jul 12 13:40:13 Philantrop	tsunam: We do not need to believe in them. We do have to respect their decisions, though.
-Jul 12 13:40:15 *	blackace looks at tsunam 
-Jul 12 13:40:32 musikc	well again, tsunam and blackace, the dark side... errr devrel would be interested in talking to you guys if you're interested
-Jul 12 13:40:35 TFKyle	so is -project going to be anything goes or?
-Jul 12 13:40:40 solar	respect is earned.. never a given
-Jul 12 13:40:46 tsunam	yes blackace I know what you're thinking yet again. I'm sure you'll come poke me about it later
-Jul 12 13:41:03 nightmorph	musikc: thanks
-Jul 12 13:41:05 tsunam	solar has a point there
-Jul 12 13:41:07 kingtaco|work	solar, if you don't respect the council then you should call for a new one to be elected
-Jul 12 13:41:11 kingtaco|work	it's that simple
-Jul 12 13:41:15 Philantrop	solar: Respect for people, yes. Respect for their decisions doesn't mean we can't critisize them, though.
-Jul 12 13:41:16 kingtaco|work	all of you
-Jul 12 13:41:29 tsunam	Philantrop: constructively
-Jul 12 13:41:31 kingtaco|work	your critism has been unfounded and misplaced
-Jul 12 13:41:32 solar	kingtaco|laptop: I'm content with this council :p
-Jul 12 13:41:41 Philantrop	tsunam: Yes, I meant that. :-)
-Jul 12 13:41:49 spb	'respect' has several different meanings
-Jul 12 13:41:53 nightmorph	kingtaco|work: i might have done that a few months ago, but it's too late now. besides, how do votes of no confidence work? i mean, can it be selective, or does it have to be all or nothing?
-Jul 12 13:41:54 blackace	kingtaco|work: as far as I'm concerned, the council is guilty of same
-Jul 12 13:41:55 kingtaco|work	you crippled the same people you voted in
-Jul 12 13:41:58 nightmorph	i'm curious about that
-Jul 12 13:42:03 blackace	yup, same
-Jul 12 13:42:12 spb	some of them have to be earned otherwise they're worthless, and some should be present almost unconditionally
-Jul 12 13:42:39 kingtaco|work	nightmorph, as I explained many months ago, if it ever got to the point where a vote of no confidence had to be called, the current council couldn't make those rules because noone would follow them
-Jul 12 13:42:41 kingtaco|work	it's a coup
-Jul 12 13:43:00 nightmorph	hmm
-Jul 12 13:43:17 Philantrop	spb: Indeed. A minimum of respect is earned simply by being a human being, IMHO. (Let's not discuss animal rights now, though. :) )
-Jul 12 13:43:23 robbat2	the most that they could do is collectively not show up for the meeting
-Jul 12 13:43:30 nightmorph	well, it's the end of the line for the current government either way, after one more meeting i guess
-Jul 12 13:43:48 robbat2	and it seems that nearly all of us aren't sticking around for the new council
-Jul 12 13:43:58 nightmorph	maybe 1 year is too long?
-Jul 12 13:44:04 nightmorph	what a bout a 6-month or 9-month term?
-Jul 12 13:44:08 spb	Philantrop: a minimum of courtesy, perhaps
-Jul 12 13:44:12 nightmorph	that way RL stuff maybe won't interfere so much
-Jul 12 13:44:26 robbat2	no, it's just long enough to get people annoyed with you so they don't vote for you as an incumbent
-Jul 12 13:44:27 nightmorph	people have kids, move, die, etc. all that tends to interfere with gentoo duties
-Jul 12 13:44:32 nightmorph	aww :/
-Jul 12 13:44:32 Philantrop	spb: Ok, I think we can agree on that. :-)
-Jul 12 13:44:51 wolf31o2	nightmorph: I don't think the term is the problem so much as general developer backlash on every decision making it undesirable to decide to serve the community in this fashion ever again
-Jul 12 13:45:04 musikc	robbat2: or they get burned out and just dont want to do it again
-Jul 12 13:45:09 Philantrop	nightmorph: Personally, I think the one year term is fine. It's needed for a somewhat stable course.
-Jul 12 13:45:16 wolf31o2	agreed
-Jul 12 13:45:17 nightmorph	wolf31o2: that's very possible. but 1 year might serve up too many repeated incidents like that for a given person's plate
-Jul 12 13:45:18 robbat2	Philantrop, ok, i'm sorry we lead you guys on. From the last meeting it looked like you were making progress with musikc, but there's been no movement since then
-Jul 12 13:45:52 wolf31o2	nightmorph: I guess... I just got tired of having this big bullseye on my back...
-Jul 12 13:45:54 nightmorph	i'm just pointing out that if the job burns everyone out that much, perhaps it can be somewhat mitigated by shorter terms
-Jul 12 13:46:07 tsunam	wolf31o2: you as well just do too much
-Jul 12 13:46:34 musikc	nightmorph: or lets go utopia on this and say wouldnt it be nice if the developer pool didnt backlash the council for every decision they were elected to make
-Jul 12 13:46:36 wolf31o2	nightmorph: I think the problem is the lack of courtesy from the developer pool coupled with the lack of visible respect for the council, its members, and its decisions...
-Jul 12 13:46:45 Philantrop	robbat2: I wasn't a proctor. :-) Personally, I think they made some progress but this issue has been decided and while I'm not convinced it was the right time for it, I can accept it.
-Jul 12 13:46:48 nightmorph	wolf31o2: that reminds me. in your declining answer to your nomination email, you said you won't be doing anything resembling a leadership position at gentoo -- i wasn't clear on whether or not that extends to your stuff as releng head?
-Jul 12 13:46:56 wolf31o2	being constantly told how little you're doing, how much you suck, and how every decision you make is "wrong" is enough to demotivate anyone
-Jul 12 13:47:18 wolf31o2	nightmorph: releng doesn't lead gentoo
-Jul 12 13:47:27 steev64	or you could not be a quitter, and prove them wrong :-P
-Jul 12 13:47:48 nightmorph	wolf31o2: well, i wasn't clear on how you were defining leadership, that's all
-Jul 12 13:47:58 wolf31o2	nightmorph: council/trustees
-Jul 12 13:48:01 nightmorph	k
-Jul 12 13:48:06 Philantrop	wolf31o2: That comes with any exposed "job" like the council's. One can either deal with it or not. If not, then the decision not to re-run is obviously good.
-Jul 12 13:48:20 robbat2	steev64, I really look forward to not being in council, i won't quit while i'm there, as I am not a quitter, but i'm not chosing to fight that battle again, when I can put my resources to better use
-Jul 12 13:48:32 robbat2	my work with infra and the tree has suffered since I've been doing council stuff
-Jul 12 13:48:42 nightmorph	that reminds me. how much does council have to do council work outside of the monthly meetings?
-Jul 12 13:48:46 robbat2	and that was quite frankly a lot more enjoyable
-Jul 12 13:48:48 nightmorph	i'm wondering about time commitments
-Jul 12 13:48:53 wolf31o2	Philantrop: I think it comes from the general lack of professionalism, courtesy, and real world experience of the majority of our developer pool
-Jul 12 13:49:17 wolf31o2	nightmorph: during the CoC thing, Mike (KingTaco) and myself (at least) spent an entire work week doing Gentoo things
-Jul 12 13:49:21 Uber	in other words a bunch of punks
-Jul 12 13:49:24 wolf31o2	I missed out on *any* paid work that week
-Jul 12 13:49:25 Uber	sorry - kids
-Jul 12 13:49:37 kingtaco|work	yes, I wasted a week on that shit
-Jul 12 13:49:50 Philantrop	wolf31o2: Yes, that is a valid critisism, IMHO.
-Jul 12 13:49:51 musikc	Philantrop: it would be nice to see developers support council, as the developers did pick their council members one might hope it wasnt based on a popularity contest
-Jul 12 13:49:52 nightmorph	i missed some too, as i was the one who had to guidexmlify the thing with no notice :)
-Jul 12 13:49:55 nightmorph	took a few hours
-Jul 12 13:49:59 wolf31o2	Uber: for the most part... though I have met many young developers who possessed those skills... so it isn't the age so much as the outlook
-Jul 12 13:50:16 Uber	wolf31o2: true - dsd is a good example of that :)
-Jul 12 13:50:23 wolf31o2	yes
-Jul 12 13:50:44 robbat2	nightmorph, as an average during my time in council, i'd say that you should budget 2 hours/week, and be prepared to burn that entire annual budget in one week.
-Jul 12 13:50:53 nightmorph	hmm
-Jul 12 13:50:56 nightmorph	that much, eh
-Jul 12 13:50:58 Philantrop	musikc: I support people when I think their cause is just and I won't if I think it's not. It's as simple as that.
-Jul 12 13:51:06 steev64	musikc: not all have though - some didn't have the opportunity to vote (based on age of developer status)
-Jul 12 13:51:45 Betelgeuse	steev64: isn't it for trustees only that you must be 6 months old?
-Jul 12 13:52:08 steev64	Betelgeuse: i thought it was for trustees, council and for running
-Jul 12 13:52:24 musikc	Philantrop: no person will agree 100% with another person all of the time, thats understood. but the backlash ive seen over the last few years personally appears to be something else entirely
-Jul 12 13:52:50 robbat2	i have to go for some work stuff and other meetings now. once my term in council is over after next month, there's an email i've got to write as a summary of being in council
-Jul 12 13:52:59 musikc	steev64: im not sure tbh, i didnt think so
-Jul 12 13:53:07 nightmorph	next question to current council members: when is transparency desirable and when is it not?
-Jul 12 13:53:21 nightmorph	i'm ticking off a list of stuff i've always wanted to know about the council
-Jul 12 13:53:24 wolf31o2	musikc: it seems more like people being pricks just because they can and they know nothing will happen to them
-Jul 12 13:53:25 nightmorph	time crunch was the first :)
-Jul 12 13:53:33 Philantrop	musikc: Yes, to some extent it's undoubtedly simply challenging any authority, total opposition, etc.
-Jul 12 13:53:52 wolf31o2	nightmorph: we try to do everything as transparently as possible... we've had exactly one private discussion, and that was the CoC stuff
-Jul 12 13:54:09 *	kingtaco|work (n=kingtaco@gentoo/developer/kingtaco) has left #gentoo-council ("eat me")
-Jul 12 13:54:12 Uber	even some wanted that to be a public discussion iirc
-Jul 12 13:54:29 robbat2	and we suspect that leaked anyway
-Jul 12 13:54:50 nightmorph	uh huh. now, besides time crunch, transparency, etc., what percentage of council decisions are technical ones (like ebuild policy) vs. nontechnical stuff like..i dunno, community-focused things like the coc and MLs
-Jul 12 13:54:54 nightmorph	robbat2: it did
-Jul 12 13:55:05 kingtaco|laptop	robbat2, it did leak
-Jul 12 13:55:14 kingtaco|laptop	there is zero doubt about it
-Jul 12 13:55:18 kingtaco|laptop	it leaked to ciaranm
-Jul 12 13:55:38 wolf31o2	nightmorph: probably 80/20... I'd guess...
-Jul 12 13:55:41 Philantrop	musikc: We have a proverb here in Germany, though, that translates to something like "Why should the German oak bother if the pig rubs itself on it?". :-)
-Jul 12 13:55:43 kingtaco|laptop	it's pretty obvious who did it but noone will ever know for sure
-Jul 12 13:55:44 wolf31o2	most seemed to be technical
-Jul 12 13:56:08 robbat2	the technical ones gather very few complaints
-Jul 12 13:56:11 musikc	Philantrop: ok ya, that just makes me laugh
-Jul 12 13:56:14 nightmorph	kingtaco|laptop: it leaked to more than just him, but yes
-Jul 12 13:56:15 robbat2	the social ones eat up all the time
-Jul 12 13:56:27 nightmorph	hmm, so the majority by far is technical?
-Jul 12 13:56:35 wolf31o2	correct
-Jul 12 13:56:40 Uber	supposed to be
-Jul 12 13:56:41 nightmorph	hmm .... and to this point, only ebuild-type devs have ever been on it?
-Jul 12 13:56:41 robbat2	by number, technical. by time involved, social.
-Jul 12 13:56:44 wolf31o2	but as robin says, the social take up almost all the time
-Jul 12 13:56:47 nightmorph	heh
-Jul 12 13:56:59 Uber	nightmorph: no, i think swift was coucil and he's not ebuild dev
-Jul 12 13:57:09 Uber	*was*
-Jul 12 13:57:14 robbat2	i must go now
-Jul 12 13:57:16 robbat2	byte
-Jul 12 13:57:17 robbat2	bye
-Jul 12 13:57:18 wolf31o2	swift was a trustee... I don't think he was council
-Jul 12 13:57:19 Uber	cu
-Jul 12 13:57:20 *	robbat2 sets mode -e robbat2
-Jul 12 13:57:20 *	You are now known as robbat2|na
-Jul 12 13:57:20 *	services. sets mode +e robbat2|na
-Jul 12 13:57:27 robbat2|na	somebody please do logs+summary
-Jul 12 13:57:33 Uber	ok, my memory is failing then - old age :)
-Jul 12 13:58:26 nightmorph	thanks for talking this stuff over with me guys :)
-Jul 12 13:58:26 wolf31o2	and yes, someone who isn't an ebuild dev could run for council, but I personally don't think they would be a good fit for the job, since they would need to be able to decide things that affect the tree... but most of it is just learning about something and making a decision
-Jul 12 13:59:05 wolf31o2	so really anyone could do it... and if there were someone who isn't an ebuild dev but had lots of "gentoo" experience in general, I'd definitely consider them (again, personally)
-Jul 12 13:59:06 nightmorph	wolf31o2: that is what i have been thinking about
-Jul 12 13:59:42 nightmorph	decision making ability, transparency, and determination are all important, but i'm also thinking about how technical stuff is important too
-**** BEGIN LOGGING AT Thu Jul 12 14:00:19 2007
-
-Jul 12 14:00:19 wolf31o2	ok... gotta run... meeting
-Jul 12 14:00:32 wolf31o2	the technical is the largest share, but tends to take the least time
-Jul 12 14:01:04 wolf31o2	it's usually a "discuss, vote, approve/deny" and on to the next topic w/ technical
-Jul 12 14:02:28 nightmorph	hmm
-Jul 12 14:13:29 *	Ingmar^ has quit (Remote closed the connection)
-Jul 12 14:13:45 *	Ingmar^ (n=ingmar@d51A487D7.access.telenet.be) has joined #gentoo-council
-Jul 12 14:18:13 SpanKY	ah looks like i was a slacker today
-Jul 12 14:19:22 Uber	bad SpanKY
-Jul 12 14:20:22 SpanKY	had to pick up my brother's car ... forgot today was meeting :(
-Jul 12 14:20:32 spb	excuses excuses
-Jul 12 14:20:51 SpanKY	your momma
-Jul 12 14:33:04 *	kingtaco|laptop (n=kingtaco@gentoo/developer/kingtaco) has left #gentoo-council ("Leaving")
-Jul 12 14:38:40 *	pilla (n=pilla@gentoo/developer/pilla) has joined #gentoo-council
-Jul 12 14:39:01 *	pilla (n=pilla@gentoo/developer/pilla) has left #gentoo-council
-Jul 12 14:48:07 *	nightmorph (n=nightmor@gentoo/developer/nightmorph) has left #gentoo-council
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070816-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20070816-summary.txt
deleted file mode 100644
index d222a73074..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070816-summary.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-- clarification on the procedural side of things with transition to new Council:
-	* Nominations will always be in the month of July
-	* Voting will always be in the month of August
-	* August will always be the last month for a new Council
-	* New Council will always take over in September
-	Delays in misc aspects (like setting up infra to allow voting) will merely
-	delay the start of the new Council and the end of the old Council.  Once
-	the new Council is voted in and takes over, it will still face the end
-	date of August.  This is to avoid ugly sliding windows over time of "Council
-	members serve for a year, but they started late on date XXX so we have to
-	delay the start of the next Council by XXX days blah blah blah".
-
-  Since this year voting ends after the 2nd Thursday but before the 3rd
-  Thursday in September, we'll simply delay the September meeting until the 3rd
-  Thursday so that the new Council gets to sit out 12 meetings.
-
-- mailing list changes (wrt new gentoo-dev-announce).  gentoo-dev-announce is
-  no longer auto cross-posted to gentoo-dev.  reply munging is no longer in
-  effect.  devs can manually cross-post and take discussion to gentoo-dev.
-
-- pms has been moved over to Gentoo infra and will be maintained by the portage
-  team and any other interested Gentoo parties.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20070816.txt b/xml/htdocs/proj/en/council/meeting-logs/20070816.txt
deleted file mode 100644
index c57295cb8d..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20070816.txt
+++ /dev/null
@@ -1,498 +0,0 @@
-[16:02] --- kingtaco|work sets modes [#gentoo-council +m]
-[16:02] <kingtaco|work> lets get this shit started
-[16:02] <-- amne has quit (Remote closed the connection)
-[16:02] <kingtaco|work> roll call
-[16:02] <Uber> I'm 'ere
-[16:02] <kingtaco|work> Kugelfang, robbat2, SpanKY, Uber, wolf31o2|work
-[16:02] <robbat2> hi
-[16:03] --> amne (n=amne@85-124-176-198.dynamic.xdsl-line.inode.at) has joined #gentoo-council
-[16:03] <kingtaco|work> ....
-[16:04] <kingtaco|work> I don't have time to idle
-[16:04] <vapier> ?
-[16:04] <Kugelfan3> pon
-[16:04] <Kugelfan3> g
-[16:04] <kingtaco|work> anyone have any agenda?
-[16:04] <Kugelfan3> me neither
-[16:04] <vapier> i dont one's been posted, but i'd like to know what's up with pms repo on gentoo.org
-[16:04] <vapier> and we should decide about sept
-[16:04] <-- desultory has quit (Client Quit)
-[16:05] --> desultory (n=dean@gentoo/developer/desultory) has joined #gentoo-council
-[16:05] <kingtaco|work> whats up with sept?
-[16:05] <Uber> maybe it's on one of the servers that was taken down recently
-[16:05] <kingtaco|work> um, we don't have any servers by that name
-[16:05] --> hparker (n=hparker@gentoo/developer/hparker) has joined #gentoo-council
-[16:05] <vapier> as in the month
-[16:05] <vapier> toolbox
-[16:06] --> dostrow (n=dostrow@gentoo/developer/dostrow) has joined #gentoo-council
-[16:06] <vapier> this is supposed to be our last meeting, new council in sept
-[16:06] <vapier> however due to delays, voting doesnt end soon enough
-[16:06] <kingtaco|work> fox2mike announced the vote this morning
-[16:06] <kingtaco|work> I suppose a meeting is skipped
-[16:06] <vapier> i'd make the statement: sept is a floating month ... if new council isnt voted in soon enough, existing council handles sept
-[16:07] <Kugelfan3> sounds fair enough
-[16:07] <vapier> but regardless, aug will continue to be the official last month
-[16:07] <Uber> yeah, we should always have a council
-[16:07] <vapier> so we dont have to deal with an ugly sliding window of "1 year"
-[16:07] <kingtaco|work> sure
-[16:07] <robbat2> my bad on the pms repo, but the PMS guys haven't done much lately either - http://pastebin.ca/660160
-[16:07] <robbat2> there was still flak from them on why to have it moved anyway
-[16:07] <robbat2> more on that in a bit
-[16:08] <vapier> one sec
-[16:08] <vapier> we agree on the sept issue ?
-[16:08] --> astinus (n=alex@gentoo/developer/astinus) has joined #gentoo-council
-[16:08] * Uber votes yes
-[16:08] <vapier> sound off like you have a pair
-[16:08] <kingtaco|work> vote: old council will stay past their date in the event a new council hasn't been elected
-[16:08] <Kugelfan3> yes
-[16:08] <robbat2> yes
-[16:08] <vapier> yes
-[16:08] <kingtaco|work> yes
-[16:08] <wolf31o2|work> yes
-[16:08] * kingtaco|work prods Uber 
-[16:09] <vapier> i'll tweak the glep/docs/whatever and make announce later
-[16:09] <kingtaco|work> WFM
-[16:09] <kingtaco|work> next
-[16:09] <kingtaco|work> pms stuff
-[16:09] <kingtaco|work> robbat2, vapier ?
-[16:09] <vapier> i'm not going to hound pms until gentoo.org repo is ready
-[16:09] <vapier> and i have yet to hear "it is" from robbat2
-[16:10] <kingtaco|work> robbat2, ?
-[16:10] <robbat2> there's give and take that they didn't want to give up being able to commit directly, that's also what other projects are saying that want external folk working on things (overlays most notably)
-[16:10] <robbat2> i still haven't gotten the ACL stuff safe to my satisfaction either
-[16:10] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council
-[16:10] <robbat2> that's why I haven't called it 'ready'
-[16:10] --- kingtaco|work sets modes [#gentoo-council +o jaervosz]
-[16:11] <robbat2> it's as up to date as the upstream SVN
-[16:11] <robbat2> which isn't moving fast at all
-[16:11] <kingtaco|work> delay yet another month?
-[16:12] <robbat2> i'd like to ask
-[16:12] <vapier> here's the part i want: when you say the repo is in a usable state with ACL's able to grant/revoke write access
-[16:12] <vapier> when that is ready, we move it and we're done
-[16:13] <robbat2> i see some repos moving away from Gentoo infra already because people want external contributors, and infra has historically said we won't give it to them
-[16:13] <kingtaco|work> I don't see that changing anytime soon
-[16:13] <kingtaco|work> not on the cvs/svn server
-[16:13] <robbat2> from a security point of view
-[16:13] <robbat2> it's not safe to do with CVS and SVN
-[16:13] <kingtaco|work> maybe someplace else like overlays or soc or sunrise
-[16:13] <robbat2> but is doable safely with Git
-[16:13] <robbat2> witness repo.or.cz
-[16:13] <robbat2> which is where some of the gentoo repos have moved
-[16:14] <kingtaco|work> they can stay IMO
-[16:14] <kingtaco|work> infra is taxed enough as it is
-[16:14] <kingtaco|work> we don't need to be supporting every single rcs
-[16:14] <Kugelfan3> that begs the question why PMS can't... (playing advocatus diaboli)
-[16:14] <vapier> if there were a gentoo git server, it'd be a non-issue
-[16:15] <kingtaco|work> vapier, read my statement that infra is over taxed
-[16:15] <kingtaco|work> and before you start the bring more people on, we just did
-[16:15] <robbat2> if I were less busy i'd have the ACLs done already
-[16:15] <vapier> everyone is taxed
-[16:15] <vapier> that's the nature of open source
-[16:16] <robbat2> so the better question, continuing Kugelfan3's point - why force PMS to move if we are letting others stay out there?
-[16:16] <robbat2> it's certainly less load on infra if they stay out
-[16:16] <Uber> so ciaranm has commit access I thought
-[16:16] <kingtaco|work> because they are working on overlays and shit like that, not core policy
-[16:16] <vapier> i dont believe in something that Gentoo relies critically on can live outside of Gentoo
-[16:17] <wolf31o2|work> I tend to agree... something like the specification that defines what is a Gentoo package manager should live within Gentoo
-[16:17] * Uber agrees also
-[16:17] <wolf31o2|work> after all, the package management system is likely the main defining point of Gentoo
-[16:17] <robbat2> it's a document, we don't rely on it, you can break it, it won't break anything in systems
-[16:17] <vapier> i think you need to review your definition of "rely"
-[16:18] <Uber> robbat2: it's like hosting our mission statement on windows servers
-[16:18] <wolf31o2|work> if the document is incorrect and a package manager is released following the incorrect spec, you *can* break boxes
-[16:18] <kingtaco|work> s/can/will
-[16:19] <vapier> the pms doc is a guarantee ... if you use a pm that follows the pms, then things in the tree should work
-[16:19] <wolf31o2|work> exactly
-[16:19] <robbat2> if the overlays weren't so overloaded, we could just trivially move PMS's SVN there
-[16:19] <kingtaco|work> that said, do we(gentoo) need a pms or is it more for the external pm
-[16:20] <kingtaco|work> looking at who contributes to it, it's mainly the paludis group
-[16:20] <wolf31o2|work> kingtaco|work: Gentoo has no need for a PMS if we're only supporting portage... it was written pretty much exclusively to allow external package managers to be on the same page as portage
-[16:20] <kingtaco|work> which makes me wonder, does gentoo define is specs by what's in the tree
-[16:20] <robbat2> Jokey points out that the finnish translations already use the overlays box in the same fashion that I suggest for PMS
-[16:20] <robbat2> so there is certainly precedent
-[16:20] <robbat2> and it works
-[16:20] <kingtaco|work> it's possible that any PMS is of primary use for external projects and perhaps we don't need to involve ourselves
-[16:21] <robbat2> i see the goal of PMS as allowing external PMs to be supported in Gentoo
-[16:21] <robbat2> because they do the same thing as Portage
-[16:21] <wolf31o2|work> has anyone ever thought to ask if Gentoo even cares to support external package managers?
-[16:21] <kingtaco|work> I have no desire to support anything other than what gentoo calls official
-[16:21] <-- jaervosz has quit (Read error: 104 (Connection reset by peer))
-[16:22] <Uber> we have some Gentoo users who do care
-[16:22] <kingtaco|work> I also have no desire to verify that an external manager is indeed PMS compliant
-[16:23] <wolf31o2|work> Uber: users don't have to actually do the support, so I'm not sure that make s a bit of difference... after all, users can do whatever they want to their systems... doesn't mean we have to support it in any way
-[16:23] <kingtaco|work> I'd rather let the portage devs dictate what EAPI does what
-[16:23] <Kugelfan3> afaik portage devs do want PMS
-[16:23] <Kugelfan3> but i might be wrong
-[16:23] <kingtaco|work> if an external manager wants to follow what we do fine.  if they don't thats fine too.
-[16:24] <wolf31o2|work> do they really want it? or do they just want it to shut up the external guys? (I'm honestly asking, I have no clue)
-[16:24] <kingtaco|work> I suspect the latter
-[16:24] <-- test has quit (Remote closed the connection)
-[16:25] <Kugelfan3> kingtaco|work: that is what you suspect... why don't you ask them?
-[16:25] <Kugelfan3> like zmedico
-[16:25] <Uber> wolf31o2|work: I don't see it as any different compared to say supporting a another OS inside of portage
-[16:25] --- kingtaco|work sets modes [#gentoo-council +v zmedico]
-[16:25] <kingtaco|work> zmedico, ping
-[16:25] <wolf31o2|work> Uber: I don't get your meaning
-[16:26] <zmedico> pong
-[16:26] <vapier> Uber: in that case, there are developers actively working on it because they care about it
-[16:26] <Uber> wolf31o2|work: do you expect package owners to fix freebsd bugs with their packages or the freebsd team?
-[16:26] <wolf31o2|work> Uber: that has nothing to do with an external project, so again, I don't get the bearing on this conversation
-[16:27] <kingtaco|work> zmedico, regarding PMS, would the portage team rather develop portage and define EAPI bumps along the way or does the team feel it's important to go the PMS route?
-[16:28] <Uber> wolf31o2|work: no, but it has everything todo with package support which is your bone of contention
-[16:28] <wolf31o2|work> the gentoo/freebsd team *is* a gentoo project, not external... as for who I would expect to fix the packages... both... package maintainers should be writing ebuilds in a portable manner and the alt arch guys should be pointing out issues as they see them and either fixing them or the maintainer fixing them, depending on the severity and extent of the issue at hand... but again, that has nothing to do with external projects
-[16:28] <wolf31o2|work> ok... that's not what I'm saying, at all
-[16:28] <wolf31o2|work> but I really don't care to continue trying to state my point repeatedly... so I'll just say "sure" and we can move on
-[16:29] <vapier> portable isnt quite the word ... we've got an informal standard of things that are/are not OK
-[16:29] <vapier> which is fluid and changes as agreed on gentoo-dev mailing list
-[16:29] * wolf31o2|work hands the pedantic hat to vapier 
-[16:29] <wolf31o2|work> I mean things like... using "cp -a"
-[16:29] <kingtaco|work> gimme my hat back bitch
-[16:29] <zmedico> kingtaco|work: EAPI bumps should be based on input from the general ebuild developer community I think, since the the purpose of EAPI bumps is to give them features that they want.
-[16:29] <kingtaco|work> zmedico, thanks
-[16:29] <vapier> OK: gnu make NOT: crappy POSIX make
-[16:30] <wolf31o2|work> sure
-[16:30] <wolf31o2|work> and if I start using "cp -a" in ebuilds, I'd expect the freebsd guys to come give me a good hard ass kicking
-[16:31] <Uber> yes you would :P
-[16:31] <kingtaco|work> ok, so I ask again, why does gentoo itself care about PMS
-[16:31] <Uber> cp -RPp
-[16:31] <vapier> but *only* because we agreed on the ass kicking ahead of time on the gentoo-dev mailing list
-[16:31] * Uber nods
-[16:31] <wolf31o2|work> we care about it only to define what features are supported in a given EAPI version so it can be used by ebuilds devs
-[16:31] <kingtaco|work> no, the discussion on -dev ml defines eapi bumps
-[16:32] <vapier> which brings us back to do we just merge the doc into portage svn or overlay svn and be done
-[16:32] <vapier> when we agreed on project originally, we gave it to the QA team to maintain
-[16:32] <kingtaco|work> or just ignore it, and start working on eapi1
-[16:32] <kingtaco|work> which has been needed for quite a while
-[16:33] <kingtaco|work> vapier, would seem they've dropped the ball
-[16:33] <zmedico> it's more specific features that are needed than just an "eapi1"
-[16:33] <wolf31o2|work> I agree... it's been a year and we still don't have a completed spec...
-[16:34] <vapier> eh, i would look at it more along the lines of is the QA team even appropriate
-[16:34] <kingtaco|work> in it's current form, I'd say no
-[16:34] <vapier> having it split between teams seems to have just added overhead
-[16:35] <-- Ingmar^ has quit (Read error: 60 (Operation timed out))
-[16:35] <wolf31o2|work> I would say no...
-[16:35] <vapier> if the route we're going is that we dont add crazy things to EAPI/PMS unless we cover it in gentoo-dev, then having it be with the current package manager would lessen that maintenance
-[16:36] <wolf31o2|work> ok... do new features require council buy-in?
-[16:36] <vapier> i think originally the idea was that we needed QA team to watch over it as we had a much more fluid "standard"
-[16:36] <wolf31o2|work> well, it was the qa team that was pretty much asking for it, too
-[16:36] <vapier> but the portage team has reeled themselves in wrt keeping things stable
-[16:36] <vapier> true
-[16:36] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council
-[16:36] <vapier> i dont think stating council buy in is appropriate
-[16:37] <vapier> handle it like anything else ... let it sort itself out and if it doesnt, then we stick a foot in it
-[16:37] <vapier> the figurative "Council Boot" if you will
-[16:38] <wolf31o2|work> ok... reason I am asking is it would determine where pms would best fit... being a global technical document, the best place for it really is the council... in fact, all of our technical specifications really belong under the council, being the council is the primary technical decision-making body...
-[16:38] <wolf31o2|work> which would still work with the "council boot"
-[16:39] <vapier> we take a more fallback guidance roll rather than being on the fore-front
-[16:39] <kingtaco|work> is there a license on the pms stuff?
-[16:39] <-- jaervosz has quit (Read error: 104 (Connection reset by peer))
-[16:39] <vapier> it's all create commons
-[16:39] <vapier> so yes, we can just take it
-[16:39] <kingtaco|work> iirc it's ccsa, but I don't remember exactly
-[16:39] <kingtaco|work> so just take it and be done
-[16:40] <kingtaco|work> the cryers are going to cry no matter what we do
-[16:40] <vapier> the community decides, council steps in when community cant sort itself out
-[16:40] <kingtaco|work> people will leave
-[16:40] <kingtaco|work> shit happens
-[16:40] <kingtaco|work> the community hasn't said anything on it in months
-[16:40] <vapier> i think anyone who would leave over pms has already left ;)
-[16:40] <kingtaco|work> we're in limbo
-[16:40] <kingtaco|work> lets get out and be done with it
-[16:40] <robbat2> nobody has brought a new GLEP up in many months
-[16:40] <Kugelfan3> vapier: no, i haven't yet
-[16:40] <Kugelfan3> vapier: but i will
-[16:41] <wolf31o2|work> so we pull it in house, finalize it, publish it as a finished spec, then move onto the next thing...
-[16:41] <vapier> whatever floats your boat
-[16:41] <kingtaco|work> I don't understand why we have to accomodate any external party
-[16:41] <wolf31o2|work> well, no matter what, the finished version of the spec needs to be on our infra somewhere... even if the repo behind it isn't... I just dont' see a point in keeping them separate
-[16:41] <kingtaco|work> we might choose to, but being forced like this is silly
-[16:42] <wolf31o2|work> we aren't forced to
-[16:42] <robbat2> if we fork it to inhouse, will the inhouse fork still have enough momentum?
-[16:42] <wolf31o2|work> we can pull the repo right now
-[16:42] <kingtaco|work> then why are we doing all this git shit?
-[16:42] <wolf31o2|work> robbat2: what momentum?
-[16:42] <wolf31o2|work> heh
-[16:42] <robbat2> touche
-[16:42] <vapier> yeah, what momentum
-[16:42] <vapier> there is no fork, there is only what represents the tree
-[16:43] <Uber> well, i would imagine there would be some momentum if that happens
-[16:43] <Uber> cue lots of posts to -dev by the usual suspects
-[16:43] <vapier> Gentoo is open sourced, people can do whatever they like with the code
-[16:44] <robbat2> (next agenda item: ML review, requested by tomk)
-[16:44] <wolf31o2|work> right... so we pull it in and the naysayers be damned?
-[16:45] <vapier> it isnt like where we'd be putting it would damn people
-[16:45] <wolf31o2|work> I mean, we already know that any decision (including the lack of one) will cause a flame war
-[16:45] <Uber> i would say yes to bring it under our full control at lesat
-[16:45] <wolf31o2|work> so let's just do what we think is best and deal with it
-[16:45] <robbat2> so move it to overlays, just like the .fi translations?
-[16:45] <vapier> Kugelfang, spb, whoever can still commit all they like
-[16:45] <wolf31o2|work> robbat2: how far away is the SoC box?
-[16:45] <robbat2> wolf31o2|work, ask kingtaco|work
-[16:46] <wolf31o2|work> (I'd prefer not abuse overlays if we don't have to)
-[16:46] <wolf31o2|work> kingtaco|laptop: ^^
-[16:47] <kingtaco|work> it's been ready
-[16:47] <kingtaco|work> gimme a svn dump and it's a command away
-[16:47] <robbat2> vote: move PMS as-is SVN to SoC/Overlays/svn.g.o
-[16:47] <kingtaco|work> user management is vanilla so that'll suck
-[16:47] <kingtaco|work> but it's doable
-[16:48] <vapier> what is the SoC box ?
-[16:48] <kingtaco|work> a box meant for hosting SoC projects and the like
-[16:48] <kingtaco|work> the closest thing we've got to allowing external people repo access
-[16:49] <wolf31o2|work> vapier: it is a new box that is half-dev/half-infra that will host repos allowing for non-gentoo contributors... for the SoC projects but also usable for this sort of thing
-[16:49] <kingtaco|work> sorta like sunrise
-[16:49] <vapier> does svn http://
-[16:49] <wolf31o2|work> my vote: yes
-[16:49] <kingtaco|work> ssh currently
-[16:50] <kingtaco|work> hold on a sec
-[16:50] <kingtaco|work> on that vote
-[16:50] <kingtaco|work> vote for it to go to a specific place, not a "throw the problem at infra"
-[16:50] <vapier> we've already thrown it at infra
-[16:50] <wolf31o2|work> why? the council doesn't care what specific box it resides on... that's infra's job... all we care about is if it is on our infra or not
-[16:50] * vapier looks at robbat2 
-[16:51] <kingtaco|work> why?
-[16:51] <wolf31o2|work> do you really want the council telling you how to run your infra?
-[16:51] <kingtaco|work> because infra doesn't want to choose acls for it
-[16:51] <kingtaco|work> so maybe reword that
-[16:52] <vapier> i recall infra getting angry last time we told them how to run infra
-[16:52] <Uber> why does it need acls? any dev can commit to the tree, why not pms?
-[16:52] <kingtaco|work> what about external people?
-[16:52] <kingtaco|work> that's the problem
-[16:52] <wolf31o2|work> uhh... wouldn't the acls be per-repo anyway?
-[16:52] <kingtaco|work> ok, you're missing the point
-[16:52] <wolf31o2|work> apparently
-[16:53] <kingtaco|work> only current gentoo developers and staff have access to the cvs/svn repos
-[16:53] <kingtaco|work> that will not change
-[16:53] <wolf31o2|work> correct... on our main svn/cvs box
-[16:53] <kingtaco|work> that would be the default place we would put something like this
-[16:53] <kingtaco|work> there is an open unanswered question about external contributors
-[16:53] <kingtaco|work> answer that and infra will work the magic
-[16:53] <kingtaco|work> grok?
-[16:53] <wolf31o2|work> then ask that question rather than beating around the bush... :P
-[16:53] <wolf31o2|work> yep
-[16:54] <wolf31o2|work> so... do we care about external contributors being able to directly commit at this point?
-[16:54] <kingtaco|work> the way the vote was worded forced that question onto infra
-[16:54] <kingtaco|work> hence my objection
-[16:54] <Uber> i care for them not to directly
-[16:54] <wolf31o2|work> I don't see there being enough activity to justify it anymore... so I would say that we are not at the mercy of external contributors
-[16:55] <kingtaco|work> so the vote really is: allow direct external contributors to spec repo
-[16:55] <Uber> and if you are skilled enough to contrib to the PMS then you should by default be a Gentoo dev anyway
-[16:55] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council
-[16:55] <robbat2> Uber, careful with that, re ciaranm
-[16:55] <wolf31o2|work> Uber: that's untrue and PMS is a prime example
-[16:55] <wolf31o2|work> ex-devs can be skilled enough, too
-[16:55] <wolf31o2|work> ;]
-[16:56] <kingtaco|work> Uber, technical skill alone does not make a gentoo dev
-[16:56] <Uber> yes, but isn't that the point - ex dev means not a gentoo developer. Hence as they're not a gentoo developer then they have less power to affect gentoo development
-[16:56] <robbat2> how about this then: infra gets it moved to a Gentoo box asap, and shuffles it to soc/overlays later if there is a large demand for direct external commits
-[16:57] <wolf31o2|work> I'd agree to that
-[16:58] <Uber> ok
-[16:58] <-- jaervosz has quit (Read error: 104 (Connection reset by peer))
-[16:58] --> Ingmar^ (n=ingmar@83.101.12.130) has joined #gentoo-council
-[16:58] <kingtaco|work> vote: fork current external pms repo into svn.gentoo.org and follow up if/when external contributors whine
-[16:59] <Kugelfan3> no
-[16:59] <vapier> what is the follow up
-[16:59] <vapier> what i've heard in the past was "no"
-[17:00] <kingtaco|work> the follow up is someone deciding if/when to move it to a place where external people can commit directly
-[17:00] <robbat2> Kugelfan3, do you want it straight to somewhere that externals can commit directly?
-[17:01] <robbat2> or just don't want it to move
-[17:01] <wolf31o2|work> does it matter?
-[17:01] <wolf31o2|work> it's a yes or no vote
-[17:01] <wolf31o2|work> ;]
-[17:01] <Kugelfan3> heh
-[17:01] <robbat2> i'm wondering why he said no
-[17:01] <Kugelfan3> robbat2: don't move....
-[17:01] <wolf31o2|work> my vote: yes
-[17:01] <vapier> that doesnt answer his question
-[17:02] <kingtaco|work> y'all can vote any time...
-[17:02] <robbat2> yes
-[17:02] <kingtaco|work> don't get shy now
-[17:02] <Uber> yes
-[17:02] <kingtaco|work> vapier, ?
-[17:03] <vapier> i'm for it ... unify current + portage access to the repo
-[17:03] <robbat2> kingtaco|laptop, jaervosz?
-[17:04] <kingtaco|work> my vote is yes
-[17:04] <kingtaco|work> jaervosz is a slacker today
-[17:04] <robbat2> and jaervosz seems to have timed out again
-[17:04] <robbat2> ok, so it's passed and done
-[17:04] <kingtaco|work> any other topics?
-[17:04] <robbat2> infra needs to get an svndump from the existing site
-[17:05] <robbat2> and then just put it online
-[17:05] <kingtaco|work> robbat2, I thought you had one?
-[17:05] <Kugelfan3> ask spb for it
-[17:05] <robbat2> kingtaco|work, I made my git clone via a pull
-[17:05] <wolf31o2|work> mailing lists is next
-[17:05] <robbat2> tomk wanted to know abouts lists
-[17:05] <robbat2> gentoo-dev-announce exists
-[17:05] <robbat2> for cross-posting
-[17:06] <robbat2> there is a hiccup
-[17:06] <robbat2> if you send the message only to gentoo-dev-announce, the auto cross-post fails
-[17:06] <kingtaco|work> I don't think it necessary to vote on moderating -dev list.  -project and -dev-announce seem to have resolved everything
-[17:06] <robbat2> if you put both addresses in to/cc, then the manual copy AND the auto-cross-post get to -dev
-[17:06] <Uber> kingtaco|work: true enough - -dev is running smoothly along :)
-[17:06] <wolf31o2|work> why is dev-announce auto-forwarding anyway?
-[17:06] <wolf31o2|work> it makes it *so* much less useful that way
-[17:07] <robbat2> because people asked for it
-[17:07] <kingtaco|work> so devs can sub to only dev-announce
-[17:07] <kingtaco|work> or only -dev
-[17:07] <kingtaco|work> and noone misses out on announcements
-[17:07] --> windzor (n=windzor@82.143.229.102) has joined #gentoo-council
-[17:07] <wolf31o2|work> but it makes it completely useless for other lists
-[17:07] <kingtaco|work> there is some training that has to be done there
-[17:07] <robbat2> tell them just to sub?
-[17:07] <robbat2> to dev-announce or both
-[17:07] <Uber> yeah, just auto-subscribe all devs or tell em to
-[17:07] <wolf31o2|work> I think it would be easier to just sub all devs to core and announce
-[17:07] <wolf31o2|work> right
-[17:08] <wolf31o2|work> let them decide if they want to sub to projects and dev themselves
-[17:08] <kingtaco|work> that works
-[17:08] <wolf31o2|work> so, for example, I can send a mail to dev-announce announcing something on the releng list
-[17:08] <kingtaco|work> still have to train people to send to the right list though
-[17:08] <wolf31o2|work> that's fine... brow beating works wonders for that sort of thing
-[17:08] <wolf31o2|work> =]
-[17:08] <robbat2> ok, so i'll go and turn off auto-forwarding and sub alls devs to dev-announce
-[17:09] <kingtaco|work> also need to make devrel aware of the changes so they can adjust recruiters procedures
-[17:09] <robbat2> i think that part is scripted, so just adjust the script
-[17:09] <wolf31o2|work> cool... I'm going to research if it is possible to allow for a default reply-to that can be overridden... so I can set reply-to tp gentoo-releng on my releng announcements
-[17:09] <wolf31o2|work> =]
-[17:09] <kingtaco|work> um, it wasn't when I left
-[17:09] <kingtaco|work> we had to go to the mlmmj interface for -core
-[17:10] <kingtaco|work> who's a recruiter in here?
-[17:10] <wolf31o2|work> it still isn't, according to phreak when I asked about adding a gwn email to their recruitment scripts
-[17:10] --- kingtaco|work sets modes [#gentoo-council +v Betelgeuse]
-[17:10] <kingtaco|work> Betelgeuse, you here?
-[17:10] <robbat2> the unsub portion is definetly scripted
-[17:10] <kingtaco|work> but not the sub
-[17:11] <robbat2> what lists? -core, -dev-announce? i'll do a script right now
-[17:11] <kingtaco|work> ok, do we need to vote on this?
-[17:11] <robbat2> i don't think so
-[17:11] <kingtaco|work> nor I
-[17:12] <vapier> if it's part of the recruitment process, just let em decide
-[17:12] <vapier> auto subscribe to all the lists that devs are *supposed* to be one
-[17:12] <vapier> if they dont want to be on them, they can unsub
-[17:12] <kingtaco|work> WFM
-[17:12] <wolf31o2|work> yeah, I don't think it needs a vote...w e all seem to be in agreement
-[17:12] <kingtaco|work> any thing else on this topic?
-[17:12] <kingtaco|work> no?
-[17:12] <kingtaco|work> ok
-[17:13] <vapier> umm, i think there was something on 4chan.org/b
-[17:13] <kingtaco|work> anyone have anything else?
-[17:13] <kingtaco|work> hahaahah
-[17:13] <kingtaco|work> anonymous++
-[17:13] <vapier> kingtaco|laptop: you post logs/summary for last meeting
-[17:13] <Betelgeuse> kingtaco|work: yes
-[17:13] <wolf31o2|work> yes, we're going to pull a feed from 4chan to the front page, right?
-[17:13] <Betelgeuse> kingtaco|work: what do you need?
-[17:13] <vapier> cause if you didnt, you need to
-[17:13] <kingtaco|work> vapier, I don't log anymore
-[17:13] <kingtaco|work> if you don't see my base nick I don't have a log
-[17:13] <vapier> i was a slacker at that meeting
-[17:14] <kingtaco|work> Betelgeuse, how new devs are sub'd to -core
-[17:14] <robbat2> i'll give you my logs, and you can summarize
-[17:14] <vapier> so someone needs the logs for it
-[17:14] <Betelgeuse> kingtaco|work: recruiters add them
-[17:14] <Betelgeuse> kingtaco|work: via a web interface
-[17:14] <robbat2> Betelgeuse, care for a one-shot script?
-[17:14] <kingtaco|work> Betelgeuse, k, that's what we assumed, wanted to make sure it didn't change
-[17:14] <vapier> robbat2: just e-mail them to me please
-[17:14] <Betelgeuse> robbat2: script?
-[17:14] <Betelgeuse> robbat2: For what?
-[17:14] <kingtaco|work> ok, any other topics?
-[17:15] <kingtaco|work> we really gotta stay focused
-[17:15] <kingtaco|work> people got work to do
-[17:15] --> jaervosz (n=jaervosz@3305ds1-ar.0.fullrate.dk) has joined #gentoo-council
-[17:15] <kingtaco|work> last chance....
-[17:15] <vapier> i think we're done
-[17:15] <-- igli (n=igli@unaffiliated/igli) has left #gentoo-council
-[17:15] --- kingtaco|work sets modes [#gentoo-council -m]
-[17:15] <kingtaco|work> open floor
-[17:15] <vapier> robbat2: actually i see 20070712 posted, so someone did it
-[17:15] <kingtaco|work> flame away
-[17:16] <agaffney> heh, I apparently missed the council meeting
-[17:16] <vapier> robbat2: actually it looks like *you* did it
-[17:16] <wolf31o2|work> go andrew!
-[17:16] <agaffney> I just switched to this window
-[17:16] <fmccor|home> Suggestion for next meeting --- why not postpone it until after election, like this one was postponed for LWE?
-[17:16] <eroyf> Now, you've been talking about moving PMS for many months now. What is the technical reason for such a move?
-[17:16] <agaffney> did I miss anything interesting? :P
-[17:16] <vapier> you missed the no-pants-vote
-[17:16] <genone> Kugelfan3: while you're here, care to say who's in charge of eselect while you and spb aren't around?
-[17:17] <robbat2> vapier, well do you have logs of this one?
-[17:17] <dostrow> vapier: quick question....once pms is on gentoo infra when will it be officially stamped as "accepted"?
-[17:17] <vapier> robbat2: yes
-[17:17] <fmccor|home> Similar situation --- this one was moved because council could not be here last week.  Move next for same reason.
-[17:17] <Kugelfan3> genone: ask pioto
-[17:17] <vapier> dostrow: dont see why not once we get the few things missing merged
-[17:17] <vapier> fmccor: makes sense
-[17:18] <fmccor|home> vapier, By accident, that happens on occasion. :)
-[17:18] <wolf31o2|work> fmccor: the council isn't only the council for the meetings... they're the council the entire time... one way or another, we have to stay on as council until the election is done
-[17:18] <wolf31o2|work> whether we end up at the next meeting or not
-[17:18] <fmccor|home> Sure.  I was only talking of the meeting date.
-[17:19] <vapier> both good points
-[17:19] <fmccor|home> So that next council would have their full 12 meetings.
-[17:19] <vapier> i'll post log/summary if no one else wants to
-[17:19] <eroyf> Noone able to answer my question?
-[17:19] <robbat2> eroyf, it was answered during the council meeting
-[17:19] <Uber> vapier: i think you've just talked yourself into doing it :P
-[17:19] <vapier> READ THE LOG
-[17:19] <eroyf> I didn't see it.
-[17:19] <Uber> WHEN HE POSTS IT
-[17:19] <vapier> IN MY BUTT
-[17:20] <vapier> i'll audit that part
-[17:20] <eroyf> I saw that someone didn't want to commit to PMS because it was not on Gentoo infrastructure.
-[17:20] <Uber> lol
-[17:20] <-- Jointy (n=j0inty@dslb-084-058-236-123.pools.arcor-ip.net) has left #gentoo-council
-[17:21] <-- Ingmar^ has quit (Read error: 60 (Operation timed out))
-[17:22] <kingtaco|work> fmccor|home, we can always vote to simply adjurn next meeting
-[17:22] <vapier> going for a run first
-[17:22] <kingtaco|work> then the new kids can hold their own
-[17:22] <vapier> work off my "LWE 15"
-[17:22] <vapier> i blame ktaco
-[17:22] <kingtaco|work> haha
-[17:22] <kingtaco|work> strike me down!
-[17:22] <Uber> is that 15 inches extra?
-[17:22] <kingtaco|work> your mom wishes!
-[17:22] <vapier> rofl
-[17:23] --> Ingmar^ (n=ingmar@83.101.12.130) has joined #gentoo-council
-[17:23] --- rbrown`_ is now known as rbrown`
-[17:23] <Philantrop> eroyf: The argument was not primarily a technical one but an organisational one - PMS (quoting wolf31o2|work) "being a global technical document, the best place for it really is the council... in fact, all of our technical specifications really belong under the council, being the council is the primary technical decision-making body". PMS defines how a PM should work and how things at the heart of Gentoo work. Thus, it should be
-[17:23] <Philantrop> stored on Gentoo infrastructure. (Everything not marked with quotation marks is my understanding only.)
-[17:24] <fmccor|home> kingtaco|work, sure.  I just thought that since election ends in a month, just moving the meeting date by a week (or 2 weeks, however it works out) was simplest.  Moving this meeting set a precedent for that sort of thing.
-[17:24] <kingtaco|work> fmccor|home, not really, we've moved meetings before
-[17:24] <fmccor|home> Even better. :)
-[17:25] <jmbsvicetto> fmccor|home: The date for the meetings is also set by each council
-[17:25] <jmbsvicetto> fmccor|home: The next council might decide to have meeting on full moons thursdays at 2AM UTC ;)
-[17:25] <eroyf> Philantrop: so basicly. There's no technical reason
-[17:26] <wolf31o2|work> oh wait... back onto dev-announce... should we disable the reply-to munging on it or no?
-[17:26] <fmccor|home> jmbsvicetto, I suppose.  Does that guarantee any meetings?
-[17:26] <Philantrop> eroyf: That is my understanding.
-[17:26] <eroyf> Philantrop: yup.
-[17:26] <cruxeternus> eroyf: Doesn't sound like it.  What's you're next question?
-[17:26] <jmbsvicetto> fmccor|home: I think that would give us a meeting every 28 days ;)
-[17:26] <robbat2> wolf31o2|work, yes
-[17:26] <genone> wolf31o2|work: is it possible to add reply-to if noone is set by the sender?
-[17:27] <wolf31o2|work> robbat2: k... I'm on it
-[17:27] <robbat2> unforuntely not
-[17:27] <robbat2> wolf31o2|work, i'm there already
-[17:27] <robbat2> don't touch
-[17:27] <fmccor|home> jmbsvicetto, except for that "Thursday" requirement.
-[17:27] <wolf31o2|work> genone: I'm trying to fidn out... I'd love to be able to do that, but I don't think that we can
-[17:27] <wolf31o2|work> robbat2: ok... I was already there, too
-[17:27] <wolf31o2|work> heh
-[17:27] <genone> sucks
-[17:28] <robbat2> wolf31o2|work, at some point, we need to make mlmmj pass the mail through procmail just before it goes into outgoing delivery
-[17:28] * Uber outs
-[17:28] <wolf31o2|work> robbat2: doesn't the customheaders allow for regex like the others do? if so, could we make up a regex that defaults to gentoo-dev if it's empty?
-[17:28] <wolf31o2|work> robbat2: k
-[17:28] <wolf31o2|work> we could definitely do it w/ procmail in there, too
-[17:29] <fmccor|home> jmbsvicetto, My point was simply that although this council is the council of record until after the election, it does not need to meet again (because we will have a new council in mid-September anyway).
-[17:29] <robbat2> wolf31o2|work, customheaders just get added on completely blindly
-[17:30] <wolf31o2|work> damn
-[17:30] <robbat2> that's why there was delheaders Reply-To then customheaders
-[17:30] <-- mpagano has quit (Client Quit)
-[17:30] <jmbsvicetto> fmccor|home: I understand and agree. I was just adding in, that we don't know when the next council will want to meet. So if they decide to have meetings at the end of the month, they won't even need to postpone their first meeting
-[17:30] <wolf31o2|work> I had always wondered about that... so you have to delheaders it if you're adding it to customheaders... makes sense...
-[17:30] <-- sybille (n=sybille@brc29-2-88-162-36-171.fbx.proxad.net) has left #gentoo-council
-[17:30] <fmccor|home> True.
-[17:32] <-- jaervosz has quit (Read error: 104 (Connection reset by peer))
-[17:32] <fmccor|home> jmbsvicetto, I suppose I was saying that this council need not meet again because there will be a new one next month, and 2nd Thursday is not cast in stone.
-[17:33] <jmbsvicetto> fmccor|home: true
-[17:34] * fmccor|home wanders away; seems the excitement is about over.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071011-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20071011-summary.txt
deleted file mode 100644
index 11d51b3d0f..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20071011-summary.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-Summary of 11 October 2007 council meeting
-
-Present: all members, josejx proxying for lu_zero
-
-=========================================================================
-"What are not clear are (1) whether the Code of Conduct is in effect; (2)
-if so, how we enforce it."
-
-- The CoC is in effect, but it needs a new enforcement section since the 
-proctors were disbanded. The council is sending discussion of this to 
-the gentoo-project list, to come up with proposals for three points:
-	- who enforces it
-		- musikc said devrel could
-		- tsunam said userrel could
-	- how to enforce it
-		- whether it's active or passive enforcement
-		- which actions are appropriate
-
-- If the -project list does not come up with a draft, dberkholz will 
-write one based on -project discussion to vote upon at the November 
-council meeting.
-
-=========================================================================
-packages.gentoo.org: https://bugs.gentoo.org/show_bug.cgi?id=187971
-	comment #86 from marduk on rewrite
-	comment #90 re jokey's rewrite (comment #85)
-
-- The infrastructure team will decide the future of packages.gentoo.org.
-
-- KingTaco informed us that the current code will probably not return. 
-Alternatives include:
-
-	- http://packages.gentooext.net/ (written by jokey)
-	- http://spaceparanoids.org/gentoo/gpnl/ (written by beandog)
-	- http://gentoo-portage.com/
-
-- Until we get a replacement, packages.gentoo.org will link to 
-alternatives. It now links to a forums thread describing them.
-
-=========================================================================
-GLEP 39: project RFC addition
-
-- We will amend the GLEP rather than writing a new one, and a note will 
-be added saying the GLEP was amended.
-
-=========================================================================
-When does the new council term end?
-
-- Voting will always take place the same month, as mentioned in 
-http://thread.gmane.org/gmane.linux.gentoo.devel/52081/focus=52143
-
-- If the new council is delayed, it gets a slightly shortened term.
-
-=========================================================================
-Open floor
-
-- Where is the PMS repo?
-	- robbat2 has imported it. It's in git. Need to ping him for 
-	details.
-
-- The channel was not moderated during the meeting and it went well. 
-Let's try that again next time.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071011.txt b/xml/htdocs/proj/en/council/meeting-logs/20071011.txt
deleted file mode 100644
index 4bbee28138..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20071011.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-20:00 <@vapier> http://thread.gmane.org/gmane.linux.gentoo.devel/52081
-20:00 <@dberkholz> alright, it's about that time.
-20:00 <@vapier> you can cherry pick out stuff from that thread, it's the only thing i know of
-20:01 <@vapier> someone will have to volunteer to chair this month (i cant)
-20:01 <@dberkholz> would be good for a previous council member to, if possible
-20:02 -!- robbat2|na [n=robbat2@gentoo/developer/robbat2] has joined #gentoo-council
-20:02 <@FlameBook> that would be Uber
-20:04 <@vapier> sorry, what ?
-20:04 <@vapier> everything the last council decided on should be fully logged and summarized in the council project space ...
-20:06 <@dberkholz> alright. i'm seeing 3 items mentioned
-20:06 -!- think4urs11 [n=think4ur@gentoo/developer/think4urs11] has joined #gentoo-council
-20:06 <@dberkholz> 1) code of conduct. is it in effect? should it be? if so, how do we enforce it?
-20:06 <@Uber> I'm not a good chair, dberkholz is a good candidate for that
-20:06 < KingTaco> dberkholz, FYI, fmccor was very mistaken, the last council never rescended the CoC
-20:06 < KingTaco> just the proctors bit
-20:07 < KingTaco> he's got a hardon for the proctors idea though
-20:07 <@dberkholz> 2) packages.g.o. bug #187971. jokey's working on a rewrite, mentioned in comment #85 and #90. a comment from marduk regarding a rewrite on comment #86.
-20:07 < jeeves> dberkholz: https://bugs.gentoo.org/187971 cri, P2, All, bannedit0@gmail.com->taviso@gentoo.org, NEW, pending, Gentoo Website Command Injection Issue
-20:07 <@dberkholz> 3) glep 39 never got the 'project rfc' bit added to it. this should be mostly a no-brainer
-20:08 <@FlameBook> dberkholz, unless as Doug said we need to get a new glep drafted and voted upon rather than edit it
-20:08 <@FlameBook> that would take a bit more
-20:09 <@dberkholz> let's try to get through these topics one at a time, instead of mixing
-20:09 < NeddySeagoon> KingTaco The CoC page needs a rewrite as it still refers to the proctors as the enforcement body
-20:09 <@amne> i'd like to add 4) as mentioned before with the procedural stuff. i think vapier's message in http://thread.gmane.org/gmane.linux.gentoo.devel/52081/focus=52143 sums it up though
-20:09 < KingTaco> NeddySeagoon, that's probably true
-20:09 <@FlameBook> dberkholz, yeah sorry, got the first one I had at hand :/
-20:10 <@amne> any other stuff for the agenda? otherwise i'd agree with dberkholz that we focus on the issues one by one
-20:10 < NeddySeagoon> KingTaco bug 185572 which is assigned to devrel just now
-20:10 < jeeves> NeddySeagoon: https://bugs.gentoo.org/185572 nor, P2, All, neddyseagoon@gentoo.org->devrel@gentoo.org, NEW, pending, As the proctors no longer exist the code of conduct needs an upate
-20:11 <@dberkholz> i just added council@ to CC on that
-20:11 < NeddySeagoon> dberkholz probably a good idea
-20:12 <@dberkholz> i like the CoC, because it's principles-based instead of trying to go into mind-numbing detail
-20:12 <@vapier> so first off, gotta do roll call ...
-20:13 -!- Irssi: #gentoo-council: Total of 52 nicks [8 ops, 0 halfops, 2 voices, 42 normal]
-20:13 -!- musikc|work [n=musikc@gentoo/developer/musikc] has joined #gentoo-council
-20:13 <@dberkholz> amne, Betelgeuse, dberkholz, FlameBook, Uber, vapier have all spoken. anyone seen luca?
-20:13 <@vapier> vapier/dberkholz/uberlord/flameeyes/lu_zero(josejx) i see ... how about Betelgeuse / amne
-20:13 <@Betelgeuse> dberkholz: Have I?
-20:13 <@FlameBook> dberkholz, josejx is proxying
-20:13 <@dberkholz> Betelgeuse: you have now =P
-20:13 <@Betelgeuse> dberkholz: indeed
-20:13  * amne points at himself and is here
-20:14 <@dberkholz> all accounted for, with one proxy
-20:15 < josejx> Yep, I'm lu_zero for today :)
-20:16 <@dberkholz> vapier, Uber: anything else we should do before getting into the CoC discussion?
-20:17 < KingTaco> dberkholz, nothing we did after rollcall
-20:17 -!- Netsplit over, joins: Ingmar
-20:17 < KingTaco> rollcall -> topics list -> topics discussion/voting -> open floor
-20:18 < NeddySeagoon>  KingTaco Actions from the last meeting ?
-20:18 < KingTaco> NeddySeagoon, only if any carry over
-20:18 < KingTaco> the only thing we would possibly have is the pms/eapi stuff
-20:18 <@Uber> dberkholz: nope, lets get this show on the road
-20:19 <@dberkholz> alright. before we get into the CoC discussion, we need to decide what the goal of it is
-20:20 <@amne> dberkholz: imo what fmccor wrote in the council thread on -dev@: 1) is CoC in effect, and 2) how it's supposed to be executed
-20:20 <@dberkholz> here's what i think the goal is: the CoC is still in effect, but enforcement is in question.
-20:21 <@amne> i agree
-20:22 <@FlameBook> right
-20:22  * Uber nods
-20:22 <@dberkholz> ok, that's 4 of 7.
-20:23 <@dberkholz> how do we want to enforce the CoC, now that the proctors are dissolved?
-20:24 <@Betelgeuse> Well does the original problem exist that much any more any way?
-20:24 <@Uber> Betelgeuse: we don't want to be reactionary to that again
-20:24 < KingTaco> Betelgeuse, it's always been spiky
-20:24 <@Uber> some feel that CoC and proctors were rushed
-20:24 <@amne> Uber++ (twice)
-20:25 <@Betelgeuse> KingTaco: Indeed but now it can be dumped to -project. Emphasis on dump.
-20:25 <@FlameBook> Uber is right
-20:25 < KingTaco> Betelgeuse, my personal assessment is that the addition of all the lists recently has probably taken the critical mass off -dev
-20:25 <@Uber> it was a problem we didn't see until too late in the day - we still need a CoC
-20:26 < josejx> I'd say that the increase in actualy "development" happening on -dev has helped quite a bit too, things seem to be much better lately
-20:27 <@amne> the commits threads scared away the flames :-) but still i think all interested folks should work on a new policy that's approved and documented
-20:28 <@Uber> right, and that should happen on -project or some other list
-20:28 <@amne> personally i think that it'll be best solved by collaboration of dev-/userrel in cooperation of the other people already working in the moderations department (read forums mods and #gentoo ops)
-20:28 <@amne> Uber: yes
-20:30 <@dberkholz> so should we push this enforcement discussion to the -project list, then return to it next month?
-20:30 <@amne> i think it's a good idea to do so (unless someone has a better one)
-20:31 <@dberkholz> what we need to figure out is 1) who enforces it, 2) whether it's active or passive enforcement, and 3) what actions are appropriate
-20:31 < musikc|work> amne: speaking for devrel, i have no problems with us continuing to serve that function if and when appropriate
-20:32 <@dberkholz> alright.
-20:32 < musikc|work> you'd have to ask christel or tsunam about userrel but id expect a similar reaction from them
-20:33 <@dberkholz> here's the plan: discussion on -project, then come to the next council meeting with a new draft of the enforcement section to vote on.
-20:33 <@amne> musikc|work: that's good (and also current more or less documented ;-) status afaik)
-20:33 -!- tsunam [n=tsunam@gentoo/developer/tsunam] has joined #gentoo-council
-20:34 < tsunam> *poofs*
-20:34 <@dberkholz> if that draft doesn't happen by consensus, someone will need to write it. does anyone else want to do it, or shall i?
-20:34 <@FlameBook> dberkholz, why discard a volunteer? you're perfectly fit to ;)
-20:34 <@amne> dberkholz: +1 on your plan, and i'm also willing to contribute (no problem if you do the main work though, more slack for me)
-20:35 <@Uber> sounds good to me
-20:36 <@Uber> plus, dberkholz writes good docs :)
-20:36 <@dberkholz> Betelgeuse, josejx, vapier: any input before we move on to the next agenda item?
-20:37 < josejx> No, I don't think I have anything else to add
-20:38 < tsunam> musikc is correct about the userrel reaction/feeling at least from me
-20:38 < tsunam> Only thing I'd like to see is more faith in projects overall
-20:38 <@Betelgeuse> dberkholz: nope
-20:38 <@Uber> tsunam: only that can come from the participants, not from us
-20:39 < tsunam> Uber: no it has to come from the council as well
-20:39 <@amne> tsunam: musikc|work: i hope you both are on -project and will take part there, too
-20:39 < josejx> tsunam: What do you mean exactly by more faith in projects?  What could be done?
-20:39 < tsunam> as the council can kill a project if its in the "tech" sphere
-20:39 < musikc|work> amne, indeed i am and will keep an eye out for that discussion
-20:39 < tsunam> Uber: need I remind everyone about one that failed and was killed by the council?
-20:40 <@dberkholz> we're getting a bit offtopic here. let's return to this after we get through the scheduled agenda items?
-20:40 < tsunam> josejx: not jumping to inaccurate thoughts
-20:40 <@FlameBook> dberkholz, agreed
-20:40 <@amne> musikc|work: good
-20:40 < tsunam> amne: I'm not on project
-20:40 <@dberkholz> the next agenda item concerns packages.gentoo.org.
-20:42 <@dberkholz> the goal is apparently to clarify what's going to happen for a web package database in the future.
-20:42 <@FlameBook> can someone give me a summary of what happened about that? I ended up in hospital just a few days after receiving the down mail and I haven't followed it closely... I gather it needs a complete rewrite, and jokey is taking care, is that right?
-20:42 <@dberkholz> bug #187971 has close to 100 comments about this
-20:42 < jeeves> dberkholz: https://bugs.gentoo.org/187971 cri, P2, All, bannedit0@gmail.com->taviso@gentoo.org, NEW, pending, Gentoo Website Command Injection Issue
-20:43 < KingTaco> FlameBook, went down because of a sec hole, found more while it was down, assigned to security for an audit, jokey started his rewrite which infra is liking so far
-20:43 <@FlameBook> dberkholz, that's why I asked, a bit too many to read at a glance :P
-20:43 <@dberkholz> good, i wanted to hear from infra about whether they would support jokey's rewrite.
-20:43 <@dberkholz> since it seems that will be ready before a full audit of the current p.g.o code
-20:43 <@Uber> so we now have 3 code bases for the same thing?
-20:44 <@Uber> anyone else seen http://spaceparanoids.org/gentoo/gpnl/ ?
-20:44 < KingTaco> there are some reservations about the deps, but it's looking good otherwise
-20:44 < KingTaco> robbat2|na is the main infra contact there
-20:44 <@dberkholz> KingTaco: are you speaking for yourself on this, or on behalf of the infra team?
-20:44 < KingTaco> dberkholz, myself and robbat2 are the op leads
-20:45 < KingTaco> I'm speaking for infra
-20:46 <@dberkholz> are there any security people here who can say something about the likelihood of that audit getting finished anytime soon?
-20:46 < KingTaco> dberkholz, infra does not expect to put the marduk codebase back online
-20:46 <@dberkholz> ok
-20:47 < KingTaco> jokeys example is at http://packages.gentooext.net
-20:48 < KingTaco> you can see that the basic functionality is there, but there's still more work
-20:49 <+jokey> robbat2 already added some more functionality though they need adaption to mysql
-20:49 <@dberkholz> KingTaco: have you looked at beandog's package database too?
-20:49 <@dberkholz> the one Uber mentioned above
-20:49 < KingTaco> dberkholz, nope
-20:49 < KingTaco> lemme see
-20:50 <@dberkholz> mainly shows keywording now, but i could envision some design changes and minor enhancements to add the rest
-20:50 < josejx> jokey's looks nice so far
-20:50 < KingTaco> dberkholz, it's neato
-20:51 <@Uber> i use it - i actually prefer it to p.g.o as it just looks cleaner
-20:51 <@Uber> ok, no gentoo colours, but still
-20:52 <@Uber> just my tuppence worth
-20:52 < KingTaco> beandog hasn't said anything about his p.g.o to infra afaik
-20:52 < KingTaco> I don't know if he even wants to share
-20:53 <@dberkholz> from the council perspective, i'd just like to confirm that this is infra's decision.
-20:53 <@Uber> KingTaco: well, why don't you ask him?
-20:53 < KingTaco> what exactly am I confirming?
-20:53 < KingTaco> Uber, I just saw it 5 minutes ago!
-20:53 <@dberkholz> KingTaco: nothing, the council is
-20:54 < KingTaco> dberkholz, ohhhh, gotcha
-20:55 -!- agaffney [n=agaffney@gentoo/developer/pdpc.active.agaffney] has left #gentoo-council []
-20:55 <@Uber> dberkholz: yes, that decision should be with infra - they run the infra side of things. We shouldn't influence their choice of software, except for religious pokes like vim vs emacs
-20:55 <@dberkholz> council, vote please: the infrastructure team will decide the future of packages.gentoo.org.
-20:55 <@Uber> aye
-20:55 <@dberkholz> yes for me
-20:55 <@amne> ++
-20:55 <@FlameBook> good for me
-20:56 <@Betelgeuse> \o/
-20:57 <@dberkholz> Betelgeuse: is that a yes, or a smiley face i don't understand? =)
-20:57 <@Betelgeuse> btw http://gentoo-portage.com/
-20:57 <@FlameBook> dberkholz, a little man with the arms high in the air :P
-20:58 <@amne> as we seem to agree on the future of p.g.o, i'd just like to make a suggestion to infra (that is KingTaco being here), imho it would be a nice idea to have some links to the current alternatives on p.g.o until it's back.
-20:58 < josejx> Sure
-20:59 <@amne> assuming the people providing other, similar services are fine with it of course. and infra wants that, too
-20:59 <@dberkholz> that would be useful
-20:59 < KingTaco> amne, there's some policy against linking to gentoo-portage or gentoo-wiki and it wouldn't be fair to link to the others IMO
-20:59 <@amne> hm
-20:59 < jmbsvicetto> KingTaco: What about a link to the forums thread that talks about alternatives?
-21:00 <@dberkholz> i think that only really applies when we have a duplicate of the same type of service
-21:00 < KingTaco> jmbsvicetto, that we could do
-21:00 < KingTaco> gimme a url
-21:00 <@amne> sounds like a good plan (jmbsvicetto)
-21:00 <@Betelgeuse> KingTaco: http://gentoo-portage.com/
-21:00 <@Betelgeuse> KingTaco: That's one at least.
-21:01 <@FlameBook> Betelgeuse, he meant to the forum thread, I think
-21:01 < KingTaco> Betelgeuse, no, of the forum thread
-21:01 <@Betelgeuse> KingTaco: ah
-21:01 < KingTaco> there was a bug we closed that requested linking to all the different sites
-21:02 < jmbsvicetto> KingTaco: https://forums.gentoo.org/viewtopic-t-574544.html shoud work unless amne has a better one
-21:02 < jmbsvicetto> should*
-21:03 <@amne> jmbsvicetto: i would have suggested the same, perhaps some useful info from the thread can be summarized in the first post by a volunteer... like you :-P
-21:03 <@amne> KingTaco: that would be useful, too if you could find it
-21:03 -!- desultory [n=dean@gentoo/developer/desultory] has joined #gentoo-council
-21:05 <@dberkholz> alright, let's move on to the next agenda item.
-21:05 <@dberkholz> the previous council voted to require RFC's to -dev for new projects, but it was never added to glep 39.
-21:05 <@dberkholz> goal: to decide whether to modify the glep or to add a new one
-21:06 <@dberkholz> we have already modified glep 39 once: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0039.txt?view=log
-21:07 <@dberkholz> a note was added to the Status noting that it was amended
-21:07 < KingTaco> fyi, p.g.o updated with that forums link
-21:08 <@amne> KingTaco: cheers
-21:09 <@amne> if updating is OK with our policies (which i'm not perfectly sure), i think it would the process easier
-21:09 <@FlameBook> I would also consider just amending it
-21:10 <@Betelgeuse> http://www.gentoo.org/proj/en/glep/glep-0001.html#reporting-glep-bugs-or-submitting-glep-updates
-21:10 <@Betelgeuse> GLEP says GLEPs can be updated.
-21:10 <@Betelgeuse> +1
-21:11 <@vapier> it should really be a community thing ... if you're an asshat, people should let you know ... if you continue to be an asshat, you get ejected ... unfortunately, i dont think our community is tight enough to do that
-21:12 < jmbsvicetto> vapier: Are you talking about having new projects approved on -dev or about having council removing people/leads/projects?
-21:12 <@dberkholz> vapier: is that back to the CoC discussion?
-21:12 <@amne> Betelgeuse: ah, that's fine then -> +1 amending
-21:12 <@dberkholz> i'm for amendments also
-21:13 <@dberkholz> that's amne, Betelgeuse, FlameBook and i, so we'll just amend it.
-21:14 <@dberkholz> that was the last agenda item
-21:15 <@Uber> cool
-21:15 <@amne> uhm
-21:15 <@Uber> anyone want to add anything before we open to the floor?
-21:15 <@amne> 22:08 <@amne> i'd like to add 4) as mentioned before with the procedural stuff. i think vapier's message in  http://thread.gmane.org/gmane.linux.gentoo.devel/52081/focus=52143 sums it up though
-21:15 <@vapier> i think my ping is off the charts ... but that sounds good for the CoC
-21:17 <@Uber> vapier: so bad you should be dropping packets :P
-21:17 <@dberkholz> amne: agreed. i think the original glep also can be interpreted most reasonably that way.
-21:18 <@Uber> yeah, mike did a good summary there
-21:18 <@amne> so that leaves us with 11 meetings though which is in conflict with what chris wrote in http://thread.gmane.org/gmane.linux.gentoo.devel/52081/focus=52179
-21:18 <@FlameBook> agreed mike++
-21:19 <@amne> basically the 11 meetings part. i don't have a problem with it though
-21:20 <@dberkholz> the original glep says "Council members will be chosen by a general election of all devs once per year." which i read as saying the election happens at the same time each year.
-21:21 < KingTaco> I suggest that the existing council take the initative to start the election process at the right time
-21:21 < KingTaco> we should have last year
-21:21 < KingTaco> er, this year
-21:22 <@amne> KingTaco: i'm not 100% following - right time being the same time as every year?
-21:22 <@Uber> ok, so we done for tonight?
-21:22 < KingTaco> amne, whenever it's the right time.  there seems to be some disagreement
-21:22 < jmbsvicetto> KingTaco: In that spirit, it wouldn't hurt to have the council explicitly approving the calendar for the election ;)
-21:22 <@amne> heh
-21:23 <@dberkholz> since we don't seem to be sure, let's have a vote.
-21:23 -!- astinus [n=alex@gentoo/developer/astinus] has joined #gentoo-council
-21:23  * Uber votes we maintain the dates as is, and kick infra butt next election
-21:23 < KingTaco> Uber, it's not infra, it's election officials
-21:23 <@FlameBook> I vote for mike's summary, keeping the dates in the same period
-21:23 < jmbsvicetto> dberkholz: It seems there wasn't a disgreement about the process, only about the dates / this council term duration
-21:23 <@dberkholz> vote: should elections be the same month every year, regardless of whether that shortens the council term (except as contradicted by glep 39's reelection rule)?
-21:23 < KingTaco> used to be grant did it
-21:23 <@Uber> KingTaco: whatever, kicking off someones butts
-21:23 < josejx> I'd vote to keep the dates the same.  I don't see a good reason to change it
-21:24 <@Uber> of*
-21:24 < KingTaco> Uber, yes
-21:24  * amne votes ++ on what dberkholz/vapier's email said
-21:24 <@Uber> well, that's an easy majority
-21:24 <@dberkholz> alright.
-21:25 <@dberkholz> any other issues for the open floor?
-21:25 <@Uber> yeah, who kept an irc log of this?
-21:25 < jmbsvicetto> So can you please add to the council page that the nominations for the council take place in July and the voting on August?
-21:25 <@amne> i have one
-21:25 <@dberkholz> i should have a log.
-21:25 <@dberkholz> i've also got a summary written
-21:25 <@dberkholz> anyone else got a summary yet?
-21:26 < jmbsvicetto> And please add that the election officials need to be selected before the nominations start
-21:26 <@Uber> wooooo, volunteers for summary writing!
-21:26 <@amne> dberkholz: no summary here, but i can write one or look over yours
-21:27 <@dberkholz> http://dev.gentoo.org/~dberkholz/20071011-summary.txt
-21:28 < tove> 5) topic of every meeting: status of pms? where is the repo today?
-21:28 <@amne> dberkholz: looks good, i'd just change "Until we get a replacement, packages.gentoo.org will link to
-21:28 < KingTaco> robbat2 has imported their repo
-21:28 < KingTaco> tove ^^
-21:28 < jmbsvicetto> tove: I thought that was solved on last council's meeting
-21:28 <@amne> alternatives." to "will indirectly link..." perhaps
-21:29 < tove> jmbsvicetto: the summary of last meeting doesn't really help.
-21:29 < tove> KingTaco: how to access the repo?
-21:29 <@dberkholz> i don't feel the need to specify that implementation detail... do you?
-21:29 < KingTaco> tove, I think it's git.  you need to ping him
-21:29 -!- dertobi123 [n=tobias@gentoo/developer/dertobi123] has joined #gentoo-council
-21:29 <@amne> dberkholz: probably best to ask KingTaco because of infra's link policy if it's important to mention it
-21:30 <@amne> KingTaco: ^^^
-21:30 < KingTaco> amne, I'm not sure who's policy it is tbh
-21:30 <@amne> ah ok let's just ignore my "improvement" then ;-)
-21:30 < KingTaco> amne, but it's one we respect
-21:30 <@amne> or whatever is fine for everyone
-21:31 <@dberkholz> i added a little bit.
-21:31 <@dberkholz> alright. vote to adjourn?
-21:33 <@amne> just a quick note from side on the way the meeting went (but we can talk about that once the meeting is officially closed as well): i think the meeting went well besides the channel wasn't moderated
-21:33 <@amne> as long it works out civil, it may be something i'd like to consider for the next meetings, too
-21:33 <@amne> other then that adjourn++
-21:33 <@dberkholz> i agree, i discussed that with jokey in query.
-21:34 <@FlameBook> totally agreed with amne
-21:35 <@dberkholz> amne and i are ready to adjourn until next month. how about the rest of you?
-21:35 <@FlameBook> I was agreeing with that too :P
-21:36  * Uber is done here
-21:37 -!- Ingmar^ [n=ingmar@83.101.12.135] has joined #gentoo-council
-21:37 -!- Ingmar [n=ingmar@83.101.12.167] has quit [Nick collision from services.]
-21:37 <@dberkholz> that's a majority. the meeting's over; i will send summary and log
-21:37 <@dberkholz> which lists should they go to?
-21:37 -!- doc|work [n=doc@gentoo/contributor/doc-007] has left #gentoo-council ["."]
-21:38 <@amne> dberkholz: since the meeting is also announced on -dev@, it would be a good place to see it there. other than that, council list?
-21:38 <@dberkholz> i was thinking -dev, -dev-announce, -council
-21:38 < jmbsvicetto> dberkholz: dev-announce and council?
-21:38 <@amne> -dev-announce, good idea
-21:39 <@amne> and reply to -dev@?
-21:40 -!- Ingmar^ is now known as Ingmar
-21:40 < tove> dberkholz: please don't send the log itself -- just add a link to proj/en/council/meeting-logs/..
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071108-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20071108-summary.txt
deleted file mode 100644
index 31daa35121..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20071108-summary.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-amne        here
-betelgeuse  absent (1 hour late)
-dberkholz   here
-flameeyes   here
-lu_zero     here
-vapier      absent (no show)
-uberlord    resigned
-jokey       here (replacing uberlord)
-
-Agenda:
-http://thread.gmane.org/gmane.linux.gentoo.devel/52772
-
-Also continuing discussion on CoC enforcement. Proposal:
-http://thread.gmane.org/gmane.linux.gentoo.council/82
-
-==============================================================================
-
-Empty council slot: vote for Jokey to happen on gentoo-council list
--------------------------------------------------------------------
-
-Jokey is the candidate to replace uberlord [1], and it requires a 
-unanimous council vote [2]. Since not all council members are present, 
-we'll do this vote on the gentoo-council list. All 6 present council 
-members supported Jokey's addition.
-
-1. http://www.gentoo.org/proj/en/council/meeting-logs/20070208-summary.txt
-2. http://www.gentoo.org/proj/en/council/voting-logs/council-2007-vote-distribution.txt
-
-
-Daylight savings change: no slacker marks
------------------------------------------
-
-In the US and Europe, 2000 UTC shifted by an hour in local time. The 
-email announcement was wrong, so we will not give slacker marks to the 
-two absent council members.
-
-vapier needs to fix his script before the next announcement.
-
-
-EAPI=1 approved for use in the main tree
-----------------------------------------
-
-Stable portage version 2.1.3.12 supports EAPI=1. It's now officially OK 
-to start using it in the main tree. From the ebuild ChangeLog for 
-portage:
-
-  This release is the first to have support for EAPI-1 (#194876), which 
-  includes SLOT dependencies (#174405), IUSE defaults (#174410), and 
-  ECONF_SOURCE support for the default src_compile function (#179380). 
-  Package maintainers should carefully consider the backward compatibility 
-  consequences before defining EAPI="1" in any ebuilds, especially if
-  other packages depend on those ebuilds. See the ebuild(5) and emerge(1) 
-  manual pages for EAPI related documentation.
-
-EAPI=1 features are documented in PMS as well as the man pages, but they 
-are not yet documented in the devmanual or the dev handbook.
-
-Code of Conduct enforcement proposal: generally positive feedback
------------------------------------------------------------------
-
-dberkholz sent out a proposal this morning [1], so we just discussed it 
-today instead of voting. Initial feedback from council members was 
-positive. Some concerns came up on the list about time zone differences 
-and coverage, which were brought up again during the meeting.
-
-People generally agreed that although the environment is better now, it 
-hasn't been before and won't always be good.
-
-lu_zero brought up the point that since things are fairly good now, we 
-don't need to rush through this process and we can take our time and do 
-things right.
-
-Council support for the team's actions should not be as controversial 
-with the requirement that all actions be private.
-
-The team will need to create the tools to deal with the actions it needs 
-to take (short-term moderation on IRC, mailing lists, and Bugzilla). 
-This could happen during the initial training period suggested on the 
-gentoo-council list.
-
-If there's already existing moderation somewhere (for example many of 
-the #gentoo-* IRC channels or the forums), the team will first liaise 
-with them rather than preempt them. All official Gentoo forums must 
-adhere to the CoC, however; having their own moderation does not exclude 
-them from following Gentoo's standards as a whole.
-
-The expectation is that successive actions against the same person will 
-increase in length, eventually reaching the 3-day cutoff that requires 
-council approval and forwarding to devrel/userrel. The idea is that if 
-someone keeps violating the CoC after a given length of moderation, it 
-apparently wasn't enough so it shouldn't be repeated.
-
-Next month, we will vote on a concrete proposal.
-
-1. http://thread.gmane.org/gmane.linux.gentoo.council/82
-
-
-Baselayout-2: uberlord will continue to maintain it
----------------------------------------------------
-
-lu_zero asked whether we had anything to do about baselayout-2 since 
-uberlord resigned. He's continuing to maintain it in a git repository 
-and will remain upstream for it. More details will emerge over time.
-
-kingtaco raised the question of trusting external releases and hosts. 
-Some responses suggested that using git may prevent the malicious host, 
-because of the possibility of GPG-signed tags. He mentioned the 
-possibility of the infra team hosting Gentoo-critical repositories with 
-access by non-Gentoo developers. It's just an idea at this point, but 
-he's going to talk to the rest of the infra team.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071108.txt b/xml/htdocs/proj/en/council/meeting-logs/20071108.txt
deleted file mode 100644
index d1ee15d642..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20071108.txt
+++ /dev/null
@@ -1,479 +0,0 @@
-20:01 <@dberkholz> anyone got a web link to the agenda thread? not a whole lot on it
-20:01  * jokey ties amne to $chair
-20:01 -!- nox-Hand [i=johnhand@unaffiliated/nox-hand] has joined #gentoo-council
-20:01 -!- Netsplit anthony.freenode.net <-> irc.freenode.net quits: cruxeternus, peper, koxta
-20:01 < nox-Hand> Am I too late to talk?
-20:01 < nox-Hand> And HAI by the way if I can talk
-20:02 <@dberkholz> http://thread.gmane.org/gmane.linux.gentoo.devel/52772
-20:02 -!- Netsplit over, joins: cruxeternus, koxta, peper
-20:03 <@dberkholz> alright, roll call
-20:03 <@dberkholz> who's here?
-20:03 <@amne> amne:
-20:03  * Flameeyes present
-20:03  * jokey me
-20:03 <@amne> uberlord is absent due to his resignation, which also makes it a point for the agenda
-20:03 <@amne> ah, hi jokey :-)
-20:04 <@dberkholz> amne: yes, that's on the linked thread
-20:05 <@amne> dberkholz: yupp
-20:06 <@amne> so where's the rest?
-20:06 <@dberkholz> lu_zero, vapier, SpanKY, Betelgeuse: where are ya?
-20:07 < nox-Hand> Late reply to the roll call, I am here, but not sure if that matters any..
-20:07 <@dberkholz> nox-Hand: just council members; feel free to chip in later on, when the discussion you're interested in is happening
-20:07 <+jokey> nox-Hand: erm nop, council people now...
-20:07 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-20:08 < nox-Hand> jokey: dberkholz I Figured as much, cheers, I'll start chirping at my allocated chirpy time :]
-20:09 -!- uberpinguin [n=uberping@unaffiliated/uberpinguin] has joined #gentoo-council
-20:09 <@amne> hm
-20:10  * igli gags nox-Hand
-20:10 <@amne> due to the change to daylight savings in europe the meeting is an hour earlier today
-20:10 < NeddySeagoon> amne, everyone beaten by the hour change last week ?
-20:10 <@amne> i guess that could explain why lu_zero and Betelgeuse aren't here (both europeans, aren't they?)
-20:10 < fmccor> Even US has changed now.
-20:10 <@Flameeyes> amne, yeah they are, but as fmccor, us already catched up
-20:11 <@amne> ah
-20:11 <@dberkholz> can someone help me find the council summary link where it says the next highest voted person will fill an empty spot
-20:11 <+jokey> so should we delay another bit? ;)
-20:11 <@Flameeyes> dberkholz, should be around february last year
-20:11 <@amne> council.g.o doesn't work for me right now, anyone else got the same problem?
-20:12 <@amne> http://c.g.o to be more accurate
-20:12 <@Flameeyes> dberkholz, http://www.gentoo.org/proj/en/council/meeting-logs/20070208-summary.txt
-20:12 < NeddySeagoon> dberkholz, I don't think it was ever written down in the process but its established as custom and practice now
-20:12 <+jokey> amne: WORKSFORME
-20:12 <@Flameeyes> NeddySeagoon, that link above
-20:12 -!- Netsplit anthony.freenode.net <-> irc.freenode.net quits: musikc, mpagano__, genone, zxy_64
-20:12 <@amne> jokey: strange, but as long it works for everyone else :-)
-20:12 <@lu_zero> cough...
-20:13  * lu_zero is alive
-20:13 <@lu_zero> distracted but alive...
-20:13 < NeddySeagoon> Flameeyes, thank you
-20:13 -!- Netsplit over, joins: musikc, mpagano__, zxy_64, genone
-20:13 <@Flameeyes> [I remembered it easily, it was just before I left :)]
-20:13 <@amne> gentoofan23 just pointed out there still was some confusion: gentoofan23> amne, the time is 15:12 EST right now whereas the e-mail said 16:00 EST so maybe that explains it..
-20:14 <@dberkholz> well, that means we'll have 5 of 7 people
-20:14 <@lu_zero> legal/solar time mismatch?
-20:14 <@Flameeyes> [21:10] [Whois] Betelgeuse has been idle for 20 hours, 0 minutes, and 20 seconds.
-20:14 <@Flameeyes> Betelgeuse seems not around
-20:14 <@dberkholz> the other two should've paid closer attention
-20:15 <@Flameeyes> mike will probably appear midway through the meeting as usual
-20:15 <@dberkholz> we might as well move on, today will be primarily discussion
-20:15 <@lu_zero> ok
-20:15 <@amne> works for me
-20:15 <@dberkholz> first item requires no voting
-20:15 <@Flameeyes> fine
-20:15 <@dberkholz> we're welcoming jokey to the council, filling the spot left vacant by uberlord
-20:16 <@Flameeyes> and I lost my liason :)
-20:16 <+jokey> poor Flameeyes ;)
-20:16 <@lu_zero> eh...
-20:16 <@dberkholz> so, welcome jokey!
-20:16 <@dberkholz> how do we get the ops status fixed?
-20:17 <+jokey> tomaw should be able to
-20:17 < tomaw> Hi
-20:17 <@Flameeyes> /tomaw access #gentoo-council add jokey 30
-20:17 <@Flameeyes> :P
-20:17 < tomaw> You people should really equip yourselves to do this on your own.
-20:18 < tomaw> Let me check, as I probably shouldn't be doing it without a nod from the right people
-20:18 <@lu_zero> hmm
-20:18 <@amne> vapier is listed as channel contact, he should be able to do it
-20:18 < tomaw> yeah, he can do it, but noone else (bar staff) can
-20:18 <@dberkholz> tomaw: aren't we the right people? =P
-20:19 <@lu_zero> what about having all of us marked as contact/with an higher level?
-20:19 < tomaw> No, freenode requires that the group contact ask staff.  group contacts are currently phreak, christel and whoever your recruitment lead is now
-20:19 <@dberkholz> you can only add people to levels below your own
-20:19 <@Flameeyes> lu_zero, beside owner and staff, anyone else can add up to (hislevel-1)
-20:19 < fmccor> tomaw, Betelgeuse is.
-20:19 <@amne> uhm
-20:20 <@amne> dberkholz: If they accept and the current Council unanimously accepts the new person, they get the position with a 'reduced' term such that the yearly elections still elect a full group.
-20:20 < tomaw> fmccor: that's the guy!
-20:20 <@Flameeyes> fmccor, let's get someone who's around, don't we? :P
-20:20 <@amne> dberkholz: doesn't that mean we actually need to vote on jokey?
-20:20 < fmccor> tomaw, phreak might be.
-20:21 < tomaw> I pinged him already :)
-20:21 <@dberkholz> amne: it certainly reads that way. i wonder if we already effectively did so on the mailing list thread about it
-20:21 <+jokey> just do again so we're set ;)
-20:21 <@Flameeyes> if we were all around we could vote on it, but I doubt Betelgeuse is around now
-20:22 <@lu_zero> we could just use the email...
-20:22 <@amne> works for me
-20:22 <@lu_zero> next item?
-20:23 <@dberkholz> the daylight savings change mentioned
-20:23 <@dberkholz> announcement email was wrong, so i say we don't give slacker marks this week
-20:24 <@amne> yupp
-20:24 <@lu_zero> fine
-20:25 <@Flameeyes> oky doky
-20:25 <@amne> vapier: plz fix your announcement mail kthx :-)
-20:25 <@dberkholz> alright, next item
-20:26 <@dberkholz> approving EAPI=1 for use in the main tree
-20:26 <@dberkholz> i wish Betelgeuse were here for this because he had some points
-20:27 <@lu_zero> dberkholz which portage version won't be able to handle it?
-20:27 <@dberkholz> portage has supported the EAPI variable for more than a year, and stable portage (2.1.3.12) now has EAPI=1 support.
-20:27 <@lu_zero> and how old would it be?
-20:27 <@lu_zero> fine to start using it then
-20:28 <@dberkholz> documentation is in PMS, ebuild and emerge manpages, but it should be added to the devmanual and dev handbook
-20:28 <@lu_zero> I see
-20:28 <@Flameeyes> what were the finalised features in EAPI=1?
-20:28 <@dberkholz> This release is the first to have support for EAPI-1 (#194876), which includes SLOT dependencies (#174405), IUSE defaults (#174410), and ECONF_SOURCE support for the default src_compile function (#179380).
-20:29 <+jokey> slot deps and iuse defaults being the more important parts
-20:29 <@Flameeyes> I'm fine for it just at slot deps
-20:29 <@dberkholz> what EAPI=1 means is already finalized, we're just saying it's fine to start using it in gentoo-x86.
-20:30 <@Flameeyes> yeah
-20:30 <@dberkholz> i talked to zmedico yesterday and he thought it would be a good idea for the council to approve it
-20:30 <@lu_zero> it's fine
-20:30 <@amne> ++
-20:30 <+jokey> ack
-20:31 <@Flameeyes> dberkholz, your vote?
-20:31 <@dberkholz> yes from me
-20:31 <@Flameeyes> so it's fine for five out of seven (two missing)
-20:33 <@dberkholz> alright, last agenda item is discussion of the CoC enforcement proposal
-20:33 <@dberkholz> i got it together too late for a vote
-20:33 -!- phreak`` [n=phreak``@gentoo/developer/phreak] has joined #gentoo-council
-20:33 <@lu_zero> dberkholz I read it and seems fine
-20:34 <@lu_zero> probably I should take a bit of time to rethink it
-20:34 <+jokey> the idea of it is good imho
-20:34 <@amne> i also like it
-20:35 <@Flameeyes> I join lu_zero
-20:37 -!- mode/#gentoo-council [+o jokey] by ChanServ
-20:37 <@lu_zero> oh =)
-20:37 <@amne> duck and cover!
-20:38 <@amne> so, which points from the proposal need specific discussion?
-20:38 -!- phreak`` [n=phreak``@gentoo/developer/phreak] has left #gentoo-council ["................. do I need to say anything else ?"]
-20:39 -!- Netsplit anthony.freenode.net <-> irc.freenode.net quits: musikc, mpagano__, genone, zxy_64
-20:39 <@dberkholz> amne: you're probably in the best position to talk about whether my understanding of the situation was correct
-20:39 <@jokey> I think one valid point was the timezone problem
-20:39 -!- Netsplit over, joins: musikc, mpagano__, zxy_64, genone
-20:39 <@dberkholz> yeah, but there are distinct times of day that are much more active than others
-20:40 <@amne> yeah, i think that's the main point, i'll take a quick look at the mails agani
-20:40 <@dberkholz> i don't think we need to try for 100% coverage of people watching everywhere every second
-20:40 <@amne> i also like the idea of having a test run as suggested - during that time we can also evaluate how the coverage works
-20:40 <@dberkholz> we just need to show that we will enforce it if it's violated
-20:40 <@lu_zero> there were violations lately?
-20:41 < fmccor> lu_zero, off and on --- some things devrel sees now are really CoC issues in my opinion.
-20:42 <@amne> fmccor: agreed
-20:42 < fmccor> lu_zero, but rather low volume to us.
-20:42 <@dberkholz> i'm not sure how closely y'all read it for devrel/userrel connections, i did add a line about that
-20:42 <@lu_zero> fmccor so there isn't a dire need for them
-20:43 <@lu_zero> _so_ nobody would start talking about us putting them up in hurry because of crisis
-20:43 <@amne> lu_zero: still things may explode again some day, so we shouldn't wait until then
-20:43 <@jokey> lu_zero: just that history has proven we could use it from time to time
-20:43 <@Flameeyes> agreed with amne
-20:43 <@dberkholz> my earnest hope is that we can create a group of people who spend 99% of the time taking no actions
-20:43  * jokey resyncs brainlink with amne
-20:44 <@amne> jokey: get out of my head! :-P
-20:44 <@amne> dberkholz: yes
-20:44 <@lu_zero> amne the main point is the second
-20:44 <@Flameeyes> dberkholz, and 1% doing drills organised by us councilers?
-20:44 <@dberkholz> heh. they could look over old irc logs. =P
-20:44 < fmccor> lu_zero, remember, devrel typically does not watch for these very quick things unless we happen to see them in passing.
-20:44 <@lu_zero> since there isn't need we can approve/appoint them
-20:45 <@lu_zero> s/need/immediate need/
-20:46 < NeddySeagoon> My hope is that the council will back the body while they work - and hold a 'lessons learned' after every incident
-20:47 <@amne> good idea
-20:47 <@jokey> I don't see a reason to not back stuff up atm, but we'll how stuff goes
-20:48 <@amne> otherwise the people execute CoC don't know what the council wants in the first place
-20:48 < jmbsvicetto> dberkholz: An important point about userrel, Is that userrel hasn't been doing the "user control" role for a long time
-20:48 <@lu_zero> why not?
-20:48 < jmbsvicetto> dberkholz: userrel can definitely have that role, but it's something that has been lost for some time
-20:48 <@dberkholz> that makes me think of a couple of points. first, the council won't back up decisions it disagrees with. second, the council needs to be careful not to overreact
-20:48 <@Betelgeuse> hmm it's winter time
-20:48 <@Betelgeuse> damn it
-20:48 <@lu_zero> hi Betelgeuse
-20:48 <@Betelgeuse> stupid UTC
-20:49 <@amne> Betelgeuse: welcome
-20:49 <@jokey> heya Betelgeuse
-20:49 <@dberkholz> Betelgeuse: http://dev.gentoo.org/~dberkholz/summary-20071108.txt
-20:49 <@dberkholz> summary so far
-20:49 -!- Netsplit anthony.freenode.net <-> irc.freenode.net quits: musikc, mpagano__, genone, zxy_64
-20:49 <@amne> dberkholz: agreed, but they still should back up the team doing the work, even if they disagree with a single decision
-20:50 <@dberkholz> and on the other side of that, the team needs to handle its actions appropriately
-20:50 -!- Netsplit over, joins: musikc, mpagano__, zxy_64, genone
-20:50 <@dberkholz> doing the right thing in the wrong way will ruin it
-20:50  * amne nods
-20:50 < NeddySeagoon> dberkholz, My point is that the council supports any action in progress until its concluded, so we don't have incidents like the one that killed proctors
-20:50 < igli> amne's point is critical though, imo
-20:50 <@Betelgeuse> dberkholz: Did you want my input on something?
-20:50 <@dberkholz> Betelgeuse: nah, was just mentioning some points you brought up about EAPI=1
-20:51 <@amne> i guess a --dry-run phase would help a lot with these issues
-20:51 < jmbsvicetto> lu_zero: I think that role hasn't been carried by userrel because the current members have focused more on other projects
-20:51 < NeddySeagoon> dberkholz, The council 'interfering' in a work in progress will undermine the team
-20:51 <@Betelgeuse> dberkholz: Well it's documented in the current PMS version so that's good.
-20:52 <@dberkholz> NeddySeagoon: i think that will be difficult if not impossible with the change to only private actions
-20:52 -!- Tabasco [i=rhcp@gateway/tor/x-91a87846c415d662] has quit [Read error: 104 (Connection reset by peer)]
-20:53 <@dberkholz> all the team would do release is anonymous statistics; X people modded for 6 hours; Y for 12 hours; etc
-20:53 <@dberkholz> s/ do//
-20:53 < NeddySeagoon> dberkholz, Thats a change I welcome - much procting was done in private anyway
-20:55 <@dberkholz> Betelgeuse: while you're here; do you support just adding jokey to council? we need unanimous
-20:55 <@Betelgeuse> dberkholz: sure if he is the next one on the list
-20:55 <@Betelgeuse> I thought that was already decided by the last counci
-20:56 <@amne> i think we should also discuss which tools are available for moderation or even needed to implement
-20:56 <@dberkholz> Betelgeuse: the last council said that the next person would be offered the spot, contingent upon unanimous council approval
-20:56 <@dberkholz> amne: yes that's very true, i thought about that and didn't add anything to the proposal
-20:57 <@Betelgeuse> dberkholz: okay
-20:58 <@amne> last proctors had some mailing list interface (which was done by robbat2 iirc) to block emails from people, was there anything else?
-20:59 <@jokey> I'm with the mail that stated we don't need another set of moderation for irc and forums where it is in place already
-20:59 <@jokey> so we don't need more than this interface imho
-20:59 <@amne> other stuff (that's not implemented, but i think was planned) would have been delaying messages until someone approves they are flame free
-21:00 <@amne> well, that feature could be potentially useful - otoh if mailing list bans are short term it may not be worth the effort to implement
-21:00 <@jokey> ack
-21:00 -!- gentoofan23 [n=gentoofa@gentoo/contributor/gentoofan23] has quit [Client Quit]
-21:01 <@lu_zero> ++
-21:02 <@Flameeyes> [I'm not saying anything because I'm fine for what you're saying :)]
-21:02  * Philantrop wonders what jokey and lu_zero ack'ed - "potentially useful" or "not worth the effort".
-21:02 <@amne> also the bans would need to be unset manually after the time of ban/silencing/foo is over
-21:02 <@dberkholz> jokey: yep, mailing lists and #gentoo-dev are the main things
-21:02 <@amne> this means people should also be there to unban people in a timely manner
-21:02 <@dberkholz> might be able to script that sorta thing
-21:03 <@amne> dberkholz: atm the mailing list has a web-interface for that
-21:03 <@amne> but that's all technicalities that i think can be solved. i think it would be best to ask robbat2 about these things, too
-21:03 <@jokey> if needed, scripting it shouldn't be too hard iirc
-21:03 < jmbsvicetto> dberkholz: I think that would require some sort of cron for that
-21:04 <@amne> perhaps he can easily implement a self-destruct timer for bans
-21:04 < igli> at would be better
-21:04 <@amne> ban amne@gentoo.org for 12 hours -> done
-21:04 <@dberkholz> that's really just a detail that can be figured out after we decide whether to do this at all
-21:04 <@amne> nod
-21:04 <@dberkholz> let whoever's doing the work deal with it
-21:04 <@jokey> yup
-21:05 < NeddySeagoon> amne, it directs mail to /dev/null just now
-21:05 <@amne> NeddySeagoon: ack
-21:05 <@amne> is anyone aware of any other big issues that we haven't discussed yet?
-21:06 <@dberkholz> regarding CoC, or in general?
-21:06 <@amne> CoC
-21:08  * jokey assigns silence to None ;)
-21:08 <@dberkholz> i wrote down all my ideas, so i'm waiting for others to respond. =)
-21:08 < fmccor> Is bugzilla covered by it?
-21:09 <@dberkholz> anywhere without existing moderation should be, so i'd say so
-21:09 <@dberkholz> which i would interpret as "anything gentoo except for #gentoo and forums"
-21:09  * fmccor had guessed that, but did not recall.
-21:09 <@amne> dberkholz: i like the proposal (including the things that have been discussed now)
-21:09 < igli> i don't think having one strong leader is a good idea. better a strong collective imo.
-21:09  * fmccor wanted to hear "yes" :)
-21:10 <@amne> i think it would be good to continue in that direction and finalize it
-21:10 < NeddySeagoon> dberkholz I was expecting your paper to be discussed on -project rather than -council.  As an ex proctor, I intend to provide the benefit of my experiance.  I've just been reading the thread
-21:11 <@amne> discussing it further on -project sounds like a good idea to me
-21:11 <@lu_zero> we could try -project if the noise ratio increase we'll fallback on -council
-21:11 <@lu_zero> deadlines for it?
-21:11 < NeddySeagoon> amne, That was what the last council meetting decided
-21:11 < igli> project is pretty quiet ;-)
-21:12 <@dberkholz> project list had an opportunity to express its interests, which it did
-21:12 <@dberkholz> from those interests i created a concrete proposal
-21:12 <@dberkholz> i don't think that concrete details are well-designed by committees
-21:13 <@dberkholz> i do think basic interests are, though
-21:13 < NeddySeagoon> dberkholz, agreed
-21:13 <@dberkholz> so if any of the basic interests are incorrect or need refinement, i'd be happy to hear about that wherever
-21:13 < jmbsvicetto> dberkholz: One word of caution, your comment of everything gentoo except #gentoo and forums caused a lot of grievance for proctors
-21:13 <@dberkholz> jmbsvicetto: could you expand on that?
-21:14 < jmbsvicetto> dberkholz: Most #gentoo-* irc channels feel they already have a moderation team and are not to keen on having outside interference
-21:14 <@dberkholz> if they want to be an official channel, they have to deal with the CoC
-21:14 < jmbsvicetto> dberkholz: Also, no one has ever been able to come up with a consensous list of official #gentoo-* channels
-21:15 <@dberkholz> whatever's on the IRC channels page
-21:15 <@amne> jmbsvicetto: all #gentoo-* is official
-21:15 <@Flameeyes> ##gentoo-* should be the unofficial ones
-21:15 <@jokey> amne: I don't think so, some are driven by users
-21:15 <@amne> jmbsvicetto: if you want it to be non-official, it's ##gentoo-*
-21:15 <@dberkholz> but certainly this team would need to work with the existing moderation, it doesn't need to take direct action to preempt them
-21:15 <@Flameeyes> [like we have ##gentoo-anime]
-21:15 < jmbsvicetto> dberkholz: I agree, but for instace, #gentoo-userrel, #gentoo-devrel, #gentoo-sparc or #gentoo-pt, just random examples, are not likely to welcome that interpretation
-21:16 <@lu_zero> Flameeyes we should have #gentoo-anime
-21:16 <@dberkholz> are they part of gentoo? if so, the CoC affects them.
-21:16 <@Flameeyes> lu_zero, let's keep it unofficial ;)
-21:16 <@dberkholz> we just need to figure out the best way to deal with that
-21:16 <@Flameeyes> dberkholz, regional channels are a problem though, that I agree with
-21:16 <@Flameeyes> [it so happens I'm one of the #gentoo-it moderators btw]
-21:17 <@dberkholz> that's why the team would liaise with existing moderation
-21:17 <@amne> yes
-21:17 < jmbsvicetto> amne: ok, though question then, is #gentoo-xeffects an official gentoo channel? Also, has freenode changed their policy? Last time we had this discussion the gentoo contacts left it very clear that is was impossible to refuse anyone from registering #gentoo-my-channel
-21:18 <@jokey> tomaw: have some up-to-date details there ^^
-21:18 <@lu_zero> jmbsvicetto if they have the gut to register it as different project
-21:18 <@amne> jmbsvicetto: yes; not that i am aware of; i've seen channels being removed because they were not official and used # instead of ##
-21:18 <@lu_zero> and we aren't knocking them with a trademark hammer
-21:18 <@lu_zero> sure
-21:19 <@amne> lu_zero: yeah, it were some special cases where people used the official #gentoo-* to be abusive
-21:19 <@amne> lu_zero: don't remember the exact details any more
-21:19 <@amne> i don't think anyone who does some good work will get slapped by us for not being official enough or whatsoever
-21:19 < jmbsvicetto> So I'm not misunderstood, I do agree that #gentoo channels should be official channels, but that is not the case currently and freenode doesn't seem to be willing to support that claim
-21:20 <@amne> jmbsvicetto: how come?
-21:20 < jmbsvicetto> amne: well, if they will allow anyone to register any #<whatever> channel, how can you enforce that #gentoo-* channels are official gentoo channels?
-21:21 <@jokey> from what I know, at least within europe you can't enforce trademark over channel names, I think there was something with #debian.de in the past...
-21:21 <@amne> jmbsvicetto: freenode staff can get it back
-21:21 < jmbsvicetto> amne: But I think that working with existing teams and working with people that are doing "good work" is the best way
-21:21 <@amne> jmbsvicetto: yes
-21:22 <@lu_zero> agreed
-21:22 < jmbsvicetto> However, I urge you to have a "crystal clear" definition of where you want/expect that team to work
-21:22 <@amne> jmbsvicetto: i think the only problem would be someone managing an official (#gentoo-*) channel and refusing to accept CoC at all by allowing attacks and other nasty stuff
-21:23 < NeddySeagoon> amne, like in -dev ?
-21:23 < jmbsvicetto> amne: You were on the proctors team, so you know the answer to that ;)
-21:23 <@amne> NeddySeagoon: #gentoo-dev?
-21:23 <@amne> jmbsvicetto: heh
-21:23 < NeddySeagoon> amne, yes. With everone an op, its impossible to enforce
-21:24 < tomaw> jmbsvicetto: it's difficult to refuse them being registered, but a contact could reclaim it if they felt they should
-21:24 < tomaw> jmbsvicetto: that's freenode policy - I have no idea of gentoo policy
-21:24 <@amne> NeddySeagoon: #gentoo-dev has no clearly defined people in charge, does it? (so it's up to the new team to manage it imho)
-21:25 <@lu_zero> everybody should be in charge
-21:25 < NeddySeagoon> lu_zero, everbody == nobody
-21:25 <@dberkholz> in general it's sort of devrel, since they're the ones who add/remove ops
-21:26 < jmbsvicetto> tomaw: At least that's what I gathered from my talks with some gentoo contacts while I worked on the proctors
-21:26 < NeddySeagoon> Its a detail to think about
-21:26 <@jokey> indeed
-21:26 < jmbsvicetto> amne: I agree, but you should expect resistance to a "controlled" #gentoo-dev
-21:27 <@amne> i think #-dev should fall under the same treatment as the mailing list
-21:27 < tomaw> jmbsvicetto: yes, the gentoo project registered with freenode and claimed #gentoo-* channels.  Currently, it's possible for anyone to register a channel in that namespace, but it can still be turned over the to gentoo project on request.
-21:27 < kingtaco|laptop> not really, tell them to go somewhere else
-21:27 < kingtaco|laptop> freedom of speech(if we even have it) is the freedom to say what you want, not where you want
-21:27 < jmbsvicetto> tomaw: Thanks for clearing that
-21:27 <@amne> jmbsvicetto: i told you :-P
-21:28 < jmbsvicetto> amne: :)
-21:28 < tomaw> jmbsvicetto: note that a single project cannot own #gentoo-* and ##gentoo-*, so gentoo has no control over ##gentoo-* channels
-21:30 <@jokey> despite talking on details, are there big points we missed?
-21:31 <@amne> seems everyone's happy (or fallen asleep)
-21:31 <@amne> perhaps it hasn't been said explicitely, but from my understanding, if someone gets into trouble frequently, issues will be escalated to devrel, right?
-21:32 <@lu_zero> I think it's sane
-21:32 <@jokey> amne: devrel or userrel
-21:32 <@amne> jokey: right
-21:33 <@dberkholz> my presumption is that successive actions against the same person will eventually extend to the 3-day cutoff that means they need council approval and forwarding to devrel
-21:33 <@amne> dberkholz: ack
-21:33 <@dberkholz> but i didn't really allow for someone getting a million 6-12 hour blocks
-21:33 <@amne> heh
-21:33 <@dberkholz> maybe i should expressly disallow that, as it's the same "warnings go on forever" problem that means nothing ever gets fixed
-21:34 <@amne> hm
-21:35 <@amne> personally i'd prefer loose guidelines and individual treatment depending on the situation
-21:35 <@amne> but if someone is warned and repeats his behaviour, action should follow
-21:36 <@lu_zero> ok
-21:36 <@dberkholz> http://dev.gentoo.org/~dberkholz/summary-20071108.txt has my summary of the discussion so far
-21:36 <@dberkholz> we should wrap it up soon and send back to the -council list
-21:38 <@lu_zero> do we have anything to discuss about baselayout2 and uberlord?
-21:39 <@amne> dberkholz: summary looks good to me
-21:39 <@Betelgeuse> lu_zero: Not much if Uberlord contains to maintain it  externally
-21:39 <@Betelgeuse> lu_zero: Otherwise we do need to find someone who works on it.
-21:39 <@lu_zero> Betelgeuse BSD license switch included?
-21:39 <@dberkholz> it wasn't a switch, it was an addition
-21:39 <@dberkholz> so dual GPL/BSD
-21:40 <@dberkholz> both of which are FSF free, fwiw, so fits our social contract fine
-21:40 <@lu_zero> held on git on our infrastructure?
-21:40 <@dberkholz> not sure about the infrastructure bit. anyone know?
-21:41 <@Flameeyes> I think the idea was to use our git
-21:41 <@Betelgeuse> I think infra does not allow commit access to non devs but I could be wrong.
-21:41 <@dberkholz> i'm also unsure how much it matters; i suspect other distros use init systems they don't personally keep on their infra
-21:42 <@jokey> imho it doesn't matter where it resides as long as someone packages it for gentoo ;)
-21:42 <@Betelgeuse> dberkholz: yeah like upstart
-21:42 <@Flameeyes> dberkholz, yeah doesn't really matter, it just means we have to split baselayout (base files) from the rc system
-21:42 <@Flameeyes> and that was probably a good idea to begin with
-21:42 <@lu_zero> as long it doesn't break for us...
-21:43 <@dberkholz> Flameeyes: i'm sure upstream would be glad to include distro files for any distros that wish to use it. =)
-21:43 <@Flameeyes> dberkholz, I think Roy's idea was splitting them, anyway I'll certainly follow up with him about it as I do have interest in it
-21:43 <@dberkholz> sure, i don't know the details
-21:43 <@lu_zero> ok
-21:44 <@dberkholz> anyway it seems that baselayout-2 remains in good hands and maintained
-21:45 <@dberkholz> anyone got another open floor topic?
-21:46 <@jokey> nox-Hand: you wanted?
-21:46 < kingtaco|laptop> what about infra?
-21:46 <@dberkholz> kingtaco|laptop: is there something in particular about infra you'd like to bring up?
-21:47 < kingtaco|laptop> nope, just cought my eye
-21:47 < kingtaco|laptop> you guys were talking about infra
-21:47 <@dberkholz> kingtaco|laptop: oh, we're just not exactly sure where baselayout-2 repository will end up
-21:47 <@amne> kingtaco|laptop: we decided infra needs to provide the ice cream machine i promised in the election :-)
-21:47 < kingtaco|laptop> amne, sure, just send me the money
-21:47 <@amne> heh
-21:47 <@lu_zero> kingtaco|laptop we were thinking about overhauling one of the boxes
-21:47 < kingtaco|laptop> dberkholz, yeah, thats a problem.
-21:48 < jmbsvicetto> amne: Please put it next to bender. kthxbye :P
-21:48 < kingtaco|laptop> lu_zero, ?
-21:48 <@dberkholz> kingtaco|laptop: i see it as an open question, certainly
-21:48 <@lu_zero> kingtaco|laptop for the icecreams
-21:48 <@dberkholz> it's fine on any site that hosts git, as far as i'm concerned
-21:48 < kingtaco|laptop> lu_zero, no recycled icecream please
-21:49 <@lu_zero> dberkholz so far repo.or.cz
-21:49 < kingtaco|laptop> dberkholz, tbh, I don't know if that's good
-21:49 <@dberkholz> kingtaco|laptop: why?
-21:50 < kingtaco|laptop> well, put something as critical as baselayout on anything other than our hardware and it's hard to trust.  that said the guy who write the stuff is no longer a dev so it's hard to trust him as well
-21:50 <@lu_zero> kingtaco|laptop solutions?
-21:50 <@jokey> it's open source so you take a look at the diffs
-21:50 <@dberkholz> kingtaco|laptop: how about all the other code on your system?
-21:50 < kingtaco|laptop> whoever is importing it into gentoo is going to have to keep a close eye on whats going on
-21:50 <@lu_zero> beside abducting roy
-21:50 < kingtaco|laptop> lu_zero, sadly, no
-21:50 < kingtaco|laptop> dberkholz, well, baselayout is critical
-21:50 < kingtaco|laptop> other stuff is not
-21:51 <@dberkholz> baselayout is just as critical as glibc, gcc, coreutils
-21:51 <@jokey> ack
-21:51 < jmbsvicetto> I agree with kingtaco|laptop in particular if we take into account the decision regarding the PMS
-21:51 <@lu_zero> still we can keep a local git
-21:51 <@lu_zero> and pull from roy from time to time
-21:51 <@dberkholz> and yes, it's git so we can do whatever we want
-21:51 <@dberkholz> we can maintain our own patchset on top, we can track his branch, we can fork off, whatever
-21:52 < kingtaco|laptop> I'm not saying not do it, I'm saying whichever gentoo dev is the one who is importing it is going to have to audit each and every import.  there is just too much chance for an exploit.  projects like coreutils/gcc/glibc have built up a reputation which is why they are different
-21:52 <@jokey> and not trusting him because he just is no longer a dev tastes very very bad imho
-21:52 <@dberkholz> that's disgusting
-21:52 <@Betelgeuse> I would trust Uberlord lot more than new devs.
-21:53 <@dberkholz> roy's built a reputation too, and quitting gentoo does not affect my view of it in any way
-21:53 < kingtaco|laptop> would you trust whatever random host he hosts the repo on?
-21:53 < kingtaco|laptop> I know I wouldn't
-21:53 <@dberkholz> i trust sha512
-21:53 <@jokey> if he uses git ans signs it, then yes
-21:53 <@jokey> *and
-21:53 < kingtaco|laptop> SCM doesn't matter here
-21:53 < kingtaco|laptop> signs it perhaps
-21:54 < kingtaco|laptop> however, you're still trusting uberlord to audit his own code before he releases
-21:54 <@dberkholz> how's that different? =)
-21:54 <@amne> (i have to slack off and take care of some stuff, hope no one minds)
-21:54 < kingtaco|laptop> it's where you put the trust
-21:55 < igli> isn't that what the testing releases are for?
-21:55 -!- desultory [n=dean@gentoo/developer/desultory] has joined #gentoo-council
-21:56 < kingtaco|laptop> when it was on gentoo hardware developed by a gentoo dev there was a lot of trust.  now it's on random hardware by a (trusted) ex dev
-21:56 <@jokey> kingtaco|laptop: re trust... we had exploitable code for year(s) on packages. and we controlled the repo and had a gentoo dev maintaining it. so I really don't see a point
-21:56 < kingtaco|laptop> I think you need to consider how it can be attacked before you decide on trivialities like git
-21:56 <@dberkholz> git supports gpg-signed tags and the whole thing is based on sha1 sums
-21:57 < kingtaco|laptop> jokey, packages is not an attack vector for each and every single gentoo install
-21:57 < kingtaco|laptop> baselayout is
-21:58 < kingtaco|laptop> dberkholz, I don't know enough about git to comment on it's trustworthness
-21:59 -!- leio_ is now known as leio
-21:59 < igli> hang on; uber signs it so it's verifiably his code. base-system bring it in and sign off on review, then it goes thru testing. where's the vector?
-21:59 <@dberkholz> the suggestion is that nobody will audit the code, either roy or ebuild maintainers
-21:59 <@dberkholz> and the git host will somehow be the vector
-21:59 <@dberkholz> i'm just asking in #git about that
-22:01 < kingtaco|laptop> when it was on gentoo hardware, you could trust the repo as much as you trusted a combination of gentoos security, arch, and infra teams.  when it's somewhere random, you can't trust that git doesn't have a bug or that the host of the git repo isn't doing something malicious
-22:01 <@dberkholz> i don't think malicious hosts are possible with how git is implemented
-22:02 <@dberkholz> but i'm asking for clarification
-22:02 -!- uberpinguin [n=uberping@unaffiliated/uberpinguin] has quit ["Leaving"]
-22:02 < Philantrop> kingtaco|laptop: Would infra allow non-devs to commit to the repository if it was on Gentoo hardware?
-22:02 < bonsaikitten> apart from bugs in git itself the signing should be as tamper-resistant as any other system
-22:02 < igli> sorry i don't see it; only vector is a bug in gpg, which i agree has happened before
-22:02 < kingtaco|laptop> dberkholz, this is a package that's so important that infra would entertain allowing a baselayout repo for uberloard to use
-22:02 -!- fmccor_ is now known as fmccor|home
-22:03 -!- Ingmar^ [n=ingmar@83.101.12.48] has joined #gentoo-council
-22:03 < kingtaco|laptop> Philantrop, normally no, this is an extrodonary case where I would bring it up with the other infra folks
-22:03 -!- Ingmar [n=ingmar@83.101.12.89] has quit [Nick collision from services.]
-22:04 <@jokey> anyway there are no full rewrites near so a diff shouldn't be hard to look into (at least when looking at last updates)
-22:05 < Philantrop> kingtaco|laptop: Well, if I had anything to say about it, I'd prefer the Gentoo hardware under that circumstances even though I don't think there are any attack vectors but gpg itself.
-22:05 < igli> would be better
-22:05 < kingtaco|laptop> Philantrop, on the surface, I would prefer that too, but infra has to have a pow-wow to look deeper
-22:06 < kingtaco|laptop> dberkholz, jokey can you table this until next month so I have time to talk to infra peeps?
-22:06 <@dberkholz> repo.or.cz is a git hosting site from the git developers, so i guess if you trust git, you can trust the site
-22:06 <@dberkholz> kingtaco|laptop: we're not making any decisions so we have nothing to table
-22:06 < kingtaco|laptop> if we can't do it, then I'll shut up
-22:06 < eroyf> kingtaco|laptop: infra is willing to let uberlord work on baselayout even though he's not a developer?
-22:06 < kingtaco|laptop> eroyf, not exactly
-22:06 < eroyf> then what exactly
-22:07 < kingtaco|laptop> what I proposed is that infra might create a seperate repo for him to use for the sole purpose of his baselayout development
-22:07 < eroyf> so he's going to stay as a developer or what?
-22:08 < kingtaco|laptop> afaik, he quit
-22:08 < kingtaco|laptop> if he's intending on coming back, I don't know about it
-22:08 <@dberkholz> basically the proposal is that we'd become a very limited project-hosting site for non-gentoo devs working on critical gentoo packages
-22:08 < eroyf> or do you create a repo for him to work on and then let someone with an @gentoo.org commit it to the *right* repo?
-22:08 < eroyf> with svn support?
-22:09 < kingtaco|laptop> I don't care about the scm
-22:09 < igli> which other packages are so critical, and not dev'ed by gentoo?
-22:09 < kingtaco|laptop> if I had my way everyone would still use RCS :p
-22:09 < eroyf> PMS for example.
-22:09 < eroyf> which is not a package.
-22:09 < eroyf> but infra simply refused to let non-developers get access to that repo
-22:09 < eroyf> so this is somehow interesting.
-22:09 < igli> if moot
-22:10 < kingtaco|laptop> extremely moot
-22:10 < eroyf> well, i'm looking forward to see what you decide
-22:10 < kingtaco|laptop> ok...
-22:10 <@dberkholz> since we're not going to make any progress at this meeting, let's just adjourn the meeting
-22:11 <@dberkholz> feel free to keep talking about it afterwards
-22:11 -!- igli [n=igli@unaffiliated/igli] has left #gentoo-council ["Have a good one ;-)"]
-22:11 < kingtaco|laptop> I don't have much more to say, I need to talk to my team about it and work out the details.  I'll send you guys an email when infra agrees on something
-22:16 < fmccor|home> A final thanks to dberkholz for his CoC proposal, which I view as great progress.
-22:17 <@dberkholz> thanks fmccor|home, i'm glad it went over fairly well
-22:17 -!- windzor [n=windzor@84.238.69.202] has quit [Remote closed the connection]
-22:18 < fmccor|home> In my opinion, better than "fairly well". :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071213-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20071213-summary.txt
deleted file mode 100644
index 3009d30bee..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20071213-summary.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-Roll call
----------
-
-amne         here
-betelgeuse   here
-dberkholz    here
-flameeyes    here
-lu_zero      here
-vapier       here
-jokey        here
-
-Agenda
-------
-
-New USE documentation
-	http://archives.gentoo.org/gentoo-dev/msg_149120.xml
-	Considering the precedent set by how this was implemented,
-		what should we do?
-
-	- Should we leave it or revert it?
-	- Should we require a GLEP?
-		- Other options
-			- Discuss improvements on -dev, make changes, document them.
-				In other words, normal development process
-			- Leave as is
-			- Require future global changes to be sent to -dev in advance,
-				or they will be reverted.
-
-Code of Conduct enforcement 
-	http://thread.gmane.org/gmane.linux.gentoo.council/82
-	http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt
-
-	- Should we make a decision today?
-	- If so, what decision?
-	- If not, what needs to happen for us to make a decision?
-
-=======================================================================
-
-New USE documentation
----------------------
-
-1. We're leaving it, and considering further changes
-2. It should have been posted to -dev before committing for discussion
-
-General process for global changes:
-	1.  Post to -dev for discussion
-	2a. Consensus for implementing your idea as-is. No GLEP, no council. BREAK.
-	2b. Consensus for a GLEP for your idea, maybe disagreement over the idea.
-	    Write GLEP. Discuss on -dev. Submit GLEP to council.
-	2c. Disagreement, but some support. No consensus for a GLEP. Respond to the
-	    council agenda mail with a post containing a summary of your idea as
-	    well as patches for code and documentation.
-	2d. No support. Refine your idea, or think of a new one. GOTO 1.
-	3.  Council votes on the idea.
-
-Any future global changes that aren't discussed on -dev in advance may 
-be reverted by the council if at least two council members vote to revert 
-the changes. Those changes must be discussed on -dev and approved by the 
-council before recommitting. If they're recommitted without council 
-approval, the developer in question gets kicked out.
-
-Code of Conduct enforcement
----------------------------
-
-Christy Fullam (musikc) made some valuable suggestions:
-
-	- The proposal should be restricted to only apply to #gentoo-dev and the
-		gentoo-dev list. Most other locations already have moderators of some
-		sort, and the council can work with them directly if there are CoC
-		problems. This idea went over really well.
-	- Moderation should be capped at 2 days, and then will be handed off to
-		devrel/userrel. No council approval involved.
-
-Mike Doty (kingtaco) suggested that we look for a way to prevent the 
-snowball effect on IRC: what if a modded person is voiced/opped by an 
-unmodded person, and a chain of this goes?
-
-Donnie Berkholz (dberkholz) will incorporate these changes into the 
-proposal and post an update to the -council list.
-
-Open floor
-----------
-
-Wulf Krueger (philantrop) asked which PMS repo was authoritative. The 
-external one had been getting changes, and the "official" gentoo.org one 
-had not. Mike Doty reported that they're working on allowing non-Gentoo 
-developers to contribute to the repository, which should resolve the 
-technical problems. Wulf responded that some people didn't want to 
-commit to a Gentoo-hosted repository.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20071213.txt b/xml/htdocs/proj/en/council/meeting-logs/20071213.txt
deleted file mode 100644
index 8a78510ea4..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20071213.txt
+++ /dev/null
@@ -1,369 +0,0 @@
-20:00 <@jokey> dberkholz: you've taken chair, start the show plz ;)
-20:00 <@dberkholz> ok
-20:00 <@dberkholz> council members, sound off
-20:00  * amne looks
-20:01 <@Flameeyes> I'm here
-20:01 <@Betelgeuse> \o/
-20:01 <@jokey> \o/
-20:03 <@dberkholz> vapier: how's your ping?
-20:04 <@vapier> hot
-20:04 <@dberkholz> sweet.
-20:04 <@dberkholz> first issue, new USE documentation.
-20:04 <@dberkholz> it's in place, should we revert it or leave it in place and consider further changes?
-20:05 -!- Maedhros [n=jc@gentoo/developer/Maedhros] has joined #gentoo-council
-20:05 <@lu_zero> leave it and consider improvements
-20:05 <@lu_zero> ("go agile" =P)
-20:05 <@Flameeyes> as lu_zero said
-20:06 <@dberkholz> anyone disagree with that?
-20:06 <@amne> lu_zero++
-20:06 <@vapier> sounds peachy
-20:06 <@Flameeyes> none of the concerns I've read about seems to be incompatible with the current (albeit basic) implementation
-20:06 <@jokey> with it
-20:06 <@vapier> that doesnt mean it was done "properly"
-20:07 <@jokey> right, but still won't block further extensions of it
-20:07 <@Flameeyes> vapier, I disagree but you know that already :)
-20:07 <@vapier> planet.g.o is not the place for development
-20:07 <@vapier> there's a development mailing list
-20:07 <@vapier> use it
-20:07 <@lu_zero> so point 1b, how to fix the process
-20:08 <@lu_zero> Flameeyes pointed in many places that the glep process is problematic
-20:08 <@Betelgeuse> it's not
-20:08 <@Betelgeuse> but we do need some GLEP editors
-20:09 <@Betelgeuse> old ones need updating
-20:09 <@dberkholz> could you remind me what problems there were besides him not wanting to write in english?
-20:09 <@lu_zero> dberkholz let me see
-20:09 <@Flameeyes> dberkholz, never said I don't want to write in english, in fact, I actually do write in english more than I write in italian lately :)
-20:09 <@lu_zero> - the system seems to let proposal go stale
-20:09 <@vapier> people still use italian ?
-20:10 <@Flameeyes> my problem on language was more that the glep review process seems to go anal on grammar more than feasibility
-20:10 <@lu_zero> - writing a glep takes no much effort, getting it through more than implementing the proposals sometimes
-20:10 <@vapier> Flameeyes: i wouldnt say it's anal on grammar, it's anal on being correct
-20:10 <@dberkholz> one other issue i remember is that someone said that gleps never ended up getting integrated into other documentation, and you couldn't figure out what the actual result was in one place
-20:10 <@vapier> you're talking about a mini-spec
-20:11 <@vapier> it cant be ambiguous
-20:11 <@jokey> dberkholz: that's valid though (mostly devmanual additions have been left out from what I recall on that list)
-20:12 <@jokey> might be related that we have no active devmanual maintainer atm
-20:12 <@Betelgeuse> Halcy0n is coming back.
-20:12 <@Betelgeuse> He will hopefully do it.
-20:12 <@vapier> he seems set on it
-20:12 <@Flameeyes> vapier, and that's one problem, I can see why a spec is needed for big changes, but we're full of little changes for which I think a spec is an overkill
-20:12 <@dberkholz> yeah, he's submitted a lot of patches to it
-20:12 <@Flameeyes> and for those, being anal on correctness slows down the process quite a lot
-20:13 <@vapier> Flameeyes: i'm not arguing that this needed a GLEP, just that it should not have been done without being on the gentoo-dev mailing list
-20:14 <@Flameeyes> vapier, I can see your point in this, and I can agree on that, seeing it afterward
-20:14 <@Flameeyes> I certainly wasn't expecting this much of discussion on it anyway
-20:14 <@Flameeyes> still, I see the need for a min-spec for smaller changes an overkill
-20:14 <@vapier> usually after arguing it out on gentoo-dev, it is generally apparent whether it needs a GLEP
-20:15 <@vapier> if everyone is like "great super happy hard love it", then you do it
-20:15  * Flameeyes needs to take a quick shower
-20:15 <@lu_zero> vapier knowing the people there you ALWAYS need a glep
-20:15 <@Flameeyes> you already knows my point so I suppose I can go afk for a few mins ;)
-20:15 <@lu_zero> ok
-20:15 <@lu_zero> or you could bring the laptop there
-20:15 <@jokey> I'm with vapier here, sometimes small things turn out to rattle more cages you might have thought of ;)
-20:16 <@dberkholz> well, you could imagine getting council approval without having a full glep
-20:16 <@lu_zero> dberkholz and which are the minimum requirement for this small glep?
-20:17 <@dberkholz> just post your patches and a summary, following their discussion on -dev, when the council agenda request goes out
-20:18 <@lu_zero> fine for me
-20:19 -!- yoswink [n=yoswink@gentoo/developer/yoswink] has joined #gentoo-council
-20:20 <@jokey> more input or?
-20:22 <@Flameeyes> back
-20:23 <@Flameeyes> dberkholz, if we make that a feasible and accepted way, that works for me
-20:23 <@dberkholz> i don't see anything prohibiting it now
-20:23 <@dberkholz> people can submit anything they want to the council
-20:24 <@Flameeyes> dberkholz, sure, the problem is if that will make those things "properly" submitted or not...
-20:24 <@lu_zero> I'd say that would be up to su decide if we need a full glep or not
-20:24 <@lu_zero> (yes I'm asking for pain)
-20:24 <@vapier> i think current state is fine
-20:24 <@lu_zero> s/su/us/
-20:25 <@dberkholz> exactly
-20:25 <@dberkholz> we can say, either that needs a glep, or sure we'll take it like this
-20:25 <@dberkholz> or, take it back to -dev, we won't decide on that
-20:26 <@dberkholz> the only thing i'm a stickler about is making sure that non-glepped things have accompanying documentation
-20:28 <@lu_zero> I'm fine with it
-20:29 <@dberkholz> now a question of how to deal with these undiscussed global changes in the future
-20:29 <@dberkholz> do we leave them, or revert them?
-20:29 <@Flameeyes> I'd say decide on a case-by-case, by mail consultation with the council
-20:30 <@jokey> well everything like that should go through -dev first
-20:30 <@jokey> otherwise plain revert it
-20:31 <@dberkholz> ok, what if we assume it will be reverted but the council can veto
-20:31 <@jokey> then it also has to leave a comment on -dev
-20:31 <@dberkholz> we agree that these things need to go through -dev beforehand, right?
-20:32 <@jokey> right
-20:32 <@lu_zero> yes
-20:32 <@dberkholz> so if they don't, and we do nothing, that doesn't exactly help
-20:32 <@jokey> we revert it and post (at least) a notice to -dev about it
-20:33 <@Flameeyes> problem is defining what "undiscussed global changes" mean
-20:33 < kingtaco|work> something that affects more than what you control
-20:34 <@dberkholz> certainly things affecting every ebuild author would qualify as global
-20:34 <@Flameeyes> kingtaco|work, well, there is always a project controlling software
-20:34 <@vapier> Flameeyes: care to write a GLEP about the meaning of "undiscussed global changes" ?
-20:34 <@Flameeyes> I'd consider a change in portage behaviour global, but portage code is under portage's devs control for instance
-20:35 <@vapier> global should be pretty self evident
-20:35 <@vapier> if other people outside your team are affected
-20:35 <@vapier> blamo
-20:35 < kingtaco|work> that's a pretty easy way to see it
-20:35 <@vapier> it's the same "global" definition we've always used
-20:35 <@vapier> new developers: when do you use gentoo-dev ?
-20:35 < kingtaco|work> easier to define local and let global be the res
-20:35 < kingtaco|work> rest
-20:35 <@vapier> global issues !
-20:38 <@Flameeyes> do doc team have to pass through -dev to change the guidexml dtds for instance?
-20:38 <@Flameeyes> the dtds are under doc project's control, but guidexml is not just used by doc team
-20:39 -!- ZeRoX [n=zerox@nelug/developer/zer0x] has joined #gentoo-council
-20:40 <@dberkholz> they should probably pass through gentoo-doc instead
-20:40 <@jokey> guidexml was "offered" by doc team, so it's a related issue with them
-20:41 <@dberkholz> perhaps with a pointer to the discussion on -dev if it's really significant
-20:41 <@jokey> (and should be on their mailinglist as dberkholz pointed out=
-20:41  * Flameeyes still thinks this is subjective a lot from one's prospective
-20:43 < kingtaco|work> Flameeyes, which is why communicating when there is any question if it's global is important
-20:43 < kingtaco|work> really, a quick poll in #-dev is enough to figure out if people consider a topic global
-20:46 <@jokey> indeed. communication++
-20:46  * Flameeyes still isn't much revert-happy but it's not his decision
-20:46 <@lu_zero> well I'd rather avoid that
-20:47 <@lu_zero> still telling on -dev what you are doing isn't that problematic
-20:48 <@dberkholz> all our code's in version control, it's not like reverting something makes it disappear forever. it's trivial to re-commit later after it's been discussed
-20:48 <@Flameeyes> lu_zero, I think that in case like this, when skipping -dev is an overseen rather than malicious action, reverting would be too much
-20:48 <@dberkholz> i think that doesn't make any difference
-20:49 < kingtaco|work> dberkholz, out of all the problems we've had, revert wars have not been one.  should try to keep it that way :)
-20:49 <@dberkholz> well, it's no war because the buck stops with the council
-20:49 <@dberkholz> you commit undiscussed global change. council reverts it. if you recommit without council approval, we kick you out.
-20:51 < kingtaco|work> you don't see the problem with that?
-20:51 <@dberkholz> what's the problem?
-20:51 < kingtaco|work> if it needed to be reverted, then it's likely urgent enough that it cannot tolerate the latency of a council vote
-20:52 < kingtaco|work> otherwise the revert is a punishment and nothing more
-20:52 <@jokey> two council members can decide temporarily until next meeting
-20:52 <@lu_zero> ok
-20:52 <@Flameeyes> kingtaco|work, that's exactly what I meant
-20:52 <@Flameeyes> I'm not against a revert _if needed_, I'm against revert as just a punishment
-20:53 < kingtaco|work> it's just kind of pointless to revert if there's not a need
-20:53 < kingtaco|work> it's gonna hurt peoples feelings
-20:53 <@Flameeyes> hence my "case by case" idea
-20:53 < kingtaco|work> flamewars will probably ensue
-20:53 <@dberkholz> how is it a punishment? it's saying you can't commit things we haven't discussed, because they may be half-baked
-20:54 <@dberkholz> if people commit things we haven't discussed despite that, it just encourages lack of discussion because people will keep on doing that
-20:54 < kingtaco|work> that's true
-20:54 < jmbsvicetto> If it's a policy violation, than qa should be the one doing the revert in the first place
-20:54 < kingtaco|work> need a more active QA before that's possible
-20:54 < kingtaco|work> in theory QA should be doing it though, yes
-20:54 < NeddySeagoon> You have just decided the USE documentation on a case by case basis ... if it was good enough for that, why not going forward too, now the precedent has been set ?
-20:55 <@dberkholz> it's grandfathered in
-20:55 <@dberkholz> we can't retroactively apply new rules
-20:56 <@lu_zero> ok
-20:56 <@dberkholz> ok, here's what i've got
-20:56 <@dberkholz> Any future global changes that aren't discussed on -dev in advance will
-20:56 <@dberkholz> be reverted unless two council members vote to veto the reversion. Those
-20:56 <@dberkholz> changes must be discussed on -dev and approved by the council before
-20:56 <@dberkholz> recommitting.
-20:57 <@dberkholz> Flameeyes: it might make you feel a little better that it would have to be a pretty bad idea if it couldn't even get 2 council members to stop it from getting reverted
-20:57 < kingtaco|work> who can "revert"
-20:57 <@dberkholz> i just added "by the council"
-20:57 <@Flameeyes> dberkholz, I'd have preferred it the other way, but it's not me to decide, I shouldn't really vote on this issue at all
-20:57 < kingtaco|work> a consensus of people who happen to be active?  QA(when it's active)? anyone with a grudge?
-20:58 <@Flameeyes> [the other way as in, it will be reverted _if_ two council members vote to revert]
-20:58 <@dberkholz> sure you should, it's not applying to your thing =)
-20:59 <@dberkholz> Flameeyes: that would make it easier to revert, since only 2 need to favor reversion instead of 2 opposing it. is that what you want?
-21:00 <@Flameeyes> dberkholz, I consider the council savvy enough on the issues to decide if it's really the case to revert
-21:00 <@dberkholz> it does simplify the logic, though
-21:00 <@Flameeyes> on the other hand we could give an option to freeze, other than revert
-21:00 <@Flameeyes> [like was done last year for the multiple version suffix - was it last year?]
-21:02 -!- desultory [n=dean@gentoo/developer/desultory] has joined #gentoo-council
-21:02 <@dberkholz> i think that reverting something makes it more likely to get fixed than leaving a halfway-working thing in place
-21:02 <@Flameeyes> so the option would be a) revert, and ask for fleshing out before next council meeting; b) freeze, and again ask fleshing out before council meeting, otherwise the change is reverted; c) leave it go
-21:03 <@dberkholz> i'm sure we're all familiar with hacky code that barely works, but never gets fixed
-21:03 <@Flameeyes> dberkholz, hence why the council should then revert if there is no intention to flesh out the details
-21:06 <@Flameeyes> I'd actually expect freeze (under the threat of reversal) being more effective than direct reversal
-21:06 <@Flameeyes> as that makes less likely that the person involved would just be frustrated and would give up about fleshing the changes up
-21:07 <@dberkholz> is it really that hard to submit a complete patch?
-21:08 <@Flameeyes> no, but there can be mistakes in judgement because one change is not felt global by who made it, but it is from others, so, it might happen
-21:08 <@dberkholz> (on a side note, if we used distributed scm this would be a nonissue)
-21:09 <@dberkholz> Flameeyes: you think there are cases where one person absolutely feels it's non global and another person feels it's global?
-21:09 <@Flameeyes> I'm certainly not saying this to get an escape route to fasttrack things that one knows should be discussed
-21:09 <@Flameeyes> dberkholz, yes
-21:09 <@dberkholz> if it's ambiguous, people should ask
-21:09 <@dberkholz> as kingtaco|work was saying earlier
-21:09 <@Flameeyes> dberkholz, problem is, one might not feel like there's the need to ask... if he knew he'd would just submit the thing to -dev :)
-21:10 <@dberkholz> Flameeyes: can you cite a real instance of this?
-21:10 <@lu_zero> I won't spend more time on this point...
-21:10 <@lu_zero> reverting and recommitting isn't that problem
-21:11 <@Flameeyes> dberkholz, well, I for one wasn't much thinking about the metadata change as a global issue, considering dtd seemed to be under doc's control
-21:11 <@jokey> it isn't under docs control in any way
-21:12 <@Flameeyes> jokey, beside the fact that only doc team can actually commit to that directory you mean :)
-21:12 <@dberkholz> ok, i don't want to get into that
-21:12 <@dberkholz> i'm going to post what i've got and we can vote on it
-21:13 <@dberkholz> Any future global changes that aren't discussed on -dev in advance may reverted by the council if at least two council members vote to revert the changes. Those changes must be discussed on -dev and approved by the council before recommitting. If they're recommitted without council approval, the developer in question gets kicked out.
-21:13 <@Flameeyes> what am I saying is that if it is trivial to recognize a global issue afterward, it's not that easy beforehand for some things, so I wouldn't expect a mistake never to happen; certainly I don't want that to be used as excuse for malicious forcing
-21:13  * Flameeyes votes yes
-21:14 <@dberkholz> i agree with myself
-21:14  * jokey votes yes
-21:14 <@Flameeyes> dberkholz, that's good, otherwise we should be calling an hospital ;)
-21:14 <@dberkholz> and i also want to get on with this
-21:16 <@amne> sounds good
-21:16 <@dberkholz> alright. let's talk code of conduct
-21:17 <@lu_zero> fine
-21:17 <@lu_zero> anything changed from the former proposal?
-21:18 <@dberkholz> musikc suggested some changes
-21:18 <@dberkholz> that we should cap moderation at 2 days
-21:19 <@dberkholz> no need for council approval for longer periods because they won't happen, and it'll just get handed off the devrel
-21:20 < fmccor> What about user-on-user?
-21:20 <@dberkholz> good question
-21:20 <@dberkholz> the only action we can take then is moderating/banning then
-21:20 <@dberkholz> suppose it should go to userrel
-21:21 <@dberkholz> she also emphasized that we should focus on #gentoo-dev and the -dev list, because the other places (forums, other irc etc0 already have mods in place
-21:22 <@jokey> ack on the last one
-21:22 <@dberkholz> and perhaps more than focus, actually say that this is just dev mods for those 2 places and nothing else
-21:23 <@lu_zero> so far fine for me
-21:23 <@dberkholz> i like that last idea
-21:23 <@jokey> same here, that way the impact is also predictable
-21:24 <@dberkholz> and if CoC standards turn out to be a problem in specific places, the council could directly work with those people
-21:24 < NeddySeagoon> The CoC still applies other places, where its enforced by the existing moderation groups, so no issue there
-21:25 <@dberkholz> so anywhere but gentoo-dev list and irc would have no bearing on this proposal
-21:25 <@lu_zero> and if another place appears, well we'll extend later
-21:25 < Philantrop> What about Bugzilla when it's dev vs. dev?
-21:26 < fmccor> Right now, devrel does that when called in.
-21:26 <@dberkholz> devrel's been handling that in the past, right
-21:26 < fmccor> Generally we (I at least) have to be called, otherwise I won't see it.
-21:27 <@dberkholz> right. i don't think anybody, or any group of people, can expect to read all the bug traffic.
-21:29 < kingtaco|work> I bet jakub does
-21:29 <@dberkholz> i will change the proposal to just cover gentoo-dev stuff, make a few other refinements, and post to the -council list again
-21:30 <@dberkholz> since it seems like people generally like that idea
-21:30 <@lu_zero> =)
-21:30 < NeddySeagoon> dberkholz, #gentoo-dev is not controllable while everyone has ops
-21:30 < kingtaco|work> wrong
-21:31 < kingtaco|work> devrel has the ability to perm remove ops
-21:31 <@dberkholz> guess they'll have to get deopped temporarily, then
-21:31 < NeddySeagoon> kingtaco|work, true butthat takes days
-21:31 < kingtaco|work> the peons can deop each other all they want, devrel has the ability to do it and make it stick
-21:31 < kingtaco|work> NeddySeagoon, something to take up with them I suppose
-21:32 < kingtaco|work> there seems to be a lot of things in devrel that people want to go faster
-21:32 <@jokey> from what we heard on freenode, they have some admin user for the channel and a handful of people know the password to it
-21:32 <@jokey> maybe we can do the same
-21:32 < kingtaco|work> not needed
-21:32 <@dberkholz> anyone with a high enough chanserv access level can change anyone lower's levels
-21:32 <@jokey> they being ubuntu and freebsd
-21:32 < kingtaco|work> a person needs access level of 30
-21:33 < kingtaco|work> to control #-dev
-21:33 < kingtaco|work> and 40 to control those who control #-dev
-21:33 <@dberkholz> and infinity to control the universe! bwahahaha
-21:33 < NeddySeagoon> kingtaco|work, there are two different sorts of coc enforement. An instant cooling off period and longer term for repeat offenders. How do you do the instant cooling off in #gentoo-dev
-21:34 < kingtaco|work> NeddySeagoon, I don't have the answer, just telling you what's possible with the current setup
-21:34 <@jokey> that brings up the question... who enforces CoC?
-21:34 <@Flameeyes> dberkholz, I think the level is capped at 99 when you insert the master password ;)
-21:34 <@dberkholz> the moderators of whatever location
-21:34 < NeddySeagoon> kingtaco|work, I don't have the answer but being a proctor taught me some of the questions
-21:35 -!- ryker [n=none@a01-03c-084.calumet.purdue.edu] has quit []
-21:35 <@dberkholz> you could just ban folks for a while, have to remember to unban later though.
-21:36 <@Flameeyes> people with op can auto-unban themselves
-21:36 <@dberkholz> yes, you'd clearly have to change the levels
-21:36 < jmbsvicetto> dberkholz: on #-dev with the current setup, you'll have to give moderators an access level of 30
-21:36 <@dberkholz> i guess i'd prefer to just -op -voice and let people idle in there, so they don't miss anything
-21:36 <@Flameeyes> dberkholz, quietban
-21:36 <@dberkholz> as opposed to actually banning
-21:37 <@jokey> mode +q afaik
-21:37 <@dberkholz> Flameeyes: sure, bout the same effect in #-dev
-21:37 < kingtaco|work> except the friend of the banned will unban/unmute/whatever, prompting that person to be banned/muted, prompting another person .........
-21:37 <@dberkholz> yep, won't it be fun?
-21:37 < kingtaco|work> it's never one person against the world
-21:37 < kingtaco|work> yes
-21:38 < kingtaco|work> that's why it's ineffective
-21:38 <@dberkholz> that's a bit of a stretch
-21:38 < kingtaco|work> to the point that it's actually negative IMO
-21:38 <@Flameeyes> let's all devs have voice and not op? still allowing them to give voice to others upon request?
-21:38 <@dberkholz> that's just about lack of respect for the council and CoC, if people do that
-21:38 < kingtaco|work> instead of one problem person, you now have the group that sided with said person as the problem
-21:38 <@dberkholz> and for gentoo as a whole
-21:39 <@Flameeyes> after all the most used op feature in #gentoo-dev is giving voice to contributors
-21:39 < NeddySeagoon> kingtaco|work, I think you have to take ops away from everyone except the chan managers and coc enforcers
-21:39 < kingtaco|work> well, I assert that there isn't much respect for council, CoC or gentoo around here
-21:39 < Philantrop> Do we really have such big of a problem in #-dev that we need to make such a fuss about it? :)
-21:39 <@dberkholz> if a whole group of people chooses to get modded, who cares
-21:39 <@dberkholz> good for them
-21:40 < NeddySeagoon> Philantrop, there is a perceived need for coc enforcement
-21:40 <@dberkholz> that doesn't mean we should just let things be a free-for-all with no community standards
-21:40 < kingtaco|work> not suggesting that
-21:40 < kingtaco|work> I'm suggesting the proposed solution to the perceived problem is actually more negative that the problem due to the snowball effect
-21:41 <@dberkholz> i'm suggesting that your suggestion is not a problem if people know in advance what will happen =)
-21:42 < kingtaco|work> I respectfully disagree
-21:42 < kingtaco|work> but I've made my point :)
-21:43 <@dberkholz> and if this snowball effect you suggest, does happen, i also suggest that it's not a bad thing to mod everyone involved because it makes a point
-21:43 <@dberkholz> multiple people breaking a rule don't get away with it any more than just one
-21:43 < NeddySeagoon> dberkholz, until you get modded
-21:43 <@dberkholz> i do occasionally do other things besides sit in front of the computer =)
-21:44 < kingtaco|work> I recommend you find a solution that minimizes the potential for the snowball effect
-21:44 < kingtaco|work> if it happens so be it
-21:44 < NeddySeagoon> I was meaning in the process of quieting an unruly group
-21:44 <@dberkholz> but if i do something wrong, i don't expect to get away with it any more than anyone else
-21:45 < NeddySeagoon> if you don't change the access list, /cycle will give users there privs back
-21:46 <@lu_zero> hm
-21:46 < NeddySeagoon> anyway, we will not get an nswer here
-21:46 <@dberkholz> ok. does anyone have any new points to make about this?
-21:46 <@dberkholz> emphasis on new
-21:47 < kingtaco|work> not I
-21:48 <@dberkholz> ok
-21:49 <@dberkholz> in closing, i'll post an updated draft to the -council list for discussion
-21:49 <@dberkholz> seems like we're getting somewhere by narrowing the scope a bit
-21:49 < jmbsvicetto> I would just recall that in the case of the mls you need to make sure the tools exist before you ask anyone to moderate them
-21:49 < NeddySeagoon> dberkholz, the scope is not narrowed - the coc is enforced in other areas by existing groups
-21:49 < kingtaco|work> infra hasn't removed any of the tools
-21:50 < kingtaco|work> that said, we'll probably be pretty latent in making new ones, so I suggest you really try to use what's existing
-21:50 <@dberkholz> NeddySeagoon: the scope of the changes, anyhow. the other areas were already happening
-21:50 < NeddySeagoon> jmbsvicetto, they do but nobody gets gentoo-dev ml messages sent for moderation
-21:51 <@dberkholz> ok, let's wrap this topic up and move to the open floow
-21:51 <@dberkholz> floor, too
-21:51 <@jokey> ack
-21:51 <@dberkholz> Philantrop had one particular issue to raise
-21:52 <@dberkholz> which PMS is authoritative?
-21:52 < kingtaco|work> how is there any question to that?
-21:52 < Philantrop> Personally, I'd prefer the one that is actually being worked on - regardless of where it's hosted. :-)
-21:53 <@dberkholz> kingtaco|work: well, there's one that's actually been getting changes, and one that hasn't
-21:53 < Philantrop> kingtaco|work: The one on our infrastructure doesn't even have EAPI1 docs.
-21:53 <@dberkholz> you mentioned something about the pms repo earlier, so maybe you have a clue what's going on
-21:53 < kingtaco|work> I don't have the details, but here's the general gist
-21:54 < kingtaco|work> we're going to treat PMS the same as ubers baselayout repo
-21:54 <@jokey> except that ours is not being worked on but the external hosted one is
-21:54 < kingtaco|work> in the past, the only hold up on moving PMS to gentoo is there were a couple external contributers that were offended by the thought of having to pass their commits through a dev
-21:55 < kingtaco|work> this removes that
-21:55 < kingtaco|work> as for which one gentoo follows, it's kind of foolish that we would follow an external spec for something that gentoo created
-21:55 < Philantrop> kingtaco|work: I apologize if I ask something that has been covered but how do we treat Uber's repo? :)
-21:56 < kingtaco|work> regardless of what external projects do
-21:56 < kingtaco|work> Philantrop, via git
-21:56 < Philantrop> kingtaco|work: Ah, so we pull regularly?
-21:56 < kingtaco|work> I don't know the git specific terms, but the repo is hosted by gentoo
-21:56 < Philantrop> kingtaco|work: Yes, that's the status quo. :)
-21:57 <@dberkholz> well, it seems more like uber etc will be able to push to our repo, actually
-21:57 <@dberkholz> we're going to be able to allow pushes by external contributors
-21:57 < kingtaco|work> we don't replicate someone elses repo, we're hosting it
-21:57 <@jokey> once we get the new overlays box in place
-21:57 <@dberkholz> kingtaco|work: fyi, a pull would mean we had a designated person merging in external changes from other repos
-21:58 < kingtaco|work> dberkholz, ok, it's certainly not that
-21:58 < Philantrop> kingtaco|work: a) That's semantics. b) The "external contributors" you're probably referring to don't want to push to our repository.
-21:59 < kingtaco|work> Philantrop, I only know of one person who had the problem, and frankly, his problems are his own
-21:59 < kingtaco|work> gentoo does not need to bend itself to accomodate him
-22:00 < kingtaco|work> as far as I care, any perceived responsibility ends when we make the service available for him to use
-22:00 < kingtaco|work> we certainly can't force him to use it
-22:00 < Philantrop> kingtaco|work: I agree with the latter. Nevertheless, from what I was told by several people he's not the only one. And we, as in Gentoo, don't seem to work on PMS currently.
-22:01 < kingtaco|work> I don't doubt there are others, but I can't address them if I don't know what the specific issue is
-22:01 <@jokey> main issue is, only the guy who did the initial svn conversion can continue syncing up
-22:01 < kingtaco|work> and again, gentoo is not held hostage by external contributers
-22:03 <@jokey> right
-22:03 < Philantrop> kingtaco|work: No, but there's a current, functional SVN repository and an outdated one on our infrastructure. There's no actual work on our repository. There is on "their's". Will it kill us to choose theirs? :-)
-22:03 < kingtaco|work> Philantrop, yes it would
-22:03 < kingtaco|work> it's very clear, gentoo sets it's own standards
-22:04 < Philantrop> kingtaco|work: Ah, I see. It will kill ego's. :-)
-22:04 < kingtaco|work> we can't prevent others from trying to set or influence them, but at the end of the day gentoo is only responsible to itself
-22:04 < kingtaco|work> ugh, I'm done
-22:04 < Philantrop> kingtaco|work: Same here.
-22:05 <@dberkholz> Philantrop: it's not really about egos as much as control over the specification of our own package format
-22:05 <@vapier> we already had this discussion
-22:05 <@dberkholz> it's fun to do it every week though, don't you think?
-22:06 < kingtaco|work> it's a waste of time
-22:06 < Philantrop> dberkholz: I absolutely agree in general. But we don't even have an official documentation for EAPI1.
-22:06 < kingtaco|work> gentoo has gone more than half way to accomodate external people
-22:06 < kingtaco|work> screw them if they still don't want to play nice
-22:06 <@dberkholz> alright, we're not making any progress here
-22:06 < kingtaco|work> I'll have none of it
-22:06 <@dberkholz> so you guys can continue the discussion after the meeting if you want
-22:06  * Philantrop considers the place where the actual *work* takes place as authoritative until something significant happens in our repo.
-22:06 <@dberkholz> any other topics for the open floor?
-22:07 <@lu_zero> I guess not
-22:08 <@dberkholz> ok, meeting's over. thanks for playing.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080110-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080110-summary.txt
deleted file mode 100644
index 097bb5808b..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080110-summary.txt
+++ /dev/null
@@ -1,119 +0,0 @@
-Roll call
----------
-
-(here, proxy [by whom] or slacker?)
-
-amne        here
-betelgeuse  here
-dberkholz   proxy [musikc]
-flameeyes   here
-lu_zero     here 
-vapier      here
-jokey       here 
-
-Agenda
-------
-
-GLEP 54: scm package version suffix
-	http://www.gentoo.org/proj/en/glep/glep-0054.html
-
-GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
-	http://www.gentoo.org/proj/en/glep/glep-0055.html
-
-Code of Conduct enforcement 
-	http://thread.gmane.org/gmane.linux.gentoo.council/82
-	http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt
-	http://www.gentoo.org/proj/en/council/meeting-logs/20071213-summary.txt
-
-	- What needs to happen for us to make a decision?
-
-	Last week, we agreed to just add moderators to #gentoo-dev and the
-	gentoo-dev list. Other places with their own moderation should enforce the
-	CoC themselves. We also agreed that moderation must be handed over to devrel
-	or userrel after 2 days.
-
-	Ferris asked some questions:
-		1)  Do we have an implementation schedule? ;
-		2)  Have we identified some warm bodies for it?;
-		3)  Most devrel requests seem really to relate to CoC violations.  Would
-		you like us to bounce those to the CoC people, process them using CoC
-		rules, or keep doing what we are doing now (generally, close them with a
-		note explaining why or mediate them)?  (I'm talking about the "He's
-		being rude/sarcastic/disrespectful" sorts of things which really need to
-		be processed immediately and merit a warning or brief suspension if
-		anything.)
-
-Slacker arches
-	See Caleb's post on -dev and subsequent thread
-	Calebs post:
-	  http://article.gmane.org/gmane.linux.gentoo.devel/53933
-	Kumba's comment on mips status:
-	  http://article.gmane.org/gmane.linux.gentoo.devel/54168
-        Rich0's proposal:
-	  http://article.gmane.org/gmane.linux.gentoo.devel/54103
-
-
-Document of being an active developer
-        Araujo raised that he needs some kind of written document of being an
-	active developer. Argument being that mentioning in CV in his
-	environment is only accepted if there is some kind of proof.
-	Our trustee grant deferred it back to council+infra as Foundation only
-	handles IP, but suggested it could be some kind of generated document.
-
-
-=======================================================================
-
-GLEP 54 : Postponed to -dev ML
--------
-        Comment from portage maintainer:
-	- no statement about compatibility/implementation plans
-	- more subjective:
-	  - while a distinction between CPV and atom may not be technically
-	    required, I might be useful to have
-	  - (minor) if the version part is optionl there could be some
-	    complications
-
-	So is this something we'd like to have?
-
-        Other ideas that came up during discussion:
-        - -scm or _scm ?
-	- handling as (-|_pre)9999) versions per definition
-	- implement as dynamic package sets
-
-        Related bugs:
-	- bug #9202 - Better support for CVS Ebuilds...
-
-	Pushed back to -dev ML as there are too many unresolved questions at
-	the moment. peper is given the task to repost it and expand on
-	usefulness / use cases as well as compatibility issues.
-
-GLEP 55 : Postponed to -dev ML
--------
-        - Agreement on eapi subdirectories are not feasible
-
-	Ideas during discussion:
-	- moving from EAPI= to eapi function and using repository bashrc for
-	  compatibility
-
-	Pushed back to -dev ML as there are too many unresolved questions at
-	the moment.
-
-Slacker arches
---------------
-        vapier will work on rich0's suggestion and repost it for discussion on
-	-dev ML
-
-Code of Conduct enforcement : 
----------------------------
-        Council members agreed on the direction, dberkholz will provide
-	additional details on -council ML
-
-Document of being an active developer
--------------------------------------
-        Suggested options:
-	 - Log in to dev.g.o and automatically generate there signed by
-	   infra-maintained key, put userinfo.xml website in the doc as
-	   reference.
-	 
-	 dberkholz and araujo will look into a scribus based template.
-	 devrel will have to generate a signing key for these purposes.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080110.txt b/xml/htdocs/proj/en/council/meeting-logs/20080110.txt
deleted file mode 100644
index e154ba9868..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080110.txt
+++ /dev/null
@@ -1,1038 +0,0 @@
-# Log started, 10.01.2008 21:00 CET
-
-[21:01:22] jokey gives betelgeuse another 3 minutes
-[21:02:08] <fmccor> He's active in !c#gentoo-devrel
-[21:04:06] <@jokey> well ok, let's start, roll-call 
-[21:04:12] <@lu_zero> ok
-[21:04:25] welp [n=welp@!hgentoo/developer/colchester-lug.member.welp] has joined !c#gentoo-council
-[21:04:47] <@jokey> amne: ?
-[21:05:28] Betelgeuse [n=betelgeu@!hgentoo/developer/Betelgeuse] has joined !c#gentoo-council
-[21:05:28] ChanServ [ChanServ@!hservices.] has set mode +o Betelgeuse
-[21:05:42] <@jokey> Hi Betelgeuse
-[21:05:49] <@amne> oi
-[21:05:49] <@jokey> we're just about to start ;)
-[21:05:53] <@Betelgeuse> hmm a couple minutes late
-[21:06:09] <+musikc> <----  dberkholz's proxy
-[21:06:50] <@lu_zero> who's missing?
-[21:07:00] <@jokey> all alive :)
-[21:07:22] <@jokey> so, !c#1 is GLEP 54: scm package version suffix
-[21:07:33] <@vapier> discussion, not voting
-[21:07:51] <@lu_zero> who is going to start?
-[21:07:58] ferdy [n=ferdy@!hgentoo/developer/ferdy] has joined !c#gentoo-council
-[21:08:17] <@jokey> first of all, everyone read it, right?
-[21:08:30] <@vapier> i dont think roll-call finished ;)
-[21:08:49] <@vapier> FlameBook = ?
-[21:09:02] <welp> Flameeyes
-[21:09:07] <@FlameBook> vapier, I'm here, I'd just be lesser profile than usual (because of a cold0
-[21:09:12] <welp> oh
-[21:09:24] welp thought vapier didn't know who FlameBook was
-[21:10:36] <@Betelgeuse> Well the GLEP is not in a hurry as it needss a new Portage version.
-[21:10:40] <genone> if I may say somehing about it
-[21:10:50] <@jokey> sure genone
-[21:11:15] <@vapier> input from genone / zmedico / friends surely welcome
-[21:12:44] <genone> I have three issues with it: 1) no statement about compability/implementation plans 2) while a distinction between CPV and atom may not be techincally required, I still think it's useful to have 3) (minor) if the version part is optionl there could be some complications
-[21:13:26] <genone> 1) is somewhat related to glep55, but also an issue if that would be accepted
-[21:14:09] <genone> 3) is mostly my dislike for special cases required by the glep
-[21:14:41] <@lu_zero> hmm
-[21:14:51] <genone> (haven't brought those up on the ML as they would just have resulted in other endless threads)
-[21:16:46] <@jokey> I'm with genone on 1) at least
-[21:17:00] <peper> genone: pkg-1a PN-PV or PN?
-[21:17:21] <genone> peper: former
-[21:17:50] <@vapier> anyone know the bug !c# for the original request for a "cvs" version string ?
-[21:17:57] <@lu_zero> hmm btw in what it differs than the -cvs?
-[21:18:11] <peper> genone: why?
-[21:18:13] <@jokey> backwards compatibility is certainly important as people may start with 2007.0 stages and then face that problem as a sidenote
-[21:18:20] <peper> genone: pkg-1a is a valid package name
-[21:19:24] <@Betelgeuse> Well IMHO we should first decide whether we think the idea itself is something we want to have.
-[21:19:42] <@Betelgeuse> If we are against the idea then there is no point in disgussing the technical details.
-[21:19:42] <igli> it's also a valid PF
-[21:20:02] <genone> vapier: http://bugs.gentoo.org/show_bug.cgi?id=9202
-[21:20:16] <peper> igli: that's the point
-[21:20:33] <@vapier> Betelgeuse: i think the concept has been long outstanding
-[21:20:41] <@amne> Betelgeuse: also define what the idea is. i) having some support for SCM ebuilds (good idea imho) ii) doing it via changing the naming scheme
-[21:21:00] <@vapier> i started using -9999 because Bug 9202 was outstanding
-[21:21:05] <jeeves> vapier: https://bugs.gentoo.org/9202 enh, P2, x86, sbc28@cornell.edu->dev-portage@gentoo.org, RESOLVED, DUPLICATE, Better support for CVS Ebuilds...
-[21:21:15] <@jokey> amne: idea behind is obvious imho
-[21:21:21] <@lu_zero> vapier still I see some problems in the idea of usage
-[21:21:34] <@vapier> i'm trying to see why "-scm" (which would require quite a bit of changes everywhere) is better than "_scm" (which would be trivial to drop in everywhere)
-[21:22:02] <@lu_zero> since -9999 ebuild should stay p.masked
-[21:22:02] <peper> b/c scm is different than other suffixes we have
-[21:22:22] <igli> peper: so as a random string it matches PF regex; hence it's parsed as PF with no context. what's your point?
-[21:22:36] <@amne> http://bugs.gentoo.org/show_bug.cgi?id=9202
-[21:22:38] <@amne> oops
-[21:22:46] <@amne> sorry, copy and paste error
-[21:22:59] <@FlameBook> vapier, I sincerely find myself comfortable with -9999 and x.y.9999 versioning too, needing no extra support...
-[21:23:06] <@jokey> peper: I don't agree that it's any different from CPV pov
-[21:23:43] <@jokey> FlameBook: the idea is to follow _pre versions and just make it scm aware (so you get the next stable release without any major work)
-[21:24:01] <genone> to make it clear: I don't have a problem with the idea itself (portage already has a similar, though unused extension), I'm just not completely comfortable with the details
-[21:24:17] <@FlameBook> jokey, see amarok: 1.4.9999 will follow any 1.4.9_preXXXXX version
-[21:24:27] <peper> igli: I think you are confused...
-[21:24:53] <igli> *plunk* not any more
-[21:24:57] <@FlameBook> 2.9999 will build the amarok-2 branch as soon as it's in a state that users might want to look at :P
-[21:24:59] <genone> peper: just tested, foo-1a isn't a valid package name
-[21:25:15] <@jokey> FlameBook: but when 2.0 comes out then, you won't notice it
-[21:25:22] <peper> how did you test that?
-[21:25:44] <@FlameBook> jokey, hm? if one is using live svn it shouldn't notice if a new version comes up, no?
-[21:25:50] <genone> created a matching ebuild and called emerge with it as argument
-[21:26:00] <@lu_zero> FlameBook another issue about usage
-[21:26:08] <@lu_zero> something not covered by this glep
-[21:26:11] <peper> well, portage accepts '*' as a pkgname, is it valid then?
-[21:26:33] <genone> peper: huh?
-[21:26:46] FlameBook just can't find any good reason at the moment for switching from -9999/.9999 to something different
-[21:27:25] <peper> 9999 is a dirty hack, for one
-[21:27:34] <genone> FlameBook: there are some _potential_ benefits outside ordering, like implicit masking
-[21:27:43] rbrown [n=rbrown@!hgentoo/developer/paludis.rbrown] has joined !c#gentoo-council
-[21:27:45] <genone> or grouping
-[21:28:06] <@jokey> plus having scm functions available from pkg manager
-[21:28:14] <@jokey> so the eclass hacks can disappear
-[21:28:27] <@lu_zero> jokey eclass hacks got just moved
-[21:28:29] <@lu_zero> at best
-[21:28:34] <@vapier> genone: your opinion on -scm vs _scm ?
-[21:28:55] Pesa [n=Pesa@!halpha.tat.physik.uni-tuebingen.de] has joined !c#gentoo-council
-[21:29:39] <@FlameBook> genone, I find explicit masking better, actually
-[21:29:45] <genone> vapier: if it's used for more than ordering (likely), -scm seems better to me
-[21:30:56] <genone> FlameBook: everyone has his preferences ;)
-[21:31:29] <@FlameBook> jokey, so you'd have to have a package manager to support all kind of scm? cvs, svn, bzr, git, hg, darcs?
-[21:31:30] <@lu_zero> I find implicit masking wrong
-[21:31:47] <@lu_zero> you forgot monotone and perforce
-[21:31:53] <@FlameBook> what about dependencies? would the ebuild have to depend on the correct client package?
-[21:31:55] <@vapier> monotone is irrelevant
-[21:32:03] <@lu_zero> vapier pidgin
-[21:32:06] <genone> lu_zero: was just an idea what could be done with a special tag
-[21:32:09] <@lu_zero> sadly
-[21:32:18] <@jokey> FlameBook: yep, given that including layman is something feasible, it would be needed eitherway, you can avoid code duplication
-[21:32:22] <@vapier> still irrelevant, mt is terrible
-[21:32:34] <@FlameBook> because if the ebuild have to do that by hand... then it would be quite a mess imho
-[21:32:35] <@lu_zero> vapier I know
-[21:32:38] hydrogen [n=hydrogen@!hc-75-68-137-232.hsd1.nh.comcast.net] has joined !c#gentoo-council
-[21:32:49] <@FlameBook> having part of the code laying on the package manager side and partly on the ebuild/eclasses
-[21:33:08] <@vapier> can we envision any other possible uses ?  extending the version syntax isnt trivial, so doing it one off for scm's when it isnt usable by anything else ...
-[21:34:08] <@jokey> I don't see something else than scm atm
-[21:34:14] <igli> which these benefits are not available with existing -cvs[0-9]* ?
-[21:34:17] <igli> of^
-[21:34:34] <@Betelgeuse> periodic reinstall but that could probably be done with 9999 too
-[21:35:06] <igli> ty
-[21:35:27] <@vapier> except for the projects that actually use 9999 in their version ;)
-[21:35:45] <@Betelgeuse> vapier: yeah
-[21:35:48] <@FlameBook> Betelgeuse, as far as I can understand it, if you have package set you can easily take care of periodic reinstall without having to add extra support to the package manager
-[21:35:59] <@jokey> well if we agree on using that version(part) for live ebuilds, even that can be done
-[21:36:17] <+musikc> fwiw, this proxy's stance on the topic is neutral
-[21:36:20] p-y [n=p-y@!hgentoo/developer/p-y] has joined !c#gentoo-council
-[21:36:46] <genone> FlameBook: the nice thing would be that we could create a dyamic package set containing all -scm installs, rather than each user having to maintain a static list
-[21:37:07] <@FlameBook> genone, and that can't be achieved in any other way?
-[21:37:42] <peper> what's the scm version of pkg which currently has version '20060621' in your 999 syntax?
-[21:37:43] <@FlameBook> what about a possible AUTO_PACKAGE_SETS variable in ebuilds? (so one could also have a "xorg-drivers" dynamic package set, or a "gstreamer-plugins" package set, ...)
-[21:37:45] <genone> FlameBook: well, we'd somehow have to identify such installs, the version tag is an easy and reliable way, but not the only one
-[21:38:40] <genone> well, package sets as implemented in portage are extremely flexible, just need the data
-[21:38:47] <@lu_zero> <peper> what's the scm version of pkg which currently has version '20060621'
-[21:38:47] <@lu_zero>           in your 999 syntax?
-[21:38:59] <@lu_zero> what do you mean?
-[21:39:03] <@vapier> FlameBook: pretty much everything could be done if we codified the meaning of "9999", but arbitrarily reserving a number is wrong and can lead to false positives
-[21:39:09] <peper> I mean that 9999 is a hack
-[21:39:14] <peper> which need to die
-[21:39:16] <@vapier> sticking scm in there conversely leads to no false positives
-[21:39:17] <@FlameBook> 99999999 probably, looks nasty, but works
-[21:39:42] <@Betelgeuse> vapier: yeah
-[21:39:43] <@FlameBook> peper, might be an hack, but I don't see any good reason to change the versioning spec just to kill off that hack
-[21:39:43] <peper> so you match any number of nines as scm?
-[21:39:54] <peper> or just between 4 and 8?
-[21:40:14] windzor [n=windzor@!h84.238.69.216] has joined !c#gentoo-council
-[21:40:20] <@FlameBook> vapier, I meant declaring inside the ebuild that the package has to be added to the scm dynamic set
-[21:40:42] <@FlameBook> peper, I don't see any reason _why_ there should be a way to identify the scm packages from an automatic perspective at the moment
-[21:41:01] <@FlameBook> ordering, I find 9999 still working decently, automatic package sets, there are other solutions
-[21:41:25] <@FlameBook> as for different scm software, it would be _quite_ a mess to support every and all scm systems from a package manager..
-[21:41:28] <@lu_zero> I still don't see why live ebuilds should be expanded since it has such limited usage
-[21:41:36] <@lu_zero> and the usage should remain as is
-[21:41:36] Zephyrus [n=emanuele@!h81-174-11-81.static.ngi.it] has joined !c#gentoo-council
-[21:42:48] jakub notes that -scm is much more likely to match something existant than -9999 and moves on...
-[21:43:26] <peper> FlameBook: support every scm system? what?
-[21:43:33] DrEeevil [i=dreeevil@!hgentoo/user/bonsaikitten] has joined !c#gentoo-council
-[21:43:42] <jakub> IOW, foo-scm is $PN-$PV or $PN?
-[21:43:49] <peper> there are eclasses for that
-[21:43:52] <@FlameBook> maybe give a complete list of all the things you can have implemented by transitioning to -scm, indicating which ones can't be achieved in any other way.. then I might find something that makes me think that changing the versioning spec is worth the play
-[21:44:00] <@FlameBook> peper, so okay not even eclasses cease to exists, as jokey hoped
-[21:44:23] <@FlameBook> which comes back to my previous point: what can -scm do that we can't do already or in a different way that does not require changing the version spec?
-[21:44:43] <peper> why are you so concerned about changing the version spec?
-[21:44:50] <ferdy> false positives and not looking like a hack
-[21:44:57] <TFKyle> jakub: think $PN-$PV is the intent
-[21:44:58] <peper> we can clean up the mess
-[21:44:59] <@FlameBook> ferdy, false positive doing what?
-[21:45:04] <@FlameBook> which mess?
-[21:45:04] <ferdy> 999999999
-[21:45:16] <@FlameBook> ferdy, that's a false positive of what?
-[21:45:42] <@vapier> peper: because it breaks everything, takes a while to adjust, and is not reversible
-[21:45:49] <jakub> TFKyle: and, how are you going to ensure that? (well sorry for the noise here)
-[21:45:54] <ferdy> fine, avoid POTENTIAL false positives
-[21:46:05] <@vapier> changing the version spec is not trivial and should never be taken lightly
-[21:46:07] <@FlameBook> ferdy, potential false positive doing _what_, that's what I'm asking for a while now
-[21:46:30] <@lu_zero> avoid non existent, unlikely false positive, that could lead to unmentioned results
-[21:46:31] <ferdy> making the package manager know it is dealing with a 'live' package
-[21:46:39] <@lu_zero> ferdy undefined
-[21:46:41] <@FlameBook> as vapier said, it's not something to take lightly, so if it's just for the sake to look "nicer", I wouldn't like that
-[21:46:49] <ferdy> lu_zero: what's undefined?
-[21:46:55] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: Excess Flood
-[21:46:55] <@FlameBook> ferdy, and why should the package know that?
-[21:47:00] <@lu_zero> what is the suggested behaviour
-[21:47:05] <@FlameBook> the best thing that came up till now is genone's dynamic package set
-[21:47:19] <peper> actually, it's pretty easy together with GLEP 55
-[21:47:21] <ferdy> FlameBook: to allow other stuff like 'only build if there are changes in the underlying repo'
-[21:47:22] <@FlameBook> which as I said can be implemented in a different way, and become an even more interesting idea per-se
-[21:47:42] <@lu_zero> ferdy how you plan to implement that?
-[21:47:44] <@FlameBook> ferdy, how can the package manager know about changes in underlying repository if the fetching is done by an eclass?
-[21:47:51] <jakub> ferdy: you can detect repo changes via SCM tools... not via p.manager
-[21:47:53] lukass [n=lukas@!h153.29.227.87.static.kba.siw.siwnet.net] has joined !c#gentoo-council
-[21:47:57] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
-[21:48:00] <@FlameBook> should it tar everything up and run an md5?
-[21:48:15] <ferdy> no, you can ask eclasses to comply to some 'protocol' like "return blah from function bleh if there are no changes"
-[21:48:26] <ferdy> that'd be the first hack that comes to mind
-[21:48:26] <@lu_zero> ferdy the glep fails to deliver those details
-[21:48:27] <eroyf> haha.
-[21:48:34] <@FlameBook> what lu_zero just said
-[21:48:41] <@FlameBook> ferdy, oh so we exchange an hack for an hack?
-[21:48:45] <@lu_zero> and you stressed already that the main point is avoid hacks
-[21:48:57] <ferdy> who said we should implement that hack ?
-[21:49:12] <@lu_zero> ferdy what's written in the glep-54?
-[21:49:14] <ferdy> and no, the GLEP shouldn't address this kind of stuff
-[21:49:27] <@FlameBook> okay so the idea of just rebuilding stuff if repository has changed can't be implemented
-[21:49:34] jakub finds using $scm native tool a _lot_ more reliable for detecting when something should be re-compiled than some -scm or whatnot suffix
-[21:49:46] <@FlameBook> we're back to the only interesting thing being genone's dynamic package sets
-[21:50:13] <@lu_zero> that can be implemented in quite a range of different ways
-[21:50:38] <@FlameBook> lu_zero, I would like having that with a variable inside the ebuild
-[21:50:49] <@FlameBook> so that we could have dynamic sets for plugin packages
-[21:50:53] jensp [n=jens@!hunaffiliated/jensp] has joined !c#gentoo-council
-[21:51:05] <@jokey> but even with dynamic sets, portage needs to have a safe skip package option then
-[21:51:08] <@FlameBook> if we still had xmms in the tree, it would be nice to have a dynamic "xmms-plugins" package set )
-[21:51:09] <@FlameBook> :)
-[21:51:14] <@jokey> if there are no changes, go on
-[21:51:36] <@FlameBook> jokey, which can't be implemented with the scm fetching implemented in eclass
-[21:51:45] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Read error: 104 (Connection reset by peer)
-[21:51:46] <@lu_zero> still all those discussions are missing my original question
-[21:51:48] <@FlameBook> and again brings us up to something different from what peper proposed till now
-[21:52:04] rangerpb [n=baude@!hgentoo/developer/rangerpb] has joined !c#gentoo-council
-[21:52:07] <@lu_zero> is it really worth the required effort?
-[21:52:08] <ferdy> FlameBook: it certainly can, see functions can 'return' values to the PM
-[21:52:12] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
-[21:52:19] <@FlameBook> ferdy, you said it was an hack though
-[21:52:36] <ferdy> no, I didn't
-[21:53:01] <@FlameBook> and it would mean accepting a change to versioning specs on the basis that it could be possible implementing a feature in the package manager which hasn't been specified at all up to now..
-[21:53:12] <@FlameBook> I'd like to see that (maybe make it a different glep) before going on with accepting this glep as it is
-[21:53:47] <ferdy> it would mean accepting a change that would make the package manager know that a certain ebuild is a live ebuild
-[21:54:09] <@FlameBook> so it would be fine if we accepted a change that makes the package manager know that a certain ebuild is an xmms plugin, too?
-[21:54:16] <@FlameBook> at the moment I find the same usefulness between the two
-[21:54:22] <@jokey> let's abstract it a bit, it would mean there are special options the package manager can provide
-[21:54:24] <@lu_zero> next to 0?
-[21:54:25] <@FlameBook> as nothing specifies what the package manager has to do differently for an scm ebuild
-[21:54:44] <ferdy> heh, trying to make those things look similar is like pretending the people here are idiots
-[21:54:58] ulm [n=ulm@!hgentoo/developer/ulm] has joined !c#gentoo-council
-[21:54:59] <@jokey> brings us back to the original question anme asked.. "do we want this"? or maybe even do we need it?
-[21:54:59] <@lu_zero> they aren't?
-[21:55:20] <@FlameBook> and without knowing what the package manager can do differently for a scm ebuild, I find that the current proposal would mean accepting a change that has no practical value
-[21:55:48] <jakub> ferdy: on that note... mythtv-* ebuilds... are those 'live' or not?
-[21:55:48] <@FlameBook> jokey, as it stands, no I don't, I'd be happy to think again about this if we can get more information on why should we need this
-[21:55:50] <genone> maybe the discussions is a bit too limited by the "scm" part, could be extended to allow tags in general
-[21:56:13] <@FlameBook> genone, couldn't the tag be expressed by variables inside the ebuild?
-[21:56:19] <ferdy> jakub: don't know a tad about those... do I have to look at them or is it a rethoric question?
-[21:56:29] gentoofan23 [n=gentoofa@!hgentoo/contributor/gentoofan23] has joined !c#gentoo-council
-[21:56:33] <@FlameBook> [without breaking versioning spec]
-[21:56:34] <genone> FlameBook: yes, but those are quite a bit harder to access
-[21:56:35] <jakub> ferdy: fetches a fixed rev from a repo
-[21:56:41] <ferdy> jakub: no
-[21:57:10] <@FlameBook> genone, but quite a bit simpler to implement, I guess?
-[21:57:11] <@jokey> FlameBook: genone +1 here, having to acces the data is not helpful if you want to provide special functions like weekly or whatever rebuild
-[21:57:25] <peper> breakage of verioning spec is not a problem if we do GLEP 55
-[21:57:38] <@lu_zero> jokey that can be done with cron and custom sets
-[21:57:54] <@FlameBook> jokey, if you create dynamic sets based on tags, you don't need to access the ebuilds by hand, no?
-[21:57:58] <@lu_zero> peper that hasn't been discussed yet
-[21:58:03] <peper> just saying
-[21:58:08] <genone> FlameBook: depends
-[21:58:14] <@FlameBook> just need to keep the dynamic sets' definitions consistent with the installed packages
-[21:58:36] <ferdy> those dynamics sets being something that hasn't been specified, or has it?
-[21:58:39] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Read error: 104 (Connection reset by peer)
-[21:59:00] ferringb [n=ferringb@!hc-24-4-204-103.hsd1.ca.comcast.net] has joined !c#gentoo-council
-[21:59:14] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
-[21:59:18] <@lu_zero> wb genone
-[21:59:33] <@FlameBook> it hasn't, which brings us again to the point that whatever we're going to accept, it should at least provide some useful use cases
-[21:59:48] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Remote closed the connection
-[22:00:20] <peper> emerge --reinstall-scm
-[22:00:30] <ferdy> heh... so "it can be done with dynamic sets" is pure science fiction
-[22:00:48] <jakub> peper: well, _if_ we agree on some convention, the same can be done with -9999
-[22:00:49] <@FlameBook> ferdy, it's no more and no less than what you were saying up to now
-[22:00:59] <@FlameBook> with the difference that I don't have to convince you to accept dynamic sets
-[22:01:11] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
-[22:01:21] <@FlameBook> while, considering I'm not convinced by -scm at the moment, you're the ones that should be convincing me to accept those
-[22:01:23] <ferdy> with the difference that the -scm stuff IS working in a different package manager, so it is not science fiction
-[22:01:43] <@FlameBook> [or just decide that you don't want to convince me, and then stop the discussion right here, with my vote being "no"]
-[22:02:13] <@lu_zero> ferdy -9999 is working fine with about 2 or 3
-[22:02:15] <@FlameBook> ferdy, is working to do what? I asked that already, if you don't intend to answer that, then I suppose I can simply state my vote here to be "no" and move over
-[22:02:17] <jakub> ferdy: well, passing qlist -CIv 9999 output works exactly the same w/ portage
-[22:02:18] <@lu_zero> so it's pointless
-[22:02:50] <peper> jakub: why not 99999?
-[22:03:06] <ferdy> FlameBook: periodic reinstalling done right, I thought it had been said already
-[22:03:31] <@jokey> peper: as stated in the glep, 9999 has become common sense
-[22:03:31] <@lu_zero> ferdy cron and fixed sets works as should already
-[22:03:35] <ferdy> also... you feel yourself very important... I'm not trying to convince *YOU*, I'm trying to get my facts straight, no need to convince anyone...
-[22:03:44] <ferdy> lu_zero: no it doesnt, read up why
-[22:04:11] <peper> jokey: there are packages with versions like YYYYMMDD, so rather a common hack
-[22:04:12] <ferdy> that doesn't handle a package that has several different scm 'versions' as git does
-[22:04:20] <jakub> peper: as said... just agree on some convention (plus, 9999 doesn't require extensive changes everywhere as already noted)
-[22:04:32] <@vapier> would i venture to say this needs to move back to the mailing list
-[22:04:52] <@vapier> well, i did venture
-[22:04:56] <@vapier> would i be correct in ...
-[22:05:03] <ferdy> jakub: doesn't work, read what I said
-[22:05:21] <jakub> vapier++
-[22:05:26] <peper> jakub: like 15 nines to be sure?
-[22:05:44] <@jokey> vapier: indeed, as there seems to be too many unresolved ideas atm and undiscussed other options
-[22:05:53] <jakub> peper: 9999 doesn't conflict w/ anything I have installed; -scm is much more likely to conflict
-[22:06:05] <@vapier> so, peper, repost the glep, and anyone with issues, post them to the list for responses
-[22:06:14] <@vapier> if you dont post them, then you cant bring them to the table next time :p
-[22:06:15] <ferdy> jakub: again, the 9999 doesn't work, read up why... it is a legit case
-[22:06:25] <peper> vapier: alright
-[22:06:26] <+musikc> vapier: agreed. lots of discussion on this one still.
-[22:06:28] <igli> with existing sol'n, the pm *has* to know it's cvs to order it correctly. iow this is already available as data
-[22:06:33] gentoofan23 [n=gentoofa@!hgentoo/contributor/gentoofan23] has quit IRC: Client Quit
-[22:06:43] <@lu_zero> ferdy quote yourself I couldn't find the line in /lastlog
-[22:06:45] <jakub> ferdy: it worked for me for ages :) well, doesn't belong here really
-[22:06:52] <ferringb> peper: expanding the glep to contain the arg against the existing -cvs version would be useful also, please.
-[22:07:06] jensp [n=jens@!hunaffiliated/jensp] has left !c#gentoo-council
-[22:07:13] <ferdy> jakub: doesn't in the case of git where you need at least two different 'scm' versions
-[22:07:17] <peper> ferringb: does it really need more args than nobody using it?
-[22:07:27] <@lu_zero> ferdy 2?
-[22:07:33] <ferdy> yes, two
-[22:07:33] <@lu_zero> as in?
-[22:07:41] <genone> peper: well, how many people actually know about it?
-[22:07:55] <genone> (but I agree it sucks)
-[22:07:56] <ferringb> peper: yes, imo, since the support ought to still be there (can't say for paludis, but pkgcore and portage still have it last I looked)
-[22:08:05] <ferdy> lu_zero: also, your dynamic set thing doesn't work because those haven't been defined, so, as I said, it is pure science fiction
-[22:08:22] <@lu_zero> ferdy never said dynamic
-[22:08:26] <@lu_zero> CURRENT sets
-[22:08:31] <ferringb> peper: either way, look at it from the angle of documenting the failing of it if you like- expanding the arg for why it must be finally killed off, and -scm replace it would help ;)
-[22:08:39] <@lu_zero> as available in portage and pkgcore
-[22:09:06] <ferdy> lu_zero: 2 as in 'master' and 'next' and every master and next from every release cycle
-[22:09:21] <ferdy> also, vapier said to repost, so this should move to another topic
-[22:09:41] <@jokey> indeed, pushing this back to -dev for discussion
-[22:09:49] <@lu_zero> ferdy I still don't understand what you mean
-[22:09:56] <@lu_zero> anyway next item
-[22:10:04] <@FlameBook> lu_zero, he probably refers to multiple branching
-[22:10:15] <@lu_zero> that isn't 2
-[22:10:20] <jakub> ferdy: once again... -scm or -9999 is _not_ a reliable indication whether you need to recompile something or not..
-[22:10:21] <@FlameBook> [which is what I said before about amarok's 1.4.9999 vs 2.9999]
-[22:10:21] <@lu_zero> is $any
-[22:10:34] <peper> vapier: do you except me to do any changes or just repost as is?
-[22:10:35] <ferdy> jokey: did I say otherwise ?
-[22:10:42] <peper> *expect
-[22:11:07] <ferdy> lu_zero: I said GIT needs at least 2... really, it is much better if you read my sentences instead of skimming over them
-[22:11:19] <@jokey> next topic on agenda would be GLEP 55, can we move on to that?
-[22:11:34] NeddySeagoon [n=NeddySea@!hgentoo/developer/NeddySeagoon] has joined !c#gentoo-council
-[22:11:36] <ferdy> sorry not jokey, jakub.
-[22:11:47] <+musikc> jokey, seems like we should
-[22:12:04] <@jokey> or does anyone want to not push GLEP54 back to dev ML?
-[22:12:13] <peper> do you expect me to do any changes or just repost as is?
-[22:12:26] <@lu_zero> peper add a section about pm behaviour
-[22:12:41] <@lu_zero> and anything else that states its usefulness
-[22:13:14] <peper> ok, move on to 55, I want to see what you think about it first
-[22:13:31] <TFKyle> jakub: that along with update checking would be, though interface-wise you'd probably have to specify something extra to the pm to check scm repos due to hitting the network
-[22:14:25] <@jokey> okay, next topic then... GLEP 55 "This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1)."
-[22:14:50] <armin76> poor jokey :)
-[22:15:09] <genone> as said on the ML, I'm definitely against it silently expanding the scope of EAPI, also a note aboute compability would be nice IMHO. Other than that I don't really like it, but it's probably the best option if we want to avoid sourcing the ebuild to access EAPI
-[22:15:31] <@lu_zero> why sourcing is a problem exactly?
-[22:16:03] <peper> genone: hmm, where is scope of EAPI defined that you are talking about expanding?
-[22:16:05] <ferringb> genone: unless I'm on crack, it still explicitly requires it due to the post source EAPI angle
-[22:16:14] <ferringb> peper: can you confirm that?
-[22:16:33] musikc thinks there should be some visible agreement among package manager developers (portage, pkgcore, and paludis) before we go further or even support it
-[22:16:58] <peper> for backwards compatibility, yes. but pm doesn't source ebuilds with usupported pre-source eapi
-[22:16:59] <@lu_zero> "Let's call the EAPI included in the ebuild filename the pre-source EAPI, and the EAPI set inside the ebuild the post-source EAPI. Given these two, the final EAPI used by the ebuild can be established by following these steps:"
-[22:17:08] <@amne> musikc: good point
-[22:17:16] <genone> peper: you very well know that it's not defined formally
-[22:17:33] <ferringb> peper: one failing there is that it can miss ebuilds that (post-source) it's able to handle, thus inadvertantly masking stuff
-[22:18:01] <ferdy> ferringb: hrm.. how so ?
-[22:18:03] <ferringb> peper: that scenario, imo, is enough to raise the question of "why do post source then?"- pardon it wasn't on the ml, but I've been looking for an answer to that
-[22:18:21] <peper> ferringb: for backwards compatibilty
-[22:18:27] <peper> read the Application part of the glep
-[22:18:48] <peper> specification is how pm is supposed to do it to get it right
-[22:19:01] <ferringb> ferdy: portage-2.3.ebuild-3 w/ a pm that supports EAPI=(1,2), the portage ebuild has a post-source EAPI=2 w/in it, thus it *is* supported by the pm, but the pre-source serves as a mask
-[22:19:26] <@lu_zero> genone, ferringb and peper : why sourcing is a problem?
-[22:19:30] <peper> ferringb: and who would make such an ebuild?
-[22:19:34] <ferringb> peper: pkg-4.ebuild-2, EAPI=1 is a given example in the glep of this, just assume the manager supports EAPI=1 only; thus it *would* be able to use .ebuild-2, just would miss it
-[22:19:38] <@lu_zero> I'd like to have an answer about that first...
-[22:19:44] <ferdy> ferringb: I seem to recall the GLEP explicitly prohibiting that
-[22:19:52] <ferdy> lu_zero: have you read the discussion ?
-[22:20:07] <peper> lu_zero: read Problem section
-[22:20:12] <@lu_zero> done
-[22:20:12] <ferdy> in the mailing list, I mean. I think it has been covered...
-[22:20:14] <ferringb> ferdy: will recheck the glep to see if I was wrong, but the potential (even if it's stupid) was bugging me a fair bit.
-[22:20:16] <@lu_zero> nothing said about it
-[22:20:29] <@lu_zero> ferdy done, nobody explained that
-[22:20:31] <genone> lu_zero: the (potential) problem is that the EAPI might affect how things are sourced, and we can't trap the setting of a variable
-[22:20:48] <peper> ferringb: again, post-sourcing is just for backwards compat. devs are not supposed to use both
-[22:20:51] <@vapier> considering EAPI is stilled allowed and required to be respected properly in the ebuild, i dont see how this solves anything
-[22:21:04] <@vapier> you're still required to handle EAPI in the ebuild if no suffix, so why bother with suffix
-[22:21:09] <@jokey> genone: well if per definition the first line sets EAPI, then it shouldn't be an issue in any case, right?
-[22:21:26] <ferringb> genone: can trap the setting via adding an eapi function, which can be deployed via a bashrc hack as compatibility w/ managers growing the appropriate func however
-[22:21:42] <@vapier> and if the EAPI placement is simply "must come first", then the sourcing problem isnt a big deal
-[22:22:16] <genone> ferringb: yes, and I've mentioned that the motivation section is something that needs to be worked on as it currently has no real use cases short of glep54
-[22:22:46] <ferringb> genone: 'k; that (admittedly) is something I should've done initially instead of the var approach, although at least the transition to the func wouldn't be that painful
-[22:24:12] <ferringb> peper: aside from the addition of -scm to version component, can you add doc out any other complaints beyond what's there for the var approach?
-[22:24:34] <@lu_zero> genone putting the eapi tag in a comment like vim/emacs modelines won't give the same effect w/out such change?
-[22:24:41] <peper> ferringb: isn't it handled in the other ideas secion?
-[22:25:00] <ferringb> (I exempt the -scm one, since that is a general repo versioning issue, same scenario can play out with manifest/digest changes, thus should be solved that way imo)
-[22:25:08] <peper> it's neither backwards nor forwards compatible
-[22:25:13] lukass [n=lukas@!h153.29.227.87.static.kba.siw.siwnet.net] has quit IRC: "Leaving"
-[22:25:21] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has joined !c#gentoo-council
-[22:25:48] <ferringb> peper: not really imo, I'm looking for specific complaints leveled towards EAPI beyond "functions have to check it in the global scope to see if they support it"- that one is addressable w/ a few tweaks to existing eapi mechanism
-[22:26:53] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: Excess Flood
-[22:27:20] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
-[22:27:42] <peper> ferringb: and I am looking for technical objections to that GLEP, it solves all the problems nicely, in a backwards and forwards compatible way
-[22:27:52] Cardoe [n=cardoe@!hgentoo/developer/Cardoe] has joined !c#gentoo-council
-[22:27:54] <genone> lu_zero: well, lots of things are possible, I think the ML thread contains some drawbacks for the other solutions but I'd have to check (can't do that now)
-[22:28:31] <jmbsvicetto> genone: One question I didn't see a clear answer about was the one about using xml files. Is it a no-no to have eapi set on metadata.xml?
-[22:28:39] <ferringb> peper: the scenario of post-source being supported, but pre-source serving as a mask can play out via an eclass setting eapi however btw, so that one still is a valid scenario (it's considered a QA bug under the glep, 'cept I'm willing to bet it'll pop up in overlays)
-[22:28:42] <Caster> I liked the idea of eapi string not going at the very end, keeping the suffix constant
-[22:29:07] <@Betelgeuse> The sub directories approach would work for that.
-[22:29:23] <@Betelgeuse> The performance issue shouldn't really matter as users are using the metadata cache any wya.
-[22:29:35] <genone> jmbsvicetto: well, metadata.xml is ... complicated if you only want to target specific versions (and currently portage doesn't use metadata.xml in any way)
-[22:29:37] <peper> ferringb: the idea of the GLEP is to get rid of post-source eapi. the specification is for the package managers to get the backwards compatibility right
-[22:29:47] <@Betelgeuse> Also would need factual data if there is anything significant any way.
-[22:29:52] <ferringb> peper: technical objection to the glep basically comes down to "why punt whats there, when whats there works and can be tweaked to keep working"- I don't claim EAPI will work if the ebuild format shifts away from bash, but EAPI was intended for bash ebuilds only, expected newer formats to do versioning their own way
-[22:29:53] <peper> devs are supposed to use pre-source only
-[22:30:17] <@FlameBook> Betelgeuse, I would like to hear from infra about that as iirc CVS isn't nice with loads of directories
-[22:30:31] <@Betelgeuse> FlameBook: true
-[22:30:37] <peper> Betelgeuse: you first look for ebuild, then look at the cache
-[22:31:18] <@Betelgeuse> peper: to see if the cache is valid?
-[22:31:50] <ferringb> peper: additional thing the glep should doc, exactly what the manager does when it encounters a post-source EAPI it doesn't support cache wise (including regeneration of that entry if the manager sees that entry, and now supports that EAPI)
-[22:31:53] <peper> generally, you query cache for stuff, not traverse it
-[22:32:02] <genone> the subdir approach is nasty besides the performance issues
-[22:32:15] <ferringb> genone: agreed by all, I suspect
-[22:32:35] hncaldwell [n=hncaldwe@!hgrey.iitsystems.csupomona.edu] has joined !c#gentoo-council
-[22:33:04] <Cardoe> this is all starting to sound like over-design
-[22:33:11] <Cardoe> designing for a situation that will never happen
-[22:33:15] <Cardoe> KISS
-[22:33:52] <jakub> Cardoe++
-[22:34:00] <@Betelgeuse> well this hsould be useful for changing how inherit behaves etc
-[22:34:03] <peper> you are just not thinking enough
-[22:34:05] Ken69267 [n=Ken69267@!hgentoo/contributor/ken69267] has joined !c#gentoo-council
-[22:34:15] <peper> yep
-[22:34:30] <genone> as I said: the specification section is ok, but the motivation section needs a huge workover
-[22:34:38] <@lu_zero> Betelgeuse must it be changed?
-[22:34:55] <@Betelgeuse> lu_zero:  it was just an example of what this enables
-[22:35:07] <ferringb> peper: question for you; did you look at converting EAPI=N to eapi N, ie, forcing a func so the manager sourcing can bail at that point if unsupported; either way, I'd suggest expanding the glep to counter-arg that one since it's a solution to the inherit problem
-[22:35:59] <peper> for one, it's not backwards compatible
-[22:36:18] <@Betelgeuse> peper: well we would just have agree on profile.bashrc
-[22:36:18] <ferringb> peper: via bashrc stuck into the repo, it is
-[22:36:26] <ferringb> interim compatibility func basically
-[22:36:47] <genone> ferringb: paludis doesn't use profile.bashrc according to ciaranm
-[22:36:58] <@Betelgeuse> genone: yeah I think so too
-[22:37:14] <@Betelgeuse> There is lots of Portage specific hacks in profile.bashrc atm
-[22:37:14] <genone> not that I care ...
-[22:37:23] <ferringb> without the func, the ebuild gets sourced fully, and the manager sees the unsupported EAPI at the end of sourcing, does the usual thing (probably with a few errors spat during it); with the func, the manager bails at the first imperative sign of an unsupported eapi, thus bypassing any visibile errors.
-[22:37:25] <@Betelgeuse> but they could be put under some conditional
-[22:37:33] <Caster> we don't need back compatibility for paludis at this point
-[22:38:13] <ferringb> peper: so... imo, it's backwards compatible- sorry to spring it on you during this meeting rather then ML prior also ;)
-[22:39:15] <peper> it doesn't allow to change the versioning spec and I see it useful
-[22:39:26] <Caster> can newer portage easily ignore the eapi in bashrc then?
-[22:39:52] <@lu_zero> peper versioning spec changes aren't being approved
-[22:39:57] <@lu_zero> don't be circular
-[22:40:03] <ferringb> peper: versioning spec is a repo level compatibility issue imo, although you could argue other wise; again, I'd try to get that one doc'd out also, cause I know genone (and myself in this case) both via it as not the ebuild formats versioning responsibility
-[22:40:16] <ferringb> s:via it:view it:, pardon
-[22:40:34] <genone> peper: question: is glep54 the main (only?) motivation for glep55 for you?
-[22:40:50] <peper> no, it's a coincidence
-[22:41:55] <@jokey> can you give some real world examples, where this pre-source information is needed then?
-[22:43:10] <@jokey> as inherit-behavior-change is possible without it
-[22:43:33] <@vapier> so is there a reason we cant just force EAPI as the first line in an ebuild ?
-[22:43:38] <@vapier> is there some limitation i'm not aware of ?
-[22:43:52] <peper> vapier: backwards compatibility for one
-[22:43:53] <Philantrop> jokey: The PM will never have to read *any* content that might potentially cause it to die horribly because of EAPI issues. It sees a pre-source EAPI spec that it isn't compatible with and thus simply won't touch it and consequently avoid any potential problems easily.
-[22:44:06] <@vapier> peper: not really
-[22:44:17] <@vapier> and certainly *a ton less so* than changing the naming spec
-[22:44:25] <@jokey> Philantrop: still I want a real world example that breaks the sourcing that horrible
-[22:45:00] <@lu_zero> Philantrop having all non ebuilds in a package dir would break in a more spectacular way
-[22:45:44] <Philantrop> jokey: We don't have it yet so that's a bit hard. :-) It's something that opens the door for easier development in the future and improved transitions from one EAPI version to the next.
-[22:45:48] <@lu_zero> and I'm not sure about how manifests should be generated
-[22:45:58] <ferringb> Philantrop: that is achievable via the tweak adding an eapi func also; what we're talking about here re: "die horribly" is moreso "fail the sourcing, noting the EAPI and spitting noise at the user" also :)
-[22:46:50] <@vapier> Philantrop: claiming it'll happen in the future, just not now, isnt really an example
-[22:46:54] <Philantrop> ferringb: I'm not sure I understand you. You refer to users being confused by the output?
-[22:46:59] windzor [n=windzor@!h84.238.69.216] has quit IRC: Remote closed the connection
-[22:47:03] <@vapier> it's also a good argument for delaying the change until needed for real
-[22:47:17] <@vapier> instead of engineering for something that may not occur
-[22:47:52] <@jokey> vapier: exactly my point :)
-[22:48:03] <ferringb> Philantrop: no, what I'm saying is that a sane manager checks EAPI on the way out, as part of the metadata generation process.  if the EAPI is unsupported, and the new eapi added some global functions, *worst* you see is some screwed up metadata and errors spat to the users term on sourcing
-[22:48:18] <ferringb> Philantrop: it doesn't kill the manager (or shouldn't, if the manager is implemented sanely imo), it just is slightly ugly
-[22:48:38] <Philantrop> vapier, jokey: Why should we always operate *reactively*?
-[22:48:45] <ferringb> Philantrop: introducing an eapi func (which can be transitioned to via profile.bashrc) eliminates the inherit arg, and eliminates the potential for bash complaints to be spat during sourcing
-[22:49:13] <Cardoe> vapier: exactly what I meant by my previous comments
-[22:49:13] <@jokey> Philantrop: because acting proactive without a real value (you can't even come up with a potential example) doesn't make sense
-[22:49:17] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: "Leaving"
-[22:49:35] <Cardoe> if we over-design and work on engineering something that MIGHT happen, but never happens
-[22:50:04] <Cardoe> rather then engineering a logically extensible method (what EAPI itself provides), that can be in the future changed as things necessitate.
-[22:50:09] <Philantrop> ferringb: I see what you mean now but I can't say much more than that what was said on the -dev ml already. And so I go back to lurking here.
-[22:50:27] <@vapier> plus, this doesnt really address what started it all ... allowing eclasses to use a different EAPI from an ebuild
-[22:50:31] p-y [n=p-y@!hgentoo/developer/p-y] has quit IRC: Read error: 110 (Connection timed out)
-[22:50:45] <Cardoe> vapier: right. that was the whole point that spawned this whole thing.
-[22:50:58] <genone> vapier: well, that's simply not possibly, no matter how you define EAPI
-[22:51:00] <Cardoe> vapier: instead we've added about 12 steps of complexity and didn't even solve the original thing.
-[22:51:07] <peper> eclasses can't define EAPI
-[22:51:14] <@vapier> why not ?
-[22:51:23] <@vapier> why cant we segment things logically
-[22:51:39] <genone> vapier: which EAPI is effective: the calling env or the definition env?
-[22:51:53] <@vapier> genone: segment things logically
-[22:51:53] <ferringb> genone: could you rephrase the question please (didn't get the meaning there)
-[22:52:02] <peper> vapier: what do you mean?
-[22:52:08] <@vapier> eclasses are not affected by the ebuild at all
-[22:52:18] <@FlameBook> considering we have two other points on today's list, do we want to take a decision on this, postpone it, or what?
-[22:52:22] <@vapier> eclasses can use different EAPIs independently from the ebuild
-[22:52:37] <ferringb> vapier: not true, imo
-[22:52:49] <@vapier> might as well push it back to the list
-[22:52:59] <ferringb> vapier: eapi is a definition of the env (vars, funcs), switching the env dependant on ebuild/eclass context isn't viable imo
-[22:53:03] <genone> ferringb: see http://article.gmane.org/gmane.linux.gentoo.devel/53354
-[22:53:21] <peper> I think you meant vapier
-[22:53:23] <@vapier> ferringb: having one env force/imply restrictions on the other is bad
-[22:53:51] <Cardoe> vapier: it also brings up the point that eclasses are abused and enibbles or elibs need to be available.
-[22:53:55] <@vapier> it means all consumers of an eclass need to worry about the eclass which sort of defeats the purpose of the eclass -- not having to worry about its contents
-[22:54:11] fmccor [n=fmccor@!hgentoo/developer/fmccor] has quit IRC: "Leaving"
-[22:54:15] <genone> vapier: http://article.gmane.org/gmane.linux.gentoo.devel/53354 <- answer those questions please if you want different EAPIs
-[22:54:37] <ferringb> vapier: agree with you in principle, disagree on implementing it however ;)
-[22:54:51] <@vapier> i'm not trying to imply the implementation is trivial
-[22:55:05] <genone> i's a conceptual problem
-[22:55:08] <@vapier> regardless, back to the list and us on to the next item
-[22:55:11] fmccor [n=fmccor@!hgentoo/developer/fmccor] has joined !c#gentoo-council
-[22:55:50] <@jokey> with vapier here, should be postponed to next meeting
-[22:56:00] <@vapier> no
-[22:56:12] <@vapier> pushed to the list until resolved, and then back to the council
-[22:56:24] <@FlameBook> so it's a "rejected in this state"?
-[22:56:52] p-y [n=p-y@!hmas91-3-88-163-239-36.fbx.proxad.net] has joined !c#gentoo-council
-[22:56:53] rangerpb [n=baude@!hgentoo/developer/rangerpb] has quit IRC: "Leaving"
-[22:57:11] aballier [n=alexis@!hgentoo/developer/aballier] has joined !c#gentoo-council
-[22:57:30] <@vapier> FlameBook: there was no voting involved, thus no rejection
-[22:57:43] <+musikc> needs further discussion
-[22:57:44] <@vapier> we were merely discussing the GLEPs, no request for voting
-[22:58:22] <@dberkholz> fwiw, i'm back but catching up on backlog
-[22:58:24] <@FlameBook> okay, let's go to "need further discussion" as musikc said then
-[22:58:48] <@FlameBook> dberkholz, that is perfect as we're moving to CoC :)
-[22:58:54] <+musikc> hehe
-[22:58:55] <@jokey> timing++ ;)
-[22:58:56] <peper> I am going to repost the GLEPs as is and hope you guys ask your questions there
-[22:59:33] <Caster> peper: as is? so no argument for why eapi() function can't help?
-[22:59:36] <@SpanKY> ive lost the agenda URI from my scrollback
-[22:59:44] <@jokey> SpanKY: see topic
-[22:59:44] <@FlameBook> SpanKY, http://dev.gentoo.org/~dberkholz/20080110_summary.txt
-[22:59:55] <@vapier> well that'd be too obvious
-[23:00:01] <@dberkholz> vapier: /topic
-[23:00:03] <@jokey> FlameBook: I grabbed it from dberkholz and completed it
-[23:00:15] <@FlameBook> jokey, ah I didn't even see it in the topic
-[23:00:48] Zephyrus [n=emanuele@!h81-174-11-81.static.ngi.it] has quit IRC: Client Quit
-[23:01:22] <peper> Caster: oh ok. I will add this one
-[23:01:32] <@dberkholz> i'm caught up to the first hour, another hour of backlog to go
-[23:01:43] <@lu_zero> ^^;
-[23:02:22] <@jokey> so pushing back to -dev is agreed on ? then we can move over to CoC discussion
-[23:03:04] <peper> jokey: the subjective part of the summary in GLEP 54 is wrong
-[23:03:36] <ferringb> peper: if you want me to give the eapi() a read over (since I'll be commenting on it either way), email me and I'll try to get back to you w/in the day
-[23:03:38] <@jokey> right, missing inherit breakage, adding that
-[23:03:50] <@jokey> done
-[23:03:58] <peper> as there is no way to distinguish between pkg_name and pkg_name-version on its own/, but it's not necessary anyway
-[23:04:10] <peper> jokey: I meant GLEP 54
-[23:04:33] <peper> the subjective part is just wrong, I thought it was established
-[23:05:43] <@jokey> well as it will have a log attached either way, I'm removing that line altogether
-[23:05:52] <@jokey> you're right, it's a bit subjective
-[23:06:19] <peper> no, it's not true
-[23:06:25] <peper> as there is no way to do it currently
-[23:06:38] fmccor thought he knew how to run long meetings. :)
-[23:07:00] <@jokey> anyway, pushed back to -dev ML
-[23:07:07] <peper> right
-[23:07:47] <@lu_zero> peper do what?
-[23:07:58] <@jokey> so ladies and gentlemen, let's move over to CoC now
-[23:08:03] <@lu_zero> ok
-[23:08:24] <peper> lu_zero: tell whether a string is a pkg or pkg-ver
-[23:08:42] FlameBook is probably going with "whatever donnie says" :P
-[23:09:47] <@lu_zero> dberkholz are you ready?
-[23:09:58] <@dberkholz> i'm at 20 minutes ago, so almost
-[23:10:02] <genone> peper: it is possible, your example didn't work out, also see bug !c#174536
-[23:10:05] <jeeves> genone: https://bugs.gentoo.org/174536 min, P2, All, degrenier@easyconnect.fr->pms-bugs@gentoo.org, NEW, pending, "Package names" spec not restrictive enough
-[23:10:26] <@vapier> done people, moving on
-[23:10:38] <@vapier> dont make us go +m on j00
-[23:10:52] <@dberkholz> feel free to skip to slacker arches and come back to CoC in a bit
-[23:11:07] genone just dislikes misinformation
-[23:11:15] <@dberkholz> not really sure there's anything to discuss on the slacker point, though.
-[23:11:24] <@vapier> how so ?
-[23:11:35] <@vapier> or rather, we jumping to slacker first ?
-[23:12:26] <@dberkholz> that's my suggestion, yeah.
-[23:12:45] <@dberkholz> hopefully it will go faster, and then people uninterested in the CoC can leave
-[23:12:52] <@FlameBook> kumba's mail was quite reasonable, so I don't think there's much to discuss, I suppose it could work out by just leaving the options of devs asking de-keywording on ebuild basis
-[23:13:20] <@Betelgeuse> as long as there is someone to ask
-[23:13:20] <@vapier> except that didnt really work out
-[23:13:29] <@vapier> there was no response
-[23:13:34] <jakub> FlameBook: is there someone going to respond to those mails? wasn't my experience so far....
-[23:13:51] <jakub> even when remove keyword was explicitely and repeatedly requested
-[23:14:08] <@vapier> i think what Richard posted is a pretty reasonable
-[23:14:12] <@vapier> http://article.gmane.org/gmane.linux.gentoo.devel/54103
-[23:14:13] <@FlameBook> jakub, well, kumba answered to gentoo-dev... I don't think we should _force_ it now
-[23:14:41] <@vapier> perhaps extend the dates to give more leeway to arches, but there has to be a cut off point
-[23:14:44] <jakub> FlameBook: I'm totally fine w/ that if you are going to create a working way to do it :)
-[23:14:52] <@vapier> otherwise maintainers who get tired of waiting will eventually do it
-[23:14:55] <@vapier> and then the arches get pissed
-[23:15:00] <@vapier> yell and point at policy
-[23:15:05] <@vapier> and it's the maintainer getting screwed
-[23:15:09] <jakub> nod
-[23:15:09] <@vapier> when in reality that isnt right
-[23:15:36] <ferdy> I'd like you to consider what I posted to that same thread: http://mid.gmane.org/20080109121309.GA14454@ferdyx.org
-[23:15:57] <jakub> vapier: maybe more flexible, but still needs some hard deadlines so that it doesn't become useless
-[23:16:00] <@vapier> the only responses i saw from you were "no"
-[23:16:57] <jakub> ferdy: wrt the maintainer question you've posted there... it is different, you can retire a maitainer, noone ever retired an arch yet
-[23:17:05] <@jokey> what about we do some "% packages stabled, % packages behind requests for time X -> transition to ~arch"
-[23:17:19] <ferdy> jakub: retiring a maintainer doesn't solve the issue...
-[23:17:34] <jakub> ferdy: sure it doesn't, but it
-[23:17:43] <jakub> 's still lot better than ignoring inactive people
-[23:17:43] <@FlameBook> vapier, well, I actually like Richard's proposal
-[23:18:08] <@vapier> ferdy: with arches, you're forcing maintainers to sit on things indefinitely with no reaction, which quickly chains to large !c# of affected packages
-[23:18:09] <jakub> ferdy: someone can take over the package once the slacking maintainer has retired...
-[23:18:16] <@vapier> with a maintainer slacking, the issue is isolated to one package
-[23:18:31] <jakub> and what vapier said, yeah
-[23:18:31] <@vapier> you can trivially cull a package, you cant trivially cull an arch
-[23:18:34] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has quit IRC: Read error: 110 (Connection timed out)
-[23:18:39] <jakub> ain't the same situation
-[23:18:50] <@vapier> and you can transition arches to a state that keeps maintainers happy
-[23:19:14] <ferdy> vapier: in that particular bug I posted. I would suffer from the same 'maintenance burden'.... should I, for instance, add blockers
-[23:19:18] <@amne> just a quick thought before this gets more into detail, do we want to address just this one situation or come up with a general policy for all possible times an issue like this comes up?
-[23:19:26] <jakub> seriously, why's mips so much objecting to becoming ~arch/indev? would shut up the maintainers mostly
-[23:19:43] <@vapier> no one who matters is objecting
-[23:19:43] <ferdy> please note that I personally deny that maintenance burden existing, but I think it is the very same situation
-[23:19:57] <@dberkholz> jakub: no active mips developer (kumba or redhatter) has objected to that
-[23:20:00] <@vapier> take that thread, cull the irrelevant, and you have a few e-mails to read
-[23:20:07] <@vapier> ferdy: how would you suffer ?
-[23:20:12] <@vapier> i honestly dont see it
-[23:20:18] <@vapier> please 2 elaborate
-[23:20:21] <jakub> dberkholz: well sorry then, that's what I've always heard from the folks until now :)
-[23:20:36] p-y [n=p-y@!hmas91-3-88-163-239-36.fbx.proxad.net] has quit IRC: Read error: 110 (Connection timed out)
-[23:20:39] <ferdy> I don't see it either.... but leaving versions in the tree forever is said to cause maintenance burden
-[23:20:54] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has joined !c#gentoo-council
-[23:20:55] <ferdy> which is one of the arguments in favour of "killing the mips team altogether!!!!one"
-[23:20:56] <@vapier> ferdy: i'm talking about why you think 181275 is relevant
-[23:20:59] <Cardoe> jakub: just ignore non-Gentoo developers e-mails and read official Gentoo dev e-mails and you'll see that the Gentoo devs agree with it
-[23:21:16] <jakub> ferdy: sure it is... repoman commit breaks when you want to punt obsolete broken junk... etc. etc.
-[23:21:16] <@vapier> ferdy: there will be no killing of mips
-[23:21:42] <@vapier> there will most likely be ~arching of mips which is very different from killing
-[23:21:43] <ferdy> vapier: I have to leave older versions around until that issue is solved
-[23:22:09] <@vapier> ferdy: you need to leave old versions of git in the tree until uClibc is fixed ?
-[23:22:14] <@vapier> i dont think so, remove the old versions
-[23:22:28] <jakub> ferdy: you are wasting time on investigating which broken cruft can't be removed just b/c noone responded on a bug for years... now imagine major package redesigns, becomes a huge PIT
-[23:22:28] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
-[23:22:38] <@vapier> jakub: please shush
-[23:22:48] <jakub> sure ;)
-[23:23:33] <ferdy> vapier: imagine it'd hold stabilization of newer versions.... it is not ONLY arch teams that can cause that 'problem', which is why I wanted the discussion to be more general
-[23:24:03] <@vapier> ferdy: ive been telling people not to cater specifically to uClibc when it is a burden on them and the problem lies in uClibc
-[23:24:17] <ferdy> yeah, forget uClibc for now
-[23:24:21] <@vapier> sure
-[23:24:33] <@vapier> can you propose other examples ?
-[23:24:50] <@vapier> the only ones i can come up with are keeping old things around to support broken things
-[23:24:56] <@vapier> and the answer is to fix or cull the broken things
-[23:25:35] <@vapier> the only thing that has come up on the mailing list is arches holding it back
-[23:25:49] <@vapier> so if you can show other general issues, i'd be happy to extend the proposal
-[23:26:15] <@vapier> as it is, i'd be looking for probably 2x the time frames Richard put forth
-[23:26:20] <@vapier> [ http://article.gmane.org/gmane.linux.gentoo.devel/54103 ]
-[23:26:48] <@vapier> as you say, this is a volunteer basis, and people can easily get tied up
-[23:27:15] <@dberkholz> 2 and 4 months, instead?
-[23:27:26] <@dberkholz> 4 months is an awfully long time to wait
-[23:27:57] <ferdy> vapier: I can't really give you more *examples* now (I think the reasoning is still valid), feel free to ignore it.
-[23:28:09] <@vapier> ferdy: i dont intend for us to decide today on the issue
-[23:28:32] <@vapier> i want us to put forth the recommendation to the list and the understanding is we'd decide next meeting
-[23:28:36] <@vapier> i think that's reasonable ?
-[23:28:47] <@Betelgeuse> sure
-[23:29:13] <@dberkholz> i don't think i'd quite go 2x, but i could see a sort of 1.5-ish
-[23:29:24] <@vapier> dberkholz: it is and it isnt ... maybe it's me, but i see a month shoot by in Gentoo world and not even realize it
-[23:29:26] <@dberkholz> 3 months doesn't feel quite as forever
-[23:29:27] <@Betelgeuse> The proposal should probably say something about reserve deps
-[23:29:47] <@dberkholz> vapier: guess that depends on whether it's a month waiting for someone else to do something you care about. =)
-[23:29:59] <ferdy> vapier: sure, it is reasonable
-[23:30:08] <@vapier> i would make it dependent on the profile
-[23:30:22] <@vapier> if the profile is set to "stable", then the reserve deps would need to be fixed
-[23:30:35] <@vapier> but if it's set to "dev"+, then let it break
-[23:31:00] <@dberkholz> it shouldn't be difficult to come up with some sort of scripts/tools to deal with that
-[23:31:02] <@vapier> the burden is on the arch guys to resolve it, and it wouldnt break systems anymore than if you went through the revdeps
-[23:31:12] <@dberkholz> if they don't already exist
-[23:31:26] <jakub> vapier: does this 2+4 months suggestion include security issues, or should that be a separate policy?
-[23:31:30] <@vapier> and it would actually be better for the arch guys -- fix the failing package and dont have to re-keyword the revdeps
-[23:32:06] <@vapier> people groan when the word security pops up, but i dont think it's relevant
-[23:32:30] <jakub> just asking ;)
-[23:32:36] <@vapier> removing a security affected package wont force any additional upgrades on any systems
-[23:32:47] <@vapier> world -Dup would give same result
-[23:33:12] <@vapier> i'm doing a lot of talking here
-[23:33:22] <@dberkholz> it's great.
-[23:33:37] <@dberkholz> i'm used to doing all the talking. maybe i should start coming an hour late every time.
-[23:34:11] FlameBook proposes that next meeting starts only once dberkholz is settled down :P
-[23:34:25] <@FlameBook> dberkholz, I'm also used to _you_ doing all the talking ;)
-[23:34:33] <Philantrop> vapier: KDE would prefer the 1.5x suggestion of dberkholz'.
-[23:34:50] <@jokey> with dberkolz, writing up tools if needed shouldn't be much of an issue if really needed
-[23:35:02] <jakub> vapier: mkay.... more precisely... should security be allowed to punt stuff if some arch is totally non-responsive for lets say over a year?
-[23:35:13] <@vapier> ferdy: if you had a choice of timelines, does the 2x vs 1.5x really make a difference for you ?
-[23:35:40] <@vapier> jakub: what we're talking about already allows culling at half that time
-[23:35:57] <@vapier> ferdy: i know you're one of our over burdened arch guys ;)
-[23:35:57] <jakub> vapier: thanks, answers my question :)
-[23:36:17] <@vapier> but we need to balance things here, and i'm afraid it's fallen too far towards the arch currently
-[23:37:33] xjrn [n=chatzill@!hc-24-4-108-16.hsd1.ca.comcast.net] has joined !c#gentoo-council
-[23:38:11] <@vapier> perhaps an additional bugzilla keyword would help as well for arch teams to really eck out the way past due
-[23:38:15] <@jokey> well there has been a lot of noise on -dev also which seems to have made it kind of hard to discuss just the topic and not the arch as such
-[23:38:17] <jmbsvicetto> vapier: This discussion is beyond the current mips issue, right? Having mips move to only ~mips is on the table, right?
-[23:38:17] <@vapier> CULLREQ
-[23:38:43] <@vapier> jmbsvicetto: i'm not picking on mips here, this applies to everyone
-[23:38:55] <@vapier> i imagine ive slacked more than other devs would like with some arch keywording
-[23:39:11] <@vapier> i know ive lost arch on somethings, but i dont blame the maintainers for doing it
-[23:39:15] <jakub> vapier: damn remove yourself from CC when done </rant> :P
-[23:39:24] <@Betelgeuse> vapier: and use echangelog
-[23:39:38] <ferdy> "Ebuild Stabilization Time" what happens when that period finishes ?
-[23:39:41] <@Betelgeuse> vapier: But arm/sh/whatever don't have the coverage of mips I think
-[23:39:50] <@vapier> jmbsvicetto: i imagine as a consequence of this agreement, maintainers will start the mips=>~mips
-[23:39:59] <@FlameBook> Betelgeuse, better than mips for what I maintain at least
-[23:40:01] <@dberkholz> should be easy enough to add all that to your keywording script with pybugz
-[23:40:21] <@Betelgeuse> dberkholz: Is that working nowadays?
-[23:40:22] <@vapier> but this would have applied to other arches in the past
-[23:40:28] <@Betelgeuse> dberkholz: Last time I tried it didn't work.
-[23:40:30] <beandog> Betelgeuse, http://spaceparanoids.org/gentoo/gpnl/stats.php?q=arch
-[23:40:34] <@vapier> we just dont have vocal peeps for other teams like mips
-[23:40:35] <@dberkholz> Betelgeuse: yep. wanna talk more about it, let's do that in !c#-dev
-[23:40:37] <ferdy> the first paragraph of "Removing Stable Ebuilds." is what really really makes me nervous
-[23:41:14] <@dberkholz> does that really mean removing so there's no stable version, or does it mean forcibly stabling a newer version?
-[23:41:16] <@vapier> oh, i also forgot ... there needs to be a fallback for arches to explicitly pin a version indefinitely ... with the understanding that they'd be responsible for its up keep
-[23:41:44] <@vapier> i do not think force stabilization by a non-arch maintainer makes any sense
-[23:42:02] <@FlameBook> vapier, metadata.xml allows restricted maintainership, that would work, I suppose
-[23:42:20] <@vapier> i know there's a few packages where s390 explicitly requires old versions of packages
-[23:42:24] <@dberkholz> ok, so instead of giving something marked stable that might be broken, we give them no ebuild at all.
-[23:42:26] <@vapier> dictated by ibm
-[23:42:34] <@vapier> dberkholz: they get ~arch
-[23:42:42] <jakub> vapier: well... similar fallback is feasible with single packages... not stuff like KDE I'd say... yeah, toolchain and similar for sure
-[23:43:01] <@dberkholz> they get no ebuild at all without changing their configuration, which is exactly the same situation they'd be in if we force-stabled
-[23:43:02] <jmbsvicetto> ferdy: In the case of kde, 3.5.5 is the only version with any mips keywords. So if that gets removed, mips will lose kde
-[23:43:32] <@vapier> dberkholz: i think it sort of violates the guarantee that stable brings
-[23:43:53] <@vapier> a package marked stable is an implicit guarantee from the arch maintainer that the version is known/supposed to work
-[23:44:00] <@dberkholz> that was my possible "con" too, wasn't sure whether others would share it
-[23:44:13] <@FlameBook> I agree with mike on this
-[23:44:34] <@dberkholz> as not an arch person or a stable user, it's not exactly my best area
-[23:45:14] <jakub> well... /me notes that, while talking about mips, tons of their 'stable' packages cannot compile on stable system at all
-[23:45:15] <@vapier> presumably arches that get enough noise that their stable is going away should be able to muster some workflow to get newer versions stabilized
-[23:45:27] <@vapier> we're not talking about mips
-[23:45:31] <@vapier> stop mentioning mips
-[23:45:52] <jakub> vapier: mkay... abstractly then :p should the maintainer be allowed to stabilize newer version in this case, or drop to ~arch
-[23:46:07] <@vapier> in the case where a package would lose all stable keywords, if there are users affected, they'd convey to a maintainer that version FOO works, so the maintainer would have something to go on
-[23:46:20] <@vapier> (arch maintainer there)
-[23:46:29] <@vapier> which is a hell of a lot better than a package maintainer picking random versions and moving it
-[23:46:51] <ferdy> in an ideal world, non-arch maintainers won't touch arch keywords (aside of ~all for bumps and that kind of stuff, of course)
-[23:47:06] <jakub> vapier: not talking about arch testers/maintainers... simply stuff that fails to compile w/ current toolchain/base system stuff or similar
-[23:47:16] <@Betelgeuse> ferdy: would be doable on the server side.
-[23:47:20] <jakub> what's the value of 'stable' keyword there, it's useless
-[23:47:41] <@vapier> ferdy: in an ideal world, the arch maintainers would be able to keep up
-[23:47:45] <ferdy> jakub: 'worked with a stable system when it was tested'
-[23:47:47] <@vapier> but that isnt always the case
-[23:47:54] <ferdy> vapier: that was the second part of my sentence, sorry....
-[23:48:00] <@vapier> np
-[23:48:09] <jmbsvicetto> vapier: There's another issue in here, whether a maintainer should be forced to have a keyword added for an arch that has failed to keep up.
-[23:48:17] <@FlameBook> well, I'm sorry to bail out before time, but fever is getting its way through my mind at the moment
-[23:48:21] <jakub> ferdy: well... yeah it worked once upon a time, does not any more... no mre stable
-[23:48:25] <ferdy> so we have to find a way for maintainers won't be affected when arch teams aren't able to keep up without messing anyones work
-[23:48:38] <@FlameBook> I'm fine with whatever vapier thinks is fine, he knows the problem and I trust he'll do the right thing.
-[23:49:00] <@vapier> jmbsvicetto: i dont follow ... pkg maintainers are not allowed to move ~arch to arch
-[23:49:10] <@FlameBook> as for CoC I already said I'm okay with whatever dberkholz decides, as he's way more experienced than me in that regard, and I also trust him on that issue
-[23:49:11] <@vapier> the proposal is to allow pkg maintainers to drop arch after a timeout
-[23:49:33] <jakub> good, finally an answer... :)
-[23:49:38] <@FlameBook> night 'rybody
-[23:49:41] FlameBook [n=intrepid@!hamarok/helper/flameeyes] has quit IRC: "Leaving"
-[23:50:01] <ferdy> jmbsvicetto: well... I think there shouldn't be a discussion about that. Arch teams' opinion is final, IMHO
-[23:50:11] <@vapier> i'll take Richard's proposal, tweak it according to input here, and send it out, and we can decide on it next meeting
-[23:50:18] <@vapier> aye ?
-[23:50:21] <@lu_zero> fine
-[23:50:25] <@dberkholz> sounds reasonable
-[23:50:49] <@jokey> +1
-[23:50:49] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: "Leaving"
-[23:50:55] <jakub> well, one more thing... should a maintainer be allowed to ban $arch from keywording his package?
-[23:50:57] <jmbsvicetto> vapier: No. Let me give an example. Maintainer of package xyz has had problems with 1 or more arches being able to mark stable or even keyword said package. Things get to a point where the package has one last, old version marked stable / keyworded on said arches. Should arch teams have the power to keep the keyword for that package when the maintainer doesn't want to depend on said arches any more?
-[23:51:10] <jmbsvicetto> vapier: Assuming those timelines have been broken by the arch teams
-[23:51:37] <@vapier> jmbsvicetto: it's a case by case basis which the maintainers/arches should agree on
-[23:52:07] <jmbsvicetto> vapier: Well, what about cases where maintainers don't want to have that overhead anymore and the arch team won't cooperate?
-[23:52:08] <@vapier> if the arch truly needs the older version, then they can keep it and they're responsible for maintaining it
-[23:52:24] <@vapier> if they simply dont have the time to test a newer version, then the arch team loses
-[23:53:05] <@vapier> we cant account for maintainers and arches being asshats
-[23:53:19] <@vapier> if the two truly cannot come to a decision, they can ask a higher power (probably us) to decide
-[23:53:23] <@jokey> vapier: as you'll post a revisited version, can we move to CoC?
-[23:53:29] <@vapier> yeah
-[23:53:30] <@Betelgeuse> yeah two council members can make a decision
-[23:53:30] jokey looks at the clock
-[23:53:41] <jmbsvicetto> vapier: We have a rule that prevents maintainers from dropping arches. Shouldn't we give them the option to not support an arch (on extreme cases)?
-[23:53:48] <jakub> jokey: pffft, go open a beer ;P
-[23:54:00] <Philantrop> vapier: Agreed. But let's assume a maintainer would consider actively dropping even ~arch should a team keyword the package *he/she* has to maintain.
-[23:54:17] <@vapier> assume on the list
-[23:54:20] <@vapier> moving on
-[23:54:22] <@jokey> indeed
-[23:54:27] <Philantrop> vapier: ok
-[23:54:42] <@jokey> so CoC then and dberkholz' part :)
-[23:55:09] Pesa [n=Pesa@!halpha.tat.physik.uni-tuebingen.de] has left !c#gentoo-council
-[23:55:47] <@dberkholz> jokey: are those one and the same, or do i have another mystery part?
-[23:55:52] <@vapier> personally, i'd think more about simply abolishing devrel resolution/etc... as well as CoC and take a more simple approach: if you're an asshat, you get tossed
-[23:56:01] <@vapier> no drama
-[23:56:10] <@jokey> dberkholz: it's the same ;)
-[23:56:18] <@Betelgeuse> vapier: and who decides that?
-[23:56:22] <@vapier> if you cant play nice, we have a size 15 boot here for you
-[23:56:46] <@vapier> it should be pretty self evident
-[23:56:52] <@vapier> every issue that's come up so far has been
-[23:56:53] <fmccor> Betelgeuse, That's the quiestion, isn't it?
-[23:57:00] <@vapier> but i digress
-[23:57:08] <@vapier> go on with the CoC discussion
-[23:57:31] <@dberkholz> the concept's in the agenda, but i'll briefly summarize
-[23:58:06] <@dberkholz> where there are existing moderators, they will enforce the CoC themselves. other than that, the proposal would add mods to the -dev list and !c#-dev.
-[23:58:44] <@lu_zero> who exactly?
-[23:58:59] <@dberkholz> To Be Determined
-[23:59:16] <@dberkholz> personally, i think that we could use some mod action on the list far more than !c#-dev
-[23:59:31] <fmccor> Yes.
-[23:59:36] <@jokey> maybe I'm mistaken but if someone goes insane on !c#-dev, it's a default devrel case, isn't it? and for immediate action, you can always give people a nice and warm kick
-[0:00:23] <@dberkholz> jokey: that depends. do you want to wait 2 months for a trial?
-[0:00:53] <TFKyle> vapier: would that be permanent or? (I assume by "tossed" you mean banned by atleast the medium that you acted up on in some way - or is that just for devs and getting your devship revoked?)
-[0:01:10] <@jokey> we're all ops on !c#-dev so (theoretically) any dev can kick
-[0:01:10] Cardoe [n=cardoe@!hgentoo/developer/Cardoe] has quit IRC: "Leaving"
-[0:01:28] <@dberkholz> kicking an op doesn't get you very far.
-[0:02:38] <@jokey> ubuntu people solve it by sharing a management account for the chan among 4-5 people who can immediately modify the lists if really needed
-[0:02:42] <@dberkholz> the idea on irc would be to drop someone's level below autovoice for a day or whatever, then restore it.
-[0:03:02] <@amne> imho just because everyone has ops doesn't mean there cannot be that there are some people that go after people who are abusive
-[0:03:16] <@dberkholz> if said person is still nuts, kick 'em out as vapier said
-[0:03:20] <@amne> e.g. what jokey and dberkholz just said
-[0:03:24] <@amne> yeah
-[0:04:21] <@dberkholz> the kicking part, at this point, would be handed off to devrel
-[0:04:47] <@vapier> take some personal responsibility
-[0:04:48] <@dberkholz> we could argue over whether it should instead be decided by the council
-[0:04:51] <@vapier> if you cant, you will be warned
-[0:04:52] bheekling [n=bheeklin@!h202.3.77.38] has joined !c#gentoo-council
-[0:04:56] <@vapier> if you still cant, you get tossed
-[0:05:02] <@vapier> get your act together, come back later
-[0:05:10] <@vapier> dont get your act together, stop wasting our time
-[0:05:15] <@jokey> indeed, vapier, fully with you :)
-[0:05:39] <@vapier> but my dissertation on the subject is off-topic for this CoC stuff
-[0:06:07] <@jokey> main reason is the -dev ML anyway so we should really focus on that
-[0:06:19] <@dberkholz> vapier: nah, it's on topic
-[0:06:24] <@vapier> there should be no body here ... developers should be able to call out on any other developer instead of idling accepting it
-[0:06:40] <@vapier> err, "there should be no body here making the decision"
-[0:06:47] <@dberkholz> what, have a duel?
-[0:07:14] <@vapier> there is plenty of bad karma that goes down everywhere that onlookers just accept
-[0:07:30] <@jokey> welcome to the real world ;=)
-[0:07:33] <@vapier> i'm saying any moderation solution doesnt address the root of the problem
-[0:08:10] <@dberkholz> how do you propose to change the root of the problem?
-[0:08:36] <NeddySeagoon> vapier, Well, thats too many immature alpha males ... how do you fix that ?
-[0:08:53] <@vapier> we steal g2boojum's seed, combine it with the good traits from developers, and kill off the originals
-[0:09:48] <@dberkholz> i agree that we need to create a positive atmosphere. i think that moderators can be the first step in building a culture of intolerance toward assholes
-[0:10:08] <@dberkholz> once that culture exists, we won't need mods anymore
-[0:10:24] <@vapier> i'm looking long term
-[0:10:34] <@vapier> what needs to be decided today needs to be decided today
-[0:10:40] <@vapier> my thoughts dont really have bearing on it
-[0:10:46] fmccor suspects that no matter where you start with vapier's approach, you will end up with something like devrel.
-[0:11:09] <@vapier> no centralized body ... if you dont like the culture, fork your own
-[0:11:11] <@vapier> go write a blog
-[0:11:16] <@vapier> we dont care
-[0:12:44] <@vapier> but seriously, dberkholz wants a resolution here, so focus on that
-[0:13:20] <@amne> i think dberkholz' approach is good
-[0:14:19] <@jokey> if it doesn't work out, we can/have to try something else anyway but I'm all for trying it
-[0:14:25] <@amne> heh
-[0:15:13] <@dberkholz> how many people are for the idea, as it stands now?
-[0:15:51] <@amne> me
-[0:15:58] <@jokey> as in do we want to vote?;)
-[0:16:23] <@dberkholz> well, we don't really have enough details to finalize on, unless you'd just like to delegate further details to someone
-[0:16:47] <NeddySeagoon> I don't see the difference between the current proposal and the Proctors
-[0:17:37] <jmbsvicetto> NeddySeagoon: From previous discussions, it seems it will be an even smaller group and very close to the council
-[0:17:47] <@dberkholz> there are no pointless warnings, only actions.
-[0:18:15] <@dberkholz> there isn't going to be discussion about moderation on -dev, so people will have to actually make a little effort to whine about it.
-[0:18:15] <NeddySeagoon> dberkholz, Hmm ok
-[0:18:26] <@dberkholz> since -dev is now purely technical
-[0:20:07] <@dberkholz> i think getting bogged down into -dev threads with attempted warnings, responses, and so on was an approach the mods should never take
-[0:21:13] <@dberkholz> we're starting to rehash discussions we've already had
-[0:22:04] <@dberkholz> so, what i would like from council members is: do you like the idea, do you think it needs significant changes, or do you dislik eit
-[0:22:18] hkBst [n=hkBst@!hgentoo/developer/hkbst] has quit IRC: "Konversation terminated!"
-[0:22:46] <@dberkholz> if we can agree that the idea is the way to go, we can start focusing on the details instead of returning to the original idea all the time
-[0:23:06] <@lu_zero> I like the idea
-[0:24:40] jokey too
-[0:24:50] <@vapier> i'm with dberkholz
-[0:25:40] <@dberkholz> Betelgeuse, around?
-[0:25:50] <@Betelgeuse> dberkholz: yeah
-[0:26:04] <@Betelgeuse> dberkholz: you rule
-[0:26:22] <@dberkholz> good to hear. =)
-[0:26:47] <@dberkholz> alright. we're going to proceed with this idea. i'll try to get some concrete ideas out to the -council list this week
-[0:27:39] pchrist_ [n=tester@!h84.38.8.37] has joined !c#gentoo-council
-[0:28:03] <@dberkholz> anyone else got additional CoC points now?
-[0:29:10] <@dberkholz> ok, let's open the floor for any new topics
-[0:31:03] <@jokey> well we have one missing
-[0:31:12] <@jokey> Document of being an active developer
-[0:31:16] Sweetshark [n=bjoern@!hd018195.adsl.hansenet.de] has joined !c#gentoo-council
-[0:31:21] <@jokey> s/missing/left/
-[0:31:43] <@vapier> i think that's something we could do with infra
-[0:31:53] <@vapier> have it be something you need to log into dev.g.o
-[0:31:57] <@vapier> run a command
-[0:32:08] <@vapier> it generates a digitally signed document
-[0:32:18] <@vapier> the digital key is maintained by infra
-[0:32:41] <@vapier> therefore random devs cant generate documents and just change the names
-[0:33:06] <@vapier> have it auto-include information like date of joining
-[0:33:07] <@jokey> we could add that our userlist.xml can be used for reference if it is still accurate
-[0:33:12] <xjrn> is gentoo in a  position to broker liveId's?
-[0:33:42] <@vapier> jokey: right, now that the ldap and crap is integrated
-[0:33:45] <@vapier> use that as the backend
-[0:34:04] <@Betelgeuse> jokey: userinfo.xml is generated from LDAP
-[0:34:06] <@dberkholz> xjrn: is that different from openid?
-[0:34:55] <@jokey> Betelgeuse: that's my point, once you set it to retired, it's killed at max 60 minutes later on the website
-[0:35:02] <@dberkholz> araujo: could you just print off an "official" gentoo business card with your name on it, that perhaps only gentoo devs have access to
-[0:35:06] ferdy [n=ferdy@!hgentoo/developer/ferdy] has quit IRC: "[IRSSI] Tiger Woods uses Irssi. FORE!"
-[0:36:18] <@vapier> eh, no one accepts business cards as proof of anything
-[0:36:25] <@vapier> ive tried
-[0:36:43] araujo looks around
-[0:36:52] <xjrn> dberkholz: sorry openId
-[0:37:00] <araujo> dberkholz, you mean, to send it to every developer?
-[0:37:10] <@amne> sorry guys, i'm already falling asleep here, so i'll idle out
-[0:37:12] <@dberkholz> araujo: just have a template of some sort sitting on woodpecker
-[0:37:25] <@dberkholz> devs can grab it and do whatever they need
-[0:37:35] <@dberkholz> if not a business card, some other document
-[0:38:05] <araujo> dberkholz, ok , so we won't need a script for this?
-[0:38:29] <@dberkholz> araujo: that depends how provable your proof has to be. i haven't seen digitally signed things from any job i've ever had
-[0:39:02] <@dberkholz> what are the requirements?
-[0:39:42] <araujo> dberkholz, it doesn't need to be something that complex, only a document specifying for how long you have been a Gentoo devel, and if you are still active
-[0:40:11] <araujo> something that can 'officially' prove you are a developer
-[0:40:11] NeddySeagoon [n=NeddySea@!hgentoo/developer/NeddySeagoon] has quit IRC: "what, what, what, what, what, what, what, what, what, what.  Only 10 Watts Neddy ?  Thats not very bright!"
-[0:40:39] rbrown [n=rbrown@!hgentoo/developer/paludis.rbrown] has left !c#gentoo-council
-[0:40:39] <araujo> it'd be nice if it is digital signed too
-[0:40:46] <araujo> digitally*
-[0:40:48] <@dberkholz> if we just had a pretty little scribus document that looked pretty and called itself a certificate of some sort, that might be enough?
-[0:40:59] <araujo> dberkholz, yeah, pretty much
-[0:41:32] <@jokey> maybe stuff like you can get from SETI
-[0:41:40] <@jokey> "You have solved X workunits" ;)
-[0:42:33] <araujo> this is just a way so you can prove 'on paper' you are cooperating with the project
-[0:43:37] musikc [n=musikc@!hgentoo/developer/musikc] has quit IRC: Read error: 110 (Connection timed out)
-[0:43:48] <tsunam> I had created 2 forms of letterhead when seemant needed to do a thing for another developer
-[0:43:51] pchrist [n=tester@!hunaffiliated/pchrist] has quit IRC: Read error: 110 (Connection timed out)
-[0:43:55] <tsunam> recommendation
-[0:44:09] musikc [n=musikc@!hgentoo/developer/musikc] has joined !c#gentoo-council
-[0:44:14] <tsunam> not exactly what you're talking about but
-[0:44:50] <tsunam> A standard form letter would work
-[0:44:56] <tsunam> (well should)
-[0:45:15] <araujo> or the dberkholz's certificate idea too , both would make it
-[0:45:15] <@jokey> indeed
-[0:45:25] <@dberkholz> except someone would have to actually sign a standard form letter, requiring effort from other people
-[0:46:07] <tsunam> I hereby certify that under perjury of $court of law that Mr berkholz is a developer for the Gentoo Linux Foundation. Undersigned by Joshua Jackson Gentoo developer etc
-[0:46:17] <araujo> dberkholz, sign once and scan then? :-P
-[0:46:23] <tsunam> dberkholz: would it be hard to get someone to do that?
-[0:46:33] <@dberkholz> tsunam: depends whether 1 person or 300 request them
-[0:46:34] <tsunam> araujo: no one would want their signature scanned like that
-[0:46:56] <araujo> tsunam, well, if it is hand-written per letter, *much better*
-[0:46:57] <@dberkholz> you'd have to deal with other annoying stuff like postage etc
-[0:47:32] <@jokey> well we could make all council members capable of signing such letters
-[0:47:49] <@jokey> and you pick the closest on then
-[0:47:52] <araujo> indeed
-[0:47:55] <@dberkholz> we could email out signed emails
-[0:47:57] <@dberkholz> would that work?
-[0:48:08] <araujo> dberkholz, it would work from my point of view
-[0:48:14] <@jokey> not really, corporate stuff hardly works with gpg
-[0:48:31] <araujo> what if we have both options available?
-[0:48:39] <tsunam> I'm not sure how willing an email would be as proof even if its from an @gentoo account for proof...
-[0:48:40] <@dberkholz> it does in the US, there's the e-sign act that's legally replacing an ink signature. not sure about other places
-[0:49:03] <@jokey> dberkholz: in germany you have to acquire some X509 at least
-[0:49:12] <@jokey> plus it's not equal in all cases
-[0:49:53] <@dberkholz> i don't think we need something that will hold up to a court of law
-[0:50:25] <Philantrop> dberkholz: No, but an email doesn't look very professional which would be a problem over here, at least. :) Much more than the legal stuff.
-[0:51:15] <@dberkholz> Philantrop: <html><img src="fancygentoologo" /></html>
-[0:51:31] <araujo> if you can agree on sending this letter to the actual developer (costs paid by devel of course) would be way much better, it'd be valid in a wider range of situations
-[0:52:14] <@dberkholz> araujo: the costs would basically be a pint, if you ever happened to meet. nobody's going to ask you to send them that kind of money.
-[0:52:25] <araujo> dberkholz, ok
-[0:52:48] <@dberkholz> it just gets to be a problem if certain people end up sending out huge numbers to foreign countries
-[0:52:54] <@Betelgeuse> The post expenses are probably smaller thatn the international money transfer expenses
-[0:53:21] <@dberkholz> i would much rather have something where the person who wants it can do all the work
-[0:53:40] <@dberkholz> either manually filling stuff into scribus, or some autogenerated doc like vapier said
-[0:53:45] <araujo> dberkholz, that'd be ideal ...
-[0:53:56] <@vapier> i wonder if you can combine the two
-[0:54:03] <@dberkholz> probably, it's just xml
-[0:54:17] <@vapier> ah, was not aware
-[0:54:36] <@vapier> do we have any scribus to start with ?  or does someone need to start from scratch ?
-[0:54:57] <@dberkholz> find . -name '*.sla*'
-[0:56:09] <@vapier> araujo: you any good at scribus ? ;)
-[0:56:11] <Philantrop> dberkholz: I totally agree with that. The Scribus variant would be my personal favourite but an automated doc is fine, too. Just email is not ideal. :)
-[0:56:18] <@dberkholz> think there's some stuff floating around
-[0:56:23] <@dberkholz> i can do scribus
-[0:56:40] <@jokey> ack, scribus would look even nicer :)
-[0:56:46] <araujo> vapier, haha, not really, but i can help
-[0:57:00] <@vapier> so we'll follow up to the dev list
-[0:57:08] <@vapier> see if there are any quick takers
-[0:57:13] dberkholz notes his above comment
-[0:57:16] <@vapier> ive toyed with scribus and it doesnt seem terribly difficult
-[0:57:22] <@jokey> still at least I'm willing to offer hand-signed if developer who requests it pays shipping
-[0:57:24] araujo can help dberkholz 
-[0:57:37] <@vapier> dberkholz: well i was just trying to get the guy who wanted it to do it :)
-[0:57:38] <@dberkholz> aha, gentoo-projects/pr/ has some scribus stuff
-[0:57:49] <@vapier> scribus base + automated fill in + digital signing
-[0:57:52] <araujo> jokey, yes, I think it's good idea to offer 'both' ways
-[0:57:54] <@vapier> see if we cant get infra to do somethin
-[0:58:00] <@dberkholz> i can come up with a scribus template, araujo can deal with the rest
-[0:58:04] <tsunam> I'd probably say that quite a few developers wouldn't mind having something official that says "I worked on the project" to be honest
-[0:58:20] <@dberkholz> tsunam: perhaps we should start handing out little pins for years of service too =)
-[0:58:25] <xjrn> wow, seems like nukes and htmldoc could do the whole thing to validate an account has a status into a pdf mime/download ...
-[0:58:25] <tsunam> dberkholz: lol
-[0:58:38] <tsunam> dberkholz: now you're getting the idea ;)
-[0:58:45] <tsunam> dberkholz: gold watch after 25 years? :-P
-[0:58:51] <araujo> dberkholz, ok
-[0:58:56] <@dberkholz> something along those lines wouldn't be a bad idea, actually. i'll look into it.
-[0:59:06] <@dberkholz> not with actual expensive stuff, but at least personal emails
-[0:59:11] <araujo> so, any council member will be able to sign it?
-[0:59:27] jokey is for that
-[0:59:30] <@dberkholz> araujo: we'd probably just come up with a signing key that would autorun somewhere
-[0:59:31] <tsunam> I would say that the council would be the body that would be the best choice
-[0:59:59] <araujo> dberkholz, ok
-[1:00:00] <@dberkholz> perhaps get it signed by the releng key, unless there's a more master key around
-[1:00:24] <@jokey> could even generate a council key if needed
-[1:00:41] <@vapier> tsunam: you think we're made out of money ?
-[1:00:45] <@vapier> how about a pen
-[1:00:51] <@vapier> that's all i get at a real job
-[1:00:52] <tsunam> vapier: heh
-[1:00:55] <@vapier> a goddamn pen
-[1:01:03] <@vapier> oh and a pin
-[1:01:03] <tsunam> vapier: at least you get a pen...
-[1:01:17] <@jokey> "I've been with gentoo for 3 years and all I got is this damn T-Shirt" ;)
-[1:01:23] <araujo> hah
-[1:01:23] <@vapier> tsunam: you can have mine
-[1:01:26] <@dberkholz> how about fake glass jewels on your nametag. (nametag purchased separately)
-[1:01:38] lu_zero heads to bed
-[1:01:44] <@lu_zero> nite
-[1:01:48] <araujo> later lu_zero
-[1:01:55] <@dberkholz> jokey: yeah, it might not be a bad idea to come up with a master gentoo key if we end up having more than 1 purpose for it
-[1:02:11] <@dberkholz> one we could hide in a fireproof vault somewhere and only remove once a year
-[1:03:14] <@jokey> don't even need that... make it "Gentoo Council Signing Key 2007-2008" and invalidate when new council is approved
-[1:03:36] <@vapier> it sounds like a key for recruiters to maintain
-[1:03:43] <@vapier> they are the in/out gateway after all, not the council
-[1:04:10] <@Betelgeuse> vapier: in only
-[1:04:16] <@Betelgeuse> vapier: different team doing retirement
-[1:04:22] <@dberkholz> there's "undertakers" now
-[1:04:37] <@dberkholz> doesn't that cool name make you want to join?
-[1:04:58] <@jokey> want just one point agreed on explicitely: will council members be allowed to sign such documents on behalf of gentoo?
-[1:05:22] <@dberkholz> perhaps so, but they should somehow log their actions like that
-[1:05:25] <@vapier> infra then i guess since they are the real care takers of this information
-[1:05:36] <@vapier> recruiters/undertakers update the same db
-[1:05:51] <@vapier> it's a key signing fest
-[1:06:01] <tsunam> ultimately it needs to reside with someone...and as it appears there's not one group its perfect for...
-[1:06:06] <tsunam> who would actually accept the duty?
-[1:06:07] <@jokey> dberkholz: as in send a notification to council@?
-[1:06:13] <araujo> I guess you (the council) will have to track the signing of these documents?
-[1:06:35] <@dberkholz> jokey: or something else that people don't see unless they go looking for it, like a file in cvs
-[1:06:48] igli [n=igli@!hunaffiliated/igli] has left !c#gentoo-council: "Have a good one ;-)"
-[1:07:05] <@dberkholz> tsunam: it sounds like devrel in some way to me, wherever it falls in there
-[1:07:22] <@vapier> yeah
-[1:07:49] <tsunam> well that's 4 groups now, recruiters,hatchetmen (aka undertakers),council,devrel
-[1:08:12] <@dberkholz> recruiters+undertakers all fall into devrel. we could just hand it off to devrel lead to take from there
-[1:08:47] <@dberkholz> imagining devrel as a sort of HR dept, and council as executives, this seems like something that's clearly HR
-[1:08:48] <@vapier> yes
-[1:08:59] <tsunam> very valid point dberkholz
-[1:10:27] <@dberkholz> so, where to proceed from here
-[1:11:02] <@jokey> dberkholz: you and araujo looking into a scribus'ed template, devrel generating a signing key for these purposes?
-[1:11:44] <@dberkholz> musikc: around again?
-[1:13:28] <@jokey> could we agree on that plan and then close the meeting if there's nothing else? 1 a.m. here already ;)
-[1:13:54] <araujo> fine with me :-)
-[1:13:59] welp [n=welp@!hgentoo/developer/colchester-lug.member.welp] has quit IRC: Read error: 110 (Connection timed out)
-[1:14:22] <@dberkholz> jokey: sounds good
-[1:14:50] <@jokey> k' then
-[1:15:05] <@dberkholz> let's close up shop for this month
-[1:15:12] <@jokey> indeed
-[1:15:20] <@dberkholz> jokey: you're on summary/log committing and mailing duties
-[1:15:42] <@jokey> dberkholz: yup, written it already, can you quickly glance over it to spot potential typos? ;)
-[1:16:19] <araujo> dberkholz, brb in a few minutes, then I can look into this
-[1:16:43] <@dberkholz> jokey: could you try to add a one-line summary for each topic, right whether the topic name is. like GLEP 54: Postponed to -dev. etc..
-[1:17:10] <@dberkholz> s/compability/compatibility/
-[1:17:21] <@dberkholz> s/techincally/technically/
-[1:17:28] <@dberkholz> s/optionl/option/
-[1:17:46] <@dberkholz> s/compatibiliy/compatibility/
-[1:17:58] <@jokey> wondering if there are dicts installed on dev.g.o
-[1:18:17] <@dberkholz> could you note in CoC that i'll provide them on the -council mailing list
-[1:19:00] ulm [n=ulm@!hgentoo/developer/ulm] has left !c#gentoo-council: "ERC Version 5.2 (IRC client for Emacs)"
-[1:25:40] <@jokey> we're closed then. thanks for the discussion to everyone involved :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080214-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080214-summary.txt
deleted file mode 100644
index 4bd799e2ff..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080214-summary.txt
+++ /dev/null
@@ -1,126 +0,0 @@
-Quick summary
-=============
-
-Code of Conduct enforcement
----------------------------
-	Promote individual devs responding to people who are being jerks.
-	Keep responses private, unless that person gets out of hand.
-
-	dberkholz will get things going.
-	To help or get advice, contact him.
-
-GLEP 46: Allow upstream tags in metadata.xml
---------------------------------------------
-	Approved, with a caveat:
-		Clarify reasoning for protocol restriction to http:// and https://
-
-EAPI=1: Where is the approved specification?
---------------------------------------------
-	A long discussion was had about using EAPIs without a spec.
-
-	Halcy0n is getting the PMS ready for EAPI=0.
-	To help, contact him so we can get it done and approved ASAP.
-
-Roll call
-=========
-
-(here, proxy [by whom] or slacker?)
-
-amne        here
-betelgeuse  here, but 1h20m late of the 2h meeting [server problems]
-dberkholz   here
-flameeyes   here
-lu_zero	    here
-vapier      proxy [halcy0n]
-jokey       here
-
-Updates to last month's topics
-==============================
-
-	http://www.gentoo.org/proj/en/council/meeting-logs/20080110-summary.txt
-
-	Code of Conduct enforcement
-	---------------------------
-	Last month:
-		Council members agreed on the direction.
-
-		dberkholz will provide additional details on -council ML
-	Updates:
-		dberkholz posted a simple suggestion to -council last night:
-		http://archives.gentoo.org/gentoo-council/msg_ba125098c929ea31f34051dfb009d436.xml
-
-		The basic idea is to just promote individual devs responding to
-		people who are being jerks. Privately, unless things get out of hand.
-
-		Council supported the implementation.
-		dberkholz will get things going.
-
-	Document of being an active developer
-	-------------------------------------
-	Last month:
-		dberkholz and araujo will look into a scribus based template.
-
-		Devrel will have to generate a signing key for these purposes.
-	Updates:
-		araujo was working on a script to automatically insert data into XML
-		in scribus or inkscape formats. He said he would work on it
-		this weekend.
-
-		Template file on hold pending format decision from script
-
-		Any news from devrel on key? dberkholz pinged musikc for an update.
-
-	Slacker arches
-	--------------
-	Last month:
-		vapier will work on rich0's suggestion and repost it for 
-		discussion on -dev ML
-	Updates:
-		No changes.
-
-	GLEP 54: scm package version suffix
-	-----------------------------------
-	Last month:
-		Sent back to -dev. peper was to repost it.
-	Updates:
-		No discussion on -dev. No resubmission to council.
-
-	GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
-	-------------------------------------------------
-	Last month:
-		Sent back to -dev
-	Updates:
-		No discussion on -dev. No resubmission to council.
-
-New topics
-==========
-
-GLEP 46: Allow upstream tags in metadata.xml
---------------------------------------------
-	http://www.gentoo.org/proj/en/glep/glep-0046.html
-	http://archives.gentoo.org/gentoo-dev/msg_46d474d621455bc204654dc483e87cc5.xml
-
-	Approved, with a caveat
-		Questions were raised about requiring http:// and https:// only.
-		What about ftp:// ? What about no limitation, and requiring 
-		tools to throw out protocols they don't recognize?
-		Why is that restriction there?
-
-		Once those questions are resolved, it will be finalized.
-
-EAPI=1: Where is the approved specification?
---------------------------------------------
-	http://archives.gentoo.org/gentoo-dev/msg_e1b4a369534e30b8a64c6c6429cfe729.xml
-
-	A long discussion was had about whether we should continue using 
-	EAPI=1 when we don't have EAPI=0 approved, reverting EAPI=1, and the 
-	value of specifications in producing quality code. People generally 
-	agreed about not adding any new EAPIs until the PMS for EAPI=0 is 
-	approved, but there wasn't agreement on changing anything about 
-	EAPI=1.
-
-	To make forward progress, Halcy0n agreed to work on getting the PMS 
-	ready for EAPI=0. He asked for anyone else interested to contact him 
-	so we can get it done and approved ASAP.
-
-	Halcy0n will give us an update at the next council meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080214.txt b/xml/htdocs/proj/en/council/meeting-logs/20080214.txt
deleted file mode 100644
index 09fb276e82..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080214.txt
+++ /dev/null
@@ -1,454 +0,0 @@
-20:00 < Flameeyes@> we're up in a minute
-20:00 <      amne@> wheeeeeee
-20:00 <    jeeves > dooooooork
-20:00 < Flameeyes@> actually, we're up, I think
-20:00 < Flameeyes@> jeeves, you act like a jerk ;)
-20:00 <   lu_zero@> hi
-20:00 <     jokey@> ho
-20:00 < Flameeyes@> roll-call!
-20:01 <      amne@> let's roll
-20:01 <   lu_zero@> seems to be the time now
-20:01 < Flameeyes@> amne, dberkholz, jokey, lu_zero, SpanKY, Betelgeus (e)?
-20:01  *  lu_zero rolls
-20:01 < dberkholz@> yep
-20:01 <     jokey@> yup
-20:01 < Flameeyes@> lu_zero, how many d20?
-20:01  *    jokey rolls as well
-20:01 <   lu_zero@> I'm cooking so I'll be here and there for the next 10 min
-20:01 <     jokey@> 18
-20:02 <   lu_zero@> time to have other people take care of the stuff
-20:02 < dberkholz@> Betelgeus, vapier, SpanKY: ping
-20:04  *  lu_zero is watching people cooking takoyaki while he is preparing some sort of soup and some venus rice is in the boiler
-20:04  *   araujo gets some tea
-20:05 < Flameeyes@> lu_zero, where on the world are you now?
-20:05 -!- rbrown [n=rbrown@gentoo/developer/paludis.rbrown] has joined #gentoo-council
-20:05 <      amne@> Flameeyes: i guess it's because of valentines day
-20:06 <    araujo > that's a good question .. don't you guys have a life?
-20:06 < dberkholz@> it's only noon here.
-20:06 < Flameeyes@> araujo, I think I do, but it's almost as good as new
-20:06  *   araujo thought he was the only one with no life
-20:06 < dberkholz@> this was a bad day to schedule a meeting. we should've moved it.
-20:07 <    araujo > yeah
-20:07 <      amne@> why that?
-20:08 <   lu_zero@> dberkholz right
-20:08 <    araujo > because it's valentines
-20:08 <    araujo > well, for those with a life
-20:08  *     amne has a life but valentine's day = no care :-P
-20:08 <   lu_zero@> ehm
-20:08 <   lu_zero@>  lupercalia you mean
-20:08 < dberkholz@> alright, let's give the slackers till :15 and then get rolling. go for a walk or something
-20:09 <      amne@> heh
-20:09  *   araujo walks in circle around the room
-20:09 < dberkholz@> that's about 5 minutes for the time-challenged
-20:09 <   Halcyon > Pretty sure vapier isn't going to make it, he told me he wasn't feeling well last night, so I am going to fill in for him.
-20:10  *  lu_zero gots some time to cook other weird stuff 
-20:10 < dberkholz@> Halcyon: i just want to check whether he actually asked you to proxy, or you're just offering to fill in now
-20:11 < dberkholz@> ok, just got some queried goodness from Halcyon 
-20:11 < dberkholz@> that leaves Betelgeus with 4 minutes to show up
-20:11 <   lu_zero@> ^^;
-20:12  *    jokey moves quickly upstairs
-20:12 <    araujo > well, we have 30 minutes yet
-20:12 <    araujo > enough time for lu_zero to prepare sushi for everyone here
-20:13 <   Halcyon > I already had sushi today...no more please.... :P
-20:13 <     jokey@> heh
-20:13 <     jokey@> sushi
-20:13 <     jokey@> mmmmm
-20:14  *   araujo should get some for dinner
-20:14 <    araujo > hiho jokey
-20:15 < dberkholz@> ok, let's get going.
-20:15 < dberkholz@> everyone's got the agenda?
-20:15 < dberkholz@> if not, it's in /topic
-20:15 <     jokey@> yup
-20:16 <    araujo > dberkholz, shouldn't we wait 30 more minutes?
-20:16 < dberkholz@> araujo: how long do you want to wait? it's not that hard for people to be on time, or even within 15 minutes of on time
-20:16 <   lu_zero@> I'd wait other 15 and then call the slackers
-20:16 <    araujo > just saying ... since it says is at 2000 UTC
-20:17 < dberkholz@> and it's 20:17 utc
-20:17 <      amne@> who's effectively missing now?
-20:17 < dberkholz@> Betelgeus
-20:17 <      amne@> well, i think that's enough people and if he shows up late that works for me too
-20:18 <      amne@> as long we don't have a vote where his voice is resolving a tie or something...
-20:18 < dberkholz@> it really shouldn't be that tough for people to show up on time or ask someone to proxy. this lack of respect for the rest of us is not acceptable
-20:18 <   lu_zero@> =/
-20:18 <     jokey@> just start
-20:18 <      amne@> yeah
-20:18 <   lu_zero@> dberkholz I could think about N situations that are cause of incidents
-20:18 <   lu_zero@> including network outage
-20:18 <   lu_zero@> anyway
-20:19 <   lu_zero@> let's go
-20:19 <    araujo > :-P
-20:19 <     jokey@> we have slacker marks damnit ;)
-20:19 < dberkholz@> first, progress on last meeting's topics
-20:19 < Flameeyes@> dberkholz, you sounded like Darth Vader, but keep on going :)
-20:20 < dberkholz@> only one with any discussion worth speaking of is the CoC thing, again.
-20:20 <   lu_zero@> sigh
-20:20 <   lu_zero@> fine with your latest idea
-20:21 <     jokey@> yup, that looked okay to me as well
-20:21 < dberkholz@> i'm going to just move on with making this happen. if it goes fine, no need to bother with anything further
-20:21 <      amne@> good
-20:21 <   Halcyon > Sounds like a plan.
-20:21 < Flameeyes@> nice to hear
-20:22 <     jokey@> dberkholz++
-20:22 <      amne@> if there's some place found, i'd be interested hanging out there a bit just to see what's going on and probably giving some advice if people want to hear it
-20:22 <      amne@> other than that i have not too much interest to get involved deeper though, nor the time
-20:23 < dberkholz@> various folks have brought up the idea of groups not working and such, so might just have some public IRC backchannel for discussing stuff before posting on -dev. not sure about that
-20:23 < dberkholz@> anyway, i think we're set on that point
-20:23 <      amne@> yeah
-20:25 < dberkholz@> nothing more to talk about in old topics
-20:25 < dberkholz@> in new topics, we've got glep 46
-20:25 < dberkholz@> i'll give ya a couple minutes to review it again
-20:26 <      amne@> is anyone from the glep folks around?
-20:26 < dberkholz@> do you have specific questions?
-20:27 <      amne@> yeah, 2 minor things
-20:29 < dberkholz@> vanquirius isn't on irc, dev-zero's idle 8 hours, ciaran's away
-20:29 <      amne@> well, actually it's just one thing:
-20:29 < dberkholz@> you'd think that people with an agenda item would attend the meeting
-20:29 <      amne@> changelog should contain a URL prefixed with http:// or https:// where the location of the upstream changelog can be found.
-20:30 <      amne@> same for doc - not really likely for most packages, but perhaps this should be extended for ftp://
-20:31 < dberkholz@> i'm curious why it needs to specify the allowed protocols
-20:31 <      amne@> there are some projects that only host on ftp, iirc vsftpd is one of them
-20:32 <      amne@> e.g. ftp://vsftpd.beasts.org/users/cevans/untar/vsftpd-2.0.6/Changelog, which is linked on http://vsftpd.beasts.org/
-20:32 <      amne@> dberkholz: following my thoughts further that leads to your question, yeah
-20:33 < Flameeyes@> dberkholz, I suppose for the software to be prepared to read that protocol
-20:33 < Flameeyes@> but I admit a generic URI would be nicer
-20:33 < Flameeyes@> for instance it would be easier to point to an svn:// url
-20:33 < dberkholz@> just reject stuff you don't know how to handle
-20:35 <      amne@> ah right, the other thing that may be a bit confusing (at least to me): there's maintainers and maintainers
-20:35 <      amne@> one of them is upstream (as specified inside the upstream tags) and the other one the gentoo maintainer
-20:35 <      amne@> still, this may be a bit confusing (or is it just me)
-20:35 < Flameeyes@> not just you for sure
-20:36 < dberkholz@> being part of the upstream hierarchy makes that reasonably clear to me
-20:36 <   Halcyon > In the structure its going to be put into, it seems sane enough to me as well.
-20:37 < Flameeyes@> ambiguos no, a bit confusing yes to me, but I ca cope with it :)
-20:37 < dberkholz@> if i'm looking at an appropriately indented metadata.xml with that, it's pretty straightforward
-20:37 <      amne@> ok, works for me then, just wanted to make people aware before they notice it later and cry about it ;-)
-20:39 <      amne@> ok, so we're happy with that then i think
-20:39 < dberkholz@> right. so what do we want to do with this?
-20:39 < dberkholz@> it's pretty much approveable, but there's the protocol question
-20:40 <   lu_zero@> I'd just update and approve
-20:40 < Flameeyes@> if possible, I'd say approve it without protocol limitation
-20:40 < dberkholz@> i suppose we could approve it with that caveat attached, which must be resolved before it can be officially "approved glep"
-20:40 <      amne@> yupp
-20:40 < dberkholz@> there might be a reason for that, which we don't know
-20:40 <   Halcyon > So, no protocol limitation at all, or do we want to come up with a sane set?
-20:41 < Flameeyes@> that's a good reason for the proposers to be around when the council discuss a glep :P
-20:41 < Flameeyes@> Halcyon, I'd say "valid URI" and that would be it
-20:41 < dberkholz@> Halcyon: i think that's a question for the authors to answer, not us
-20:41 < Flameeyes@> if we need a proper valid uri list...
-20:41 <   Halcyon > The only reason I can think of is that you'd need who knows how many tools to be able to access the various SCMs (for example)
-20:41 < Flameeyes@> dberkholz, does freedesktop have anything on that?
-20:42 <   Halcyon > dberkholz: yea, I'm just kind of throwing it out there, for what is going to be asked of them.
-20:42 < dberkholz@> i don't know
-20:44 <      amne@> just looked through the old and new threads, seems this wasn't discussed
-20:45 <     jokey@> maybe people didn't even think about that or assumed it
-20:46 <      amne@> (or i'm not seeing it of course)
-20:46 <      amne@> jokey: i'd guess so
-20:46 <     jokey@> at least I would assume it without further thinking
-20:47 <      amne@> well, i consider it rather a minor detail that needs to be figured out while the rest of the glep looks good to me
-20:47 <     jokey@> same here
-20:47 < dberkholz@> alright. let's vote on approved with caveat
-20:47 <     jokey@> I'm all for it
-20:48 <   Halcyon > Sounds good
-20:48 < dberkholz@> yes from me
-20:48 <      amne@> so if it's fine with you folks we could just approve it under the condition it'll be discussed
-20:48 <      amne@> i type too slow
-20:48 < Flameeyes@> good for me
-20:48 <      amne@> ++ from me if not clear already
-20:48 < dberkholz@> great.
-20:48 < dberkholz@> next topic, another one that keeps coming up, is eapi
-20:48 < dberkholz@> Halcyon wants a spec
-20:49 <   Halcyon > s/Halcyon/lots of people :) /
-20:49 < dberkholz@> ok, 3 people
-20:49 < dberkholz@> one of whom is here to discuss his desires
-20:49 <   Halcyon > I definitely want it from a QA perspective as well.  Its hard to enforce something when there is no official spec.
-20:50 < dberkholz@> Halcyon: is there some particular part that's unclear?
-20:50 <   lu_zero@> the fact it isn't on a single paper?
-20:51 <   Halcyon > Correct.  The fact that we don't have a clear specification of what EAPI=0 is, and what was added to it, in a document that can be easily referenced for new developers or people writing package managers or qa.
-20:51 <   Halcyon > PMS seems to fill this void, but we don't have an approved version of it that defines EAPI=0 and 1.
-20:51 < dberkholz@> it's in ebuild(5) in two places if you search for /EAPI 1
-20:52 -!- wolf31o2|work [n=wolf31o2@gentoo/developer/wolf31o2] has joined #gentoo-council
-20:53 <   Halcyon > And I just dragged wolf31o2|work in here since he has the same feelings as I do.
-20:53 <wolf31o2|w > ehh... hi
-20:53 < dberkholz@> Halcyon: ok, we don't have EAPI=0 specification approved. so there isn't anywhere that we can point to that has a spec of it.
-20:54 <   Halcyon > So, if the ebuild manpage is our specification, what purpose does PMS have?  I'm just trying to understand where we are going to have all of this documented.
-20:55 <   Halcyon > And it would be nice for other package managers to be able to point to a document that they are implementing (I don't think paludis or pkgcore want to use our ebuild manpage)
-20:55 < dberkholz@> anyone else think we almost have too many sources of ebuild documentation?
-20:55 <     Opfer > Here!
-20:55 <      amne@> dberkholz: exactly my thoughts
-20:55  * Flameeye  
-20:56 <wolf31o2|w > for sure
-20:56 <wolf31o2|w > heh
-20:56 <   Halcyon > dberkholz: definately, which is why I'm trying to figure out where all of this is going to be documented.
-20:56 <     jokey@> thing is
-20:57 <     jokey@> specs don't help people writing ebuilds, they just help PMs
-20:57 < dberkholz@> Halcyon: i'd say put it into the devmanual
-20:57 <   lu_zero@> eh
-20:57 <   Halcyon > I guess the real thing we need to figure out is, what are the purposes of these pieces of documentation, and what should they contain? 1) ebuild manpage 2) Devrel dev handbook 3) QA's devmanual 4) PMS
-20:57 < dberkholz@> have a section that will list EAPI additions
-20:58 <     solar > EAPI= additions are being done on the fly and are illy defined
-20:58 <wolf31o2|w > 2 should be development policy-only, IMO...
-20:58 <      zlin > jokey: it certainly helps ebuild devs when there's a dispute about whether a bug is an ebuild bug or a pm bug..
-20:58 < dberkholz@> the ebuild manpage should be a reference, and i think it does a reasonably good job of that. it also pretty much duplicates a chunk of the dev handbook (not devmanual)
-20:59 <   Halcyon > jokey: the spec helps everyone to know what is valid (especially QA)
-20:59 -!- tsunam [n=tsunam@gentoo/developer/tsunam] has joined #gentoo-council
-20:59 <   lu_zero@> and a way to enforce QA includes have the PM helpers
-20:59 <   lu_zero@> so it's fine having a sane spec
-21:00 <   Halcyon > lu_zero: the problem is that we do not have a specification document that is approved right now for what should be implemented for an EAPI=1 compliant PM.
-21:00 <wolf31o2|w > a specification also defines how the PM should act... so one knows what functions to use/not use, given a desired outcome...
-21:01 <wolf31o2|w > we don't even have it for EAPI=0
-21:02 <     jokey@> Halcyon: thing is, both paludis and pkgcore have hit a bunch of corner cases which haven't been defined and won't be unless you either reverse-spec the portage code or hit those cases
-21:02 -!- Pesa [n=Pesa@151.16.87.94] has joined #gentoo-council
-21:03 < dberkholz@> the devmanual feels like an extended reference, with the same reference material but also additional descriptions. still not a tutorial, though.
-21:03 <   Halcyon > jokey: which is why we should have defined EAPI=0 before we decided to tack things on.  We don't even completely know how Portage is supposed to behave is what I'm reading in your statement.
-21:03 <   Halcyon > But, that's beside the point since we are where we are now.  Working on, and getting a complete specification that is approved by the council should be the end goal.
-21:03 < dberkholz@> well, we can define a difference in behavior as EAPI=1
-21:04 <      zlin > dberkholz: same reference material as what?
-21:04 <     solar > Halcyon: has the topic of GLEP's for EAPI >0 additions been discussed here yet?
-21:04 <wolf31o2|w > dberkholz: only after EAPI=0 is defined
-21:04 < dberkholz@> zlin: as ebuild(5), as the dev handbook's section on the same content on ebuild(5)
-21:04 <   Halcyon > solar: no, I was just going to raise that.
-21:04 < dberkholz@> wolf31o2|work: i think we can define a set of conditions that were not guaranteed before but are after without also specifying everything else that happens before and after
-21:05 <   Halcyon > dberkholz: those conditions could interact with thigns that are not specified as well though, in that case.
-21:05 <wolf31o2|w > dberkholz: then why even bother? why not just tack it all onto EAPI=0 and say that there's no specification yet and everything is EAPI=0
-21:05 <wolf31o2|w > exactly
-21:05 < dberkholz@> maybe EAPI=0 should even be built up from smaller chunks like that
-21:05 < dberkholz@> just so we can make some progress on getting it approved
-21:06 <wolf31o2|w > *nothing* is specified at this time... so any conditions would be against what, exactly? a best-guess?
-21:06 <   Halcyon > So, just to get this somewhat focused again, here are a few things I would like answers to (and I think we can answer them)
-21:06 <NeddySeago > EAPI-0 is history with EAPI-1 being in use. Why spend effort documenting EAPI-0 ?
-21:06 <    tsunam > erm...
-21:07 < dberkholz@> EAPI=1 isn't a complete replacement of everything in EAPI=0, NeddySeagoon 
-21:07 <   Halcyon > 1) What should be the purpose of PMS?  Is this going to be the document that gives the complete spec and is approved before introducing new EAPIs.
-21:07 <    tsunam > eapi=1 is seeking to expand on eapi=0
-21:07 <NeddySeago > dberkholz my understanding is that its a superset
-21:07 <   Halcyon > NeddySeagoon: so what did it build upon?  That's why we need to know.
-21:08 <    tsunam > NeddySeagoon: as well believe that eapi=0 eapi=X if that's the way it goes...are to be interoperable so that one doesn't violate another...etc
-21:08 <   Halcyon > But, before we go all over the place, lets take this on a point by point basis please :)
-21:08 <NeddySeago > tsunam, Ah yes ... I had overlooked the interoperability
-21:09 <   Halcyon > So, does anyone have an answer for my #1? :)  I have more to follow.
-21:09 <     jokey@> Halcyon: +1 and even over to -dev ML :)
-21:10 <   Halcyon > jokey: yes, it will need to go there as well, but I'd like to atleast get intial input from the council.
-21:10 -!- Opfer [n=Opfer@gentoo/developer/opfer] has quit ["Leaving."]
-21:11 < dberkholz@> i think it's important to approve PMS as EAPI=0 specification. i'm not convinced that needs to happen before we can define other EAPIs.
-21:11 <      zlin > wolf31o2|work: we bother to avoid breaking every portage that doesn't support slot deps or iuse defaults...
-21:11 < dberkholz@> i am more interested in not blocking new features we need
-21:11 < dberkholz@> the problem is that not having PMS of EAPI=0 approved makes it difficult to refer to it as a good source for anything else
-21:12 <   Halcyon > dberkholz: I agree we shouldn't impede upon progress, but we need to know the foundation we are building upon before piling more on top of it.
-21:13 <   Halcyon > But, we do agree that PMS should be the PM agnostic specification (resources, reference, whatever) that is to be approved before EAPI features are introduced in the tree? (once we clean up where we are at now and get PMS up to speed)
-21:14 <     solar > once the PMS is final.. No additions really should be added to it w/o hitting the GLEP process. Then there should be a fixed period of time before ppl just start using it.
-21:15 <   Halcyon > solar: that's kind of what I"m getting at.  I'm just trying to see if everyone else agrees too :)
-21:15 < dberkholz@> the whole fixed period of time thing is the reason for EAPI...
-21:15 < dberkholz@> s/the/a/
-21:16 <      amne@> Halcyon: i think that makes sense, yes
-21:16 <    tsunam > We're talking about something that effects a LOT of people
-21:16 -!- Betelgeuse [i=betelgeu@a88-114-31-12.elisa-laajakaista.fi] has joined #gentoo-council
-21:16 -!- mode/#gentoo-council [+o Betelgeuse] by ChanServ
-21:16 < dberkholz@> i just took a look at PMS, and it defines the EAPI=1 features similarly to ebuild(5) -- all mixed in with the other text. it also adds a mention of ECONF_SOURCE, the part of it most people don't care about.
-21:16 <   Halcyon > 2) Okay, and if PMS is not up to par by the time EAPI=2 comes around, the council will still be approving that before people add it to the tree, correct?
-21:16 < Flameeyes@> hi Betelgeuse
-21:17 <     solar > who defined it and when? Who approved those additions?
-21:17 <   Halcyon > dberkholz: I'll be actively working on PMS soon, so I'll be cleaning it up and making it easier to look through.
-21:17 <      amne@> Halcyon: can you re-word your question? not sure if i understand it correctly
-21:18 <      amne@> Halcyon: you mean eapi=2 needs to be approved before it will be used in the tree?
-21:18 <   Halcyon > amne: yes.
-21:18 <   Halcyon > Regardless of the status of PMS at that point in time.
-21:18 <      amne@> ah
-21:18 < dberkholz@> i agree that non-zero EAPIs have to be approved by the council before they can be used in the tree
-21:19 <   Halcyon > Okay, and we agree that PMS should be the single point of reference for EAPIs?
-21:19 <Betelgeuse@> Flameeyes: Stupid connection stuff.
-21:20 <Betelgeuse@> Well better late than never.
-21:20 <  g2boojum+> I assume that the concern is not that the various PMs are getting out of sync w/o a well-defined EAPI, but that features are going in w/o some sort of official channel?
-21:20 <Betelgeuse@> Flameeyes: can you upload logs so far somewhere?
-21:20 <   Halcyon > g2boojum: partly that is my concern.  My other concern is to know where the problem really lies when something doesn't work as expected.
-21:21 < Flameeyes@> Betelgeuse, http://rafb.net/p/OwynUu65.html
-21:22 <   Halcyon > So, I will begin actively working on PMS and hopefully by next month I will have made some progress on getting it closer to being "complete".  At that point in time we can assess where we are at and take it from there?
-21:23 < dberkholz@> that sounds reasonable
-21:24 <      amne@> Halcyon: if there is a complete PMS (or at least one that can be expected to be complete soon) as a basis for future eapis, that surely would be the best way to do things
-21:24 < dberkholz@> since this is another issue tied to package managers, i'd certainly want to hear from their devs before approving EAPI=0
-21:24 <   Halcyon > amne: it should have been how we started before we moved forward, but we can't go back in time now, so I want to make it better :)
-21:25 <      amne@> Halcyon: agreed - sounds great
-21:26 <Betelgeuse@> Halcyon: I don't see a problem in defining EAPI 1 before 0 is finished
-21:26 <Betelgeuse@> as it only add things
-21:27 <   Halcyon > Betelgeuse: we already discussed why that isn't a good way to look at it.  What are you adding onto?  How does it interact with what we started with?  Etc
-21:27 <wolf31o2|w > wait... you see no problem with allowing adding to a specification that's undefined?
-21:27 <Betelgeuse@> wolf31o2|work: If the other option is waiting for months to get the spec finished, then no.
-21:27 <     solar > Halcyon: Re: take it from there. So does that mean that ebuild-devs need to stop using the undefined EAPI=1 stuff in the tree?
-21:27 <    tsunam > Betelgeuse: because eapi0 isn't finished...we don't have a solid basis on which to base anything off of. Its like having 1 brick as a base then building horizontally on top of it...You'll get top heavy and topple over
-21:28 <wolf31o2|w > Betelgeus: rather than spending resources to actually... you know... finish the specification and make it usable, thereby actually *resolving* the issue rather than working around it
-21:28 <   Halcyon > solar: I don't think we are going to be able to convince people of that.
-21:28 <Betelgeuse@> wolf31o2|work: That would work if we could make people work on it.
-21:29 <Betelgeuse@> solar: Why?
-21:29 < dberkholz@> it's not undefined. it's just not defined in precisely the way some of you apparently want it to be.
-21:29 <    tsunam > wow...
-21:29 <     solar > uhh
-21:29 <wolf31o2|w > Betelgeus: how about "You won't be able to use EAPI=* where * != 0 until the spec is finished and approved and if you want the features, help get the spec complete" ?
-21:29 <wolf31o2|w > you know... that works just *great* for professional software development... why should we work differently than the established best practices for software engineering?
-21:30 <Betelgeuse@> wolf31o2|work: Well tons of Java stuff use EAPI 1 already so don't see going back.
-21:30 <wolf31o2|w > ...and?
-21:30 <wolf31o2|w > actually... never mind
-21:30 <Philantrop > Betelgeuse: As does KDE 4. We won't go back either.
-21:30 <   Halcyon > wolf31o2|work: solar: I don't think we are going to be able to go back, but I hope that everyone here does see what happened here, and learns from it atleast.
-21:31 < dberkholz@> well, imagine people are saying this about EAPI=2 instead of EAPI=1, and it has USE deps.
-21:31 <   Halcyon > Making progress is what we all want, but not at the cost of shooting ourselves in the foot down the road.
-21:31 <    tsunam > in essense we already are shooting ourselves in the foot
-21:31 <Betelgeuse@> But any way I did raise these concerns when zmedico initially brought EAPI 1 to gentoo-dev
-21:31 <      amne@> yeah, let's focus on how we can do that
-21:31 <      amne@> making progress, not shooting into our feet
-21:31 <    tsunam > progress would be having a full spec
-21:31 <wolf31o2|w > indeed
-21:31 <      amne@> as far i see it, Halcyon seems to be pretty motivated to finishing it
-21:32 <     solar > lets see. Head of releng, head of the x86 team, head of QA, head of hardened/embedded are all sharing our concerns and ppl are still putting undefined shiny little features ahead of everything else that matters.
-21:32  *    solar is proud to be apart of this team sometimes
-21:32 < dberkholz@> things that matter to you are not things that matter to everyone else in gentoo...
-21:32 < dberkholz@> if they matter to you, work on 'em. i know y'all do that anyway
-21:32 <Betelgeuse@> solar: I don't think I said that I would agree with how things went about.
-21:32 <    tsunam > dberkholz: same goes for you
-21:32 <      amne@> so if there are some people actively working on pms, do you see it finished within a reasonable timeframe?
-21:32 < dberkholz@> tsunam: precisely. so people should work on things they care about. that's how oss goes
-21:32 <Betelgeuse@> But I don't see any reason to stop using EAPI 1 now.
-21:33 <    tsunam > dberkholz: we can run that one into the ground if you want
-21:33 -!- ferdy [n=ferdy@gentoo/developer/ferdy] has joined #gentoo-council
-21:33 <wolf31o2|w > solar: that's pretty much the way I see it... and what I'm hearing is that best practices for software engineering... you know, the stuff designed to allow for this sort of collaboration, should take a back seat to "progress"
-21:33 <   Halcyon > Well, we could go at each other all day, but it isn't going to get us anywhere (fortunately or unfortunately).
-21:34 <   Halcyon > To move forward here (in a sane way), I am going to get PMS done as quickly as I can.  Everyone that is interested in helping me, please let me know.
-21:34 <NeddySeago > We are where we are ... how do we get to where we need to be ?
-21:34 <   Halcyon > I am going to be vehemently opposed to introducing any new EAPI's into the tree until we have EAPI=0 and EAPI=1 defined in a full spec.
-21:34 -!- hparker [n=hparker@gentoo/developer/hparker] has quit [Remote closed the connection]
-21:34 <   Halcyon > We can't go back from where we are (again fortunately or unfortunately), so lets all try to work together to ensure that things that you want to work on, don't make things I want to work on a living nightmare.
-21:35  *    jokey can live with not introducing new stuff but we have to keep eapi=1 now
-21:35 <wolf31o2|w > why?
-21:35 <Betelgeuse@> Halcyon: sounds good
-21:35 <wolf31o2|w > why do we have to keep it?
-21:35 < Flameeyes@> I agree with Halcyon
-21:35 <wolf31o2|w > can anyone actually explain that one?
-21:35 <      amne@> i think Halcyon's suggestion is good
-21:35 <NeddySeago > Halcylon ... timescales ?
-21:35 <   Halcyon > wolf31o2|work: I'm saying we have to keep it just because I don't want to get into a long drawn out fight that isn't going to get me anywhere.
-21:35 <   Halcyon > NeddySeagoon: when it gets done.  The more help I have, the faster I can get it done.
-21:36 <wolf31o2|w > Halcyon: so we're allowing the proliferation of EAPI=1 to continue into the tree?
-21:36 < dberkholz@> we're also allowing the proliferation of EAPI=0 to continue into the tree...
-21:37 <   Halcyon > wolf31o2|work: I don't see anyway of stopping it at this point.  Not without causing many many people to get into a useless flamewar.
-21:37 <      zlin > wolf31o2|work: have you really forgotten which council decided that pms wasn't important?
-21:37 <wolf31o2|w > dberkholz: without a specification of EAPI=0 and EAPI=1, there is *NO* EAPI, at all... so your point is completely moot
-21:37 <Betelgeuse@> Why is there an open floor?
-21:37 < dberkholz@> if there's no eapi, you aren't arguing about anything
-21:38 < Flameeyes@> Betelgeuse, we decided not to moderate unless needed
-21:38 <wolf31o2|w > zlin: is there a point you're trying to make or are you just trying to point fingers because you don't have anything useful to contribute to the conversation?
-21:38 < dberkholz@> because we just arbitrarily add new features whenever we feel like it
-21:38 <Betelgeuse@> Flameeyes: could be
-21:38 <wolf31o2|w > dberkholz: that's my point, entirely...
-21:38 < Flameeyes@> Betelgeuse, could be needed? :P
-21:38 <wolf31o2|w > dberkholz: there's nothing stopping me from adding EAPI=wolf31o2 and doing whatever I damned well please with it...
-21:38 < dberkholz@> council never approved your eapi. =P
-21:39 <    tsunam > dberkholz: has the council approved EAPI=1?
-21:39 <   Halcyon > wolf31o2|work: I'm willing to bend on somethings, so long as we don't screw up again in the future, and it seems to me that we are in agreement on that, mostly....
-21:39 <   Halcyon > tsunam: yes, they did actually.
-21:39 <wolf31o2|w > tsunam: no, but they approved its *use*
-21:39 <Betelgeuse@> Flameeyes: Just saying that I have no recollection either way.
-21:39 < dberkholz@> we approved EAPI=1 and cited the 3 features that included
-21:39 <Betelgeuse@> wolf31o2|work: well isn't that the same thing?
-21:40 <wolf31o2|w > Betelgeuse: show me the specification and I'll agree... otherwise, no it is not the same thing, at all
-21:40 <     solar > ok so thats the end of EAPI=1 and now we are on to =2 ?
-21:40 < Flameeyes@> I'm going to infringe lu_zero's copyright and just say "yawn"
-21:40 <Betelgeuse@> wolf31o2|work: So you argue that EAPI=1 must be written down to exist?
-21:40 < dberkholz@> does anyone feel like we're making any progress in this discussion, with the exception of Halcyon committing to working on the PMS?
-21:41 <    tsunam > wow...again
-21:41 < Flameeyes@> dberkholz, no
-21:41 < dberkholz@> thi sis 21:39 <wolf31o2|w > tsunam: no, but they approved its *use*
-21:41 < dberkholz@> woops
-21:41 < dberkholz@> this is not going anywhere that i can see
-21:41 <Betelgeuse@> Yep
-21:41 < Flameeyes@> dberkholz, agreed
-21:41 -!- solar [n=solar@smtp.gentoo.org] has left #gentoo-council []
-21:41 -!- wolf31o2|work [n=wolf31o2@gentoo/developer/wolf31o2] has left #gentoo-council ["Leaving"]
-21:43 <   Halcyon > And do we agree that EAPI=2 can be held off until we get an approved specification done?  I don't even think EAPI=2 is on the radar yet, so please just keep PMS and myself in mind when it does come around.
-21:43 <      amne@> so. back to constructive?
-21:43 <   Halcyon > I'll hopefully be completely done by that point in time.
-21:43 < Flameeyes@> Halcyon, agreed
-21:43 <     jokey@> Halcyon: +1 on that
-21:43 <   lu_zero@> fine...
-21:43 <      amne@> Halcyon: as long it doesn't take a trillion years for PMS, i think that's a good plan to stick to
-21:43 <   Halcyon > amne: if it does, you can override me (the council is the only group capable over overriding QA anyway :) )
-21:44 <   Halcyon > But I don't see it taking that long if I can get some movement going on it.
-21:44 <   lu_zero@> btw could we have the specs in rfc format?
-21:44  *    jokey fetches one of Halcyon's cars and overrides him just in case ;
-21:44 <   lu_zero@> (or a format that isn't yet another one)
-21:45 <   Halcyon > lu_zero: I'll see how it is now, how flexible it is, and take it from there.
-21:45 <   Halcyon > In the end though, its probably going to be what I'm most comfortable with (like devmanual) since no one else is going to work on it for the most part.
-21:45 <      amne@> Halcyon: i wouldn't want to do that as i'd rather like to see someone actively working on it anyway :-)
-21:46 <Betelgeuse@> Halcyon: Considering that zmedico hasn't implemented use deps yet it's coming very soon
-21:47 -!- kingtaco|laptop [n=kingtaco@gentoo/developer/kingtaco] has joined #gentoo-council
-21:47 <   Halcyon > Betelgeuse: I'm sure it can wait a few weeks if we are making progress with PMS.
-21:47 <   Halcyon > People have waited this long, another few weeks isn't going to kill anyone.
-21:47 <Betelgeuse@> Halcyon: Has someone said something would be coming in few weeks that I missed?
-21:47 <   Halcyon > Betelgeuse: I'm not even sure what you are saying now, could you rephrase?
-21:48 <   Halcyon > You said zmedico hasn't implemented use deps, so it will be coming very soon?  What's coming, EAPI=2?
-21:48 <   Halcyon > What is "soon"?
-21:49 <Betelgeuse@> Halcyon: I don't think there is any timeframe for use deps. I remember zmedico saying he would do them last summer :D
-21:49 <Betelgeuse@> Halcyon: So I wanted to know where the talk about a few weeks comes from as I don't understand it.
-21:49 <   Halcyon > Betelgeuse: okay, so we shouldnt' have a problem for quite awhile (since I'll have plenty of time to get PMS done)
-21:50 <   Halcyon > Betelgeuse: you said use deps would be coming soon.  I read that to mean as in any day now, so I was saying that using EAPI=2 could wait a few weeks if that was the case, so I could get documentation done.
-21:50 <Betelgeuse@> Halcyon: Seems I missed a not
-21:50 <   Halcyon > Betelgeuse: I thought so, which was why I got confused :)
-21:51 < dberkholz@> ok
-21:51 < dberkholz@> that's the last topic we had, and i'm please that Halcyon committed to some action so we're making progress
-21:51 < dberkholz@> pleased*
-21:52 < dberkholz@> are there any _new_ topics to bring up?
-21:52 <   Halcyon > Okay, and on that note, I have to run.  I will give you guys an update by the next meeting, if not before then.
-21:52 <      amne@> Halcyon++
-21:53 <      zlin > Halcyon: I think Betelgeuse was trying to say that if pms comes within a month or two it'll likely be very soon compared to use deps..
-21:54 <      zlin > or not
-21:54 <Betelgeuse@> use deps happens very fast after someone starts working on the
-21:54 <Betelgeuse@> m
-21:57 < dberkholz@> i've posted a summary at http://dev.gentoo.org/~dberkholz/20080214-summary.txt
-21:57 < dberkholz@> take a quick look through it
-21:58 < dberkholz@> Betelgeuse: do you think you should get a slacker mark?
-22:01 <      amne@> dberkholz: summary looks good, just one detail about glep 46:
-22:01 <      amne@> Approved, with a caveat
-22:01 <      amne@> did someone count?
-22:01  *     amne scrolls back
-22:01 < dberkholz@> yeah there was like 5 votes
-22:01 <      amne@> yeah, just saw it
-22:01 <      amne@> all fine then :-)
-22:02 <Betelgeuse@> dberkholz: I would let others decide.
-22:02 <Betelgeuse@> dberkholz: I would mark myself as late like with the timezone session.
-22:02 <      amne@> Betelgeuse: i guess it depends why you were late
-22:03 <Betelgeuse@> amne: Battling with the server.
-22:03 <      amne@> Betelgeuse: if you were busy watching chuck norris movies, then you're a slacker
-22:03 <Betelgeuse@> amne: You should see from your logs that it has been down for most of the day.
-22:03 <      amne@> well, that's fair enough for not being a slacker imho
-22:03 <      amne@> Betelgeuse: too lazy to check and i trust people easily
-22:04 <Betelgeuse@> amne: good, I counted on that.
-22:04 <Betelgeuse@> dberkholz: It should at least reflect that I was here for half of it.
-22:05 <      amne@> Betelgeuse: heh
-22:06 < dberkholz@> we really need to come up with some kind of rule for what to do when people are crazy late.
-22:06 < dberkholz@> this isn't the first time
-22:06  *  lu_zero is still cooking takoyaki
-22:06 <      amne@> lu_zero: don't starve while cooking
-22:06 <   lu_zero@> I'm trying...
-22:06 < dberkholz@> anyone else got thoughts or care?
-22:06 <Betelgeuse@> dberkholz: No they slack :D
-22:06 < Flameeyes@> dberkholz, I unfortunately got used to people being late
-22:07 < Flameeyes@> I live in italy after all, being on time is ... rare :P
-22:07 <      amne@> dberkholz: not really as long it doesn't makes us unable to work
-22:07 <      amne@> dberkholz: as for today, Betelgeuse was late, we started without him and i can live with that
-22:07 < dberkholz@> i'm gonna put him as here, since he was around for really the most important bit
-22:08 <      amne@> if we want to tighten up the rules, we can do that - not that i care a lot about whether it's done or not
-22:08 <Betelgeuse@> amne: I don't think that's important
-22:08 <Betelgeuse@> amne: You get what you vote for.
-22:08 <      amne@> Betelgeuse: heh
-22:08 < dberkholz@> might be a good idea to always have a backup proxy in case you're late
-22:09 <Betelgeuse@> dberkholz: That's true.
-22:09 <      amne@> Betelgeuse: if someone is always late, he'll get dropped from the council sooner or later, yes
-22:09 <Betelgeuse@> dberkholz: But people shouldn't be late that often.
-22:09 < dberkholz@> Betelgeuse: individual people, no, but 1 of 7 i think is higher chance
-22:10 < dberkholz@> well, i think we're pretty much done with the meeting part after the EAPI bit, so let's officially declare it over
-22:10 <      amne@> yeah
-22:10 <      amne@> unless anyone has anything left to say
-22:11 <      amne@> i'd like to say hi to my parents before the log closes
-22:11 < dberkholz@> i asked once already and nobody chipped in
-22:11 -!- Pesa [n=Pesa@151.16.87.94] has left #gentoo-council []
-22:11 <      amne@> dberkholz: ah, seems i missed that with all the excitement we had today
-22:13 < dberkholz@> ok, i'll send out the summary in a few minutes
-22:13 <      amne@> great, thanks dberkholz
-22:13 <   lu_zero@> ^^
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080313-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080313-summary.txt
deleted file mode 100644
index 6d21aeda13..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080313-summary.txt
+++ /dev/null
@@ -1,93 +0,0 @@
-Roll call
-=========
-
-(here, proxy [by whom] or slacker?)
-
-amne        here
-betelgeuse  here
-dberkholz   slacker [39 minutes late]
-flameeyes   here
-lu_zero	    here
-vapier      here
-jokey       here
-
-Updates to last month's topics
-==============================
-
-	http://www.gentoo.org/proj/en/council/meeting-logs/20080214-summary.txt
-
-	Document of being an active developer
-	-------------------------------------
-	No updates
-
-	Slacker arches
-	--------------
-	2 months ago:
-		vapier will work on rich0's suggestion and repost it for 
-		discussion on -dev ML
-	Updates:
-		vapier said he was going to work on it this weekend.
-
-	GLEP 46: Allow upstream tags in metadata.xml
-	--------------------------------------------
-	http://www.gentoo.org/proj/en/glep/glep-0046.html
-
-	Last month:
-		Caveat on approval about allowed protocols
-	Updates:
-		No updates; no authors present
-
-	EAPI=0
-	------
-	Last month:
-		Halcy0n was working on it
-	Updates:
-		Ciaran has been contributing and has committed quite a few 
-		things. Halcy0n hopes to work on it in the next couple of weeks. 
-		He informed us that Ciaran said when he finishes the environment 
-		tables, EAPI=0 is probably a week of solid work from having a 
-		draft for review.
-
-		Halcy0n wasn't around when the topic came up, so the above info 
-		was from after the meeting.
-
-New topics
-==========
-
-	Summer of Code
-	--------------
-	Should Gentoo devs be allowed to participate?
-
-	GNOME's policy is that they favor people who haven't contributed 
-	before, but they will accept great projects from contributors.
-
-	Decision: Council members will become additional SoC admins, and 
-	will serve as tiebreaker votes if they aren't actively participating 
-	in SoC project selection.
-
-	Decision: Gentoo SoC admins will decide whether non-contributors 
-	should be favored over contributors.
-
-	Package maintainers
-	-------------------
-	Proposed by killerx (anant)
-
-	Decision: We'll promote proxy-maintainers more -- GMN, website, etc.
-
-	amd64 arch team and big bug list
-	--------------------------------
-	Proposed by armin76 (raul)
-
-	kingtaco (mike) said it's hard to keep people interested in 
-	keywording.
-
-	Anyone interested has had permission to keyword and stabilize 
-	non-system packages since 2007.1 (see -core email from kingtaco with 
-	subject "AMD64 keywording").
-
-	Open floor
-	----------
-	A list of required attendees would be useful. dberkholz will start 
-	creating the agenda along with this list in advance of the meeting.
-	Posting the agenda on a google calendar, along with other stuff, 
-	could help. flameeyes is starting to work with the PR team on this.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080313.txt b/xml/htdocs/proj/en/council/meeting-logs/20080313.txt
deleted file mode 100644
index 546a30d520..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080313.txt
+++ /dev/null
@@ -1,665 +0,0 @@
-20:02 <      amne@> do we have an agenda somewhere?
-20:02 -!- Betelgeuse changed the topic of #gentoo-council to: Council meeting
-20:03 <     Jokey@> I think dberkholz was writing one
-20:03 <      amne@> good
-20:03  * ferringb stretches, if it's not on the agenda, eapi status would be lovely also
-20:03 <    fmccor > ferringb, No, not really you don't.
-20:03 <     Jokey@> as he always does ;)
-20:03  * ferringb turns off the red light in the meantime, and shuts up
-20:05 <     Jokey@> wondering where the other half is atm
-20:05 -!- mpagano|work [n=mike@pool-96-225-79-106.nwrknj.fios.verizon.net] has quit [Read error: 110 (Connection timed out)]
-20:05 <kingtaco|w > probably screwed by DST
-20:05 -!- mpagano [n=mpagano@gentoo/developer/mpagano] has quit [Read error: 110 (Connection timed out)]
-20:06  * kingtaco recalls this from last year
-20:06 <     Jokey@> time change or sth?
-20:06 <kingtaco|w > yeah
-20:06 <      amne@> yupp
-20:06 <kingtaco|w > US was last weekend
-20:06 <Betelgeuse@> Jokey: US goes to Summer time earlier
-20:06 <     Jokey@> ah
-20:06 -!- windzor [n=windzor@84.238.83.251] has joined #gentoo-council
-20:06 <    fmccor > Congress thinks it saves energy by making the days longer or something.
-20:06  *    Jokey waits for announcements on tv ;)
-20:07 <kingtaco|w > fmccor, actual results were more power consumption
-20:07 <kingtaco|w > congress--
-20:07 -!- Flameeyes [n=flame@amarok/helper/flameeyes] has joined #gentoo-council
-20:07 -!- mode/#gentoo-council [+o Flameeyes] by ChanServ
-20:07 <    fmccor > I think I saw that somewhere, too.
-20:07 <kingtaco|w > yeah, it was a joke
-20:07 <    fmccor > They forgot that it's dark in the morning, now.
-20:07 <    TFKyle > boo, people should just away with DST completely :)
-20:07  * Flameeye notes to himself: never write stuff down on the calendar _and don't look at it_
-20:08 <NeddySeago > Flameeyes, write that on the calendar :)
-20:08 <     Jokey@> should set up jabber announcements really ;)
-20:08 <      amne@> so, can we assume the rest isn't here until in an hour?
-20:08 <   KillerX > so we got to wait for another hour?
-20:08 <    fmccor > TFKyle, I agree, or work on standard time +1/2 all year
-20:08 <   KillerX > damn its late here :(
-20:08 <     Jokey@> KillerX: looks like it
-20:08 -!- lu_zero [n=lu_zero@gentoo/developer/lu-zero] has joined #gentoo-council
-20:08 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
-20:08 <   lu_zero@> hi
-20:08 < Flameeyes@> NeddySeagoon, I could write it on a whiteboard, and then forget about the whiteboard
-20:09 <   Halcyon > amne: actually, they should have been here an hour ago.  Its 1600 on the east coast.
-20:09 <      amne@> Halcyon: gah... i really hate time zones
-20:09 < Flameeyes@> 20UTC was ten minutes ago
-20:09 < Flameeyes@> [give or take a minute]
-20:09 <   lu_zero@> ^^
-20:09 -!- rane [n=rane@gentoo/developer/rane] has joined #gentoo-council
-20:09 < Flameeyes@> amne, so we can set next meetings on a stardate basis?
-20:10 <   KillerX > seconds from epoch
-20:10 <    vapier@> no, stars move
-20:10 <       ulm > hm, shouldn't people be one hour earlier if their local is on DST now?
-20:10 <   Halcyon > Thu Mar 13 16:10:01 EDT 2008
-20:10 < Flameeyes@> if so we have to decide whether to use TOS stardate or TNG stardate
-20:10 < Flameeyes@> ulm, DST means +1
-20:10 <      amne@> i'm for klingon time
-20:10 <   Halcyon > Flameeyes: which makes his statement true :)
-20:10 -!- vln- [n=v1n@unaffiliated/vln] has joined #gentoo-council
-20:10 <      amne@> IOW, it's always a good time to die
-20:11 < Flameeyes@> ah okay now I got what he meant, thought it as "in their timezone" :P
-20:11 <       ulm > Flameeyes: yes, that's why they should be early if the meeting is scheduled in UTC
-20:11 <    fmccor > true
-20:11 <Betelgeuse@> yeah they should have been early
-20:12 < Flameeyes@> so who is in dst?
-20:12 <    vapier@> ive been prowling for an hour
-20:12 <    vapier@> cause the topic said 1500 :p
-20:12 -!- shpaq [i=shpaq@gentoo/user/shpaq] has joined #gentoo-council
-20:12 -!- arachnist [i=arachnis@paludis/monkey/arachnist] has joined #gentoo-council
-20:12 <Betelgeuse@> So we are missing dberkholz
-20:12 < Flameeyes@> if google calendar wasn't seriously broken with konqueror I'd suggest we add a global gentoo calendar in there
-20:13 < Flameeyes@> and schedule stuff like meetings (not limited to council but also team meetings) and lastrites and similar...
-20:13 <   lu_zero@> Flameeyes I'd miss that
-20:13 <     Jokey@> Betelgeuse: most important our agenda guy :(
-20:13 < Flameeyes@> lu_zero, set it up to warn you via SMS
-20:13 < Flameeyes@> then you won't miss it :D
-20:13 <   lu_zero@> probably having an auto-im notification would do as well
-20:13 < Flameeyes@> lu_zero, hmm propose them a googletalk notification, I suppose that could be done
-20:13 <      amne@> date -d "2000 UTC"
-20:13 <      amne@> that one usually does the trick for me
-20:13 < Flameeyes@> they have sms notifications
-20:14 <Betelgeuse@> kingtaco|laptop: Do you or any other American have Donnie's phone number?
-20:14 <   Halcyon > Or....you could just remember to come :)
-20:15 <Betelgeuse@> Well imho should just get started.
-20:15 <Betelgeuse@> And find from the mailing list thread on what to talk about :d
-20:15 <      amne@> ++
-20:16 -!- antesenamon [n=antesena@host-89-230-10-219.bilgoraj.mm.pl] has joined #gentoo-council
-20:16 <antesenamo > Hi
-20:17 <kingtaco|w > Betelgeuse, nope, I don't...
-20:17 <kingtaco|w > Betelgeuse, solar might though
-20:17 <kingtaco|w > or ramereth
-20:17  * ferringb does
-20:17 < Flameeyes@> we should do like we did with last council and exchange contact information
-20:17 <kingtaco|w > ramereth almost certainly does
-20:18 <      amne@> so, let's just start without agenda and dberkholz?
-20:18 -!- lazy_bum [i=lazy_bum@chello081018206212.chello.pl] has joined #gentoo-council
-20:19 <Betelgeuse@> First thing I see is amd64 and their big bug list.
-20:19 < Flameeyes@> amne, I'd say so, I can't find an agenda on his devspace either
-20:19 <Betelgeuse@> But is there anything to discuss really?
-20:19 <Betelgeuse@> Thye need more people period
-20:19 < Flameeyes@> Betelgeuse, a bonus of 2 litres of beer for who closes most bug during the month of April?
-20:19 -!- spb [n=stephen@freenode/developer/spb] has joined #gentoo-council
-20:20 <  ferringb > sms'd donnie, so we'll see if he pops up.
-20:20 <Betelgeuse@> kingtaco|work: Any thoughts?
-20:20 <   lu_zero@> hm
-20:21 <kingtaco|w > Betelgeuse, ?
-20:21 <     Jokey@> what about status updates?
-20:21 -!- cla [i=cla@gentoo/developer/cla] has joined #gentoo-council
-20:21 <kingtaco|w > doing nothing but keywording sucks ass
-20:21 <kingtaco|w > hard to keep people interested
-20:21 <     Jokey@> vapier: you have the open task about slacker arches ;)
-20:22 <kingtaco|w > I gave everyone permission to keyword their own packages(outside of system) back when we were trying 2007.1
-20:22 <Betelgeuse@> kingtaco|work: Shouldn't you remove people who don't keyword anything from http://www.gentoo.org/proj/en/base/amd64/
-20:22 <kingtaco|w > I haven't rescended that
-20:22 <     Jokey@> besides GLEPs had no update so no discussion required either
-20:22 <Betelgeuse@> kingtaco|work: To at least make it reflect that you need more people
-20:22 <kingtaco|w > Betelgeuse, you mean fire a bunch of people, probably....
-20:23 <    vapier@> Jokey: yeah, ive done much in Gentoo ... too busy with work
-20:23 <Betelgeuse@> kingtaco|work: yes
-20:23 <    vapier@> i've got three things to get done this weekend and that's one of them
-20:23 <kingtaco|w > Betelgeuse, tbh, it's pretty low on the priority list
-20:23 <    vapier@> gcc-4.3.0, baselayout/openrc, slacker arches
-20:23 <kingtaco|w > not to mention I'm on leave
-20:23 <   Halcyon > vapier: I was going to ask you about gcc-4.3 this weekend actually :)  Let me know if you need help with anything.
-20:23 <kingtaco|w > (not that anyone respects that)
-20:23 <   lu_zero@> vapier about gcc-4.3.0 tell me how to help
-20:24  *  lu_zero has gcc-4.3.0 built already on the ps3
-20:24 <    vapier@> mostly testing
-20:24 <    vapier@> when i stick it in, start using it and get tracker bugs going
-20:24 -!- KillerX [n=anant@gentoo/developer/KillerX] has quit []
-20:25 <   lu_zero@> ok
-20:25 -!- ryker [n=ryker@76.16.114.60] has quit [Read error: 110 (Connection timed out)]
-20:25 <     Jokey@> what about we shift meeting one week and send people a notice to refresh the topics they promised to send input on?
-20:26 < Flameeyes@> Jokey, I have one topic myself
-20:26 <     Jokey@> okies
-20:26 <Betelgeuse@> Jokey: Also should talk about the 'package maintainer' post proposition
-20:26 <    vapier@> my topic wont be ready for one week ... has to let devs dust it out
-20:27 <     Jokey@> then we should formally start
-20:27 < Flameeyes@> about gentoo developers taking part in SoC as students
-20:27 <      amne@> Jokey: which topics are you refering to? i'm sure we have some we can discuss now (and if necessary still next week)
-20:27 <     Jokey@> anyone willing to take chair? :)
-20:27 < Flameeyes@> Jokey, you just volunteered yourself :)
-20:27 <      amne@> Jokey++
-20:27 <      amne@> :-P
-20:27 <Betelgeuse@> Jokey: I thought we already started :D
-20:27 <     Jokey@> #1
-20:27 <     Jokey@> roll call then
-20:28 <     Jokey@> all little councils show up please :)
-20:28  *     amne stands up
-20:28 <Betelgeuse@> \o_
-20:28 <   lu_zero@>  o/
-20:29  * Flameeye is here
-20:30 < Flameeyes@> vapier has fleed?
-20:30 <     Jokey@> looks like it ;)
-20:30 <    vapier@> ?
-20:30 < Flameeyes@> ah! we've seen you!
-20:30 <      amne@> ok, done with role call... dberkholz gets an MIA tag
-20:30 <     Jokey@> right
-20:30 < Flameeyes@> (this is going to be the less serious council meeting ever, by this pace)
-20:31 < Flameeyes@> can we start with an easy one?
-20:31 <     Jokey@> so, let's get topics first
-20:31 < Flameeyes@> okay one topic I can add is the one I proposed for soc: should we allow gentoo developers to take part in soc as _gentoo's_ students?
-20:31 <      amne@> amd64, new developer thingie between staff and full developer come to my mind
-20:32 <      amne@> Flameeyes: totally unprepared for that, have seen the thread on -dev, but not read it as it wasn't mentioned in the council meeting thread (or i've not seen it)
-20:32 -!- KillerX_ [n=anant@mnit.ac.in] has joined #gentoo-council
-20:33 <   lu_zero@> I'd leave it as up to the devs decide
-20:33 <Betelgeuse@> I would rather have existing devs doing quality stuff instead of new people doing crap.
-20:33 <      amne@> Betelgeuse: good point
-20:34 < Flameeyes@> amne, I tried to post it on gentoo-council but I'm having trouble to post there :/
-20:34 < Flameeyes@> Betelgeuse, I'd prefer new people doing something decent myself
-20:34 <      amne@> also a question: how many devs did we recruit from SoC so far per year?
-20:34 <      amne@> (probably answered on dev, not through yet)
-20:34 <Betelgeuse@> amne: I don't remember anyone going through us.
-20:34 < Flameeyes@> two last year
-20:34 < Flameeyes@> ah wait other way around
-20:34 < Flameeyes@> hm
-20:34 <     Jokey@> araujo at least
-20:34 <  KillerX_ > I'm one from the year before that
-20:34 < Flameeyes@> one, I think?
-20:34 <Betelgeuse@> KillerX_: Yeah from that we did get.
-20:34 < Flameeyes@> pioto too
-20:35 <Betelgeuse@> that was the year before
-20:35 <Betelgeuse@> I think
-20:35 < Flameeyes@> 2006
-20:35 <Betelgeuse@> yeah
-20:35 < Flameeyes@> 2007 was mostly a failure for non-devs
-20:35 <  KillerX_ > Yep, 2 from 2006
-20:35 <      amne@> ok, that's not so much.
-20:35 <Betelgeuse@> 2007 was failure from organizing pov too
-20:35 < Flameeyes@> can we forget about 2007 even existing? :)
-20:36 <   lu_zero@> right
-20:36 < Flameeyes@> anant, not sure if he was already around before 2006 soc though
-20:36 <      amne@> from my POV, the two main points it can do are a) providing new devs b) having existing devs do some work and get paid, so they have more time to do something for gentoo instead of earning money by mowing their neighbours lawn
-20:36 <   lu_zero@> still would be nicer avoid such bad esperience again
-20:36 < Flameeyes@> mdisney?
-20:36 <      amne@> for me both a) and b) sounds useful for gentoo
-20:36 <  KillerX_ > Flameeyes: I am anant :-p
-20:36 < Flameeyes@> KillerX_, ah... you confuse me! :P
-20:36 <   lu_zero@> ^^;
-20:37 <     Jokey@> heh
-20:37 <   lu_zero@> still I'd rather have more dev doing mentoring tasks
-20:37 <   lu_zero@> and make sure the slot we got doesn't get wasted
-20:38 <      amne@> Flameeyes: about your mail wrt how much money you get, i think SoC isn't that much focused on people with a regular jobs but rather students who do it as a summer job. and in that case working for gentoo could be a good alterntive to a "normal" job
-20:39 < dberkholz@> ah crap, my bad. i suck.
-20:39 <   lu_zero@> dberkholz !
-20:39 <     Jokey@> heh
-20:39 <   lu_zero@> you are ALIVE!
-20:39 <      amne@> oi dberkholz
-20:39 <     Jokey@> the slacker arrived :D
-20:39  *  lu_zero hugs dberkholz 
-20:39 < dberkholz@> i'm still a slacker.
-20:39 <      amne@> dberkholz: not if you brought an agenda :-)
-20:40 -!- akroplas [n=akroplas@gentoo/user/akroplas] has joined #gentoo-council
-20:41 -!- KillerX_ is now known as KillerX
-20:41 <      amne@> so, any more opinions/ideas/suggestions/questions wrt to that?
-20:42 < Flameeyes@> lu_zero, you scare me sometimes :P
-20:42 < Flameeyes@> amne, sincerely I'd rather leave up the slots for people wanting evne to try something new
-20:42 -!- lazy_bum [i=lazy_bum@chello081018206212.chello.pl] has left #gentoo-council []
-20:42 < Flameeyes@> it's not like there are no other projects than gentoo to contribute to
-20:42 <   lu_zero@> Flameeyes just sometimes?
-20:42 <      amne@> Flameeyes: is the number of slots limited?
-20:42 <     Jokey@> amne: yep
-20:43 <   KillerX > amne: yep
-20:43 < Flameeyes@> amne, yes, every organisation gets a number of slots
-20:43 < Flameeyes@> if there was unlimited choice of people, then I'd welcome everybody
-20:43 <     Jokey@> as we've been lucky last times, we had a bunch of slots
-20:43 <     Jokey@> not sure if it happens again but let's cross fingers :)
-20:43 < Flameeyes@> Jokey, 2007 less than 2006 though
-20:43 <   KillerX > They usually give distros more slots since we're counted as 'umbrella' organizations
-20:43 <      amne@> in that case, they should be sorted by some criteria, that should include how useful it is, chance of succes etc. i could imagine that being a potential new dev could play role here as _one_ point
-20:43 < Flameeyes@> and 2007 was quite a failure
-20:44 <   lu_zero@> Flameeyes right
-20:44 <     Jokey@> amne: proposals are voted on so you have a top list
-20:44 <   KillerX > yes that might impact our slots for 2008
-20:44 < Flameeyes@> if they are going to allocate slots based upon last year, we might not be as lucky
-20:44 <   lu_zero@> and I still wonder how not to end that way again
-20:44 <Betelgeuse@> Flameeyes: Why wouldn't existing devs be doing something new?
-20:44 <      amne@> Jokey: voted how? by us (being gentoo, not council)?
-20:44 <Betelgeuse@> Flameeyes: You aren't even allowed to just work on existing stuff.
-20:44 < Flameeyes@> Betelgeuse, because the project is just the same,
-20:45 <   KillerX > amne: All registered mentors can vote.
-20:45 <   KillerX > amne: Via the GSoC web interface (requires a google account)
-20:45 < Flameeyes@> Betelgeuse, I just would prefer different projects at that point
-20:45 <   KillerX > amne: Org. administrator approves mentors. Not sure who that is this year.
-20:45 < Flameeyes@> KillerX, even non-mentors but registered as admins, at least in 2006
-20:45 <Betelgeuse@> KillerX: We could easily make it go by council.
-20:45 <Betelgeuse@> KillerX: Just have some people vote based on the council decision.
-20:45 <      amne@> KillerX: ah. in that case i'd say, if the mentors think it's better to have projects from new guys than existing devs, it's up to them
-20:45 < Flameeyes@> KillerX, I think antarus or tsunam
-20:46 <   KillerX > amne: Yes, that about sums up the situation.
-20:46 < Flameeyes@> talking about which, we only have six people volunteering as mentors
-20:46 < Flameeyes@> it would be nice to have some more
-20:46 <      amne@> KillerX: works for me ;-)
-20:46 < Flameeyes@> and some more ideas for projects
-20:46 <     Jokey@> Flameeyes: add me in again, I forgot to send a mail your way ;)
-20:46 <   KillerX > But like Betelgeuse suggests, if we re-route the proposals to council for voting, the dev community might be able to have some impact on which ones are selected.
-20:47 < Flameeyes@> Jokey, err just commit it to the index.xml file :) no need to ask me :P
-20:47 <     Jokey@> KillerX: only problem is that proposals are not to be public if I recall it correctly
-20:47 < Flameeyes@> KillerX, well the easiest way is to make the council all register as admins... so we can see the proposals as they come
-20:47 <     Jokey@> only summaries are
-20:47  * Flameeye looks at the rest of the council
-20:47 <   KillerX > Jokey: Yes. We could discuss them on -core though?
-20:48 <   KillerX > Ah yes, Flameeyes' idea is much better
-20:48 <   lu_zero@> who is going to be the admin today?
-20:48 < Flameeyes@> KillerX, I don't think that's a good idea either, as there will be students reading there
-20:48 < Flameeyes@> [on -core I mean]
-20:48 <Betelgeuse@> Flameeyes: Weren't you against devs being students :D
-20:48 < Flameeyes@> lu_zero, well The admin as I said it's either antarus or tsunam afaics
-20:48 <   KillerX > you're right, registering council members as admins would be best
-20:48 < Flameeyes@> Betelgeuse, you just said you all aren't, so I assume I lost that battle :)
-20:49 < Flameeyes@> and yeah this is one more reason why I'd rather not have gentoo students being gentoo developers already
-20:49 <Betelgeuse@> I don't know if I can register to the admin side as I will be applying as a student.
-20:49 <    vapier@> so only have free members
-20:49 <     Jokey@> Betelgeuse: you can be admin or student for a project but not both
-20:49 -!- spb [n=stephen@freenode/developer/spb] has left #gentoo-council []
-20:49 <   KillerX > Betelgeuse: You can. As long as you're not marked mentor. I don't know if it's a bug or not, but I didn't complain :-D
-20:49 <   KillerX > admin != student
-20:50 <Betelgeuse@> KillerX: good
-20:50 <   KillerX > er, admin != mentor I mean
-20:50 <   KillerX > :-/
-20:50 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080313-summary.txt -- anyone like it?
-20:50 < Flameeyes@> Betelgeuse, student for which project? ;)
-20:50 <     Jokey@> dberkholz +1 :D
-20:51 <Betelgeuse@> Flameeyes: I haven't decided projects to apply for.
-20:51 <Betelgeuse@> Flameeyes: Orgs yes.
-20:51  *    Jokey /dev/null's his half-summary
-20:51 < Flameeyes@> Betelgeuse, orgs is what I meant
-20:51 <Betelgeuse@> Flameeyes: I am pretty sure I can get in via my Free/Java contacts.
-20:51 <   KillerX > you can't mentor and student at the same time even for different projects
-20:51 < Flameeyes@> Betelgeuse, so I suppose it's not gentoo ;) then there is no conflict of interest :P
-20:52 <Betelgeuse@> Flameeyes: I can of course apply for Gentoo too.
-20:52 <Betelgeuse@> Flameeyes: Bad experience last year thoug.
-20:52 <   KillerX > Umm, Google might object, you should check on that.
-20:52 <   KillerX > Since you'll be able to rate your own proposal in that case ;)
-20:53 <Betelgeuse@> KillerX: Just need to leave Gentoo out then.
-20:53 <   KillerX > Yes. You can be admin for Gentoo as long as you apply to a different org as a student.
-20:53 < Flameeyes@> either way, even if it's just Betelgeuse, I suppose the rest of the council can just as well join as admin for soc
-20:54 <     Jokey@> ack
-20:54 <Betelgeuse@> So should we vote on who decides who gets our slots?
-20:54 <Betelgeuse@> All admins or just council.
-20:54 <      amne@> Betelgeuse: imho admins
-20:54 < dberkholz@> the admins already have experience doing it, seems like they'd be valuable
-20:54 < Flameeyes@> I'd sincerely say admins, with council breaking up ties if anything
-20:54 <   KillerX > Coming back to the issue, I think all proposals should be rated based purely on their merit, not on the basis of who the proposer is.
-20:55 < dberkholz@> isn't that part of the merit? the likelihood of the person applying to finish the task based on his/her experience and knowledge?
-20:55 <   KillerX > That would form a part of the merit, yes. But it's also possible for a non-gentoo-dev to have that kind of experience and knowledge.
-20:56 < dberkholz@> sure, i agree
-20:56 <     Jokey@> like ex-portage devs f.ex ;)
-20:57 <     Jokey@> oh wait, jstubbs became dev again, didn't he?
-20:57 <   KillerX > I remember the gnome folks had a similar debate, let me see if I can find out where that ended
-20:59 < Flameeyes@> debian has one too
-21:00 <   KillerX > "Since an important goal of the Summer of Code for us is to get new contributors, we'll try to avoid accepting students who already participated in a GNOME-related SoC/WSOP project or who is already a GNOME contributor (thus, this does not apply to students who participated in SoC, but in a totally unrelated to GNOME project). However, this is not a strict rule: if a student in such a case proposes a really great project, we'll accept his/
-21:01 <   KillerX > that's from the gnome wiki
-21:02 < dberkholz@> so basically affirmative action for non-contributors
-21:03 <   KillerX > something like that
-21:08 <      amne@> anyone else got something to add?
-21:08 < Flameeyes@> I'll just leave the decision up to you guys
-21:08 <   lu_zero@> not much
-21:09 < dberkholz@> seems like a reasonable way to go to me
-21:09 < dberkholz@> what are the admins doing right now?
-21:09 < dberkholz@> do we even need to make a decision on this?
-21:09 < Flameeyes@> dberkholz, waiting to see if we're accepted I suppose
-21:09 < dberkholz@> i mean irt the above policy, are they doing that or something else
-21:10 < Flameeyes@> I think right now we're all making our own choices
-21:10 <      amne@> dberkholz: you mean gnome's policy?
-21:10 < Flameeyes@> myself, I won't mentor students that are already devs
-21:10 < Flameeyes@> antarus said he will
-21:10 < Flameeyes@> not sure the others
-21:10 < dberkholz@> amne: no i mean our soc admins right now
-21:10 <      amne@> dberkholz: ah, yeah
-21:11 <      amne@> i'm for the admins doing their stuff
-21:14 <      amne@> ok...
-21:14 <      amne@> since no one really responds, could we just make a vote on anything?
-21:15  * Betelgeu votes for world peace
-21:15 <      amne@> like "we don't see a need to do something from council side and will our SoC people let do what they think makes sense"?
-21:15 <      amne@> Betelgeuse: hehe
-21:15 <      amne@> if someone has a better think (on topic) to vote on, feel free to propose it
-21:16 < dberkholz@> it would be nice if any of the admins were around to say their policy
-21:17 < Flameeyes@> lu_zero
-21:17 < Flameeyes@> Jokey?
-21:17 < Flameeyes@> jmbsvicetto?
-21:17  * dberkhol  checks -dev
-21:18 <     Jokey@> I'm not admin (yet)
-21:18 <     Jokey@> I have been co-mentor last two years only
-21:18 < Flameeyes@> Jokey, I thought you were interesting to be :P
-21:18 <     Jokey@> yup;)
-21:18 < Flameeyes@> [noone is admin right now anyway as we haven't been accepted yet]
-21:20 -!- ulm [n=ulm@gentoo/developer/ulm] has quit [Remote closed the connection]
-21:20 -!- ulm [n=ulm@gentoo/developer/ulm] has joined #gentoo-council
-21:21 <   lu_zero@> hm?
-21:22 <Betelgeuse@> let's move on
-21:22 <Betelgeuse@> Or this meeting will be quite long
-21:22 <      amne@> yeah, kind of slowish today
-21:22 <     Jokey@> ack :)
-21:22 <      amne@> please folks, smoke less weed and abuse more amphetamines next time ;-)
-21:23  *  lu_zero has been killed by bureaucracy this morning
-21:23 -!- antesenamon [n=antesena@host-89-230-10-219.bilgoraj.mm.pl] has quit [Remote closed the connection]
-21:23 <   lu_zero@> I crumbled asleep at about 5.40PM
-21:24 <   KillerX > +1, it's getting late here (3 am already)
-21:24 -!- antesenamon [n=antesena@host-89-230-10-219.bilgoraj.mm.pl] has joined #gentoo-council
-21:25  *    Jokey looks at next topic
-21:25 <      amne@> if we wait til the next council meeting to finish this, would it be too late for SoC?
-21:25 <     Jokey@> I think so,
-21:25 < dberkholz@> we don't need to wait for scheduled meetings
-21:25 < dberkholz@> we can have an interim one, or just vote on the -council list
-21:26 <   KillerX > amne: Yep, student projects would have been accepted by then.
-21:26 <   lu_zero@> what is left to be discussed?
-21:26 <     Jokey@> we should keep the option to have a quick meeting based on what we hear from soc
-21:26 <      amne@> KillerX: gah
-21:26 <      amne@> dberkholz: ok, let's do it like that
-21:26 <Betelgeuse@> Well didn't we decided to a) register as admins b) devs can be students c) admins decide which ones are approved
-21:26 <Betelgeuse@> ^Does anyone object to the above
-21:26 <   KillerX > sounds good
-21:26 <   KillerX > mentors can, of course, refuse to mentor devs who apply as students (what Flameeyes will do :-D_
-21:27 <Betelgeuse@> yes
-21:27 <      amne@> Betelgeuse: not really, but having some more details from our admins can't hurt
-21:27 <   lu_zero@> I'm ok on having the council registered as admin
-21:28 <     Jokey@> +1 with lu_zero
-21:28 < dberkholz@> i'm not sure about council members being extra admins, but i don't have any strong position on that. the others are fine
-21:28 <   lu_zero@> I'd leave up to the single mentor to decide what to do with the slot
-21:28 <   KillerX > I must say reading the logs is a lot more fun that actually attending a council meeting :-p
-21:29 <   lu_zero@> still I care much about having more visibility on the process
-21:29 -!- genone_ [n=genone@gentoo/developer/genone] has quit [Read error: 104 (Connection reset by peer)]
-21:29 <   lu_zero@> the blog aggregation and stuff is fine in theory but should be enforced a bit more
-21:30 < Flameeyes@> we should really find more developers to sponsor projects and be ready to act as mentors
-21:30 < Flameeyes@> but we're coming late by now actually
-21:32 < dberkholz@> could someone briefly sum up the reason for having council people be soc admins?
-21:32 < dberkholz@> i tried reading the log but it didn't stand out
-21:32 <   lu_zero@> Flameeyes I forgot to put my proposal about the gentooificator
-21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
-21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
-21:32 -!- Philantrop [n=Philantr@gentoo/developer/philantrop] has quit [Read error: 104 (Connection reset by peer)]
-21:32 <   lu_zero@> now that you make me think
-21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
-21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
-21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
-21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
-21:32 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
-21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
-21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
-21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
-21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
-21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
-21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
-21:33 -!- Philantrop_ [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
-21:34 <     Jokey@> he should fix his client ;)
-21:34 -!- Philantrop [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
-21:34 < Flameeyes@> konversation, for sure...
-21:34 -!- Philantrop [n=Philantr@gentoo/developer/philantrop] has quit [Excess Flood]
-21:34 < Flameeyes@> [and too many channels, I suppose, never happened to me]
-21:34 -!- Philantrop [n=Philantr@gentoo/developer/philantrop] has joined #gentoo-council
-21:34 < Flameeyes@> dberkholz, well, in my view to break up ties
-21:35 < dberkholz@> ok, so council members will not be "active" admins, just tiebreakers?
-21:35 < Flameeyes@> well unless they want to be active admins/mentors I suppose :)
-21:35  * Flameeye will be an active admin/mentor
-21:36  *  lu_zero too
-21:39 <      amne@> well. so we just have people being admins/mentors and that's it?
-21:39 <      amne@> would work for me
-21:39 -!- mpagano [n=mpagano@gentoo/developer/mpagano] has joined #gentoo-council
-21:39 -!- ftpd [i=ftpd@gentoo/ricer/ftpd] has joined #gentoo-council
-21:40  *    Jokey drinks some coke
-21:40  * Flameeye looks angrily at Jokey 
-21:43 <     Jokey@> Flameeyes: want some, too? sugar-free ;)
-21:43 <     Jokey@> anyway
-21:43 <      amne@> time to move on to the next topic?
-21:43 < Flameeyes@> can't :/
-21:43 < Flameeyes@> amne, I'd say so, next toping would be?
-21:43 <   KillerX > package maintainer
-21:43 <   KillerX > let's finish that so I can go to sleep :-p
-21:43 <   lu_zero@> ok
-21:43 <     Jokey@> right, go ahead KillerX
-21:43 <   KillerX > to begin with, I'd like to find out what devs think a devs responsibility is
-21:43 <   johnjay > I'm not a developer anymore but can I put in my 2 cents here?
-21:43 <   KillerX > if all we do is write ebuilds and maintain them, then as folks pointed out in the mailing list, streamlining the recruitment process and adverstising proxy-maintainers more is the right way to go
-21:43 < Flameeyes@> myself I'd say the first and most important would be"don't hinder others" (users using the package, developers working with the package)
-21:43 <   KillerX > But, I think we can split devs into two categories: those who just write+maintain ebuilds, and others who do more wide-ranging stuff
-21:44 <   KillerX > the former don't need to give the staff quiz, and need access rights only to small portions of the repository
-21:44 <   lu_zero@> KillerX I'd like to know what's so horrible about the current recruitment process
-21:44 < dberkholz@> johnjay: put it in whenever you want, as long as it's on-topic =)
-21:44 <    vapier@> you'll have to be more specific
-21:44 <    vapier@> one package can be depended on by a lot more
-21:45 <   KillerX > lu_zero: It's too formal, and a lengthy procedure for someone who just wants to maintain 2 or 3 packages in the tree
-21:45 <   lu_zero@> KillerX no
-21:45 <   lu_zero@> I want something more detailed
-21:45 < Flameeyes@> KillerX, if one just wants to maintan 2 or 3 packages, I'd say proxy maintainership is the way to go
-21:45 <   lu_zero@> and to the point
-21:45 <    vapier@> also, there's the issue of global scope ... one bad ebuild can do mad things
-21:46 <   lu_zero@> I mean how many question we feed to the possible dev?
-21:46 <   KillerX > Giving proxy-maintainers commit access, and making the position "formal" will go a long way in attracting more contributors
-21:46 <   johnjay > When I was a developer, my goal was to make sure the pkg worked, and that I would always be ontop of the pkg news wrt to security, dev etc ... all things not necessarily only related to writing/maintaining the ebuild
-21:46 <   lu_zero@> how formal is the process by itself?
-21:47 < Flameeyes@> I sincerely think that as long as we don't have safeguards like staged trees, a way to sign singular ebuilds/manifests entries, a global gentoo keychain etc etc etc we should keep access to the repository limited to those who _does_ take the lengthy process
-21:48 <   johnjay > Also, is there some sort of digest lint's nowadays? Such that the committed Manifest is checked against the central repo?
-21:49 < Flameeyes@> johnjay, what do you mean?
-21:49 <   KillerX > vapier: The guy will still have to do the ebuild quiz. He can skip the bearucracy
-21:49 <   KillerX > (however that is spelt)
-21:50 <   johnjay > Flameeyes: sometimes when I emerge world, I will get a digest failed error, even though the file was fully received etc ... and this stops the entire process. Often times it's that the developer forgot to regenerate the digest or something along the lines...
-21:50 <Betelgeuse@> KillerX: What is the extra stuff besides doing the quiz?
-21:50 <Betelgeuse@> KillerX: Doing the quiz is the time taking part.
-21:51 < Flameeyes@> johnjay, uhhh the digest is handled altogether by repoman
-21:51 <   johnjay > Perhaps and I'm just throwing an idea out there, but a post-commit hook which would check the Manifest against the files on the central repo?
-21:51 < Flameeyes@> if a developer is committing without repoman I'd probably kick him myself ;)
-21:51 <   johnjay > Heh
-21:51 <Betelgeuse@> johnjay: Or just against the committed files...
-21:51 < Flameeyes@> other causes can be a) upstream changed the distfile (stupid upstream)
-21:51 <   johnjay > Well it does happen, often I find myself doing a --digest just to get through the process
-21:51 <Betelgeuse@> but OT
-21:51 < Flameeyes@> b) the infamous Attic/ problems with $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/Attic/20080313.txt,v 1.1 2008/03/14 07:14:13 dberkholz Exp $
-21:52 <   lu_zero@> I think we should go back to the main topic
-21:52 <   KillerX > hmm, alright
-21:52 < Flameeyes@> c) $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/Attic/20080313.txt,v 1.1 2008/03/14 07:14:13 dberkholz Exp $ in patches
-21:52 <   johnjay > Err sorry if I went off topic
-21:52 < Flameeyes@> yeah Betelgeuse and lu_zero are right :P we can discuss that in a separate forum
-21:52  *  johnjay goes away
-21:52 <   KillerX > Betelgeuse: the staff quiz?
-21:52 < Flameeyes@> KillerX, the staff quiz is just for staffer
-21:52 <   KillerX > damn I have a horrible lag :(
-21:52 < Flameeyes@> the two quizzes are the ebuild quiz and the end of mentoring quiz
-21:53 < Flameeyes@> [for ebuild developers, that is]
-21:53 <   KillerX > Flameeyes: All devs have to write the staff quiz.
-21:53 < Flameeyes@> KillerX, did it change in the last year?
-21:53 < Flameeyes@> because I came back as a dev less than an year ago and I only did ebuild and eom quizzes
-21:53 <   lu_zero@> how many questions it is?
-21:53 <   KillerX > Well that was the case when I was recruited...
-21:53 < Flameeyes@> 40?
-21:54 < Flameeyes@> KillerX, uh... I came in originally in 2005, I did have some recruits in 2006, I think you're probably confusing the staff quiz with the eom quiz
-21:54 < dberkholz@> one of those quizzes includes the gentoo hierarchy, when to use -core, etc stuff
-21:54 < dberkholz@> i think that's the section KillerX is talking about
-21:54 < Flameeyes@> should be part of the eom quiz iirc
-21:54 <   lu_zero@> still
-21:55 < Flameeyes@> but it's really more "a boring 10 minutes" imho rather than the lengthy part of the process.. just a way to make sure the person knows how to contribute properly...
-21:55 <   lu_zero@> how many questions are due to get devship?
-21:55 < Flameeyes@> lu_zero, about 40 iirc
-21:55 <Betelgeuse@> http://www.gentoo.org/proj/en/devrel/quiz/ebuild-quiz.txt
-21:55 <Betelgeuse@> http://www.gentoo.org/proj/en/devrel/quiz/end-quiz.txt
-21:55 <   KillerX > Well, we can't skip the technical questions, that's for sure.
-21:55 <Betelgeuse@> staff quiz == first part of ebuild quiz
-21:55 <   KillerX > and I think I'll agree with the fact that the staff quiz takes a lot lesser time than the other two
-21:56 <   lu_zero@> hmm
-21:56 <   lu_zero@> still you felt that the process is too taxing
-21:56 <   lu_zero@> if the quizzes aren't the problem
-21:56 <   KillerX > It is indeed, especially if your goal is just to maintain packages.
-21:56 < Flameeyes@> 45, I was near enough ;)
-21:57 < Flameeyes@> KillerX, then just accept proxy maintainership
-21:57 <   lu_zero@> what is the part we should overhaul?
-21:57 < Flameeyes@> maybe if we could move to, say, GIT, it would be simpler to be a proxy maintainer, but that's beside the point anyway
-21:58 <   lu_zero@> still I'd like to have some control about proxy maintenance
-21:58 <   KillerX > lu_zero: The quizzes themselves?
-21:58 < Flameeyes@> lu_zero, what you mean?
-21:58 <   lu_zero@> KillerX how?
-21:58 <   lu_zero@> Flameeyes make sure people don't abuse trust
-21:58 <   lu_zero@> KillerX 45 questions
-21:58 <   lu_zero@> that means at most 5 hours
-21:59 <   lu_zero@> 5 hours aren't exactly a long time
-21:59 -!- ftpd [i=ftpd@gentoo/ricer/ftpd] has left #gentoo-council []
-21:59 <   KillerX > lu_zero: Yes, but a lot of them test things which are not normally required for maintaining an ebuild
-21:59 < Flameeyes@> KillerX, like?
-21:59 <Betelgeuse@> KillerX: like?
-21:59 < Flameeyes@> Betelgeuse, jinx!
-21:59 <   KillerX > "Explain briefly the purpose of the following tools: grep, cut, sed, cat, wc, awk"
-22:00 <Betelgeuse@> KillerX: you are not going to use those in your ebuilds?
-22:00 <   KillerX > We should really avoid these exam type of questions
-22:00 <   KillerX > and get straight to the practical stuff
-22:00 <Betelgeuse@> or basic Unix command line utils in general
-22:00 < Flameeyes@> KillerX, uh, I might find awk optional, but the rest...
-22:00 < Flameeyes@> I admit the first time I took the test I just rephrased the first phrase in man $foo
-22:01 < dberkholz@> that seems pretty practical to me. explaining the purpose is about the same as saying when you need to do some task, you know which tool to use
-22:01 <   KillerX > er, sure you are, but it would be better to ask 'how would you do task XXX' instead of 'write a short description of YYY'
-22:01 <   KillerX > these essay-type questions take up maximum type to answer
-22:01 <   KillerX > s/type/time
-22:01 < Flameeyes@> essay-type? o_o
-22:01 < Flameeyes@> I sincerely think a single one-liner to explain each tool isn't an essay
-22:01 <Betelgeuse@> KillerX: What part of Explain briefly is unclear?
-22:01 <   lu_zero@> KillerX I'm afraid we perceive the questions and the possible answers differently
-22:01 < Flameeyes@> and probably is simpler than providing a solution to an use case
-22:02 < Flameeyes@> especially since the use case someone might solve using, say, perl
-22:02 <      igli > hehe
-22:02  * Betelgeu uses inline python for solving eclass problems
-22:02 <   KillerX > heh
-22:02 < Flameeyes@> Betelgeuse, better than java for sure ;)
-22:02 <Betelgeuse@> Flameeyes: I need to work with xml in eclasses
-22:02 <   lu_zero@> Flameeyes inline C
-22:02 < Flameeyes@> Betelgeuse, yes I know
-22:02 <   KillerX > alright, actually that was about the only theoretical question :-/
-22:03 < Flameeyes@> myself I have doubts about 5 and 6 (part I) of the ebuild quiz, for just ebuilders
-22:03 <   lu_zero@> KillerX sorry if you feel attacked
-22:03 < Flameeyes@> but they are two questions, about 40 seconds to answer each
-22:03 <   KillerX > lu_zero: Not at all, I see your point now.
-22:03 -!- antesenamon [n=antesena@host-89-230-10-219.bilgoraj.mm.pl] has quit ["Lost terminal"]
-22:03 <Betelgeuse@> Flameeyes: 6 is to avoid Seeds
-22:03 <   lu_zero@> still I'd like to solve the root of the problem
-22:03 <   KillerX > okay, so in conclusion - let's advertise the proxy-maintainer position more
-22:03 <      amne@> Flameeyes: if you know the answer, of course
-22:04 <   lu_zero@> why the process is considered that problematic
-22:04 <      amne@> but i guess the point of the quiz is that people know the answer afterwards
-22:04 < Flameeyes@> amne, I sincerely think to have access to the repository knowing the answer is a requirement
-22:04 <   KillerX > and maybe, somewhere in the distant future, we can move to a better VCS, wherein it would be easier for proxy-maintainers to make sure their code is committed.
-22:04 < Flameeyes@> Betelgeuse, note the "for just ebuilders" ;)
-22:04 < dberkholz@> KillerX: heh, check out bug #207056
-22:04 <    jeeves > dberkholz: https://bugs.gentoo.org/207056 enh, P2, All, kavol@email.cz->pr@gentoo.org, NEW, pending, please promote Sunrise overlay
-22:04 <      amne@> Flameeyes: yeah, but that's why people may take more than a couple of hours to complete the quiz
-22:05 < Flameeyes@> to be honest, whenever I consider someone for proxy maintainership, I ask for the second part of ebuild quiz to a minimum
-22:05 < Flameeyes@> amne, I'm not expecting anybody to become dev of _any_ project in less than a couple of hours
-22:05 < Flameeyes@> do I even have to use Debian as an example?
-22:05 <Betelgeuse@> amne: It takes more than a couple hours to talk with me.
-22:05 <      amne@> Flameeyes: yeah, but that was the argument for having a new dev rank
-22:05 <     Jokey@> dberkholz: interesting bug
-22:06 <   KillerX > Well the basic idea was to make proxy-maintainers feel more recognized
-22:06 < Flameeyes@> amne, as long as you have access to the repository, I consider you a dev :P cvs acl might help but I wouldn't expect even a new position to take less than a couple of hours ... or even a couple of days
-22:06 <      amne@> Betelgeuse: that was wrt having the quiz done in a couple of hours as someone said above ;-)
-22:07 < dberkholz@> Jokey: agreed
-22:07 -!- arkanoid [n=arkanoid@236-252-235-85.static.dsl.webpartner.net] has joined #gentoo-council
-22:07 < Flameeyes@> KillerX, well we could even try to tune down the gentoo's developers status for that ;) for instace we could use less resonant mail addresses than @gentoo.org everytime we commit :P
-22:07 <   KillerX > :)
-22:08 <   KillerX > Git would solve the problem perfectly
-22:08 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)]
-22:08 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has joined #gentoo-council
-22:09 < Flameeyes@> KillerX, could easily create a few more though :P and we're talking about migrating to something else for... four years now?
-22:10 <Betelgeuse@> I think git wasn't a good option last time when looked at because of performance problems.
-22:10 <   KillerX > Well, it can't be helped until someone with loads of time joins infra
-22:10 <Betelgeuse@> I think those should could be solved by now.
-22:10 < dberkholz@> Betelgeuse: it was lacking features we want
-22:10 < dberkholz@> might be an soc project to implement those missing features
-22:10 < dberkholz@> robbat2 knows the details
-22:11 <   KillerX > indeed
-22:11 < Flameeyes@> dberkholz, yeah that would be a good idea indeed
-22:11 <   KillerX > Okay, so in summary - No need for a new position, adverstise proxy-maintainers/overlays more (i'll probably make a gmn article out of it ;)). Anyone has anything more to add?
-22:11 < Flameeyes@> KillerX, blog about it, works a lot too :)
-22:11 <      amne@> sounds good.
-22:12 <   KillerX > Heh, I was waiting for my feed to get fixed. just happened today :)
-22:14 -!- igli [n=igli@unaffiliated/igli] has quit [Read error: 104 (Connection reset by peer)]
-22:14 < Flameeyes@> by the way, I know this is more PR's work but as donnie is here...
-22:14 < Flameeyes@> any idea about a redesign of the site?
-22:15 <   lu_zero@> another misc item
-22:15 <   lu_zero@> what about stale gleps?
-22:15 < Flameeyes@> it is more than an year since Curtis disappeared, afaict, did the project volatilise entirely?
-22:15 <   lu_zero@> autoretire them after a while?
-22:17 < dberkholz@> Flameeyes: a few folks are playing around with it
-22:17 < dberkholz@> Flameeyes: basically looking to get the whole site moved to css but functionally identical, then consider redesign work as a second step
-22:17 < dberkholz@> Flameeyes: nichoj and ali_bush, mainly
-22:17 < Flameeyes@> dberkholz, okay I'm pleased to hear it is being worked on, that's enough to me :)
-22:18 < dberkholz@> we're doing it that way because it's a lot harder to object to a css move when it doesn't come along with a ton of visual changes too, so it should go through easily
-22:18 <   KillerX > alright folks, 4 am here, better go to sleep now else I'll miss class in the morning. Good night!
-22:18 < Flameeyes@> dberkholz, yeah agreed
-22:18 < dberkholz@> good night sir.
-22:18 <      amne@> bye KillerX
-22:18 < Flameeyes@> KillerX, sweet dreams
-22:19 -!- KillerX [n=anant@gentoo/developer/KillerX] has quit []
-22:20 <      amne@> so, on to the next point?
-22:20 < Flameeyes@> amne, what's the next point?
-22:21 <      amne@> uhm
-22:21 <      amne@> open floor? or did i miss anythin in the agenda?
-22:21 <Betelgeuse@> amd64
-22:21 <Betelgeuse@> but that was discussed briefly at the start
-22:21 <      amne@> yupp
-22:21 <      amne@> not sure if anyone wants to add to that now
-22:21 <Betelgeuse@> does anyone have anything to add?
-22:21 < dberkholz@> what's the amd64 summary, pleaes?
-22:22 <Betelgeuse@> http://rafb.net/p/Idqz6c86.html
-22:22 < dberkholz@> the other 2 things are the "old topics" -- what's up with glep 46 clarification, and eapi=0 progress from Halcyon 
-22:22 <Betelgeuse@> relevant log parts
-22:22 < Flameeyes@> Halcyon, you around for the eapi=0 update?
-22:27 <      amne@> anyone remember what happened with glep 46? i think there was a brief conversation with dev-zero after the meeting, but i don't remember the outcome, nor can i find it in my inbox
-22:27 <      amne@> and the glep hasn't been updated it seems
-22:27 -!- ferdy [n=ferdy@gentoo/developer/ferdy] has joined #gentoo-council
-22:30 <      amne@> uh well this meeting is really slow today
-22:33 < dberkholz@> well, that's all the topics since those folks aren't around
-22:33 <     Jokey@> gah
-22:33 <     Jokey@> distraction--
-22:34 <Betelgeuse@> anyone have open floor items?
-22:34 < dberkholz@> we seem to be doing a really bad job of actually having people we need at the meetings
-22:34 < dberkholz@> next time i make an agenda, i'll have to put together a list of people who need to show up
-22:34 < dberkholz@> that will of course also require that i actually make an agenda in advance, and show up on time myself
-22:34 <      amne@> dberkholz: sounds like a good idea
-22:34 <     Jokey@> dberkholz: yep, maybe we should have the agenda ready 24h before actual meeting so people can take notes to show up
-22:34 <      amne@> dberkholz: heh
-22:34 < Flameeyes@> dberkholz, we should think about using google calendar
-22:35 < Flameeyes@> if we actually decide upon that I might even use firefox :P
-22:35 <      amne@> someone (forgot who) also suggested to post the agenda on www.gentoo.org - if it's ready before the meeting, that could be done too
-22:35 < dberkholz@> Flameeyes: maybe so.
-22:35 < dberkholz@> seems like there might be enough meetings and such, and it's easier than setting up our own groupware
-22:36 < Flameeyes@> dberkholz, we could also use it to write down stuff like stabilisation plans and last rites and similar
-22:36 < Flameeyes@> could probably also avoid users to wonder "when is $foo supposed to go stable?"
-22:36  *    Jokey used to tag bug subjects with (due 13-03-2008)
-22:37 <     Jokey@> and file it the moment the package is bumped
-22:37 < Flameeyes@> Jokey, I used to prepare stable bugs in advance with a similar status whiteboard
-22:37 < Flameeyes@> but then arch teams hated me for filing them too soon -_-;
-22:37 < dberkholz@> pkgcore-checks has something that can already do that
-22:37 < dberkholz@> i'm sure some other tools do too
-22:37 <     Jokey@> Flameeyes: I don't cc arches until bug is due heh ;)
-22:38 < Flameeyes@> dberkholz, well, I suppose it looks when it was added to the tree :P
-22:38 < dberkholz@> yeah
-22:38 < Flameeyes@> but for instance I don't want pambase to get stable just after 30 days, I want to test it at least 60
-22:38 <      amne@> if no one minds, i'll leave now, gotta catch some sleep
-22:39 < Flameeyes@> nighty night amne
-22:39 <      amne@> nite folks
-22:39 < dberkholz@> would be another possibility for adding to metadata.xml
-22:39 < dberkholz@> stabletime
-22:39 < Flameeyes@> so I'm going to start looking at a calender for gentoo now :P I'll report on -core or -dev whenever I have something
-22:39 < dberkholz@> Flameeyes: might be nice to work with #gentoo-pr people on that
-22:41 < dberkholz@> ok, any more topics?
-22:45 <   lu_zero@> apparently not
-22:48 < dberkholz@> alright, this meeting is over
-22:48 < dberkholz@> i'll send out a summary later tonight
-22:49 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080313-summary.txt is where it's at, not sure if i'm going to make more changes
-22:49 < dberkholz@> suggestions welcome
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080410-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080410-summary.txt
deleted file mode 100644
index 2348310196..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080410-summary.txt
+++ /dev/null
@@ -1,124 +0,0 @@
-Quick summary
-=============
-
-GLEP 46 (Allow upstream tags in metadata.xml): Approved
-
-Slacker arches: Vapier's proposal is going out tonight.
-
-Minimal activity for ebuild devs: We're trusting the judgment of the 
-undertakers. Also looking into Ohloh for commit stats.
-
-Initial comments on PMS: Unapproved EAPIs cannot go into the approved 
-document.
-
-
-Roll call
-=========
-
-(here, proxy [by whom] or slacker?)
-
-amne        here
-betelgeuse  here
-dberkholz   here
-flameeyes   proxy [tsunam]
-lu_zero	    slacker
-vapier      here
-jokey       here
-
-
-Updates to last month's topics
-==============================
-
-	http://www.gentoo.org/proj/en/council/meeting-logs/20080313-summary.txt
-
-
-	Document of being an active developer
-	-------------------------------------
-	Last month:
-		No updates
-	Updates:
-		No updates
-
-
-	Slacker arches
-	--------------
-	3 months ago:
-		vapier will work on rich0's suggestion and repost it for 
-		discussion on -dev ML
-	Last month:
-		vapier said he was going to work on it this weekend.
-	Updates:
-		vapier said he's finishing it up and will have it posted tonight.
-
-
-	GLEP 46: Allow upstream tags in metadata.xml
-	--------------------------------------------
-	http://www.gentoo.org/proj/en/glep/glep-0046.html
-
-	2 months ago:
-		Caveat on approval about allowed protocols
-	Updates:
-		Restriction to http/https has been dropped as pointed out by 
-		council members (amne and Flameeyes if I'm right).  The point 
-		for restricting the URLs to the mentioned protocols was that 
-		they shouldn't link to automatically updated ressources.  This 
-		has been replaced by an explicit specification and a 
-		recommendation that http/http should be favoured over 
-		ftp/svn/gopher/etc to make the implementation for automated 
-		update discovery tools easier (they should of course ignore URLs 
-		they can't handle).
-
-		Approved.
-
-
-New topics
-==========
-
-
-	Minimal activity for ebuild devs
-	--------------------------------
-	Current is 1 commit every 60 days. Should it be higher?
-
-	Agreement was hard to find. Some people thought it should be 1 
-	commit / week, others said that people have busy lives and 
-	questioned the benefits.
-
-	A number of people did agree that we should trust the judgment of 
-	the undertakers.
-
-	dberkholz suggested that low commit rates may not maintain the 
-	quality of the committer, and we should more carefully review the 
-	commits of these people.
-
-	Ways to track commit stats of various sorts came up, such as cia.vc 
-	and ohloh. cia seems to have too much downtime to rely on. ciaranm 
-	talked with ohloh people already. ohloh would require some 
-	modifications to ohcount to recognize ebuilds and eclasses, and a 
-	full copy of the cvs repository to start, but it seems worth 
-	exploring. Betelgeuse said he would tar up a copy of the gentoo-x86 
-	repo.
-
-
-	Initial comments on PMS
-	-----------------------
-	http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git
-
-	Are there any major changes needed, or just tuning details?
-
-	The council voted that kdebuild-1 and other unapproved EAPIs could 
-	not be in an approved PMS document. The spec isn't a place for 
-	proposals or things that will never be submitted for approval by the 
-	council. It's a specification, a reference of what is allowed in the 
-	main tree.
-
-
-	Open floor
-	----------
-
-	blackace asked about complaints against philantrop, eroyf, and spb.
-	vapier referred that to devrel. Betelgeuse said that there's been no
-	rejection or action on those complaints yet, and internal discussion 
-	is ongoing. Philantrop complained that he hadn't heard anything 
-	about complaints, and Betelgeuse said that since some members 
-	already left, he didn't want to take matters into his own hands in 
-	sharing private information.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080410.txt b/xml/htdocs/proj/en/council/meeting-logs/20080410.txt
deleted file mode 100644
index 61e8a190f5..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080410.txt
+++ /dev/null
@@ -1,798 +0,0 @@
-19:55 <    tsunam > all full now
-19:59  *     amne reports in
-20:00 <Philantrop > amne: You're one minute early!
-20:00 <    tsunam > amne: don't leave a hanging chad on your clock in...else you'll not be counted as in
-20:00 <    tsunam > <----proxy for Diego
-20:01 <      amne@> tsunam: ack, he sent an email about it
-20:01 < dberkholz@> i'm having some issues building the latest pms, just got a slightly older version, could someone post a pdf
-20:02 <       spb > did he give a reason he can't appear?
-20:02 < dberkholz@> he's sick
-20:02 <Betelgeuse@> I will hit the toiled and join then.
-20:02 <      amne@> Betelgeuse: TMI :-P
-20:02 <   astinus > Betelgeuse: toiled? You going Welsh on us? ;)
-20:03 <   Halcyon > http://dev.gentoo.org/~spb/pms.pdf
-20:03 <Betelgeuse@> astinus: Whatever let's call it paskahuussi then.
-20:03 <   ciaranm > http://paludis.pioto.org/~ciaranm/pms.pdf
-20:03 <   ciaranm > is probably a few days more up to date than spb's version
-20:04 < dberkholz@> thanks
-20:05 <      amne@> Agenda: http://archives.gentoo.org/gentoo-dev/msg_46bf3619625ec081d4c5c858e375c011.xml
-20:05 <      amne@> dberkholz: or do you have it somewhere on your devspace?
-20:06 < dberkholz@> hasn't change since i posted it =)
-20:06 < dberkholz@>  changed*
-20:06 -!- amne changed the topic of #gentoo-council to: Meeting now - Agenda: http://archives.gentoo.org/gentoo-dev/msg_46bf3619625ec081d4c5c858e375c011.xml
-20:06 <      amne@> dev-zero said he may be able to show up, but earlierst in half an hour an probably later
-20:07 <      amne@> so i'd suggest we move glep 46 towards the end and hope he can make it
-20:08 < dberkholz@> we could just figure out whether we have any questions, if so wait, if not just get through it
-20:08 -!- Irssi: #gentoo-council: Total of 69 nicks [5 ops, 0 halfops, 1 voices, 63 normal]
-20:08 < dberkholz@> we're still missing a few folks
-20:08 <    vapier@> moo
-20:08 < dberkholz@> lu_zero and jokey aren't even in the channel..
-20:08 <    vapier@> guess i'll be back in an hour
-20:09 <    vapier@> or not
-20:09 <Betelgeuse@> back
-20:10 < dberkholz@> we might as well get on with the first stuff and see if lu and jokey show up soon
-20:10 < dberkholz@> vapier: any news on the slacker archs idea?
-20:10 <    vapier@> i'm finishing it up ... have it posted tonight
-20:11 < dberkholz@> great!
-20:12 < dberkholz@> still nothing i know of for araujo's active dev documentation. it's on him to start making some progress if he cares about it
-20:13 -!- mode/#gentoo-council [+o jokey] by ChanServ
-20:13 <      amne@> oi jokey
-20:13 <     jokey@> meh, should update my reminder
-20:13 -!- Irssi: #gentoo-council: Total of 72 nicks [6 ops, 0 halfops, 1 voices, 65 normal]
-20:13 < dberkholz@> well, that's 6 at least
-20:14 < dberkholz@> does anyone have questions on glep 46, or are we ready to vote?
-20:14 <NeddySeago > dberkholz, with 2 missing, is this meeting quorate ?
-20:14 < dberkholz@> NeddySeagoon: 1 missing ... tsunam is proxy for flameeyes
-20:14  *    jokey doesn't have any questions
-20:14 <      amne@> since the stuff suggested last time was implemented it works for me, no further questions
-20:16 -!- mode/#gentoo-council [+v tsunam] by dberkholz
-20:16 < dberkholz@> maybe that'll prevent some confusion
-20:16 -!- Irssi: #gentoo-council: Total of 73 nicks [6 ops, 0 halfops, 2 voices, 65 normal]
-20:16 < dberkholz@> Betelgeuse, tsunam, vapier -- any glep 46 questions?
-20:17 <    tsunam+> none here
-20:17 <Betelgeuse@> no
-20:19 <      amne@> time to vote then?
-20:19 < dberkholz@> ok. let's vote, then. glep 46 -- yes or no
-20:19 < dberkholz@> yes
-20:19 <      amne@> yes
-20:19 <    tsunam+> yes
-20:20 <Betelgeuse@> yes
-20:21 < dberkholz@> jokey, vapier -- care to vote?
-20:21 <     jokey@> yes
-20:23 < dberkholz@> alright, that's 5 yes votes, 1 abstain 
-20:23 < dberkholz@> let's move on to the next topic
-20:23 < dberkholz@> Minimal activity for ebuild devs: Current is 1 commit every 60 days. Should it be higher?
-20:23 <     jokey@> yep
-20:24 <     jokey@> imho every dev should be able to do 4-5 commits every month
-20:24 <    tsunam+> I would say at least one a month should be a basis
-20:24 <    tsunam+> If a developer only maintains a package or two, and they don't update often...
-20:25 <      amne@> while i agree with all the shoulds, what's the positive effect for gentoo if we do that?
-20:25 <     jokey@> amne: main issue is that quite a bunch of packages have a number of bugs open, then maintainer appears, does a commit and hides again
-20:26 <Philantrop > What's the *reason* to change that? Does a dev with "only" one commit every 60 days hurt anyone?
-20:26 <    tsunam+> Philantrop: you have a point there
-20:26 <      amne@> jokey: then we should address that problem, as well as being unresponsive and letting packages bit-rot while others were willing to take over
-20:26 <Philantrop > jokey: And with your suggestion not even that one bug will be taken care of. :-)
-20:26 <      amne@> jokey: i just don't think introducing an arbituary number of commits will help with that
-20:27 <    tsunam+> amne: that's a larger issue with "posession"
-20:27 < dberkholz@> so do you think it should be more of a case-by-case thing?
-20:27 <      amne@> tsunam: yeah, heh
-20:27 <      amne@> dberkholz: yes
-20:27 <Betelgeuse@> The point of the suggestion was to give undertakers the powers to start poking with lesses activity.
-20:27 < dberkholz@> some devs have this obvious trend of drive-by commits and then disappearing
-20:27 <     jokey@> I mean if you're really interested in working as a dev, why don't actually do something?
-20:27 <Betelgeuse@> We don't really need to start arbitrary limits if we trust undertaker judgment.
-20:28 <      amne@> Betelgeuse++
-20:28 <     jokey@> Betelgeuse++
-20:28 <    musikc > Betelgeuse, undertakers is phreak and rane atm, and neither seemed to have wanted this
-20:28 <    tsunam+> does the new items increase the load of some of our teams
-20:28 <    tsunam+> such as undertakers and infra
-20:28 < dberkholz@> musikc: "this" being a higher limit?
-20:28 <    tsunam+> as there will be more tracking to do and poking and
-20:28 <    tsunam+> just general pain in the arse busy work as well
-20:28 <    musikc > increases for undertakers, saying 60 days to 7 days means more work
-20:28 <    tsunam+> cause really it is busy work
-20:29 <Philantrop > jokey: Most of you don't have a job or a family. Some of us older ones have and, thus, different priorities while Gentoo is still important to us.
-20:29 <    vapier@> dberkholz: sorry, yes to 46
-20:29 <    vapier@> btw, the e-mails are wrong in the glep
-20:29 <    vapier@> in case anyone cares ;)
-20:29 <     jokey@> Philantrop: looking at your stats, even you managed to do more than 5 commits ;)
-20:30 <     jokey@> and if one is away for a month for whatever reason, we have devaway
-20:30 <Philantrop > jokey: Yes, but I'm an idiot. :)
-20:31 < dberkholz@> musikc: but if it was 1/60 days to 8/60 days, it would be the same work with a different number
-20:31 <Betelgeuse@> musikc: I thought rane liked my script.
-20:31 <jmbsvicett > musikc / dberkholz: I saw rane comment that he didn't want to the one to have to do the judgement
-20:31 <    musikc > i like Philantrop's point though, many devs have full time jobs or substantial college obligations, in addition to family and trying to have a life some of the time. once a week is a lot and do we really want to lose those few commits entirely
-20:31 <Betelgeuse@> I would propose we make the slacker script output the activity of everyone and post it to public.
-20:31 <jmbsvicett > musikc / dberkholz: As I understood it, he wanted a clear policy
-20:31 <    tsunam+> Can it not be said that we increase it slowly?
-20:31 <    tsunam+> start with say 2 ever 60
-20:31 <    musikc > jmbsvicetto, he wanted a clear policy when people started saying policy was going to change; he said he wanted to know what the change would be
-20:32 <    tsunam+> then revisit it some months down...
-20:32 < dberkholz@> to build on what Betelgeuse said earlier, isn't this something that is just not a council decision, but rather undertaker policy?
-20:32 <    musikc > Betelgeuse, rane told me he did not want to have to sort through extra information
-20:32 <jmbsvicett > I would also like to point out that the script only looks at cvs - no svn or git
-20:32 <Betelgeuse@> dmwaters: imho council should set undertaker policy
-20:32 <      rane > i like tsunam's proposal the most, a slight increase, say 4 commits per 60 days
-20:33 <      rane > and we'll see what happens
-20:33 <Betelgeuse@> s/dmwaters/dberkholz/
-20:33 <jmbsvicett > That means most (almost all?) overlays don't count
-20:33 <    musikc > what about cvs and svn, does the script include both?
-20:33 <NeddySeago > comitts alone are a poor measure. A dev with one or two packages rare upstream updates and no bugs has no reason to commit
-20:33 <    tsunam+> hmm
-20:33 <Betelgeuse@> musikc: the script was posted to -dev and it does not do svn yet
-20:33 <Betelgeuse@> musikc: but neither does the current script
-20:33 < dberkholz@> NeddySeagoon: my question would be, why isn't that dev doing more?
-20:33 <Betelgeuse@> NeddySeagoon: That's why there is the manual step.
-20:33 <    tsunam+> the question also becomes how many commits will happen just to "commit"
-20:33 <    tsunam+> if it increases
-20:34 <      amne@> how about not taking in the positive count (like commits) but rather negative stats like being unresponsive for long times without devaway etc?
-20:34 <jmbsvicett > Betelgeuse: My point about svn / git is that it probably should count
-20:34 <Betelgeuse@> NeddySeagoon: It's not run script --> autoretire
-20:34 <    tsunam+> is it a quality or a quantity that we are after?
-20:34 <  blackace > why is there such a focus on getting rid of slacking devs?  surely rather a slacker dev than no dev at all?  or is a .forward on woodpecker so expensive?
-20:34 <     jokey@> tsunam: both
-20:34 < dberkholz@> i mean c'mon, if all i maintained was colordiff, that would be pretty sad.
-20:34 <NeddySeago > Betelgeuse, I understand that.
-20:34 <Betelgeuse@> blackace: Because coming back is easy.
-20:34 <    tsunam+> dberkholz: by all accounts I maintain nothing in the tree...I do help on some packages though
-20:35 < dberkholz@> my feeling is that low commit count may mean that the dev isn't doing enough stuff to maintain his/her quality level
-20:35 <NeddySeago > dberkholz, no time ? no interest in other stuff ?  The measure needs to include open bugs
-20:35 <    musikc > Betelgeuse, if the intent is to improve, we should try to include both
-20:35 <    vapier@> perhaps if the proxy stuff was more streamlined, there wouldnt be a need for drive by devs
-20:35 <Betelgeuse@> blackace: Also it does require some attention to keep up with latest ebuild standards.
-20:35 <  blackace > Betelgeuse: every 60 days?  seems like that would be a waste of time for undertakers
-20:35 <Philantrop > dberkholz: And you want undertakers to judge on the dev's skills/quality level?
-20:36 < dberkholz@> maybe instead of retiring these devs, we should make sure their commits get reviewed
-20:36 <Betelgeuse@> dberkholz: They don't get retired if they answer a simple mail atm.
-20:36 <    musikc > all, sorry but i have another meeting to go to. again im agreeable to an increase, say at least once a month instead of 2 months, and continue to allow undertakers to talk to the dev and their leads to determine real involvement, commits alone arent all that happens around here
-20:36 <  blackace > dberkholz: that would actually be a great idea, gentoo has a severe lack of code review...maybe we could use a reviewboard
-20:36 < dberkholz@> Betelgeuse: ok, that doesn't really address my concern one way or the other, though
-20:37 <Betelgeuse@> blackace: Anyone can do it via gentoo-commits mailing list.
-20:37 < dberkholz@> it would be pretty easy on an individual level to take the commit-count script output and use some cutoff as a procmail filter for rare committers
-20:37 <Betelgeuse@> I wouldn't mandate review as we have enough problems keeping stuff up2date as it is.
-20:38 <Betelgeuse@> dberkholz: Yes, I can setup something like that with robbat2 when he has the time.
-20:38 <Betelgeuse@> dberkholz: We will already be setting up new develop watching at some point any way.
-20:38 <Betelgeuse@> He's just damn busy.
-20:40 < dberkholz@> vapier: i'm hoping that we can get some sort of dscm going in the not-distant future to help that
-20:40 <kingtaco|w > dberkholz, would you write some procmail foo for that in any event?  that info would be useful in general
-20:41 < dberkholz@> kingtaco|work: does woodpecker allow user cron jobs?
-20:41 <kingtaco|w > dberkholz, no, but I can make an exception for something like this
-20:41 < dberkholz@> what we'd want to do is periodically grab the list and insert an update.
-20:41 < dberkholz@> anyway, details for discussion elsewhere
-20:42 <kingtaco|w > WFM
-20:42 <     jokey@> though I like the idea of just posting stats to -dev ml (or some other list if needed)
-20:42 <     jokey@> that way you can easily stab your fellow to do somethin ;)
-20:43 <    tsunam+> I would not like that honestly
-20:43 <    tsunam+> we shouldn't rat out/ paint our own developers with bright red paint
-20:43 < dberkholz@> i think it would be neat to have a commit stats page around
-20:43 <nightmorph > just to clarify -- this minimum commit requirement is strictly for ebuild devs, correct?
-20:43 <    tsunam+> the point isn't to drive people away
-20:43 <    tsunam+> its to gently nudge them into commiting more if possible
-20:43 <     jokey@> nightmorph: yep
-20:43 <     jokey@> tsunam: exactly
-20:44 <    tsunam+> but as musikc said, what a developer commits isn't always all they have worth for
-20:44 <     jokey@> and if a (good) friend of yours nudges you, the chance you actually do something is way higher imho
-20:44 <Betelgeuse@> tsunam: The info is available via anoncvs any way.
-20:45 <    tsunam+> Betelgeuse: but its not Tsunam has done : 2 commits these last 2 months
-20:45 <Philantrop > jokey: And chances are higher that commit competitions are the result. Great for quality, I'm sure. :-)
-20:45 <    tsunam+> and having say...spb, Betelgeuse, vapier, blackace all go Dude COMMIT MORE! YOU SUCK!
-20:45 <Betelgeuse@> tsunam: I am going to add gentooRoles to the script and from that it should be quite clear if someone should commit or not.
-20:46 <      rane > blackace who didn't commit anything in last 6 months is quite unlikely to bash for lack of commits
-20:46 <    tsunam+> Betelgeuse: how accurate are the gentooRoles
-20:46 <  blackace > rane: yeah, I'm not one to talk ;)
-20:46 <    tsunam+> Betelgeuse: I'm sure mine are nowhere close to be honest
-20:46 <     jokey@> Philantrop: that's why we have a commit mailinglist for public review
-20:46 <Betelgeuse@> tsunam: probably not that but one can always change them
-20:46 < dberkholz@> where "public" seems to mean "donnie reviews" in most cases.. =P
-20:47 <  blackace > rane: but then, I don't have cvs access anymore either...any script looking at commits should take into account permission to commit
-20:47 <nightmorph > it's already noted that nothing is checking for SVN commits i believe
-20:48 <    tsunam+> there are quite a few catchpa's *nods*
-20:48 <    tsunam+> ultimately its up to the undertakers to decide the relative merits
-20:48 <    tsunam+> with assistance from a script and discussion with the developer in question
-20:49 <Betelgeuse@> Perhaps we should mail the results to -core.
-20:49 <    tsunam+> Where capable, I don't think 1 commit a month is asking too much, even from a dedicated father/employee/ grad student/college student+part time worker
-20:49 <Betelgeuse@> As things like KDE keywording would be missleading to the public.
-20:51 <    tsunam+> s/father/parent/
-20:51 <Philantrop > tsunam: Just a minimal summary to make sure I understand this: There's no real identifiable benefit but literally something to lose - commits, devs, maintainership. And yet we want to ask for more?
-20:51 < dberkholz@> for all of our committing mothers. =)
-20:52 < dberkholz@> Philantrop: i pointed out the potential problems with code quality
-20:52 <    tsunam+> Philantrop: dberkholz's point, as well as the mattter of 1 commit in 60 days is 6 commits a year. How much real benefit is there in that potential?
-20:53 <NeddySeago > if the script is an undertakers aid, let undertakers set the limits so its useful to them
-20:53 <  blackace > dberkholz: code quality is pretty much impossible to solve with any blanket rule though
-20:53 < dberkholz@> anyway, more tests could be done here. for example, how many devs would this actually affect, over the course of the last year?
-20:53 <jmbsvicett > dberkholz: I think the "quality" problems should be addressed directly and not through commits - that's something for qa
-20:53 <    tsunam+> aye
-20:53 <    tsunam+> Halcyon: thoughs on the qa aspect of that?
-20:54 <Betelgeuse@> Philantrop: Rotting bugs in bugzilla?
-20:54 <Philantrop > tsunam: I say, we should take what we get. Better than nothing.
-20:54 < dberkholz@> jmbsvicetto: depends on whether there's correlation, and that's hard to say right now
-20:54 <Philantrop > Betelgeuse: And by getting rid of devs we solve that problem?
-20:54 <Betelgeuse@> Philantrop: at least they go to maintainer-wanted
-20:55 <   Halcyon > Philantrop: getting rid of them reveals the truth that we don't have people working on things.
-20:55 <Betelgeuse@> instead of the user expecting someone to act
-20:55 <Philantrop > Betelgeuse: People will expect some of us to act anyway if the package is in the tree. And they're right.
-20:55 <   Halcyon > tsunam: which part?
-20:55 <Betelgeuse@> Could also be easier to recruit new people when our developer stats are truthful.
-20:55 <    tsunam+> Betelgeuse: would you agree, that maintainer-wanted is bit-rot as well?
-20:55 <Philantrop > Halcyon: That's why I fired half of the KDE herd recently.
-20:55 <Betelgeuse@> tsunam: it is
-20:55 <    tsunam+> Halcyon: the qa with quality
-20:56 <   Halcyon > tsunam: with devs putting things into the tree that are subpar?
-20:56 <    tsunam+> Halcyon: yes as that was an issue discussed about people who seldom commit
-20:56 <   Halcyon > tsunam: we have that problem now anyway, with people that are active...
-20:57 <    tsunam+> so you consider it a non issue then as there is not a visual difference with people who commit frequently vs infrequently
-20:57 <   Halcyon > Not really.  They might be more prone to screwing up, but that's not something we can easily address.
-20:57 <    tsunam+> Well there you go
-20:58 <   Halcyon > Having easily available documentation and improving our qa tools is really the only way.
-20:58 <   Halcyon > I can't force people to read policy or documentation though.
-20:58 <    tsunam+> Its  sounding like "put this in the hands of the undertakers to decide"
-20:58 <    tsunam+> as there is no consensus
-20:58 <    tsunam+> and its up to them ultimately
-20:59 <      rane > so let's double what we have now (like musikc suggested) and see what happens
-21:00 < dberkholz@> heh, ramp it all the way up to once a month? that seems extreme to me =P
-21:01  *   tsunam has a feeling the discussion is done on the matter
-21:02 <Betelgeuse@> So what about mailing the slacker script to -core?
-21:02 < dberkholz@> tsunam: that is a consensus
-21:02 <jmbsvicett > Betelgeuse: np with that
-21:02 <    tsunam+> I'd vote no on the mailing the slacker script to core
-21:04 <    vapier@> why e-mail ?  just put it on the web
-21:04 <    vapier@> this isnt magic hidden data
-21:05 <    vapier@> anyone can calculate it
-21:05 < dberkholz@> 20:43 < dberkholz@> i think it would be neat to have a commit stats page around
-21:05 <   astinus > cia.vc?
-21:05 <   astinus > why reinvent the wheel?
-21:05 <     jokey@> astinus: way too much offline
-21:05 <     jokey@> aka not accurate
-21:05 <    tsunam+> dberkholz: like http://tsunam.org/gentoo-dev.html?
-21:06 < dberkholz@> ohloh might do it
-21:06 <    vapier@> which may eventually hit the same problem as cia
-21:06 <   ciaranm > ohloh can't handle gentoo-x86 at all until someone sends them a cvs dump of the entire repo
-21:06 < dberkholz@> tsunam: among other things. kinda like the lwn article i wrote a while back anyway
-21:06 <    vapier@> people seem to be jumping onto ohloh
-21:09 <     jokey@> other option would be we fetch cia sources and run  that page on our own servers
-21:09 <     jokey@> as the sources are public anyway
-21:09 <Betelgeuse@> vapier: The results can be a bit missleading.
-21:10 <   ciaranm > and someone would have to patch ohcount to recognise ebuilds and eclasses. which would take about ten minutes, admittedly
-21:13 <Betelgeuse@> Any way let's move on.
-21:13 < dberkholz@> ok, nobody's said anything for 3 minutes.
-21:14 < dberkholz@> we have zero conclusions so far, afaict
-21:14 <Betelgeuse@> dberkholz: I think nobody objected to undertakers setting their own limits.
-21:15 <Betelgeuse@> dberkholz: The posting to -core can be revisited after svn etc are included
-21:15 < dberkholz@> ok
-21:15 <      amne@> Betelgeuse: imho they should just do what makes sense rather than sticking to more or less useful numbers
-21:15 <     jokey@> Betelgeuse: agreed
-21:16 <      amne@> Betelgeuse: but i don't really object, too
-21:16 < dberkholz@> does anyone want to seriously look into ohloh?
-21:16 <   ciaranm > i spoke to the ohloh people about gentoo-x86 already
-21:16 <Betelgeuse@> that's 4 so we can move on
-21:16 <   ciaranm > they'd need a copy of the full cvs repo to do anything, since cvs co is too slow
-21:17 <Betelgeuse@> ciaranm: you mean operations like cvs log would be too slow?
-21:17 <   ciaranm > Betelgeuse: ohloh needs every revision ever with full logs and every file and everything
-21:17 <   ciaranm > Betelgeuse: they were getting that using cvs co, but they killed it because it was taking too long for the initial checkout
-21:18 <    tsunam+> heh
-21:18 < dberkholz@> so they get the initial dump, and then from there they could just use anoncvs?
-21:18 <   ciaranm > if someone can provide a tarball of the full repo, they can use that instead
-21:18 <    tsunam+> considering the size of it *nods*
-21:18 <   ciaranm > dberkholz: yes
-21:18 <   ciaranm > someone would also have to make ohcount recognise ebuilds. i've done stuff with ohcount before, so i could do that pretty quickly if it's going to be worthwhile
-21:19 <  dev-zero > hi everyone
-21:19 <Betelgeuse@> I can tar up the repo if everyone agrees.
-21:19 <    tsunam+> I don't see why anyone wuold disagree
-21:20 <     eroyf > hallå
-21:20 <     eroyf > er i dumme eller sådan noget?
-21:21 <     jokey@> Betelgeuse: it's open stuff anyway
-21:22 <     eroyf > hey
-21:22 <     eroyf > in the logs right
-21:22 <     eroyf > it's my birthday
-21:22 <     eroyf > say happy birthday eroyf
-21:22 <     eroyf > i'm 19 now
-21:22 <    tsunam+> eroyf: in the middle of a meeting
-21:22 <     eroyf > sorry
-21:23 <    tsunam+> what's the next order of business?
-21:23 < dberkholz@> the cool one
-21:23 < dberkholz@> Initial comments on PMS: Are there any major changes needed, or just tuning details?
-21:24 <Betelgeuse@> Hmm. I wonder if just tarring up is bad as there will be commits while it's doing it.
-21:25 < dberkholz@> ciaranm: is there a TODO around, or just looking at open pms bugs?
-21:25 <   ciaranm > dberkholz: i mailed a list to -dev@ a while ago
-21:26 < dberkholz@> ah, march 19. Subject: [gentoo-dev] Remaining PMS todo list etc
-21:26 <gentoofan2 > I probably should have mentioned to -dev that dohtml is done
-21:26 <   ciaranm > a few things on that are done now
-21:27 < dberkholz@> ciaranm: some of the features only in kdebuild-1 eapi, before they get too set in stone, will they / have they already been discussed with portage/pkgcore people?
-21:28 <   ciaranm > dberkholz: you'll have to ask the kde people for details. but as i understand it, zac has said that use deps for portage aren't ever going to happen, and the kde people have said that use deps aren't a negotiable requirement
-21:28 <   ciaranm > dberkholz: so i've no idea how that one's going to work out
-21:28 <Betelgeuse@> ciaranm: How does whether the ebuidl is interactive or not affect the PM?
-21:29 <   ciaranm > Betelgeuse: it affects parallelism... if an ebuild is interactive, a PM can't build two things at once
-21:29 <Philantrop > dberkholz: They have been presented to -dev. I've had no response from the authors of other PMs, though. So I guess they're fine with it.
-21:29 <    tsunam+> Philantrop: have you tried contacting the developers directly
-21:30 <Philantrop > tsunam: No, that's what mailinglists are for.
-21:30 <    tsunam+> I don't personally consider -dev as always the best place to get people's attention
-21:30 <Betelgeuse@> ciaranm: without I gui true but can't require that either
-21:30 <    tsunam+> Philantrop: again....it doesn't always get everyone involved. Its not hard to go "oh well shit, 130 emails to -dev, they're shite and delete the whole lot"
-21:30 <     jokey@> there's only one important thing (imho)... if those features won't make it into portage, we can't put such (k)ebuilds into gentoo-x86
-21:30 <    tsunam+> it takes an extra 2 cc's
-21:31 <   ciaranm > for the kdebuild stuff... we can flip a switch and remove it from the generated PDF for PMS if people really want. but i'd rather leave it in there, because it makes things easier for package manager authors
-21:31 < dberkholz@> it seems to be reasonably clear, thanks to the eapi tables, which features are in which eapi
-21:31 <jmbsvicett > jokey: They're only being used for live ebuilds
-21:31 <   ciaranm > whether or not kdebuild goes into the tree, and whether or not all the kdebuild features make it into EAPI 2 is a whole different topic
-21:32 < TehCaster > I thought PMS approval will only concern in-tree EAPI's and the kdebuild-1 etc while useful for some is not the subject right now?
-21:32 <Philantrop > tsunam: They've both discussed it so they obviously know it. :-)
-21:32 <Betelgeuse@> ciaranm: FEATURES userpriv checking at least could probably be switched to some UID based check
-21:32 <    tsunam+> 14:29 < Philantrop> dberkholz: They have been presented to -dev. I've had no  response from the authors of other PMs, though. So I guess  they're fine with it.
-21:32 <    tsunam+> ^^^ doesn't seem to say so
-21:32 <   ciaranm > TehCaster: i don't see there being an issue with PMS being approved with the kdebuild stuff in... doesn't mean kdebuild is legal in the tree
-21:32 <    tsunam+> in the case of standards "no answer" should not be considered a default yes
-21:32 <Philantrop > tsunam: No response by mail. They've discussed it on IRC, though.
-21:32 <   ciaranm > Betelgeuse: yeah. that one's a detail though. details can be worked out on #-dev
-21:33 < TehCaster > ciaranm: yeah so why set them to stone now as dberkholz suggested
-21:33 <   ciaranm > TehCaster: mm?
-21:33 < dberkholz@> ciaranm: anything in particular you're curious about, things you think maybe should be in there but aren't?
-21:33 <Betelgeuse@> ciaranm: But it is probably quite widely used in overlays and such that won't be fixed.
-21:33 <Philantrop > TehCaster: Because we want a *stable* EAPI.
-21:33 <    tsunam+> erm, the point is to make standards that all package mangers know and expect to have presented with
-21:34 <   ciaranm > dberkholz: i'm moderately happy with it, except for the details, just now
-21:34 <   ciaranm > tsunam: the numbered EAPIs, yes
-21:34 <    tsunam+> ciaranm: I would hope we don't have undocumented EAPI's that are not agree'd to running around
-21:35 < dberkholz@> on the big picture level, nothing really struck me in there
-21:35 <   ciaranm > my view on the kdebuild stuff is that it's more useful being in PMS than being hidden, since it's a stable EAPI. but the paludis-1 stuff shouldn't be in there, because it's not stable and not considered suitable for general use. but then, i can just flip a switch and turn the kdebuild stuff off in the PDF if people really want
-21:35 < dberkholz@> there was one spot where it wasn't clear to me that when saying ebuild, it really meant the state of the ebuild after eclasses were inherited
-21:36 <   ciaranm > dberkholz: there're probably lots of little details like that
-21:36 < TehCaster > right, stable and documented but not subject to approval of council until we are to use it in tree, that's my only point
-21:36 <Philantrop > TehCaster: Yes, that's right.
-21:37 <  ferringb > ciaranm: personally, I'd rather the kdebuild crap be out of pms- rather keep the stable/official stuff in there and not mix unofficial.  reasoning pretty much comes down to avoiding anything bleeding in from kdebuild (people make mistakes)
-21:37 <Philantrop > TehCaster: I didn't seek council approval yet for kdebuild-1 anyway. :)
-21:37 <Sweetshark > ciaranm: kdebuild stuff in pms do not matter for the decision if those are allowed in the portagetree. But a packagemanager should be pms-compliant without implementing kdebuild (for now). Would it be possible to make a clear destinction between those (maybe by making kdebuild features an optional requirement or something)
-21:38 <   ciaranm > ferringb: that's solved by having the package manager enforce EAPI. which any package manager supporting kdebuild is required to do anyway
-21:38 <    tsunam+> If its in the PMS then its part of what is expected behavior
-21:38 < dberkholz@> should /etc/portage/ be involved in any way?
-21:38 <Betelgeuse@> dberkholz: why?
-21:38 <   ciaranm > Sweetshark: that's easily done by habing a list of which EAPIs are required and optional for gentoo-x86. probably outside of PMS
-21:38 <   ciaranm > dberkholz: no
-21:38 <  ferringb > ciaranm: eh?  I'm talking about the document itself
-21:38 <    tsunam+> you can't have a moving EAPI table
-21:39 <    tsunam+> the point of EAPI's is to ensure universal support
-21:39 <   ciaranm > dberkholz: user configuration really shouldn't be in there...
-21:39 <     eroyf > s
-21:39 < TehCaster > btw zmedico just said use deps in portage are rather close, not "never going to happen"
-21:39 <    tsunam+> IF kdebuild is not fully confident by all..then it should not be part of it
-21:39 <Betelgeuse@> TehCaster: indefinately under work :D
-21:39 <   ciaranm > tsunam: EAPI 1 isn't supported by everything. should it not be in there either?
-21:39 <   Halcyon > tsunam: its not to ensure universal support, but to ensure feature sets are defined.
-21:39 <    tsunam+> ciaranm: Personally, I would say no. However, we're stuck with it at this point =)
-21:40 <   zmedico > Betelgeuse: I think they are getting very close to possible about now
-21:40 <   ciaranm > TehCaster: he's also said that every time someone asks for them he's going to delay them for six months...
-21:40 <Betelgeuse@> zmedico: Heh I remember you saying doing them duringdoing summer 07
-21:41 <Betelgeuse@> zmedico: But great to hear that progress is happening on that front
-21:41 <   zmedico > well, it's much closer now than before
-21:41 <   ciaranm > tsunam: looking at it the other way... what gain do you see from not having kdebuild documented in the same place as the core EAPIs?
-21:41 <Betelgeuse@> Discussing kdebuild is a bit OT imho as it can easily be turned off.
-21:41 <   ciaranm > what Betelgeuse said
-21:42 <    tsunam+> ciaranm: I see that we have an EAPI=0 and EAPI=1 that might be considered finalized sooner, rather then 20 revisions later..that look nothing like the current revisions
-21:42 <   ciaranm > tsunam: huh?
-21:42 < dberkholz@> ferringb, zmedico -- you guys got thoughts on the matter?
-21:42 <     jokey@> mmm personally with the option for improvements and eapi0 and 1 in it, I'm willing to accept it
-21:43 <   ciaranm > jokey: it's not ready for being accepted
-21:43 <     jokey@> ciaranm: that's why I'm saying "with the option for improvements"
-21:44 <Betelgeuse@> I would rather accept it when there aren't any known issues.
-21:44 <    tsunam+> jokey: shouldn't be a option to improve really, should be new eapi's that might modify existing ones or other aspects in the future
-21:44 <     solar > You might want to chime on on the dont use -r0 ever
-21:44 <   zmedico > dberkholz: I'm not sure what's at stake right now. can you fill me in? are you deciding something?
-21:45 <Betelgeuse@> tsunam: Well it's quite likely to find corner cases later.
-21:45 <    tsunam+> Betelgeuse: aye, that's always a case
-21:45 < dberkholz@> zmedico: 21:23 < dberkholz@> Initial comments on PMS: Are there any major changes  needed, or just tuning details?
-21:45 <   zmedico > thanks
-21:45 <    tsunam+> Betelgeuse: no code or standard will be 100% complete for all cases
-21:45 <    tsunam+> Betelgeuse: however future issues can be handled at that time
-21:45 <Sweetshark > ciaranm: its just harder to see which paragraphs can be skipped for the most basic pms-compliant implementation. If it wouldnt be so much work, I would think it would be better to have that stuff as an appendix. after being baisc pms-compliant one can look there how to support kdebuild etc ... just an opinion though.
-21:46 <   ciaranm > Sweetshark: how is it hard?
-21:46 <    tsunam+> Sweetshark: at that point, its fully part of the "standards"
-21:46 <bonsaikitt > optional and non-optional bits mixed in the text
-21:46 <  ferringb > dberkholz: don't believe kdebuild belongs in there for the reasons I mentioned above; there are a couple of loose spots in it that need correction (recent package.use for example, iirc portage now allows inline comments but isn't documented in PMS)
-21:46 <  ferringb > dberkholz: would have to review it fully again, which is kind of hard considering I can't even get the damn thing to generate properly anyways ;)
-21:47 < TehCaster > package.use is config, is that in pms?
-21:47 <      zlin > tsunam: new eapi's cannot modify existing eapi's once it's stable and accepted
-21:47 <Betelgeuse@> zlin: You would have to clarify what you mean by that.
-21:47 <Betelgeuse@> zlin: Later EAPIs can change the behaviour defined in earlier ones.
-21:48 <  arkanoid > no, they can override it
-21:48 <      zlin > they can do something different. they cannot change what the existing eapi should do.
-21:48 < dberkholz@> i think we're all saying the same thing
-21:48 <   ciaranm > what everyone's clumsily trying to say is that future EAPIs can do things differently to current EAPIs, but can't change what current EAPIs do
-21:48 < dberkholz@> the earlier eapi remains what it was, the later eapi may have different behavior
-21:49 <    tsunam+> ^^^
-21:49 < TehCaster > which is something different than correcting a glitch in the spec
-21:50 <Sweetshark > ciaranm: there would be some need for tearing stuff apart (e.g. dep ranges into the appendix). its hard to judge the amount of work for that (at least for me)
-21:50 <   ciaranm > Sweetshark: the paragraph's already indicated as not being available in all EAPIs
-21:50 <Philantrop > Sweetshark: You know that you can just turn the kdebuild stuff off when "compiling" PMS, right?
-21:51 <   ciaranm > it gets a lot harder to read if you start splitting up things like dep specs into different areas depending upon EAPI
-21:51 <    tsunam+> also...the 2.2 section and 2.3 section seems to include -scm related materials. I thought that had been pushed back?
-21:51 <   ciaranm > tsunam: kdebuild requires it
-21:51 <Sweetshark > only if you plan to implement all eapis frontup
-21:51 <    tsunam+> ciaranm: ah
-21:51 <   ciaranm > tsunam: it should say that it's EAPI dependent
-21:52 <   ciaranm > if it doesn't it's easily changed
-21:52 <    tsunam+> don't see it being said in there but I'm looking over the section closer
-21:52 <  ferringb > mmm.  metadata/cache segment still is missing mtime
-21:53 <      zlin > use deps and -scm were the most important requirements for kdebuilds
-21:53 <   ciaranm > ferringb: we weren't discussing details
-21:53 < TehCaster > just generate pms without kdebuild and then discuss :)
-21:53 <  ferringb > what are discussing then?  whether it's ready to go or not?  If so, then details matter
-21:53 <   ciaranm > ferringb: no. please stick to the agenda.
-21:53 <  ferringb > *what are we, pardon multitasking and failing and all tasks ;)
-21:54 <   ciaranm > i was really hoping to avoid the exact thing you're doing here, and i phrased the request very specifically for that reason
-21:54 <       spb > the agenda item was "are major changes needed, or just refinement of the details?"
-21:54 <  ferringb > spb: thank you.
-21:54 <       spb > as such, the details are irrelevant
-21:54 <bonsaikitt > I would ask for a general cleanup of the language, it's overly complicated and ambiguous in places
-21:54 <Betelgeuse@> I think we can just say it's the latter and conclude.
-21:54 <    tsunam+> I would say yes to changes needed without the kdebuild
-21:54 <   ciaranm > bonsaikitten: more specifically?
-21:54 <  ferringb > tsunam: that's my opinion.
-21:54 <Betelgeuse@> And move the discussion of details to gentoo-dev.
-21:54 <bonsaikitt > ciaranm: double negations, overly long sentences, ...
-21:54 <   ciaranm > bonsaikitten: more specifically?
-21:55 <   Halcyon > bonsaikitten: file bugs where you don't find it to be clear.
-21:55 <  blackace > ciaranm: you just said you didn't want to discuss details...
-21:55 <Betelgeuse@> ciaranm: ^
-21:55 <bonsaikitt > ciaranm: details are irrelevant here, I'll file bugs as soon as I have it cleaned up enough
-21:55 <   ciaranm > blackace: yes. i'm assuming that bonsaikitten is making a general comment here, rather than discussing details, so i want to know what he's on about
-21:55 <   ciaranm > if bonsaikitten thinks major wording changes are needed, i want to know where and why
-21:56 <  blackace > which would be details
-21:56 <Betelgeuse@> blackace: let's not argue that point now
-21:56 <Betelgeuse@> Point noted and let's move on.
-21:56 <   ciaranm > blackace: but since bonsaikitten brought the issue up after we said "no details", i'm assuming there's a major issue to discuss, and i need to know what he means
-21:56 <  blackace > ciaranm: as Betelgeuse said, let's move on.
-21:56 <      amne@> yupp
-21:57 <   ciaranm > well, i'd like to hear from bonsaikitten... does he think there's a major issue, or is it just a details thing?
-21:57 <  blackace > ciaranm: <bonsaikitten > ciaranm: details are irrelevant here, I'll file bugs as soon as I have it cleaned up enough
-21:57 <   ciaranm > if there's a lot of wording change needed, that's the kind of thing i need to know now
-21:57 <  blackace > now let's move on.
-21:57 < TehCaster > is there anything left?
-21:58 <Betelgeuse@> TehCaster: open floor
-21:58 <   ciaranm > i would kinda like to know which way the council is going to go with the kdebuild stuff... because if there's no objection to stay in, i can remove a load of the conditionals and make the source a bit easier to work with
-21:59 <   ciaranm > but if it's going to be one of those things that takes ages to decide, i'll just leave it as a conditional and submit both PDFs when it's ready
-21:59 <Betelgeuse@> I say to keep the conditionals.
-21:59 <Betelgeuse@> If it starts to get unmaintainable, we can reconsider.
-22:00 <Sweetshark > ciaranm: i think bonsaikitten means there are quite some little fixes to be done, none serious in itself, but in sum there is still some work to do.
-22:00 <       spb > Sweetshark: which would be "details"
-22:00 <   ciaranm > Sweetshark: so he just said what we all already know and agreed not to discuss?
-22:00 <Philantrop > ciaranm: Let it go. It's bonsaikitten. It can only be nonsense.
-22:00 <     eroyf > haha.
-22:00 < dberkholz@> i don't really care one way or the other about inclusion of not-yet-approved eapis
-22:00 <Betelgeuse@> Philantrop: useless comment
-22:01 <      amne@> ok folks keep it civil please
-22:01 < dberkholz@> it might be kinda nice to have a doc that was just approved ones
-22:01 <   ciaranm > dberkholz: would it really make things easier for anyone to have that?
-22:01 <      igli > some rationale would be useful
-22:01 <      igli > and a tighter spec
-22:02 <    tsunam+> ciaranm: I believe so
-22:02 < dberkholz@> ciaranm: learning ebuild authors, perhaps
-22:02 <Betelgeuse@> ciaranm: How easy would it be to change for example background color with kdebuild?
-22:02 <   ciaranm > dberkholz: learning ebuild authors shouldn't be touching PMS
-22:02 <  blackace > I would like to ask the council for the status of the complaint filed against Philantrop, has the council discussed it and will it be on the next meeting's agenda?
-22:02 < dberkholz@> ciaranm: people hoping to learn from it, i guess is what i'm saying
-22:02 <    tsunam+> ciaranm: as people could easily confuse a section for approved when its still in the working stage
-22:02 <   ciaranm > Betelgeuse: dunno. we were trying to do a nice cute sidebar colour, but opfer failed us and none of the rest of us know how to get that
-22:02 <Philantrop > blackace: Oh, a complaint? Would have been nice to have known it exists. :-)
-22:02 <     eroyf > a complaint against Philantrop?
-22:03 <   ciaranm > dberkholz: mm, our target audience already knows what the different EAPIs are
-22:03 <   ciaranm > tsunam: every EAPI documented in PMS is 'final', in that the only thing that'll change are spec screwups
-22:03 <Betelgeuse@> dberkholz: Why weren't the complaints included in the agenda btw?
-22:04 <    tsunam+> ciaranm: as far as I'm aware, EAPI=0 and EAPI=1 are both considered "drafts" that are just in full production use
-22:04 <    tsunam+> approved for use by council
-22:04 <   ciaranm > tsunam: 0 and 1 are supposed to be feature locked now
-22:04 < TehCaster > being able to leave it out makes it easier to read for people not involved with implementing it in PM nor writing ebuilds for it
-22:04 <   ciaranm > tsunam: 0 was supposed to have been locked as soon as portage supported EAPI
-22:04 <   ciaranm > TehCaster: does it really?
-22:05 <    tsunam+> ciaranm: was suppossed bothers me =)
-22:05 <   Halcyon > This is a details thing guys, if you want to argue the merits either way, take it to g-dev@
-22:05 <   ciaranm > i suppose what i'm saying is that i don't see how having it there hurts anyone, and i do see how having it there helps
-22:05 < TehCaster > ok, for me, if for others that's up to voting I guess
-22:05 <Sweetshark > ciaranm: it would make it easier for me to read the basics for example. so there is a gain. An document with kdebuild included can still exist, however it shouldnt be the official or "default" doc as long as those are not even used in the official tree.
-22:05 <    tsunam+> ciaranm: its a doc we're saying is approved, having it there...in essence says "its approved in this form"
-22:06 <   ciaranm > Sweetshark: PMS contains no basics
-22:07 <      igli > the fundamentals then
-22:07 -!- TehCaster is now known as Caster
-22:07 <Sweetshark > ciaranm: pms should contain everthing i need to know for implementing a package manager handling offical gentoo ebuild.
-22:07 <   ciaranm > there aren't any parts of PMS that aren't fundamental
-22:07 <bonsaikitt > *sigh*
-22:08 < dberkholz@> we don't seem to be making progress toward the one point ciaranm wanted a decision on
-22:08 < dberkholz@> could we get back to that
-22:08 <    Caster > just continue the vote :)
-22:09 < dberkholz@> i'm fine with kdebuild being in the pms
-22:09 <      igli > have the GLEPs been agreed?
-22:09 <    tsunam+> igli: 46 yes
-22:09 < dberkholz@> glep 46 was much earlier in the agenda, and yes it was approved
-22:09 <      igli > k thanks
-22:10 <    Caster > dberkholz: more specific it was about being able to build pms without it or removing the conditionals
-22:11 < dberkholz@> that's sort of a halfway decision to the real point, we could settle for "leave conditionals" if we can't agree that kdebuild-1 should stay in
-22:11 <   ciaranm > yeah, specifically the questions are a) whether anyone thinks anything's majorly wrong, and b) whether i can remove the conditionals on kdebuild or whether the council would rather i left them in so that that issue can be decided later on
-22:11 <      igli > well can we take the scm stuff out then? it makes the names thing hard to read and conflicts with existing impl (even if you don't use conditional bit)
-22:11 <    tsunam+> ciaranm: I would say leave the conditionals in unfortunately
-22:11 <   ciaranm > igli: scm is conditional on kdebuild, and required by kdebuild
-22:12 <      igli > yeah but cvs is undocumented and it's been part of existing impl for over 2 years as well as an alternative impl
-22:12 <    Caster > ciaranm: am I wrong thinking that if you wanted to distinguish it by color you would have to mark it somehow anyway which is not that different from conditionals?
-22:12 <Betelgeuse@> ciaranm: a) no b) no
-22:12 <   ciaranm > igli: the cvs stuff is currently considered to be in the same category as ( ) : ( ) deps
-22:12 <    tsunam+> Caster: be slightly different but
-22:12 <    tsunam+> Caster: same basics yes
-22:13 <   ciaranm > Caster: it's different in that the latex is less messy to just do the latter
-22:13 <    Caster > maintenance-wise
-22:13 <   ciaranm > latex buggers up spacing if you do conditional sentences
-22:13 <   ciaranm > stopping it from doing that is moderately not fun
-22:13 <   ciaranm > essentially, it treats a not taken conditional as a word or a paragraph unless you use some scary voodoo to stop it
-22:14 <    Caster > mmm thought it was better than that :)
-22:14 <    Caster > preprocess? :)
-22:14 <   ciaranm > was trying to avoid that too
-22:15 <   ciaranm > basically, any way we have of doing conditionals is a bit icky. not massively icky, but icky enough that it makes my life easier if the council decides that nuking the conditionals is fine
-22:16 <    tsunam+> ciaranm: I don't see an issue if say...items not yet solitified are for instance red...
-22:16 <    tsunam+> that's me personally
-22:16 < dberkholz@> ok. maybe we can do two binary votes to make this a little easier
-22:16 <   ciaranm > dberkholz: please
-22:17 < dberkholz@> since the kdebuild thing seems to be a 3-way choice
-22:17 < dberkholz@> 1. are you ok with kdebuild-1 and other unapproved eapi's being in pms?
-22:17 <    tsunam+> 1) no
-22:17 <     solar > no
-22:18 <NeddySeago > You will approve the document - unapproved stuff must be removed
-22:18 < dberkholz@> amne, Betelgeuse, vapier, jokey: time to wake up =)
-22:19 <      amne@> dberkholz: was just asking if this still an official vote since it's open floor
-22:19  *    jokey is awake and reading
-22:19 <Betelgeuse@> NeddySeagoon: Already voted.
-22:19 <Betelgeuse@> 01:12 <@Betelgeuse> ciaranm: a) no b) no
-22:19 <      amne@> dberkholz: no
-22:19 < dberkholz@> amne: i'd say so
-22:20 < dberkholz@> alright. that's a no from tsunam, Betelgeuse, and amne on inclusion of kdebuild-1 in the spec to approve
-22:21 <Betelgeuse@> dberkholz: Well I didn't vote on the inclusion.
-22:21 <Betelgeuse@> dberkholz: I voted on whether to remove the conditionals.
-22:21 <     jokey@> add a no from me for kdebuild incluseion, dberkholz
-22:21 <     jokey@> *inclusion even
-22:22 < dberkholz@> Betelgeuse: ok, then vote on this
-22:22 <Betelgeuse@> dberkholz: no
-22:22 < dberkholz@> righto.
-22:22 < dberkholz@> ciaranm: you've got your answer. gotta keep the conditionals, it seems
-22:23 <   ciaranm > ok
-22:23 <    tsunam+> dberkholz: well not entirely
-22:23 <     solar > seems like you just asked ppl to vote on "kdebuild-1 and other unapproved eapi's being in pms" then changed it to keeping conditionals
-22:24 < dberkholz@> that's the way the logic works in my head
-22:24 < dberkholz@> if they're to be in a draft state, and removed when we vote, they must be conditional
-22:24 <    vapier@> pms is only approved stuff
-22:25 <    vapier@> if it isnt approved, then it's a proposal, and thus not part of pms
-22:25 <    vapier@> seems pretty straight forward to me
-22:25 <     solar > exactly
-22:25 <   ciaranm > the kde people consider kdebuild-1 to be final. as in, not a proposal.
-22:25 <    tsunam+> vapier: exactly =)
-22:25 <    tsunam+> ciaranm: kde is not the concil
-22:25 <    tsunam+> council*
-22:26 <    vapier@> if you want to write stuff in the overlay that uses things that arent in the pms, then whatever, that's your business
-22:26 <    vapier@> but it obviously cant go into the tree
-22:26 -!- billie80 is now known as billie
-22:26 <    Ingmar > We don't have any such plans either..
-22:27 <   ciaranm > is there any reason kdebuild can't just be kept in the official document but clearly indicated in the big master EAPI table at the start as "Only for use in overlays where the overlay owner has approved its use"?
-22:27 <   ciaranm > rather than switching it off entirely for the official version?
-22:27 <    vapier@> a spec is not a dumping ground for unofficial pieces or proposals
-22:28 <      zlin > it's not a proposal. it's a spec for something that won't be used in gentoo-x86.
-22:28 <     solar > putting anything in there that is not targeted at being official sets a bad precedent I'd think.
-22:28 <Philantrop > vapier: It is a spec for kdebuild-1. It's not a proposal but final.
-22:28 <Betelgeuse@> ciaranm: As it's rendered now it's not clear where the conditionals go so it's better turned off.
-22:28 <    vapier@> then maintain it with your overlay
-22:28 <Betelgeuse@> ciaranm: But if the borders are clearer I will reconsider.
-22:28 <    vapier@> pms covers the tree
-22:28 <    vapier@> not random overlays
-22:28 <   ciaranm > Betelgeuse: mm, how is it not clear which bits are EAPI specific?
-22:29 <Philantrop > vapier: Oh, I thought PMS covers the Package Manager Specification, not the tree...
-22:29 <      igli >   
-22:29 <   ciaranm > the EAPI specific stuff is something we want to have done clearly anyway, kdebuild or not
-22:29 <  blackace > obviously, the reason is that it's confusing
-22:29 <   ciaranm > blackace: confusing how, specifically?
-22:29 <    tsunam+> Philantrop: do you disagree that currently gentoo-x86 is the main repository?
-22:29 <    Caster > Philantrop: next it can cover rpm's!
-22:29 <  blackace > ciaranm: see above for examples
-22:29 <    vapier@> the pms was born of the tree
-22:29 <Philantrop > tsunam: Nope.
-22:29 <   ciaranm > i was under the impression that EAPI specific stuff was all marked as EAPI specific
-22:30 <bonsaikitt > if it's not approved, why should it be in PMS at all?
-22:30 <   ciaranm > blackace: well, where isn't it clear what's EAPI specific?
-22:30 <Philantrop > Is there a problem with keeping it in *with* the conditionals?
-22:30 <      amne@> if it's in PMS, every PM should support it, right? so should every PM support kdebuild?
-22:30 <       spb > if it's in PMS, then PMS defines what it is
-22:31 <   ciaranm > Philantrop: it's staying in. the question is whether i can remove the conditionals or not
-22:31 <NeddySeago > Philantrop Do you need the council to approve  kdebuild-1 ?  If not, it should not be in PMS
-22:31 <       spb > if it's on the council's list of supported and allowed EAPIs for gentoo, then any package manager that supports gentoo must support it
-22:31 <    vapier@> if it isnt, then it doesnt belong in pms
-22:31 <       spb > the one does not necessarily imply the other
-22:32 <      igli > i think the answer to the conditional question was given 20 minutes ago
-22:32 <    tsunam+> spb: of course it does!
-22:32 < dberkholz@> are we all defining pms the same way yet?
-22:32 <      igli > or maybe it just felt like 20
-22:32 <Sweetshark > Philantrop: not if the vote is for the rendered pdf without kdebuilds ;-)
-22:32 <    tsunam+> Good lord guys
-22:32 <    Caster > this is ridiculous, and it was voted already so why keep this on
-22:32 < dberkholz@> pms == the approved copy, not the git repository where work happens
-22:33 <    tsunam+> PMS is approved copy of what is APPROVED for the Package Managers, and because of it the TREE
-22:33 <  blackace > pms should be approved or disapproved in it's entirety
-22:33 <    tsunam+> bingo!
-22:33 <    tsunam+> not helter skelter
-22:33 <  blackace > if something goes in it that isn't approved, the whole thing is disapproved
-22:33 <   ciaranm > could someone please state the specific reason that we should make life more difficult for the target audience for PMS by removing all mention of kdebuild-1?
-22:33 <     solar > Sweetshark: all unapproaved EAPI's
-22:34 <    tsunam+> -_-
-22:34 <  blackace > just like passing a bill through congress, if you put earmarks in people don't like, the whole bill doesn't pass
-22:34 <    tsunam+> ^^^
-22:34 <      igli > the target audience isn't people using kdebuild. PM implementors seem to know it quite well and discuss with each other. who else?
-22:34 <    vapier@> the generated PMS is what package managers should be implementing
-22:34 <    Caster > come on, council voted that it won't be part of PMS, so if you want to keep it in the source it must be conditional, end of story
-22:34 <    vapier@> if you want to add something to the PMS, you get it approved
-22:34 <  blackace > like an amendment
-22:34 <    vapier@> how is this difficult to fathom
-22:35 <    tsunam+> vapier: beyond me too :(
-22:35 <     solar > it's not. So call an end of the meeting so I can steal tsunam for some paying work
-22:35 <    tsunam+> lol
-22:35 <   ciaranm > vapier: is there a specific reason that the council can't approve PMS with kdebuild included, but state that only 0 and 1 are allowed in the tree?
-22:35 <      amne@> ciaranm: because it doesn't belong there
-22:35 <    tsunam+> ciaranm: because 0 and 1 were approved in previous PMS's
-22:36 <    vapier@> i generate the pms for reference.  it better not include anything that hasnt been approved.
-22:36 <    tsunam+> kdebuild has not
-22:36 <     solar > EAPI=1 should of never been allowed in this tree.
-22:36 <    vapier@> if you want to add something, get it approved
-22:36 <    vapier@> that is how it works
-22:36 <    tsunam+> spb: we're stuck with it
-22:36 < dberkholz@> let's not rehash that again...
-22:36 <       spb > lol.
-22:36 <Sweetshark > ciaranm: Well, I am target audiance. I reading the spec because im toying with writing a depresolver. I dont care at all about some fancy eapi thats never used in the official tree. keeping that stuff in is _not_ helping.
-22:36 <    tsunam+> erm...
-22:36 <     eroyf > lol.
-22:36 <     eroyf > haha.
-22:36 <    tsunam+> solar: ^^^ se above
-22:36 <   ciaranm > Sweetshark: you don't care about something used in an official gentoo overlay?
-22:36 <Betelgeuse@> EAPI 1 addition will not be rediscussed now.
-22:37 <Sweetshark > ciaranm: not in the first step
-22:38 <    vapier@> what exactly is left to be decided ?
-22:38 <    vapier@> sounds like we've agreed
-22:38 <      amne@> yupp
-22:38 <Betelgeuse@> vapier: nothing?
-22:38 <      amne@> and i gotta go anyway
-22:38 <  blackace > ok, before the meeting is ended, I'd like to get an answer to my question that was buried in the above discussion, has the council discussed the complaints against Philantrop, eroyf, and spb?  and will the complaints be on the agenda for the next meeting?
-22:38 <       spb > there was a complaint against me? on what grounds?
-22:38 <     eroyf > against me?
-22:38 <     eroyf > what.
-22:39 <kingtaco|w > tsunam, btw, are you proxying for flameeyes?
-22:39 <    Caster > isn't the first step devrel?
-22:39 <    tsunam+> kingtaco|work: that is correct
-22:39 <Philantrop > I'd like to know about that, too. Especially since there's no DevRel bug against me.
-22:39 <     eroyf > i'm not even a developer so how the hell would there be any complaints about me blackace?
-22:39 <kingtaco|w > tsunam, kk
-22:39 <     eroyf > blackace: care to answer?
-22:40 <jmbsvicett > eroyf: In theory there could be some userrel action about a user
-22:40 <    vapier@> blackace: yeah, start there
-22:40 <     eroyf > jmbsvicetto: indeed. but ther ehaven't been any that i know of.
-22:40 <    vapier@> eroyf: you have +v in #-dev which can be punted
-22:40 <  blackace > eroyf: my question is for the council members.
-22:40 <  arkanoid > eroyf: that's classified information
-22:41 <Philantrop > Betelgeuse, dberkholz, jokey, vapier, tsunam: Can I please get an official answer about that complaint against me?
-22:41 <    vapier@> blackace: is that sufficient or were you looking for something more ?
-22:41 <     eroyf > i haven't done anything in #gentoo-dev that's weird except for tonight where i've been out due to my 19th birthday party vapier.
-22:41 <     eroyf > blackace: i'd like to know about any complains about me as well given that i'm involved.
-22:41 <  blackace > vapier: is what sufficient?  did I miss an answer to my question?
-22:41 <     eroyf > and i haven't seen any so i doubt there's any.
-22:41 <    vapier@> blackace: start with devrel rather than council
-22:41 <    tsunam+> someone who's a member of the council in general able to give an appropriate answer to Philantrop
-22:42 <    tsunam+> as I'm just a proxy
-22:42 <    vapier@> we'd prefer not to be the starting point, or set an example of being the starting point
-22:42 <  blackace > vapier: complaints were sent to council@, I am asking for status on those complaints since council has not responded nor put it on the agenda.
-22:42 <     eroyf > why haven't any involved members been told about that?
-22:42 <    vapier@> blackace: and i just said
-22:42 <nightmorph > yeah, but that'd be like asking the docs-team why an ebuild isn't stabilized on a missfiled bug, blackace
-22:43 <nightmorph > if it's the wrong team to begin with, why should they have to respond?
-22:43 <Betelgeuse@> blackace: We are not that far yet.
-22:43 <     eroyf > for once, what nightmorph said.
-22:43 <Betelgeuse@> blackace: But I did see your mails :)
-22:44 <  blackace > nightmorph: no, council is the highest body, there is no reason people can't compain to the council directly
-22:44 <  blackace > s/compain/complain/
-22:44 <Betelgeuse@> blackace: Or was it someone else who sent them don't remember.
-22:44 <    vapier@> blackace: there is a reason
-22:44 <  blackace > Betelgeuse: someone else
-22:44 <     eroyf > you should go complain via the normal channels
-22:44 <    vapier@> we have the devrel group in place for complaints
-22:44 <     eroyf > which you obviously fails to do.
-22:44 <    vapier@> eroyf: shut up
-22:44 <Betelgeuse@> blackace: You don't start in the supreme court.
-22:44 <    vapier@> you're just adding noise at this point
-22:44 <Philantrop > Betelgeuse: So does this mean the council rejected the complaints?
-22:45 <  blackace > Betelgeuse: well, this isn't a legal system
-22:45 <    tsunam+> eroyf: devrel is aware of issues and has officially had complaints to it against members stated above as well
-22:45 <    vapier@> Philantrop: that sentence doesnt make any sense
-22:45 <     eroyf > no i am not. i'm saying that he should take it up with devrel / userrel ((devrel for Philantrop and spb) and userrel for me)
-22:45 <    Caster > blackace: but there are defined escalation procedures
-22:45 <  blackace > Caster: which have been followed afaik
-22:45 <    tsunam+> eroyf: I have no proble taking it up with you if you'd like :-D
-22:46 <Philantrop > tsunam: Interesting. So why wasn't I even informed as the accused party?
-22:46 <    Caster > then I don't know the one that says "start with council" :)
-22:46 <     eroyf > tsunam: fine with me, but i don't want to see my name mentioned in any coucil log by blackace when i've no clue what he's talking about.
-22:46 <    tsunam+> eroyf: lol
-22:46 <     eroyf > tsunam: if it was taken up with userrel, fine. i'd listen to you guys.
-22:46 <  blackace > again, I am not here to argue, I am here asking the council if they will have an agenda item at their next meeting.
-22:46 <    tsunam+> eroyf: just saying if you'd like to talk to userrel
-22:46 <     eroyf > i'm fine talking with userrel and i'd listen to whatever you might say.
-22:47 <    tsunam+> there are area's that directly state the council for issues
-22:47 <     eroyf > nod
-22:48 <Philantrop > Can I get a straight answer from anyone here?
-22:49 <Sweetshark > blackace: not the right time to ask - depends on if devrel etc. will need to escalate. bothering the council now with it is just ... bothering
-22:49 <    vapier@> Betelgeuse will take it over, i'm outs
-22:49 <Philantrop > tsunam: "<tsunam> eroyf: devrel is aware of issues and has officially had complaints to it against members stated above as well" - would you kindly enlighten me?
-22:50 <  blackace > Sweetshark: and you're not council, I'm not asking you a thing.
-22:51 <Philantrop > And while we're at the subject of enlightening people: "<wltjr>	NeddySeagoon: other than we are losing GNi in like ~20 days now, nope" - we're losing GNi? As in "as a sponsor"? Or what?
-22:51 <  arkanoid > blackace: afaik, two members of council told you this was the wrong place to start. Is that not an answer?
-22:51 <Betelgeuse@> Philantrop: We haven't rejected them or acted on them yet. Sorry to be a bit vague at this point but we need to decide internally first on how to go forward.
-22:51 <    tsunam+> Philantrop: that is not entirely the case
-22:52 <    tsunam+> Philantrop: and that is strictly a Foundation issue
-22:52 <     solar > great. So is this meeting over?
-22:52 <    tsunam+> Philantrop: its being handled by the Foundation and the infrastructure team
-22:52 <  blackace > Betelgeuse: thanks, that is actually a partial answer to my question.
-22:53 <     eroyf > gentoo's losing gni?
-22:53 <     eroyf > isn't gni the main sponsor of gentoo?
-22:53 <    tsunam+> eroyf: they are a large sponsor for Gentoo yes
-22:53 <Betelgeuse@> Any council members oppose ending the meeting?
-22:53 <     eroyf > don't they host bugzilla and stuff?
-22:53 < dberkholz@> alright, we're getting more and more away here
-22:53 <    tsunam+> eroyf: they do yes
-22:53 <Betelgeuse@> eroyf: The sky is not falling.
-22:54 <Philantrop > Betelgeuse: Strange way to handle complaints... Keeping the accused people in the dark about it.
-22:54 <     eroyf > anyways
-22:54 <     eroyf > before you end
-22:54 <    tsunam+> Philantrop: why invove the accused, if no decision to even do anything has been decided
-22:54 <     eroyf > as Philantrop, i'd like to hear about any complains about me.
-22:54 <  arkanoid > Philantrop: they had great success with that in the medieval times too
-22:54 <     eroyf > and not directly from blackace since i don't care about him. but from the council / devrel / userrel.
-22:55 <    tsunam+> Philantrop: I am sure if anything was to be decided to happen, you would be informed and be giving a chance to discuss the matter in a fair way
-22:55 <  blackace > eroyf: careful, you're gonna hurt my feelings saying things like that :)
-22:55 <Philantrop > tsunam: It's a very rude way, I must say. Letting this going public but not even letting me know what it is about.
-22:56 <Betelgeuse@> Philantrop: If it wasn't brought up here you would have gone on happily until we possibly would contact you. I don't see any harm in that.
-22:56 <Betelgeuse@> Philantrop: We didn't let the genie out of the bottle.
-22:56 <  arkanoid > Betelgeuse: but it's out nonetheless :)
-22:56 <Betelgeuse@> Yes it's valid a question to ask where it's going of course.
-22:56 <    tsunam+> I call for an end to the meeting for today
-22:56 <Philantrop > Betelgeuse: It has been brought up here so I'd say I have a right to know about it.
-22:56 <    tsunam+> Anyone second
-22:57 <    tsunam+> as this is beyond the confines of the meeting
-22:57 <     eroyf > Philantrop's question needs to be answered first tsunam.
-22:57 <     solar > No it does not
-22:57 <     solar > it's so fscking off topic
-22:57 <Betelgeuse@> tsunam: yeah
-22:57 <    tsunam+> eroyf: Its been answered "not sufficently" for Philantrop's expectations, but answers have been given
-22:57 <Philantrop > solar: No, two involved parties have asked the council for an official statement.
-22:57 <     jokey@> right, so anyone having anything left for this meeting?
-22:58 <     solar > Philantrop: and the council already said this is not the proper channel
-22:58 <     eroyf > solar: Philantrop and I've asked the council for an official statement. That should be enough.
-22:58 <     solar > so.. Please.. End this meeting. You are waiting everybodies time.
-22:58 <Betelgeuse@> I already said that we can't give a public statement at this point.
-22:58 <Betelgeuse@> But yes we have received said complaints.
-22:58 <  arkanoid > Betelgeuse: I'm sure just telling the involved parties about it would be satisfactory for them :)
-22:59 <  arkanoid > no need to inform the rest of us
-22:59 <Philantrop > Ok, that's enough. I'll give it a night to sleep over but I'm probably going to retire from Gentoo for this absurd and *perverted* handling of complaints.
-22:59 <    tsunam+> it would appear its not even at the preliminary point
-22:59 <Betelgeuse@> arkanoid: again the council did not start this line of discussion
-22:59 <    tsunam+> I'm gone
-22:59 <Sweetshark > eroyf: council resolved the bug as INVALID DOWNSTREAM. Everything else is just that it was inapproprate to bring this up here, but thats not councils job either, i guess (devrel again).
-22:59 <    tsunam+> night all
-23:00 <  arkanoid > Betelgeuse: nope, but know that they know about it, it does seem appropriate to inform them (and only them) properly. but then again, it was just a proposal to reach an understanding between you
-23:00 < dberkholz@> here's a summary, feel free to suggest changes before i mail it out in a little while
-23:00 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080410-summary.txt
-23:01 <   ciaranm > dberkholz: could you include the rationale for the kdebuild-1 decision please?
-23:01 < dberkholz@> ciaranm: sure, do you have any quotes handy or should i dig 'em up
-23:01 <Philantrop > dberkholz: Would you please add the unwillingness of both council and devrel to even inform the accused of what they're accused of?
-23:02 < dberkholz@> sure
-23:02 <   ciaranm > dberkholz: i ask because i don't think i understood the rationale part, and i'd like to see it rephrased
-23:04 <Betelgeuse@> Philantrop: As some members already left I didn't want to take actions into my own hands.
-23:06 <Betelgeuse@> Philantrop: And you caught us off guard any way as this wasn't supposed to be handled in this meeting.
-23:06 <Betelgeuse@> Philantrop: Well not you but blackace.
-23:06 <Philantrop > Betelgeuse: It's pretty much a moot point now. If the council didn't reject the complaint against me yet, I should be informed about its contents. If it did reject the complaint, I don't care. But hearing that DevRel has obviously received a complaint against me and isn't even informing me about it, is something I consider in extremely bad taste.
-23:06 <    Fieldy > if i may chime in, that may be something to talk to devrel about.
-23:07 <   astinus > and the reason it was raised direct with Council
-23:07 <   astinus > is because DevRel does precisely nothing, in almost all cases
-23:07 <   astinus > and this has gone far enough, Gentoo is simply *not* fun any more when stuff like this keeps happening.
-23:07 <nightmorph > badmouthing one group doesn't help anything
-23:08 <       spb > it is, on the other hand, rather amusing when stuff like this keeps happening
-23:08 <   astinus > spb: Not when it costs us good developers.
-23:08 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
-23:08 <       spb > oh, the good developers are already gone
-23:08 <       spb > not much to worry about really
-23:10 <Philantrop > spb: Thank you. ;->
-23:12 <Betelgeuse@> I need to go to bead now.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080508-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080508-summary.txt
deleted file mode 100644
index 9887f0b8c4..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080508-summary.txt
+++ /dev/null
@@ -1,209 +0,0 @@
-Quick summary
-=============
-
-Active-developer document: We reviewed it and made some suggestions for 
-improving both the document and the online developer list (adding 
-dates).
-
-ChangeLog entries: Always required. If you aren't making them now, fix 
-your script to call echangelog.
-
-Ignored arch-team bugs: What's the workflow for undermanned arch teams? 
-Can we improve it?
-
-8-digit versions: Ask package maintainers with extremely long PVs 
-whether they were needed and test the impact of extending 
-versionator.eclass. Make decision once this data is available.
-
-Enforced retirement: After 2.5 hours on the previous topics, people had 
-to go to sleep and jokey's computer broke. Instead of waiting till the 
-next regular meeting, because of its urgency, we scheduled a special 
-session next week at the same time. The appeals will *not* be decided 
-then -- it's about figuring out the validity and the process.
-
-New meeting process: 105 minutes were closed and 57 were open. It might 
-save some time if we always moderated, but it won't cut it in half. 
-Should we keep doing this, or modify it a little to have a moderated 
-#-council and open backchannel?
-
-
-Roll call
-=========
-
-(here, proxy [by whom] or slacker?)
-
-amne        slacker [30 minutes late]
-betelgeuse  here
-dberkholz   here
-flameeyes   here
-lu_zero	    here
-vapier      proxy [solar]
-jokey       here
-
-We gave amne 15 minutes to show up before getting a slacker mark.
-
-
-New process
-===========
-
-The last few meetings have dragged out for hours unnecessarily. This 
-time, we tried moderating the channel during discussion of each topic, 
-then temporarily opening the floor for that topic before a vote so 
-anyone could contribute. Here's the time breakdown:
-
-	2000-2030: closed, 30 min
-	2030-2046: open, 16 min
-	2046-2056: closed, 10 min
-	2056-2114: open, 18 min
-	2114-2146: closed, 32 min
-	2146-2209: open, 23 min
-	2209-2242: closed, 33 min
-	2242-    : open floor
-
-Total before open floor: 105 minutes closed, 57 minutes open.
-
-Optimistically, we could have saved an hour if the channel was moderated 
-throughout the meeting. That's unlikely to be the case in reality, 
-because we'd be redirecting people's comments from queries into the 
-channel.
-
-Should we keep it moderated until the final open floor? Should we have 
-an open "backchannel"?
-
-
-Updates to last month's topics
-==============================
-
-	http://www.gentoo.org/proj/en/council/meeting-logs/20080410-summary.txt
-
-	Document of being an active developer
-	-------------------------------------
-	Last month:
-		No updates
-	Updates:
-		araujo made http://dev.gentoo.org/~araujo/gcert1.pdf in Scribus. 
-		He'd like to ask for approval of this design and discuss the 
-		script, in particular its infrastructure requirements.
-
-		Suggestions on certificate content:
-			-Add title to the top: "Developer Certification"
-			-Add devrel contact info (general devrel email address)
-			-Add link to devrel userinfo page
-			-Add start and end dates to devrel retired developers page
-			-Add a sentence saying e.g. "This certifies that XXX was a 
-			 Gentoo developer from START_DATE to TODAY_DATE." The point 
-			 is to avoid implying that the developer is certified 
-			 forever, or will be a developer in the future.
-
-		The information should be gotten from LDAP, for example using 
-		python-ldap. Could base this script on devrel's slacker script.
-
-		It's unsure how signatures are going to happen, but one option 
-		is to keep a GPG-encrypted image of a signature and decrypt it 
-		on-demand for certificate creation. This should be discussed 
-		with the person doing the signing.
-
-
-	Slacker arches
-	--------------
-	4 months ago:
-		vapier will work on rich0's suggestion and repost it for 
-		discussion on -dev ML
-	2 months ago:
-		vapier said he was going to work on it that weekend.
-	Last month:
-		No updates
-	Updates:
-
-
-New topics
-==========
-
-	When are ChangeLog entries required?
-	------------------------------------
-	This question mainly relates to arch stabilizations.
-
-	The consensus was that ChangeLog entries even for arch 
-	stabilizations provide valuable information that is unique without 
-	network access and more accessible than CVS logs even with network 
-	access.
-
-	Some people were curious what proportion of space ChangeLogs take in 
-	the tree, but most people didn't think that was relevant.
-
-	welp suggested making a changelog message part of repoman commit.
-
-	It would be helpful for the QA team to help with checking for and 
-	enforcing ChangeLog messages. If that doesn't help matters, the 
-	council may have to take action.
-
-
-	Can the council help fewer bugs get ignored by arm/sh/s390 teams?
-	-----------------------------------------------------------------
-	The work happens, but Mart says it's not communicated to anyone and 
-	has no relationship to whether bugs are open.
-
-	We need to understand the workflow of undermanned arch teams and see 
-	whether there's anything we can help improve.
-
-	Possibly improving recuitment -- add a good, motivating 
-	staffing-needs entry.
-
-
-	PMS: Are versions allowed to have more than 8 digits?
-	-----------------------------------------------------
-	http://archives.gentoo.org/gentoo-dev/msg_db2f5c09c2c0c8b042ca3d0dcec7cdaf.xml
-	https://bugs.gentoo.org/show_bug.cgi?id=188449
-
-	What do various PMs/tools support? Portage, Pkgcore, Paludis all 
-	handle >8. portage-utils does not but could be fixed to use longs 
-	instead of ints, with some loss of performance (magnitude unclear).
-
-	versionator.eclass also needs fixing for >8 digits.
-
-	Apparently [ ]-style tests break with large numbers, but [[ ]] 
-	works. Have to be careful which tests are getting used anywhere 
-	large versions are compared.
-
-	The council generally favored allowing versions to have <=18 digits. 
-	This allows them to fit into 64 bits (18 signed digits or 19 
-	unsigned) and gives them an upper bound, which some implementations 
-	of version parsing could find useful.
-
-	We voted to do more research and testing, specifically to ask the 
-	package maintainers with extremely long PVs whether they were needed 
-	and to test the impact of extending versionator.eclass. The involved 
-	packages:
-
-		sys-process/fuser-bsd
-		sys-apps/net-tools
-		sys-apps/gradm
-		net-im/ntame
-		media-video/captury
-		media-libs/libcaptury
-		media-libs/capseo
-		sys-block/btrace
-		www-apache/mod_depends
-		net-wireless/rt2500
-		sys-fs/unionfs
-
-
-	Enforced retirement
-	-------------------
-
-	The meeting had already gone 2.5 hours and we were short multiple 
-	council members because of the late hour in their timezone, or 
-	broken hardware in the case of jokey. Because of the urgency of 
-	getting this resolved, we decided it couldn't wait for next month's 
-	meeting and scheduled a special session for next week at the same 
-	time.
-
-
-	Open floor
-	----------
-
-	Some people thought that we were going to make a final decision on 
-	the above appeals today, because the agenda was insufficiently clear 
-	on that. That was not the case. What we intended to do was explain 
-	why we can take the appeal and then figure out the process for it
-	because we haven't done any appeals before.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080508.txt b/xml/htdocs/proj/en/council/meeting-logs/20080508.txt
deleted file mode 100644
index c07a4c659d..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080508.txt
+++ /dev/null
@@ -1,795 +0,0 @@
-19:59 -!- mode/#gentoo-council [+m] by Betelgeuse
-20:00 <Betelgeuse@> Houston we have a go.
-20:00 <     jokey@> yep
-20:00 -!- mode/#gentoo-council [+v solar] by Betelgeuse
-20:00 <Betelgeuse@> Was anyone else proxying?
-20:01 -!- mode/#gentoo-council [+v FlameBook] by Betelgeuse
-20:01 -!- mode/#gentoo-council [+m] by dberkholz
-20:01 < FlameBook+> I don't see JoseJX
-20:01 -!- mode/#gentoo-council [+v solar] by dberkholz
-20:02 -!- Irssi: #gentoo-council: Total of 79 nicks [8 ops, 0 halfops, 2 voices, 69 normal]
-20:03 < dberkholz@> lu was active 10 minutes ago, so not sure he needs a proxy..
-20:03 <   lu_zero@> I don't need it
-20:03 <   lu_zero@> as I said I was afraid of being in late ^^
-20:03 <Betelgeuse@> Anyone seen amne?
-20:03 < dberkholz@> if anyone besides solar is proxying, query me now
-20:04 < dberkholz@> everyone's spoken in the past ~10 minutes except amne, with solar proxying for vapier
-20:05 < dberkholz@> we've got 6 people, let's get started and give amne another 10 minutes to show up before he gets a slacker mark. sound good?
-20:06 <     jokey@> yup
-20:06 <Betelgeuse@> sure
-20:06 <   lu_zero@> ok
-20:06 <   lu_zero@> anybody could sms him?
-20:06 < dberkholz@> first topic: "Document of being an active developer"
-20:06 -!- mode/#gentoo-council [+v araujo] by dberkholz
-20:07 < dberkholz@> araujo: anything to say, besides what's in the agenda?
-20:07 < FlameBook+> lu_zero: let me
-20:08 < dberkholz@> ok, anyone got opinions on http://dev.gentoo.org/~araujo/gcert1.pdf ?
-20:09 <Betelgeuse@> should it have links to somewhere?
-20:09 <   lu_zero@> dberkholz looks nice
-20:09 < dberkholz@> i'm not sure that the trustees are the correct group
-20:09 <Betelgeuse@> And a title.
-20:10 < dberkholz@> 20:09 <NeddySeago> It needs a date of signing ... and maybe an expiry date
-20:11 < dberkholz@> Betelgeuse: like "Developer Certification" on the very top?
-20:11 <     jokey@> one year expiration was agreed on wasn't it?
-20:11 <Betelgeuse@> dberkholz: something like that yes
-20:12 < dberkholz@> (for anyone who hasn't followed this, these certificates are apparently required for some jobs and such. a couple of people had a need for it.)
-20:14 <     jokey@> so, given we add an expiration date, I'm all for it
-20:14 < dberkholz@> Blackb|rd suggests that we just add a "signed" date instead of an expiration date
-20:15 <    araujo+> hello
-20:15 <    araujo+> dberkholz, well, I wonder about the infra side to implement this script
-20:15 <   lu_zero@> I'm not sure about the expiration date
-20:16 <    araujo+> jokey, I don't think that's needed since we specify the year in the cert
-20:16 <   lu_zero@> a start date and an issue date should do better
-20:16 <    araujo+> we could be more specific with the date
-20:16 <    araujo+> yeah lu_zero , that sounds good
-20:17 <     jokey@> maybe some url to verify validity
-20:17 <   lu_zero@> so "Gentoo developer since $date" "Issued $othe date"
-20:17 < dberkholz@> i'm getting lots of queries about expiration dates .... my thinking is that a signed date reflects the same information without trying to know the future
-20:17 <   lu_zero@> jmbsvicetto suggests something along "is a Gentoo developer since X/Y/Z and a member ..."
-20:18 <    araujo+> jokey, like http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml ?
-20:18 <     jokey@> araujo: yeah, something like that
-20:18 < dberkholz@> astinus suggests that we need contact information to verify this if employers want to do so
-20:19 < FlameBook+> amne is having network trouble, so I would suppose he might or might not appear
-20:19 < dberkholz@> for example a devrel contact
-20:19 <     jokey@> trustees@ would be the right thing then
-20:19 <    araujo+> dberkholz, contact information ... like ?
-20:19 < dberkholz@> devrel seems like the right group for this HR-related thing, rather than trustees
-20:19 <   lu_zero@> I agree with dberkholz
-20:20 <    araujo+> Ok, so, Devrel is enough to validate this document'
-20:20 <    araujo+> ?
-20:20 <     jokey@> works4me
-20:20 <    araujo+> ok, and what we could add for the contact information? ... devrel mail?
-20:21 <     jokey@> dunno if chrissy wants to give out her phone# ;)
-20:21 <     solar+> I doubt that she would want to
-20:21 < dberkholz@> arkanoid continues to stress the importance of expiration dates
-20:22 <    araujo+> hah ... well ... what if we create a section with the whole contact information for these certs , and use that link then?
-20:22 < dberkholz@> one thing we could do to address this is say "XXX has been a Gentoo developer from DATE to DATE"
-20:22 <   lu_zero@> I don't see what's the meaning of expiration date
-20:23 <   lu_zero@> that the certificate isn't valid?
-20:23 <    araujo+> ColdWind says that he doesn't agree with this on devrel, because that's for developer relations only , and this will involve outsiders
-20:23 < FlameBook+> what about writing on the certificate an encrypted code that can be verified automatically on the website?
-20:23 <   lu_zero@> FlameBook works for me
-20:23 < dberkholz@> i don't think we need that, we could just point to the userinfo page
-20:23 < dberkholz@> it has a link to retired devs
-20:23 <    araujo+> correct
-20:23 <   lu_zero@> and HR people could just check the website
-20:23 < FlameBook+> dberkholz: to stop possible forgery, if that ever makes sense
-20:24 <    araujo+> every time I asked about the best way to validate a developer status, was to chek the developer info page
-20:24 <     jokey@> I'm with dberkholz there, maybe making that a bit more obvious where to find "active" and "retired" ones but that should do then
-20:24 < dberkholz@> we should try to add some date fields to the retired devs page
-20:24 <    araujo+> fmccor agrees with this on devrel , and we can arrange for further contact if necessary, and no to phone numbers. <i agree>
-20:25 <    araujo+> I like the idea of the 'start date' and 'issue date'
-20:25 <    araujo+> with a link to the userinfo page
-20:28 <   lu_zero@> anybody else?
-20:28 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080508-summary.txt has 4 suggestions in it. anyone disagree with one or have more to add?
-20:29 < dberkholz@> ah right, the title
-20:29 <    araujo+> dberkholz, what devrel contact info exactly?
-20:29 < dberkholz@> araujo: reload =)
-20:29 <    araujo+> ah ok, good
-20:30  *   araujo agrees
-20:30 <     jokey@> looks good donnie
-20:30 < dberkholz@> seems we've covered most points, i'm going to open the floor for further comments on this topic
-20:30 -!- mode/#gentoo-council [-m] by dberkholz
-20:30 <      amne@> oi
-20:31 <      amne@> very sorry about the delay, i had some bloody networking problems
-20:31 < FlameBook+> and there comes amne :)
-20:31  *     amne goes read the backlog
-20:31 <   lu_zero@> =)
-20:31 <    araujo+> ok, so we agree about this?
-20:32 <   astinus > amne: slacker!
-20:32 <     jokey@> araujo: yep, fine with me :=)
-20:32 <    araujo+> if we agree about the cert format ... now I have to take care of the design, which I will be sending to -dev later ... I would like to talk about the infra side for the script
-20:33 <   astinus > araujo: I'm not sure what you'd need which is special?
-20:33 <   lu_zero@> fine for me
-20:33 <NeddySeago > araujo, if devrel will sign (in ink) and scan and email, why do you need a script at all ?
-20:33 <    araujo+> scribus is basically plain xml , so I guess I am free to choose any available scripting language for it , but I want to know what it is the preferred way to extract this developer information ...
-20:34 <     jokey@> araujo: ldap works best afaik
-20:34 <   astinus > araujo: from LDAP?
-20:34 <Betelgeuse@> araujo: python-ldap should work
-20:34 <   astinus > *nod*
-20:34 <    araujo+> NeddySeagoon, oh, you have brought a good point :-]
-20:34 <     jokey@> unisono heh
-20:34 < FlameBook+> NeddySeagoon: would be simpler to scan a signature and add it over the image :)
-20:34 <    araujo+> Should this cert be hand-signed (ink) , or can it be generated by a script with the digital of it?
-20:35 <    araujo+> Ok, good, ldap ...
-20:35 < dberkholz@> who's comfortable with having their scanned signature sitting on a gentoo box?
-20:35 <NeddySeago > it should be hand signed and emailed in a signed email
-20:35 < Blackb|rd > araujo: only after ten years of service as a dev :D
-20:35 <NeddySeago > dberkholz, not me
-20:36 < dberkholz@> from our previous discussions, i thought we could just digitally sign it with gpg
-20:36 <    araujo+> well, yeah .. this is an important detail we almost miss to discuss ... :-P
-20:36 < Blackb|rd > dberkholz: inside the PDF or detached?
-20:36 <     pilla > dberkholz: I am not sure that many potential employers will figure it out
-20:36 <Betelgeuse@> dberkholz: What's so compromising about signatures?
-20:36 < Blackb|rd > araujo: does the pdf generation process support "inline" sigs?
-20:36 <    araujo+> I guess this is pretty much up to devrel/trustee ..
-20:36 < Blackb|rd > araujo: crypto sigs, that is.
-20:37 < dberkholz@> Betelgeuse: anyone could forge my name on any document they cared, if the box gets compromised..
-20:37 <     pilla > if the signature is not crypto-protected itself, yes
-20:37 <    araujo+> Blackb|rd, will have to check it out
-20:37 <   astinus > dberkholz: We can already do that by getting ahold of any document you've ever signed and scanning it.
-20:37 <Betelgeuse@> ^
-20:37 < FlameBook+> as astinus said
-20:37 < dberkholz@> astinus: do you have access to any of those?
-20:37 < dberkholz@> are any of them on a gentoo box?
-20:38 <   astinus > dberkholz: I'd bet $20 it wouldn't be that hard. Probably easier than hacking an Infra box.
-20:38 <Betelgeuse@> any way OT
-20:38 <     jokey@> indeed
-20:38 < FlameBook+> astinus: it's easy to bet $20 >_>
-20:38 <Betelgeuse@> I sign different stuff all the time.
-20:38 <     jokey@> special details that can be discussed later
-20:38 <     jokey@> and are not subject of general "worksforus"
-20:38 <   antarus > hrm, council meeting? :)
-20:38 <   astinus > my point was *yes* there is a concern about storing a sig and overlaying onto the PDF, *but* if someone really wants your signature, there's 101 ways to get it.
-20:38 < Blackb|rd > If the retired devs page was easier to find, no need for sigs, IMHO
-20:39 < dberkholz@> that's up to the people who would have to sign it
-20:39 <NeddySeago > lets move on ... its an implementaion detail
-20:39 <   astinus > dberkholz: script it so the signature IMG is gpg'd and require it be decrypted each time as part of the certificate generation process?
-20:39  *  astinus nods
-20:40 <    araujo+> ok, but, we should agree on this
-20:40 <     jokey@> NeddySeagoon++; dberkholz: let's note that on summary that this detail has to be discussed with the signing person and move on
-20:40  *   araujo is fine with both
-20:41 <    araujo+> astinus, we can do that
-20:41  *     amne <- finished reading backlog, anyone want me to say anything? :-P
-20:41 <   astinus > amne: nah, you're just the token four-letter-nick guy ;)
-20:42 <      amne@> heh. in that case i'll just agree to what the others already said
-20:42 <    araujo+> I like astinus idea
-20:42 <    araujo+> anyone?
-20:43 < dberkholz@> sure, and i agree with jokey
-20:43 < dberkholz@> discuss that with the signer
-20:43 <      amne@> yupp
-20:44 < dberkholz@> so, next actions are for araujo to add the suggestions in the summary to the certificate, and to work on a script to acquire info from ldap
-20:44 <    araujo+> dberkholz, ok
-20:44 <   antarus > araujo: if you need help with ldap
-20:44 <   antarus > I am a wizard
-20:44 <   antarus > with pointy hat
-20:44 <    araujo+> antarus, welcome :-]
-20:44 < dberkholz@> araujo: you may also wish to discuss the signing with people in devrel
-20:44  *  astinus pops antarus' oversized head :P
-20:44 < dberkholz@> anyone else got something new to add to this topic?
-20:44 <Betelgeuse@> araujo: or could just use the new slacker script to startt with
-20:44 <    araujo+> Betelgeuse, what is that?
-20:45 <Betelgeuse@> http://rafb.net/p/5UU0MV64.html
-20:45 <     jokey@> dberkholz: doesn't look like it, next topic
-20:45 <    araujo+> Betelgeuse, nice :-]
-20:45 <     jokey@> just more details for hacking it up which can be adressed in #-dev or somewhere ;)
-20:45 < dberkholz@> Betelgeuse, araujo -- feel free to continue talking about details in #-devrel or #-dev, let's move on to the next topic here
-20:45 <  ferringb > Betelgeuse: iteritems not items :P
-20:45 -!- Irssi: #gentoo-council: Total of 88 nicks [8 ops, 0 halfops, 3 voices, 77 normal]
-20:46 <    araujo+> ok, good
-20:46 -!- mode/#gentoo-council [-v araujo] by dberkholz
-20:46 -!- mode/#gentoo-council [+m] by dberkholz
-20:46 < dberkholz@> next topic: slacker archs [vapier]. solar, don't suppose you've got any updates from him?
-20:47 <     solar+> He did not make me aware of that topic.
-20:47 < dberkholz@> ok
-20:47 < dberkholz@> nothing new then, and let's proceed to the new topics
-20:47 <     jokey@> was there any "preview" of what he worked on?
-20:48 < dberkholz@> not that i know of
-20:49 < dberkholz@> next topic: "When are ChangeLog entries required?"
-20:49 < dberkholz@> my opinion is "always"
-20:50 < FlameBook+> always for me too
-20:50 <     jokey@> same here though there is this special changelog in profiles
-20:50 <     solar+> that is an interesting topic and I would say the same. but I know the guy that I'm proxing for is the biggest offender of that
-20:50 < dberkholz@> with a possible exception for when you're changing the changelog itself in minor ways
-20:50 <Betelgeuse@> Or when rewerting a commit.
-20:50 <     jokey@> Betelgeuse: imho even that should be noted
-20:51 <     solar+> For sure when you touch a package that does not list you in the metadata.xml
-20:51 <Betelgeuse@> jokey: Useless noise if it never reaches rsync
-20:51 < dberkholz@> on the other side, many people think that stabilization entries in changelogs are just adding spam
-20:51 < dberkholz@> do they provide useful information, and is it worth the additional space?
-20:51 < FlameBook+> dberkholz: good reason to keep them: you want to know when a package was stabilised last
-20:51 <     solar+> it might but as a maintainer it gives me an idea of when XYZ arch marked pkg stable.
-20:51 < FlameBook+> and by who
-20:52 <      amne@> i think it's useful, so always++
-20:52 <Betelgeuse@> dberkholz: They are more useful for maintainers than users.
-20:52 <Betelgeuse@> But useful any wa.
-20:52 < FlameBook+> let's remember that cvs history needs network access to work
-20:52 < FlameBook+> if we had the full history locally, I'd be more likely not to push for always always always, but for now...
-20:53 <     jokey@> indeed, just go with "always" and be done
-20:56 < dberkholz@> i'm going to open the floor, a few people have things to say
-20:56 -!- mode/#gentoo-council [-m] by dberkholz
-20:56 <      amne@> had some network fuckup myself earlier ;-)
-20:57 <      amne@> oops
-20:57 <  ColdWind > just want to agree with all of you: stabilization entries are useful to me both as package maintainer and AT
-20:57 < Blackb|rd > always++
-20:57 <      amne@> and that was another network fuckup, sorry
-20:57 <    fmccor > As long as there is something called ChangeLog present, it seems to me that I should expect it to show some indication of all changes.
-20:57 < Blackb|rd > Also, stabiliziation entries should be filterable with a small amount of regex work.
-20:57 <     jokey@> anyone objections to "always" ?
-20:58 < FlameBook+> we _could_ generate the changelog out of cvs
-20:58 <    fmccor > And even when just marking something stable, I add a bit more information to the changelog.
-20:58 <   antarus > I object wholly to the stating of the question
-20:58 < dberkholz@> amne: can you stop swearing please, we're in the middle of a meeting here...
-20:58 <   antarus > I think the opposite question is better ;P
-20:58 <  ColdWind > jokey: just that you'll have to make the decision effective
-20:58 < FlameBook+> I know I can easily generate it from svn through a modified svn2cl, not sure about cvs though, it doesn't export it as xml
-20:58 <      leio > there are things like "Fix whitespace", removal of ancient redundant versions that can spam quite a bit with the removal notice on lots of patches that have been incorporated, and so on
-20:59 <     jokey@> ColdWind: I'd be willing to hack up a watcher for commits mailinglist or do it myself
-20:59 <      amne@> dberkholz: sorry, that was from a /msg and went into here because my connection died appearently
-20:59 <   antarus > it is impossible to enumerate all the cases where a changelog is required and trivial to enumerate the cases where one is not required
-20:59 <   antarus > well not impossible, but difficult
-20:59 < FlameBook+> leio: removal of a version is something _users_ might want to know about...
-20:59 <  ColdWind > jokey: actually I was talking about vapier following the decison
-20:59 <   antarus > ColdWind: enforcement is a different issue no?
-21:00 <      leio > it's gone from the filesystem, so common sense says it was removed
-21:00 < FlameBook+> leio: why? by who? was there a good reason? and so on...
-21:00 < FlameBook+> at least I tend to say why I remove something _especially_ if it's ancient
-21:00 <  ColdWind > antarus: yes (and here ends my flooding)
-21:01 < FlameBook+> if it's just not a stable candidate I can see it not to be so useful, but that's a minimum amount of messages
-21:02 <   impulze > what about the size of the tree especially when you consider tons of packages with huge changelogs? will older entries vanish from the file from time to time?
-21:02 < FlameBook+> do we have an estimate of how much space do changelog take?
-21:03 <   antarus > we can look
-21:03 <   antarus > someone want to volunteer or am I doing it? :)
-21:03 <   astinus > you just volunteered.
-21:03 <     jokey@> you do it (tm)
-21:04  *  antarus cvs ups
-21:04 < Blackb|rd > 753<
-21:04 <   impulze > or probably just keep changelogs for active ebuilds in the tree which would then of course not show why a package was removed
-21:04 < Blackb|rd > er M
-21:04 < Blackb|rd > (generated from find . -name Changelog|xargs du -h)
-21:04 <   armin76 > lol
-21:04 <   armin76 > really? how much is the full tree?
-21:04 < FlameBook+> reasons for package removal can be found on the mailinglists that's another problem entirely
-21:05 <   astinus > armin76: about that.
-21:05 < Blackb|rd > armin76: erm. 753M.
-21:05 <     jokey@> though where I'm willing to make a cut is "old" history
-21:05 < Blackb|rd > There's something amiss :)
-21:05 <     jokey@> like if the changelog grows beyond 100kb, gzip the overlapping part
-21:05 <     jokey@> (or any other size value we can come up with)
-21:05 < Blackb|rd > armin76: ChangeLog, not Changelog.
-21:06 < dberkholz@> i got 52M
-21:06 < Blackb|rd > 75.9M
-21:06 <      leio > basically the cause of raising this was that stabilizations don't get noted and maintainers, arch testers and the users of that arch might want to see it, so there seems to be a reason to have them noted - maybe arguably. I don't know why some trivial thing is useful to someone to see in ChangeLog and they can clutter the useful things indeed as for example vapier also believes. The problem is that own judgments are made on what should be there
-21:06 <      leio >  and what not, making it all inconsistent
-21:06 < dberkholz@> from this: find /usr/portage/ -name ChangeLog | xargs du -b | awk 'BEGIN { TOT=0 } { TOT += $1 } END {print TOT}'
-21:07 <   impulze > yeah so it's pretty "big" already
-21:07 <  ColdWind > and that's collaterally related to arches not dealing with arch bugs
-21:07 < FlameBook+> dberkholz: full size of your tree?
-21:07 < FlameBook+> [please note that most of those changelog wouldn't take up _less_ space if they where shorten most likely, it depends on your blocksize]
-21:07 <Betelgeuse@> leio: The only one I am aware of that doesn't record stuff to ChangeLog is vapier.
-21:07 < Blackb|rd > dberkholz: you're right. I shouldn't do public shellscripting
-21:07 <   astinus > dberkholz: find . -iname 'ChangeLog' -type f | xargs du -bhc
-21:08 <   astinus > dberkholz: 3.2MB?
-21:08  *     welp wants to be like vapier and not make changelog entries
-21:08 <     jokey@> anyway, "always" still holds, doesn't it?
-21:08 <      leio > I admit that I sometimes don't record removals of things when they are really ancient and no-one should have been using them for a long time already.
-21:08 < Blackb|rd > astinus: du gets called multiple times
-21:08 <    fmccor > leio, I always note any change, and if I look at a ChangeLog, I want to see a track of all changes, whatever they are.
-21:08 <      amne@> jokey: yeah, seems block size eats more than the actual changelogs
-21:08 <   antarus > so to be fair
-21:08 <   impulze > astinus: that's for the last directory
-21:08 <   antarus > if you want it to happen all the time
-21:09 <      leio > I also don't see whitespace fixes being noted in ChangeLogs, and other things (I haven't done research to bring more examples)
-21:09 <   antarus > you should automate it]
-21:09 <      amne@> jokey: but that's another issue
-21:09 <   antarus > because people are fallable
-21:09 <   lu_zero@> I'd keep the current behaviour and avoid changelogs if we switch to something saner
-21:09 <   astinus > impulze: well, its for the last invocation of du, which isn't necessarily the last directory =)
-21:09 <      welp > i just have a little script which updates the changelog with whatever my repoman commit message is
-21:09 <   impulze > astinus: true
-21:09 <   impulze > yeah the format of the changelog should be clear and specified so one can extract information out of it
-21:09 <     jokey@> lu_zero: ++ on that
-21:09 < FlameBook+> welp: I suppose we all have it, just need to call echangelog before the commit :P
-21:10 <   astinus > welp: maybe you should loan that script to vapier? ;)
-21:10 <   lu_zero@> would be nicer have a stock one in gentoolkit
-21:10 <      welp > or even make changelog updates a part of repoman commit?
-21:10 < FlameBook+> lu_zero: sincerely, it's a two-lines function, do you need a script?
-21:10 <  ColdWind > being realistic and pragmatic, is ChangeLog size related to vapier not using it? I don't think so, so that's OT
-21:10 <      welp > but keep echangelog available for the profiles/ Changelog
-21:10 < FlameBook+> see what welp just said is something interesting
-21:10 <     eroyf > that's what inops is supposed to do as well
-21:10 < dberkholz@> this doesn't really seem to be going anywhere
-21:10 <     eroyf > if i ever finish it
-21:11 <   lu_zero@> Flameeyes I need to have it somewhere just in case
-21:11 <     jokey@> dberkholz: ++, move on
-21:11 <      leio > he doesn't put stabilizations in ChangeLog on purpose on his own judgment of it cluttering the ChangeLog with "useless" information. He has scripts to do most of it already, but I feel a bit uncomfortable paraphrasing him here like that.
-21:11 < FlameBook+> lu_zero: man echangelog then
-21:11 <      amne@> dberkholz: agreed. i think we talked about what we should talk and agreed on that
-21:11 <   antarus > 'always' :)
-21:11 <      welp > no-one's discussing my idea
-21:11 <      welp > pfft.
-21:11  *     welp goes to sleep, gnight folks
-21:12 <      leio > (back to own judgments - I want to see consistency and enforcement and dealing with any complaints that might raise)
-21:12 <      amne@> welp: it's beyond what we should discuss here imo. sleep well :-)
-21:12 <      amne@> so, shall we move on?
-21:12 < dberkholz@> ok, we've made this decision
-21:12 < dberkholz@> i'd like if the QA people would help enforce it
-21:13 < dberkholz@> if not, we'll have to consider what to do ourselves
-21:13 <     jokey@> yup, I volunteer if QA is not in the mood
-21:13 <      amne@> sounds good (both what dberkholz and jokey said)
-21:14 < FlameBook+> fine
-21:14 -!- mode/#gentoo-council [+m] by dberkholz
-21:14 < dberkholz@> next topic: Can the council help fewer bugs get ignored by arm/sh/s390 teams?
-21:14 -!- Irssi: #gentoo-council: Total of 89 nicks [8 ops, 0 halfops, 2 voices, 79 normal]
-21:15 < dberkholz@> the work happens, but apparently it's not communicated to anyone and
-21:15 <     jokey@> unless it gets more hardware to test with, highly unlikely
-21:15 < dberkholz@> has no relationship to whether bugs are open
-21:15 <   lu_zero@> how many people are working on it?
-21:15 < dberkholz@> is anyone besides vapier working on any of those?
-21:15 <     solar+> the arm team afaik is only vaiper. I help out where I can. There has been requests by users in embedded to see arm be an officially supported arch. But the workload there is nearly unfeasible
-21:15 <     jokey@> we have an external "bug contributor", me occasionally when I update my devices and vapier for arm
-21:16 <     jokey@> for the rest, no idea
-21:16 <   lu_zero@> solar so till we don't have more people working on it
-21:16 < FlameBook+> as I said before opening, I have a board dusting around, I haven't set it up yet but I might try soon enough
-21:16 <   lu_zero@> I think we cannot do any better
-21:16 <     jokey@> okay, solar then as well but that's it
-21:16 < dberkholz@> should these arches have stable keywords?
-21:17 <   lu_zero@> I think it's up to vapier
-21:17 < FlameBook+> on my packages they don't disrupt stabilisation too much, sincerely
-21:17 <     solar+> yes. there are some pkgs in ~arch that are not stable. While others are. If arm is making other developers lives harder it would be great if we could start seeing bugs
-21:17 <     jokey@> dberkholz: I think so, as unstable breaks there lovely. otherwise we have to hack around with profiles which would be rather messy
-21:17 < dberkholz@> bugz search -a arm@ --cc=arm@
-21:18 < dberkholz@> shows a nice long list of ~175 bugs
-21:18 < dberkholz@> x11 on the other hand only has ~180. =)
-21:19 <     solar+> yeah. But if you want me to go hog wild. I can give you another 80 bugs for x11 that would make life eaiser for arm ppl.
-21:19 <     jokey@> solar: what about assigning them to embedded with arches in CC?
-21:20 <     solar+> most of the arm word is done via cross-compiles vs native compiles due to the speed.
-21:20 < dberkholz@> the problem seems to not be the number of open bugs, but the inconsistency between open bugs and reality
-21:20 <     jokey@> then it's out of the common bugmail stuff
-21:20 <     solar+> jokey: while that might make some sense. I'd like to focus for now on things I'm actually doing. The embedde team is pretty much the same thing as the arm team
-21:22 <   lu_zero@> ok
-21:22 <     jokey@> dberkholz: maybe we should talk with our bug wranglers to make sure the first part in the summary is always the package name, that way tracking that would be easy
-21:23 <     jokey@> or add one of the user values in bugzilla for that
-21:23 <     jokey@> (unless I'm mistaken bugzie offers such stuff)
-21:23 < dberkholz@> basically i think we need to figure out what vapier's workflow is (and other extremely underpowered arch teams) and see if there's anything we can improve
-21:24 < dberkholz@> just randomly discussing things isn't likely to get us far, i think
-21:24 <     jokey@> anyway not much we can do here without him being around
-21:25 <   lu_zero@> ok let's ask him later
-21:25 <   lu_zero@> next topic?
-21:25 <     jokey@> yup, all for it
-21:25 < dberkholz@> we haven't had open floor
-21:25 <     solar+> dberkholz: I can tell you that one of the biggest problems we have is either devs with a lack of hardware and a lack of interest in working on slow arches.
-21:25 < dberkholz@> if anyone has anything to say, drop me a quick query
-21:26 < FlameBook+> solar: and bad support for crosscompile with the current way ebuilds are specified
-21:26 < FlameBook+> missing a BDEPEND/TDEPEND/WHATEVERYOUCALLITDEPEND for CBUILD tools
-21:26 <     solar+> mostly libtool getting things wrong
-21:26 <     solar+> and portage feature/behavior changes
-21:26 < FlameBook+> and libtool getting things wrong becaus of .la files
-21:26 <   lu_zero@> eh
-21:26 < FlameBook+> and pkg-config that is not built for CTARGET by crossdev (I want to tackle this down)
-21:26 <     jokey@> getting OT here, let's just move on
-21:26 < FlameBook+> jokey: agreed
-21:27 <   lu_zero@> I'd push this on the last open floor
-21:27 < dberkholz@> leio noted that improving recuitment efforts (perhaps just a better description on the staffing needs) could help
-21:28 < dberkholz@> with that, let's move on
-21:28 < dberkholz@> next topic: "PMS: Are versions allowed to have more than 8 digits?"
-21:29 -!- Irssi: #gentoo-council: Total of 88 nicks [8 ops, 0 halfops, 2 voices, 78 normal]
-21:29 <   lu_zero@> do we have some backgrounds on why this limit had been set?
-21:29 <     jokey@> if I recall it correctly, this limitation is something wrt [ ] vs [[ ]]
-21:29 -!- mode/#gentoo-council [+vv ferringb zmedico] by dberkholz
-21:29 < dberkholz@> any paludis devs here to speak?
-21:29 <     solar+> 32bit ints is the problem there I think.
-21:29 <   lu_zero@> anybody from the involved party could shed some light on the issue?
-21:30 <  ferringb+> two limitations
-21:30 < dberkholz@> or other tools this limit affects?
-21:30 -!- mode/#gentoo-council [+v ferdy] by Betelgeuse
-21:30 <  ferringb+> ints, and floats.
-21:30 <  ferringb+> (0.000000000000001)
-21:30 -!- mode/#gentoo-council [+v ferdy] by dberkholz
-21:30 < dberkholz@> ferdy's voiced for paludis
-21:30 <Betelgeuse@> zmedico said that using a Portage version with 8 digit limitations would break in other ways with the current tree when I asked
-21:31 <     ferdy+> recent portage is fine from what we've checked, paludis and eix are ok too
-21:31 <     solar+> portage handles big ints fine.
-21:31 <     ferdy+> portage-utils don't (last I checked)
-21:31 <     solar+> that is correct. Fixable but afaik only a few pkgs in the tree require the need
-21:32 <   lu_zero@> ferringb ?
-21:33 <     jokey@> (afaik he's in a meeting atm, hence slower response times)
-21:33 <     ferdy+> if the limit is to stay it should be enforced, otherwise, portage-utils should be either fixed or marked as unsupported
-21:33 <  ferringb+> jokey: in between 'em atm.  pkgcore is fine, was the first to be...
-21:33 <  ferringb+> portage itself has problems there.
-21:34 <  ferringb+> give me a second, looking at the version comparison logic for floats (portage/versions.py around line 75)
-21:34 <     solar+> ferdy: yeah I said it's fixable. But I'm not a fan of having to change to longs. It will make atom handling slower.
-21:34 <   zmedico+> ferringb: portage uses all strings and ints so it's fine
-21:35 <     ferdy+> solar: *nod*
-21:35 <     solar+> but then the next limit for it would be 16 or so on 32bit arches.
-21:36 <  ferringb+> zmedico: the float comparison logic there is broke offhand
-21:36 <     solar+> sorry maybe thats long long that is required.
-21:36 <  ferringb+> zmedico: try 0.01 vs 0.1.
-21:36 < FlameBook+> solar: let's call it uint64_t :)
-21:36 <     solar+> FlameBook: patches welcome :)
-21:36 <  ferringb+> either way, technically it'll support long long there, just doesn't do the float comparison rules...
-21:36 < dberkholz@> my basic philosophy here is that the package manager shouldn't get in the way of the packagers, so if >8 makes some packages easier, it should be allowed
-21:37 < dberkholz@> what's using >8 now?
-21:37 <     solar+> dberkholz: gradm
-21:37 <     ferdy+> net-tools
-21:37 <     jokey@> afaik mplayer was one of them, not sure though
-21:38 <     solar+> gradm-2.1.11.200804142058 (YYYY/MM/DD/HH/MIN) and to change the logic would be a real pita
-21:39 < dberkholz@> sys-process/fuser-bsd
-21:39 < dberkholz@> sys-apps/net-tools
-21:39 < dberkholz@> sys-apps/gradm
-21:39 < dberkholz@> net-im/ntame
-21:39 < dberkholz@> media-video/captury
-21:39 < dberkholz@> media-libs/libcaptury
-21:39 < dberkholz@> media-libs/capseo
-21:39 < dberkholz@> sys-block/btrace
-21:39 < dberkholz@> www-apache/mod_depends
-21:39 < dberkholz@> net-wireless/rt2500
-21:39 < dberkholz@> sys-fs/unionfs
-21:39 < dberkholz@> those all have 9 or more numbers in a row
-21:40 < dberkholz@> anyone have something more to add before we open the floor for discussion prior to the vote?
-21:40 <     solar+> so clearly we can see developers have legit reasons for using more than 8 numerics in a row. And we can see the advantage of limiting it to 8.
-21:41 <   lu_zero@> solar splitting the value is that problematic for devs?
-21:41 < dberkholz@> solar, ferdy: i don't suppose you have any idea what the magnitude of performance loss is when going from int to long
-21:41 <   lu_zero@> and vice-versa
-21:42 <     ferdy+> dberkholz: such a comparision has never showed up in any of my profiles, so I'd say 0 in a package manager
-21:42 <  ferringb+> dberkholz: why would it matter?  this isn't exactly the hotspot of any package manager...
-21:42 <     ferdy+> also, versionator.eclass doesn't handle it properly either
-21:42 <  ferringb+> ferdy: versionator has a few other bugs iirc anyways
-21:43 <     solar+> dberkholz: I think it's the 32bit arches that would take the biggest hit there at the low level. sending 2x as much data over the bus as required for every lookup.
-21:43 < dberkholz@> ferringb: solar expressed a concern about portage-utils ... 
-21:43 <  ferringb+> parsing is going to cost more then int -> long conversion
-21:43 <     ferdy+> ferringb: I don't follow....
-21:43 <     solar+> I don't mind changing portage-utils. Thats pretty easy
-21:43 <     ferdy+> ferringb: I mean, fine, it has more bugs. But it is also kind of irrelevant to what is being discussed (the 8 digit limit)
-21:44 <  ferringb+> ferdy: saying it needs fixing anyways ;)
-21:44 <  ferringb+> so not really much of a blocker imo
-21:44 <     ferdy+> I'm not touching versionator myself.... the council can find someone to do it :)
-21:44 <   lu_zero@> brr
-21:44 <     ferdy+> but versionator should be fixed if the limit is to go
-21:46 < FlameBook+> if any of the packages using the then-extended limit needs versionator... as long as there is no need for versionator on those ebuilds it can be put in lower priority
-21:46 < dberkholz@> ok, let's open it up to see if anyone else has a new point
-21:46 -!- mode/#gentoo-council [-m] by dberkholz
-21:46 <     ferdy+> that's pretty fragile
-21:46 <     solar+> to go? afaik this has never been really discussed. Before opting to vote. Perhaps contacting the devs of the pkgs in question and asking for input from them might help in the council make an informed desision?
-21:47 <   lu_zero@> solar agreed
-21:47 <  ferringb+> dberkholz: anyone check into the [ ]/[[ ]] issue I mentioned?
-21:47 <     ferdy+> I meant to go away from PMS
-21:47 <  ferringb+> specifically when bash introduced the double bracket support?
-21:47 < dberkholz@> double brackets have been around since 2.05 at least, arrays were in 2.05
-21:48 <  ferringb+> 'k.  so... only downside to >8, is that any code using  [ ] goes boom w/ a large enough number.
-21:48 <       ulm > this is not exactly related to the package manager, but aren't version components with > 8 digits pretty difficult to read? what's the problem with splitting YYYYMMDDHHMM into YYYYMMDD.HHMM?
-21:48 <   lu_zero@> ulm none that I can see
-21:48 <   lu_zero@> but the devs managing that could tell us more
-21:49 <  ColdWind > ulm: that's really annoying with net-tools, when it comes to dates it's annoying, although it'd be nice to follow it if upstream does it
-21:49 <     solar+> ulm: that could probably be done. But then it does not exactly match upstream versioning and becomes a little ulgy to do all the parsing in the ebuilds to get SRC_URI right.
-21:49 < dberkholz@> ulm: slightly more annoying to have to parse that into SRC_URI
-21:49 < dberkholz@> ulm: particularly once they release 2008050816.1
-21:49 <Betelgeuse@> solar: we could write versionator functions for it
-21:49 <Betelgeuse@> solar: delete_version_separator N
-21:49 <    Cardoe > Betelgeuse: if you wanna maintain versionator...
-21:50 < Blackb|rd > Also note that 2^31 is 2147483648 (I suspect that that's the problem). Thats a signed 32-bit int. What's the problem with this? it's more than a hundred years in the future? Even more so for 2^32.
-21:50 < FlameBook+> dberkholz: remember to never let you choose a version number for anything ;)
-21:50 <    Cardoe > someone keeps trying to pawn versionator off on me.
-21:50 <       ulm > dberkholz: you parse it once and then you're done for that package
-21:50 <Betelgeuse@> There actually is one already.
-21:50 <  ColdWind > if you finally decide to remove the 8 eight limit... please, people should use common sense and don't use such annoying version if there's no good reason (e.g. upstream using that scheme)
-21:50 < dberkholz@> ulm: right, so you repeat this thing and add extra code for every package doing it instead of having native PM support
-21:50 < dberkholz@> ulm: that sounds like the tool getting in your way
-21:50 < Blackb|rd > Oh. H:M. nevermind me.
-21:51 <Betelgeuse@> So basically we could keep the 8 digit limit and make people use versionator too.l
-21:51 <Betelgeuse@> Or are there issues with that?
-21:51 <     ferdy+> it gets in the way of maintainers....
-21:51 < FlameBook+> Betelgeuse: slower?
-21:51 <     ferdy+> it is always better to use what upstream uses
-21:51 <   lu_zero@> I'd ask them first
-21:51 < FlameBook+> for once I'm agreeing with ferdy, I'd quite rather follow upstream
-21:51 -!- ajp is now known as Ida
-21:51 <     solar+> or dump the idea and continue down the existing path. Perhaps limiting it to uint64_t
-21:52 <       ulm > solar: how many digits is that?
-21:52 <     ferdy+> about 20 iirc
-21:53 <       ulm > well, 19 for unsigned and 18 for signed
-21:53 < Blackb|rd > ferdy: 20, yes
-21:54 <       ulm > Blackb|rd: 2^64 has 20 digits, but you can not represent all 20-digit numbers
-21:54 <   impulze > exactly
-21:54 <   impulze > the first one is dismissed
-21:54 < FlameBook+> portage-utils could probably just use string comparison for sorting to make it accept arbitrarily-sized values
-21:54 <   impulze > so it's 19 unsigned and 18 signed just as ulm said :)
-21:54 <     ferdy+> the only reason I see to have a limit here is to ease implementation
-21:55 < FlameBook+> and pkgcore/portage said above they use strings comparison
-21:55 < Blackb|rd > ulm: exactly.
-21:55 < FlameBook+> ferdy: I suppose paludis does/could use string comparison too?
-21:56 <     ferdy+> paludis supports an arbitrary long revision 'number', yes
-21:56 <     solar+> FlameBook: Re:strings. not going to do that to get the equiv of big ints.
-21:56 < FlameBook+> solar: I said could :)
-21:57 <   lu_zero@> still I'd set a sane limit
-21:57 < dberkholz@> ok, so there's 11 packages using >8 digits, and 0 packages using >18 digits. that seems to set a fairly good range where this is useful
-21:57 <   lu_zero@> dberkholz ++
-21:57 < FlameBook+> yeah and if we need to go over that and we have reasons to do that, we'll discuss it in the future
-21:57 <     solar+> so unsigned long long is the desired max limit?
-21:57 < FlameBook+> for now < 18 should be fine
-21:58 < dberkholz@> and 2 packages using 14 digits, those are the longest
-21:58 < FlameBook+> solar: uint64_t (I hate long/longlong)
-21:58 < dberkholz@> so i favor a 64-bit limit
-21:58 <     solar+> FlameBook: afaik. Don't you get into typecasting problems when trying to printf() on that
-21:58 <       ulm > FlameBook: I'd go for <= 18 to play it safe. then it fits into signed 64 bit
-21:59 <     solar+> where knowing ulong long will always be "%lu"
-21:59 < FlameBook+> solar: "this is a uint64_t: " PRId64 "\n"
-21:59 <     ferdy+> actually, the limit should be 18 digits and not a C type
-21:59 < dberkholz@> ferdy: expecting negative versions?
-22:00 <     ferdy+> I'm not, I just think it is more clear in a document like PMS
-22:00 < dberkholz@> (in other words, why not 19?)
-22:00 < FlameBook+> solar: for what it's worth, %lu has different size on 32-bit and 64-arches, stdint.h makes it explicit on the size
-22:00 <    fmccor > Someone did that once (smalleiffel)
-22:00 <     ferdy+> dberkholz: I'm fine with either, honestly :)
-22:00 < FlameBook+> fmccor: can we propose upstream sniping if that repeats?
-22:00 < dberkholz@> if we're effectively doing this to make things fit into 64 bits, we might as well take the biggest advantage of that as possible and go with <20
-22:01 <       ulm > dberkholz: noone is using > 14
-22:01 <    fmccor > FlameBook, They were counting up to the release at 0.0 (It's smarteiffel now).
-22:02 <     jokey@> I'm also for limiting it on something like 14 or so
-22:02 < FlameBook+> they got smart and stopped doing negative versions?
-22:02 <     jokey@> rest simply doesn't make sense
-22:02 <NeddySeago > Don't design it here
-22:02 <     solar+> FlameBook: well I'm all for patches. But dealing with full strings would be kinda ulgy+slow (think arm at runtime). We have a really nice/fast atom parser in portage-utils and I'd love to avoid slowing it down for cases which would probably never exist. (60+ digit etc..).
-22:02 < dberkholz@> ulm: what's the reason for creating an arbitrary restriction like 14, when your storage could hold more?
-22:02 <       ulm > dberkholz: and 19 doesn't work in bash
-22:02 <       ulm > 18 does
-22:02 < dberkholz@> ulm: what does work in bash, then
-22:03 <       ulm > ^^
-22:03 < dberkholz@> ok, presumably bash uses signed longs..
-22:03 < FlameBook+> solar: that's why I said we can discuss that _if_ the problem arises
-22:03 < FlameBook+> solar: and yeah I would expect it to be slow on RISC... x86 wouldn't probably be affected
-22:03 <       ulm > dberkholz: yep
-22:03 <   lu_zero@> anyway uint64_t is a good storage for now
-22:03 <  ferringb+> mmm.  pkgcore cpy extension probably has a limitation on rev range, although said limitation can be backed out easily enough
-22:04 < dberkholz@> the way i'd like to word this is <=18 digits, since someone's already mentioned that having a rule as a C datatype isn't the best..
-22:04 <   lu_zero@> fine
-22:04 < dberkholz@> date-based versions give 14 digits (yyyymmddhhmmss), and that leaves an additional 4 for whatever other weirdness they think up
-22:05 <     solar+> bash is written in c :)
-22:05 < dberkholz@> for example milliseconds
-22:05 <     solar+> unixtime etc.
-22:05 <  RobbieAB > For what it is worth, I think assumeing version numbers are positive is a bad idea, as it's an invitation for someone to do a negative version number... :)
-22:05 < dberkholz@> although i pray nobody does that
-22:05 <   astinus > dberkholz: yyyymmddhhmmss1337
-22:05 < dberkholz@> anyone got a new point, or are we ready to vote?
-22:06 <    fmccor > RobbieAB, As I mentioned, it's happened. :)
-22:06 <   astinus > dberkholz: I think RobbieAB makes a good point.
-22:06 < dberkholz@> we aren't making that assumption, actually... the reduction to <=18 allows for it in a 64-bit number
-22:06 < Blackb|rd > astinus: making them integers, asks for reals, making them reals asks for irrationals, irrationals asks for complex.
-22:07 <      leio > such long numbers should be heavily discouraged as noted before and not used without good reason (yyyymmddhhmmss isn't one)..
-22:07 < FlameBook+> Blackb|rd: complex?
-22:07 < Blackb|rd > astinus: just kidding ;)
-22:07 <   astinus > leio: We cannot influence upstream.
-22:07 < Blackb|rd > FlameBook: imaginary+real
-22:07 <     ferdy+> wait, are you suggesting '-r-91828383' ?
-22:07 < FlameBook+> Blackb|rd: I know what imaginary is...
-22:07 < FlameBook+> err complex is I meant
-22:07 <     solar+> that would never parse correctly anyway :)
-22:07 <   lu_zero@> =_=
-22:07 < FlameBook+> I meant what would they ask after that?
-22:07 <      leio > upstream using it is a good reason, our own snapshots unreadable like that without separators isn't (imho)
-22:07 <     ferdy+> solar: exactly my point
-22:07 <   lu_zero@> let's ignore the issue
-22:08 < Blackb|rd > FlameBook: don't look at me, I wouldn't do it, I'm just extrapolating
-22:08 < Blackb|rd > FlameBook: after complex? I dunno. Multidimensional vectors?
-22:08 < FlameBook+> Blackb|rd: non-arabic numeric systems?
-22:08 <     solar+> in version atoms?
-22:08 <   lu_zero@> =_=
-22:08 < Blackb|rd > FlameBook: nifty. roman numerals would be a nice challenge
-22:08 <   lu_zero@> let's stay sane
-22:08 < dberkholz@> portage-(2+3i,4+2i).ebuild
-22:08 <     ferdy+> ok, can we get this rolling?
-22:08 < Blackb|rd > lu_zero: ok.
-22:09 < FlameBook+> lu_zero: stay?
-22:09 <   lu_zero@> get
-22:09 <   astinus > We're way past the 2hr mark and the next topic will be heated. We seem to be getting away from the point too. The suggestion was <=18 and not to be more specific about implementation.
-22:09 <   lu_zero@> saner at least
-22:09 < FlameBook+> ferdy: D20 or D10?
-22:09 < dberkholz@> since nobody's really brought up anything new, let's vote
-22:09 < dberkholz@> remoderating
-22:09 <   lu_zero@> ok
-22:09 -!- mode/#gentoo-council [+m] by dberkholz
-22:09 -!- Irssi: #gentoo-council: Total of 88 nicks [7 ops, 0 halfops, 5 voices, 76 normal]
-22:09 -!- mode/#gentoo-council [-vvv ferdy ferringb zmedico] by dberkholz
-22:09 -!- Irssi: #gentoo-council: Total of 88 nicks [7 ops, 0 halfops, 2 voices, 79 normal]
-22:09 <     solar+> dberkholz: what i said till holds. I think there should be no such limitation put in place right now. As for a vote I think you should not vote till asking for input from all the authors of the ebuilds in question.
-22:09 <   lu_zero@> I'm fine with the 18 digits limits
-22:10 <   lu_zero@> and should be pretty much a sane upper bound
-22:10 <      amne@> what solar says makes sense
-22:10 <   lu_zero@> the switch between uint32 and uint64 shouldn't hit too much IMHO
-22:11 <     solar+> I can't stop at 18 but extending it past 8 would be fine..
-22:11 < dberkholz@> i looked at a number of those ebuilds, and they're all based on upstream versioning
-22:11 <      amne@> i don't think a vote is necessary right now
-22:11 <   lu_zero@> solar could you check the performance hit on small arches?
-22:12 <     solar+> lu_zero: I probably wont have time for that.
-22:12 <     solar+> but the eclass is what will see the biggest hit
-22:13 <   lu_zero@> solar ok
-22:13 < FlameBook+> I'm fine with extending to 18 for now and leaving open for the future to be discussed
-22:15 <      amne@> are we going to vote on anything right now? because i really have to go get some sleep, i'll have to get up again in 2.5 hours unluckily, so i cannot attend the meeting any longer (but hey, i was marked slacker anyway already)
-22:16 < dberkholz@> jokey apparently ran into computer difficulties
-22:16  *  lu_zero is almost asleep
-22:16 < dberkholz@> it might be reasonable to test the impact of the change in versionator before voting
-22:18 < dberkholz@> so we've got 3 options here, let's see where people stand on them
-22:19 < dberkholz@> 1) allow <=18 now. 2) keep at 8 digits. 3) further research with package maintainers and testing of the impact
-22:19 <Betelgeuse@> Well isn't versionator performance more of an issue with the cache generation machine?
-22:19 <Betelgeuse@> And it's not one of the slower arches.
-22:20 < dberkholz@> which options do you like, folks?
-22:20 < FlameBook+> I'm fine with 1 and 3
-22:20 < dberkholz@> 1 or 3 seem ok to me
-22:20  *     amne is for 3) and out now
-22:20 <   lu_zero@> same
-22:20 <   lu_zero@> 1 and 3
-22:20 < dberkholz@> we already know solar's for 3
-22:21 < dberkholz@> that makes 3 people for option-1, and 5 people for option-3
-22:23 <Betelgeuse@> Might as we well go with 3 but say that people can add new >8 if they need to.
-22:23 < dberkholz@> i put the details we discussed of the further research into http://dev.gentoo.org/~dberkholz/20080508-summary.txt
-22:23 <   lu_zero@> ok
-22:27 -!- Irssi: #gentoo-council: Total of 86 nicks [7 ops, 0 halfops, 2 voices, 77 normal]
-22:27 < dberkholz@> since it's already getting late for a couple of you, and a couple others aren't here today, here's what i'd suggest
-22:28 < dberkholz@> we can cover the background information on the enforced retirement today and plan a special session in the next week or so to make the decisions mentioned in the agenda
-22:29 -!- mode/#gentoo-council [+v musikc] by dberkholz
-22:29  *   musikc waves
-22:29 <   lu_zero@> hi musikc
-22:29 -!- mode/#gentoo-council [+v fmccor] by dberkholz
-22:29 <    fmccor+> Good evening.
-22:30 < dberkholz@> i'd like to ask the directly involved people (council + musikc + fmccor, mainly) to tell us how that works for them
-22:30 <    fmccor+> dberkholz, It's fine with me to delay the entire discussion.  It's not time critical.
-22:30 <    musikc+> wfm
-22:30 <   lu_zero@> I can resist for another hour
-22:30 <   lu_zero@> both ways are fine
-22:31 < dberkholz@> i'm aware that we really need to get some action one way or the other for everyone's sake, so i don't think we should wait until the next regularly scheduled meeting
-22:31 <    musikc+> agreed
-22:31 <    fmccor+> dberkholz, sure.
-22:31 <    musikc+> i think it will do more to ease the minds of others if we talk about it sooner than later
-22:32 < FlameBook+> I'm fine with the reschedule, as I'm probably going away soon, too
-22:32 < FlameBook+> [reschedule to special I mean]
-22:32 <    fmccor+> Right
-22:32 <    musikc+> and for anyone reading in doubt, please do not assume that council made me take a particular course of action. i apologize if that is how it was interpretted but again that is just not how it happened.
-22:32 < dberkholz@> how about next week, same bat time, same bat channel as a tentative date -- how's that work for people?
-22:33 <    musikc+> sure, i just cant be available for 2+ hours because it is the middle of my work day
-22:33 <    fmccor+> Works for me.  Please send a email or something so as not to make a liar of me. :)
-22:33 < dberkholz@> that appears to be almost immediately following the trustees meeting
-22:33 < dberkholz@> if my calendar is right
-22:34 <    fmccor+> trustees are meeting in special session this Sunday and regular meeting a week from Sunday.
-22:34 < dberkholz@> hm, apparently the google calendar is wrong
-22:34 < dberkholz@> it says thursday may 15
-22:34 < dberkholz@> following the may 10 session
-22:34 <    fmccor+> That's wrong.
-22:35 < dberkholz@> rane: could you fix the calendar, please? looks like you posted the trustees meeting on may 15 three days early
-22:35 <    fmccor+> Should say the 11th and the 17th
-22:36 < dberkholz@> i was in my localtime...might be different in utc.
-22:36 < dberkholz@> ok. do we agree that we'll cover the entire topic in our upcoming special session?
-22:36 <    fmccor+> (Er, no.  11th and 11+7 = 18th (11+7 us not 17, I guess)
-22:37 <    fmccor+> Should say 11th and 18th, both at 1900UTC
-22:38 < dberkholz@> i think it makes more sense than breaking the related subtopics apart
-22:38 <    fmccor+> dberkholz, Sorry for the confusion.  Havving problems with addition, I guess.
-22:38 <    fmccor+> That works fine for me.
-22:38 <   lu_zero@> ^^;
-22:38 -!- Irssi: #gentoo-council: Total of 85 nicks [7 ops, 0 halfops, 4 voices, 74 normal]
-22:39 <    musikc+> ok, so we all agree to meet same time next week to cover the remaining topic of retirements/how handled/appeals/etc?
-22:39 < dberkholz@> amne, Betelgeuse, FlameBook, solar -- rescheduling to a special session work?
-22:40 < dberkholz@> ah, FlameBook already said yes
-22:40 <Betelgeuse@> o
-22:40 <Betelgeuse@> k
-22:41 < dberkholz@> looks like amne went to bed
-22:41 < dberkholz@> enough of us agree on that, so let's do it
-22:41 < dberkholz@> that brings us to the open floor
-22:42 < dberkholz@> does anyone else have any topics unrelated to either today's topics or the special session?
-22:42 -!- mode/#gentoo-council [-m] by dberkholz
-22:42 < Blackb|rd > Thanks, guys (and gal).
-22:42 <    fmccor+> Thanks, that works better for me at this point (over 2.5 hours and counting). :)
-22:42  * Blackb|r heads for bed now :)
-22:43 <   lu_zero@> I'd wait for 10min and then go to bed as well
-22:43 <   astinus > this just proves ideas to cut down meeting time *FAIL*
-22:43 <      rane > i fixed the calnder
-22:43 <      rane > calendar
-22:44 <      zlin > yeah, keeping people waiting for 2½ hours just to tell them it gets delayed a week is fucking awesome
-22:44 < dberkholz@> yeah, wonder whether we should try all-moderated except the final open floor, and just let people query the chair or other council members
-22:44 < dberkholz@> i had no idea the earlier topics would take so long, that was insane
-22:45 <    fmccor+> rane, You caught my addition error that 11+7 is 18, not 17?
-22:45 <    musikc+> dberkholz, that sounds like a good idea to me
-22:45 <   astinus > zlin: Wow, someone forgot to take their calm pills this evening :S
-22:45 <  ColdWind > zlin: I agree, but that's mostly due to all the version length nonsense
-22:45 <    musikc+> it is prime business hours in the states and close to bed time for a lot of other folks
-22:46 <    fmccor+> dberkholz, I don't think the time went to the open floor parts.
-22:46  * RobbieAB agrees with fmccor
-22:46 <      zlin > fucking waste of time
-22:46 <      Sput > basically discussing implementation details for two hours...
-22:47 <   astinus > zlin: Actually quite a lot got discussed/agreed.
-22:47 <      zlin > ColdWind: and even that was too hard to make a decision on
-22:47  *  astinus forcefeeds zlin some positivity potion.
-22:47 < dberkholz@> there was a decision, it was "not enough data"
-22:48 < dberkholz@> seemant had a nice philosophy of "show me the code", so i tend to agree that seeing the impact in code and real numbers would help
-22:49 <      zlin > dberkholz: even if I agree with that it shouldn't take an hour to figure that out
-22:49 -!- fmccor is now known as fmccor|home
-22:49 <      zlin > s/agree/agreed/
-22:49 < dberkholz@> zlin: you're right, i wish it went faster. do you have any advice on how to do that?
-22:49 <      zlin > who's going to collect those data btw?
-22:50 <  RobbieAB > dberkholz: not ask anyone else for input? It would be much faster that way... </sarcasm>
-22:50 <      rane > fmccor|home, yes, i did
-22:50 <fmccor|hom+> rane :)
-22:51 < dberkholz@> i've gotta migrate to a new location, should be back in ~5 min
-22:51 <      zlin > dberkholz: I wouldn't actually give a fuck if I hadn't been sitting and waiting for the outcome of those appeals..
-22:51 <  ColdWind > it will make things faster if discussion about negative, complex, and non-arabic versions are banned ;)
-22:51 <      rane > zlin, i was doing other stuff while they were busy figuring out if bash support 18+ or not
-22:51 <   astinus > zlin: the appeals were never happening today?
-22:52 <      rane > zlin, you should try it next time :-)
-22:52 <      zlin > astinus: huh?
-22:52 <   astinus > zlin: the appeals themselves were not tabled for today
-22:52  *   Fieldy passes around some calm pills
-22:52  *     rane takes all of them
-22:53 <  RobbieAB > ColdWind: negative versioning has occurred, so in the context of lu_zero advocating uint_64t it was relevant.
-22:53  * ColdWind goes and release something with complex numbers
-22:53 <  ColdWind > :p
-22:54 <   astinus > zlin: what was tabled today was fmccor+musikc presenting Council with the facts, and a discussion about how to proceed with the appeals, if at all?
-22:54 <   astinus > ie: if they should be held at all. When. Should it involve the whole Council, or a panel of 2-3 to keep things simpler, etc
-22:54 <   astinus > unless I'm drastically misreading the agenda :)
-22:55 <  RobbieAB > ColdWind: lol.
-22:55  *    pilla releases something with a quantic version number
-22:56 <      rane > release something with no version number
-22:56 <jmbsvicett > astinus: That's not how I read the topic
-22:56 <  ColdWind > rane: that's occurs too often already
-22:56 <    musikc+> astinus, i wasnt aware that i was presenting anything
-22:56 <   astinus > jmbsvicetto: Fair enough, maybe Donnie could clarify.
-22:56 <jmbsvicett > astinus: And the appeals were made on time for this meeting
-22:57 <   astinus > jmbsvicetto: yet the folks supposedly appealing weren't asked to be present?
-22:57 <jmbsvicett > astinus: I'm not a council member ;)
-22:57 <    musikc+> here's what is in the summary:
-22:57 <    musikc+> What was the council's role in the recent enforced retirement of 3 developers?
-22:57 <      rane > we should discuss policies before we start using them
-22:57 <    musikc+> Why does the council permit such actions in apparent violation of Gentoo's policy of openness?
-22:58 <    musikc+> What is the council's role in an appeal?
-22:58 <   astinus > musikc: Part of my point still stands. Other than discussing the role of Council in an appeal process, there is no actual appeal on the agenda, ie: Philantrop's
-22:58 <jmbsvicett > musikc: Yes, I noticed. But at least 2 of the members appealed on time for this meeting. I find it reasonable to expect some discussion about the appeals
-22:59 <    musikc+> astinus, ahhh... so you wish to know when council will respond to the appeals?
-22:59 <   astinus > musikc: no.
-22:59 <   astinus > 23:49 < zlin> dberkholz: I wouldn't actually give a fuck if I hadn't been sitting and waiting for  the outcome of those appeals..
-22:59 <   astinus > musikc: I was responding to that ^^^^
-22:59 <  RobbieAB > jmbsvicetto: council can't table the appeals until it has decided if it is going to hear them...
-22:59 <    musikc+> ahhh
-22:59 <jmbsvicett > astinus: He sent a mail to council asking for that
-22:59 <     p0w4h > hi im learning cisco
-22:59 <Betelgeuse@> We should discuss starting the meeting an hour earlier.
-23:00 <Betelgeuse@> I am heading for bed.
-23:01 <    musikc+> nn Betelgeuse
-23:04 -!- Irssi: #gentoo-council: Total of 80 nicks [7 ops, 0 halfops, 3 voices, 70 normal]
-23:05 < dberkholz@> since nobody's said anything for 5 minutes, and most of the discussion has been venting, anyone mind if we end the meeting?
-23:05 <   astinus > thought we had =)
-23:06 < dberkholz@> effectively yes, since everybody's going to sleep
-23:06 <jmbsvicett > RobbieAB / astinus: I understand your argument, but I expect the council to make a decision about accepting or not the appeal in a "reasonable" timeframe
-23:06 <   astinus > dberkholz: Would you mind clearing up exactly what's meant by the final items on the agenda, and what will be discussed in the special meeting, please?
-23:06 <jmbsvicett > My "unreasonable" response time was caused by network connectivity issue
-23:06 <jmbsvicett > +s
-23:07 < dberkholz@> astinus: the intent was not to make a decision on the appeal, but to explain the council's role so far and to decide exactly how to proceed with it. we haven't done any appeals before, so we need to figure out the best way how.
-23:08 <   astinus > dberkholz: But the implication is you're accepting the appeal and are somehow going to hear it, where 'somehow' is TBD?
-23:08 <jmbsvicett > dberkholz: By the way, the last point about the council role, only applies if the Council starts the action - that has been my argument and I think Ferris
-23:08 <   astinus > or is the decision to accept/reject the appeal also TBD?
-23:09 < dberkholz@> astinus: it's kind of a big mess because of some ideas brought up by ferris and co. my opinion is that we can take the appeal, we will take it, we will figure out the best way to handle it, and then we will handle it.
-23:09 <jmbsvicett > dberkholz: As long as devrel takes the action, I don't see any "conflict"
-23:10 <   astinus > jmbsvicetto: and that's already been cleared up by musikc - she said above that Council wasn't the guys taking that decision
-23:10 <    musikc+> jmbsvicetto, *I* took the action
-23:11 <jmbsvicett > musikc: sorry, I didn't meant to imply otherwise
-23:11 <    musikc+> all council did was say hey, there is talk that devrel doesnt respond to complaints, please do acknowledge these
-23:11 <jmbsvicett > musikc / astinus: I was going to finish my thought by saying that I've been told and have no reason to doubt that it was musikc's action
-23:12 <   astinus > most of the "devrel hasn't done squat in these types of complaints" ruckus was caused by me, as *previously* DevRel has had great difficulty getting off its rumpus and actually doing anything
-23:12 <jmbsvicett > musikc: I'm sorry for not completing the thought. I was caught no /msg
-23:12 <   astinus > which I already apologized to musikc for ;)
-23:12 <    musikc+> astinus, it's ok, you had a valid point
-23:13 <    musikc+> people have expressed similar, that they too felt devrel wouldnt take action. bear in mind i did not do something extreme just to show that we would, i stand by my decisions.
-23:14 <    musikc+> the only thing council really did was advise me what devrel had authority to do and to what extent, hence the policy change in devrel, as i was advised it was always policy whether i wrote it or not it always existed.
-23:14 <    musikc+> i know some people were upset about a change in policy followed by action, and i have apologized to my team and to anyone who cared to discuss it with me for confusion and lack of communication.
-23:14 <    musikc+> <end soap box>
-23:15 <   astinus > I think the 'danger' of Gentoo getting bigger is a culture of red tape setting in
-23:15 <   astinus > everything has to be discussed and approved by committees of committees of committees, so everything takes 4 years
-23:16 <   astinus > personally I'm a fan of trusting the guys in a role -- if policy is slow, and we want change, do it. Folks like Council and Trustees are there to second guess via appeals
-23:16 <      Sput > that said, has that particular bug been opened to the public yet?
-23:16 <   astinus > and we in turn trust Council via the election/voting process.
-23:16 <   astinus > Sput: yes.
-23:16 <      Sput > kk
-23:16 <   astinus > Sput: there's nothing on it, despite how much people hyped "ZOMG SEKRIT BUG!"
-23:17 <      zlin > for about ten minutes. then it was closed to non-devs.
-23:17 <      Sput > astinus: not very surprised about that, but I think closing it at all was causing a lot of uproar
-23:17 <      Sput > I mean if there is nothing to hide, why pretend there is?
-23:18 <   astinus > Sput: part of the problem is it was locked to Infra
-23:18 <fmccor|hom+> Sput, Last I knew, it was developers-only.
-23:18 <   hparker > Keeps the cabal theories flying
-23:18 <   astinus > Sput: which means someone from Infra needs to unlock it =) and relatively few people have that foo
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080515-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080515-summary.txt
deleted file mode 100644
index 83be110483..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080515-summary.txt
+++ /dev/null
@@ -1,2 +0,0 @@
-The meeting was attended by less than 50% of council members.
-No topics of the agenda were discussed and no votes were taken.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080515.txt b/xml/htdocs/proj/en/council/meeting-logs/20080515.txt
deleted file mode 100644
index cde7d8b133..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080515.txt
+++ /dev/null
@@ -1,126 +0,0 @@
-20:00 < dberkholz@> ok, let's get started
-20:00 < dberkholz@> who's here?
-20:01  *   musikc does a bigger wave
-20:01  *   fmccor waves
-20:01  *  edit_21 hides behind musikc 
-20:01  *   musikc ducks so everyone sees edit_21 
-20:01 -!- Irssi: #gentoo-council: Total of 66 nicks [6 ops, 0 halfops, 2 voices, 58 normal]
-20:01  *  edit_21 swan dives
-20:01 < dberkholz@> flameeyes isn't in the channel
-20:01 <    musikc > into a wall
-20:01  *   musikc snickers at edit_21 
-20:02 < dberkholz@> lu_zero mentioned late last night that he's traveling today again
-20:02 <   edit_21 > :/
-20:02 <    musikc > blah
-20:02 <    musikc > dberkholz, can you speak for those on council who may not be present?
-20:02 < dberkholz@> amne just talked, so he's here
-20:02 < dberkholz@> Betelgeuse, vapier, SpanKY, jokey: here?
-20:03 < dberkholz@> i can only speak for them insomuch as i can tell you what they've already said
-20:03 <    musikc > fmccor is that satisfactory for you or should we just reschedule?
-20:04 < dberkholz@> we need at least 4 council members here, or we can't do this.
-20:04 <    musikc > well i mean we should give them 5-10 mins but if no show, should we reschedule
-20:04 <      amne@> agenda looks good to me and as noted by dberkholz i'm around
-20:04 <    fmccor > musikc, dberkholz depends on what is to come out of this.
-20:04  *   musikc pokes amne, Betelgeuse, jokey, SpanKY, and vapier 
-20:04 <   antarus > this was supposed to be a meeting about process was it not?
-20:04 <   antarus > maybe if I had read the agenda.. ;)
-20:04 <    fmccor > as dberkholz said, can't vote without 4 present.
-20:05 < dberkholz@> well, technically 2 of us could make a decision that can be overturned by a full vote, but that kinda sucks
-20:05 <    musikc > can someone toss me the agenda link?
-20:05 < dberkholz@> 19:32 < dberkholz@> here's a reminder of the agenda pushed forward from last  week: http://dev.gentoo.org/~dberkholz/20080515-summary.txt
-20:06 -!- dberkholz changed the topic of #gentoo-council to: Meeting now, pending council member attendance || Agenda: http://dev.gentoo.org/~dberkholz/20080515-summary.txt
-20:07 <    fmccor > dberkholz, Since this might effect spb, rbrown , or Philantrop , if they are around perhaps they might indicate how they'd like to proceed if there are only 2 Council members present?
-20:07 <    musikc > fmccor, this is not a vote on their appeal
-20:08 <    fmccor > musikc, No, but it is a discussion of process
-20:08 <    musikc > and dberkholz already said we cant have this unless there are 4 or more members
-20:08 <   antarus > indeed, this is wrapping their in a bunch of beauracratic crap! :P
-20:08 <    musikc > fmccor, only a vote on council process, not what happened to them
-20:08 <   antarus > +appeal somewhere in there
-20:09 <    musikc > dberkholz, did flameeyes or lu_zero appoint proxies?
-20:09 < dberkholz@> not to my knowledge
-20:09  *   musikc almost typed pixies  hehe
-20:10 < dberkholz@> i intend to end the meeting and send a public censure to the council people who didn't show up, if there aren't at least 4 of us by :15
-20:10 <    musikc > well it looks like only one council member showed up :(
-20:10 < dberkholz@> amne's here
-20:10 <    fmccor > amne is around
-20:10 <      tove > GLEP39 says: "If any meeting has less than 50% attendance by council members, a new election for all places must be held within a month. The 'one year' is then reset from that point."
-20:10 <    fmccor > Er, like dberkholz said. :)
-20:10 <    musikc > amne is very quiet for being around
-20:11  * dberkhol  grins -- nice, tove
-20:11 <    fmccor > <amne> agenda looks good to me and as noted by dberkholz i'm around at 20:04
-20:11 <   edit_21 > hes about
-20:11  *  antarus laughs
-20:11 <    musikc > tove, ouch. not sure if that counts for impromptu meetings. donnie?
-20:11  *  antarus goes to infra to get an election ready
-20:11 <    fmccor > Well, it is a meeting which was previously scheduled. :)
-20:12 <      amne@> i just didn't say much as i was primarily waiting for the other punks to show up
-20:12  *   musikc hugs amne 
-20:12 <    musikc > you ARE here :)
-20:12 <   antarus > I love how the glep says must instead of may
-20:12 <   antarus > ;P
-20:12 <      amne@> surely
-20:12 <      amne@> i'm not always late for meetings just because i was last time
-20:12 <    fmccor > Not enough Council members here to interpret tove's point.  Interesting little problem. :)
-20:13 <   antarus > you don't need a council to hold an election
-20:13 <   antarus > technically
-20:13 <    musikc > antarus, not sure when that glep was made it if had considered non-standard meetings
-20:13 <     eroyf > 'any meeting'
-20:13 <     eroyf > means.. any meeting.
-20:13 < dberkholz@> i don't think there's much interpretation to do, unless you think we did such a poor job of announcing it that it doesn't count.
-20:14 <   antarus > If you take its intention to 'boot out a slacker council' than I think it would not count in this case
-20:14 <    fmccor > The GLEP says any meeting, and requires at least one per month.
-20:14 < dberkholz@> which would imply that most council members don't actually read the meeting summary
-20:14 <    musikc > its an interesting scenario for sure
-20:14 <    fmccor > If any meeting has less than 50% attendance by council members,  [to quote]
-20:14 <    Fieldy > certainly annoying. ah well next week i guess (grumble)
-20:14 <    musikc > dberkholz, that's like RTFM, we dont do that around here *snciker*
-20:15 <    musikc > or spell check evidently ;)
-20:15 <      amne@> gah
-20:15 <    musikc > omg it would so suck to have to do elections again
-20:15  *  antarus quickly edits the glep to say may
-20:15 <   antarus > problem solved!
-20:15 <    fmccor > Sort of suck just to ignore policy, too. :)
-20:16 < dberkholz@> for what it's worth, i've briefly written up my positions here: http://dev.gentoo.org/~dberkholz/20080515-pov.txt
-20:16 <    musikc > fmccor, again i think there may be some debate as to the intention
-20:16 <     ferdy > musikc: well... it sucks to have a council that wouldn't show up to a meeting :)
-20:17 <    musikc > ferdy, no doubt
-20:17 <     eroyf > let us debate something some former developer decided to vote for ages ago first time it might be useful.
-20:17 <    fmccor > musikc, For intention, just ask g2boojum and ciaranm --- they wrote it and Gentoo hald a vote on it.
-20:17 <    musikc > fmccor, i dont really think it is relevant
-20:17 < dberkholz@> if you want to be a lawyer about it, we could just keep the meeting open until they show up.
-20:17 <   edit_21 > out of intrest - how many are in the council ?
-20:18 < dberkholz@> i'd rather not do that
-20:18 <   edit_21 > 8?
-20:18 <    musikc > if it leaves doubt, then it needs revision
-20:18 <    fmccor > And it was last updated 4 months ago.
-20:18 <    fmccor > 5
-20:18 <    fmccor > (on council)
-20:18  *  edit_21 nods
-20:18 <   edit_21 > ta
-20:18 <    musikc > fmccor, thats why we dont write on stone tablets
-20:18 <Philantrop > musikc: If I may ask, what doubt might that be considering what tove quoted?
-20:18 <    musikc > it allows for revisions :-P
-20:18 <    fmccor > So the GLEP is current as of late January, 2008.
-20:19 <     eroyf > what
-20:19 < dberkholz@> my view is that this was a meeting, doesn't matter if it was the regular one because it was scheduled in advance, and the only possibility i'm considering is that it wasn't well-enough announced because the council members might not be expected to read summaries of a meeting they attended
-20:19 <     eroyf > you are going to change a rule when someone is about to be hit by the rule?
-20:19 <   antarus > This was updated by the glep editor
-20:19 <   antarus > (aka me)
-20:19 <    musikc > Philantrop, i question whether others will interpret to mean standard monthly meetings. personally im a bit irritated that more council didnt show up, but im not allowing my personal feeling to dictate how others may interpret
-20:20 <      amne@> dberkholz: i second your POV on the meeting issue
-20:20 <    fmccor > If there is some reason not to, I think it has to be interpreted to mean what it says.
-20:20 <      zlin > edit_21: 7
-20:20 <   antarus > Philantrop: I don't doubt the wording; I doubt the intention of the clause
-20:20 <     ferdy > dberkholz: said GLEP doesn't state what the requirements for a meeting are
-20:21 <  blackace > dberkholz: was the scheduling of this meeting voted on by the attendees in the last meeting?
-20:21 <      amne@> dberkholz: as one of the council members who vanished during the end of the meeting the least you should expect from a council member is to read the backlog or summary
-20:21 < dberkholz@> ferdy: that means i could declare a meeting in a text file on my computer and reelect the council if they don't show up
-20:21 <    fmccor > This was announced a week ago as a single subject meeting.
-20:21 <     ferdy > dberkholz: common sense states otherwise
-20:21 <     eroyf > lol.
-20:21 <    musikc > ferdy, there is sadly fault in your logic... sense isnt common ;-)
-20:22 <     ferdy > musikc: you mean common sense isn't as common as one would like? :)
-20:22 <    musikc > ferdy++
-20:22 <  arkanoid > dberkholz: the date was discussed at the last meeting as well, so council members should either have read their backlogs or the summary
-20:23 <    fmccor > ferdy, This one was openly announced and is again mentioned in the summary.
-20:23 < dberkholz@> i'm going to send a email to the -council and -project lists right now about the lack of people, and we'll go from there
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080612-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080612-summary.txt
deleted file mode 100644
index 42f17c964c..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080612-summary.txt
+++ /dev/null
@@ -1,236 +0,0 @@
-Quick summary
-=============
-
-Overall, the meeting went really well! Things that helped were 
-additional preparation notes in the agenda, a requirement to hold 
-discussions on-list instead of dragging out the meeting, and our 
-emphasized ability and willingness to hold votes on-list rather than 
-waiting another month. The meeting started at 20:00 and was over at 
-21:23, a vast improvement. We beat the 2-hour time limit we set.
-
-Because of the emphasis of on-list discussions, a number of the topics 
-in the agenda & summary weren't actually mentioned during the meeting. 
-Instead consider the agenda & summary as a list of ongoing matters for 
-the council.
-
-
-PMS: Versions can have >8 digits. If you want a maximum limit, discuss 
-it with relevant people and propose one.
-
-Appeals: Will be handled using dberkholz's proposal: 
-http://archives.gentoo.org/gentoo-council/msg_d7c402fb577a3d5b1707e2bdf4b0a264.xml
-
-LDFLAGS="--as-needed" by default: antarus will present a deployment plan 
-to -dev for how this would proceed.
-
-GLEP 54: There was a new proposal 12 hours before the meeting. Wait for 
-discussion. Council members should post anything they have to add by the 
-end of the weekend.
-
-GLEP 55: Discussion is clearly active. Council members should post 
-anything they have to add by the end of the weekend.
-
-GLEP 56: Technically good, still some room for improvement. Council 
-members should post anything they have to add by the end of the weekend.
-
-PMS status: This is a discussion that belongs on the mailing list. 
-Council members should post anything they have to add by the end of the 
-weekend.
-
-
-
-Roll call
-=========
-
-(here, proxy [by whom] or slacker?)
-
-amne        here
-betelgeuse  here
-dberkholz   here
-flameeyes   proxy [cardoe]
-lu_zero	    here
-vapier      slacker [emergency at work]
-jokey       here
-
-
-Meeting
-=======
-
-Moderation
-----------
-Modes +qnm, with voice for people involved in discussions?
-
-If it becomes necessary, we'll do it. Leave channel open till then.
-
-Time limit
-----------
-2 hours?
-
-Yes. We'll move any topics we didn't cover to the mailing lists.
-
-
-Updates to last month's topics
-==============================
-
-http://www.gentoo.org/proj/en/council/meeting-logs/20080508-summary.txt
-
-
-Document of being an active developer
--------------------------------------
-Requested attendees: araujo
-
-Last month: Numerous suggested improvements to info on the certificate.
-
-Preparation: araujo needs to post progress, an updated certificate and 
-any new requests to the gentoo-council or gentoo-project list 2+ hours 
-before the meeting.
-
-Goal: Suggest changes. This should happen on-list. No discussion 
-expected.
-
-
-Slacker arches
---------------
-Preparation: vapier needs to send the post 2+ hours before the meeting.
-
-Goal: Suggest changes. This should happen on-list. No discussion 
-expected.
-
-
-Can the council help fewer bugs get ignored by arm/sh/s390 teams? 
------------------------------------------------------------------ 
-Preparation: Someone on an undermanned arch team needs to describe their 
-workflow on-list 2+ hours before the meeting.
-
-Goal: Suggest changes. This should happen on-list. No discussion 
-expected.
-
-
-PMS: Are versions allowed to have more than 8 digits?
------------------------------------------------------
-http://archives.gentoo.org/gentoo-dev/msg_db2f5c09c2c0c8b042ca3d0dcec7cdaf.xml
-https://bugs.gentoo.org/show_bug.cgi?id=188449
-
-Preparation: Do the package maintainers with extremely long PVs need 
-them? The involved packages:
-	sys-process/fuser-bsd
-	sys-apps/net-tools
-	sys-apps/gradm
-	net-im/ntame
-	media-video/captury
-	media-libs/libcaptury
-	media-libs/capseo
-	sys-block/btrace
-	www-apache/mod_depends
-	net-wireless/rt2500
-	sys-fs/unionfs
-
-Preparation: What's the impact of extending versionator.eclass? 
-
-Goal: With data in hand, make a decision.
-
-Decision: We didn't have all of the testing requested. We still voted to 
-allow versions >8 digits. Adding a maximum restriction is a separate 
-question and was not addressed -- if anyone wants this restriction, 
-please discuss with fellow implementors and present your consensus to 
-the council.
-
-
-How to handle appeals
----------------------
-Preparation: Post to the gentoo-council mailing list 2+ hours before the 
-meeting with your opinion.
-
-	dberkholz: http://archives.gentoo.org/gentoo-council/msg_d7c402fb577a3d5b1707e2bdf4b0a264.xml
-
-Goal: Vote on an approach that was previously posted to the list.
-
-Decision: We approved dberkholz's proposal.
-
-
-New topics
-==========
-
-as-needed by default
---------------------
-antarus requested that we vote on whether to add it to the default 
-LDFLAGS.
-
-Preparation: Post your opinion to the -dev thread "RFC: --as-needed to 
-default LDFLAGS" 2+ hours before the meeting.
-
-	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_fdfd519c5372394cc7f3aacaefa387b9.xml
-
-Goal: Vote.
-
-Result: Whether this should be in default LDFLAGS or suggested in 
-make.conf.example wasn't clear. Betelgeuse suggested that we should know 
-the whole tree will build with this LDFLAGS setting (with open bugs for 
-packages that append -Wl,--no-as-needed) before we would consider 
-enabling it by default.
-
-Antarus will post a deployment plan to -dev for discussion. We can vote 
-on it on -council as soon as it solidifies.
-
-
-GLEP 54
--------
-Preparation: Post your opinion to the -dev thread "A few questions to 
-our nominees" 2+ hours before the meeting.
-
-	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml
-	lu_zero: http://archives.gentoo.org/gentoo-dev/msg_05614741b3942bfdfb21fd8ebb7955e0.xml
-
-Goal: Vote.
-
-Result: lu_zero posted a second plan 12 hours ago. Since it hasn't been 
-around long enough to get much feedback, we decided to let them develop 
-and see if the ideas somehow merge.
-
-
-GLEP 55
--------
-Preparation: Post your opinion to the -dev thread "GLEP 55" 2+ hours 
-before the meeting. Let it attempt to come to a consensus before we 
-vote.
-
-	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml
-
-Goal: Vote once the discussion's no longer clearly ongoing. We can hold 
-this vote on the -council mailing list instead of waiting for the next 
-meeting.
-
-
-GLEP 56
--------
-Preparation: Post your opinion to the -dev thread "[GLEP56] USE flag 
-descriptions in metadata" 2+ hours before the meeting. Let it attempt to 
-come to a consensus before we vote.
-
-	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_54ee20d2b1d8122370afdd4b3d7aafc9.xml
-
-Goal: Vote once the discussion's no longer clearly ongoing. We can hold 
-this vote on the -council mailing list instead of waiting for the next 
-meeting.
-
-There is still room for improvement in this GLEP, not so much in its 
-technical aspects but in the way it promotes itself, the possible 
-generation of legacy files, and the tools to use it.
-
-
-Status of PMS
--------------
-ferringb said:
-  I'd like the council to please discuss the current status of PMS, if 
-  the running of it satisfys the councils requirements of a *neutral* 
-  standard, if the proposed spec actually meets said standards, and if 
-  said spec is actually going to be approved sometimes this side of '09.
-
-Preparation: Post your opinion to the -dev thread "One-Day Gentoo 
-Council Reminder for June" 2+ hours before the meeting.
-
-	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_9e9652212b3aefe09d93fc24c6ec4cb7.xml
-	vapier: http://archives.gentoo.org/gentoo-dev/msg_37b3ca89a1d253516437facd22a3d806.xml
-
-Result: This is a discussion that belongs on the mailing list. Council 
-members should post anything they have to add by the end of the weekend.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080612.txt b/xml/htdocs/proj/en/council/meeting-logs/20080612.txt
deleted file mode 100644
index 5175aaf816..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080612.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-20:00 < dberkholz@> ok, it's 2000
-20:00 <NeddySeago > antarus but not real time iteration
-20:00 < dberkholz@> council members, speak up if you're here
-20:00 <Betelgeuse@> \o/
-20:01 < dberkholz@> i've seen amne, Betelgeuse, dberkholz, cardoe [flameeyes], lu_zero. waiting on vapier and jokey 
-20:01 < dberkholz@> SpanKY: around?
-20:02 <     jokey@> evening
-20:02 <   edit_21 > \o
-20:02 <   lu_zero@> o/
-20:02 <     jokey@> spanky just sent notice to be a slacker
-20:02 <Betelgeuse@> dberkholz: just got a mail from vapier saying he is slacking because of company emergency
-20:03 <   lu_zero@> =/
-20:03 <   astinus > if he worked at Google, he could have dispatched the tea boy^W^W^Wantarus to fix that ;)
-20:03  *  astinus hides
-20:03 < dberkholz@> ok.
-20:04 <   astinus > "Houston, we are *go* for liftoff!"
-20:04 < dberkholz@> first off, do we want to try the channel modes i suggested?
-20:04 <    Cardoe > I liked that idea.
-20:04 < dberkholz@> see /topic if you want to read them
-20:04 <NeddySeago > only if chatter gets out of hand
-20:05 <     jokey@> time to start, isn't it?
-20:05 <    Cardoe > the official log can be taken by someone with +o, so that people comments will be included due to the +z
-20:05 <      amne@> dberkholz: yes on channel mode
-20:05 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
-20:06 <NeddySeago > comments that are not public should not be in the log
-20:06 <     nadio > I doubt there will be no need for it, kind of loses its point if the users have common sense.
-20:06 < dberkholz@> one reason we moderated in the past is because that isn't the case. people kept interjecting random offtopic comments and questions
-20:07 <Ford_Prefe > Might be worth giving a shot to see how it works
-20:07 <    TFKyle > guessing ops would have to restate anything that they answer from an unvoiced user? or will the +z mostly be to see voice requests?
-20:07 <   edit_21 > dberkholz, well people like that need gagging
-20:07 <   lu_zero@> grr
-20:07 <   lu_zero@> network issues
-20:07 < dberkholz@> i don't want to spend much time dealing with this, so let's do as NeddySeagoon suggests and hold it in reserve and try to get through our topics
-20:08 <      amne@> ok
-20:08 < dberkholz@> next small thing is a 2-hour time limit. we cut off at 2200 and move to the lists with anything we didn't get to. that ok with people?
-20:08 <     jokey@> yup, works for me
-20:08 <      amne@> ++
-20:09 <     jokey@> Betelgeuse?
-20:10 <    Cardoe > dberkholz: works for Diego
-20:10 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
-20:10 <Betelgeuse@> yeah fine
-20:10 < dberkholz@> alright, we're ending at 2200.
-20:10 <Betelgeuse@> I have the worst time zone any way
-20:10 < dberkholz@> first topic that we might have enough info for is >8-digit versions.
-20:11 -!- mode/#gentoo-council [+o lu_zero_] by ChanServ
-20:11 <  lu_zero_@> sigh
-20:12 < dberkholz@> lu_zero_: use screen or something, you're going to be missing info
-20:12 <  lu_zero_@> dberkholz hopefully from there I should be fine
-20:12 < dberkholz@> a nonzero number of packages do have upstream versioning with yyyymmddhhmm or similar.
-20:12 < dberkholz@> as far as i'm aware, nobody with interest in the topic did the testing in versionator.eclass
-20:12 <     jokey@> yep we see a number of packages also on the agenda
-20:13 <     jokey@> I saw that topic floating around in #-portage.. assumed one of us took it up with people there
-20:14 < dberkholz@> we didn't get responses from all of those maintainers. ulm replied that some emacs packages would be able to use it because their upstream versioning was >8
-20:14 -!- mode/#gentoo-council [+o lu_zero__] by ChanServ
-20:14 -!- lu_zero__ is now known as lu_zero
-20:14 <   antarus > I would prefer versionator eclass die
-20:15 <   antarus > and instead get some sort of hook that is PM dependent
-20:15 <   astinus > antarus: do you have a replacement?
-20:15 <     jokey@> antarus: that would be something for eapi-2 then
-20:15 <   antarus > jokey: yes
-20:15 < dberkholz@> are you prepared to vote one way or the other, or do you have a specific problem/question that needs to be answered first?
-20:16 <     jokey@> clear to vote here
-20:16 <     ferdy > antarus: *nod* that's better done on the PM side
-20:16 <    Cardoe > good to go here
-20:16 <   lu_zero@> let me reread
-20:16 <      zlin > that would delay eapi 2. I'm all for getting it in a future eapi though.
-20:17 <     jokey@> other option would be disallowing it until eapi2 is there but I highly dislike that option
-20:17 <   antarus > zlin: I stand corrected, s/2/futureEAPI/ ;)
-20:17 < dberkholz@> i'm still waiting for enough council members to answer my question to move on..
-20:18 <   lu_zero@> dberkholz ok
-20:18 <Betelgeuse@> ok
-20:18 < dberkholz@> these other issues with replacing the eclass are probably better discussed over in #-dev
-20:18 <     jokey@> right, not subject here now
-20:19 <      amne@> uhm i may have trouble reading, what exactly is the question we're voting on now?
-20:19 <    Cardoe > amne: to allow >8 versioning or not
-20:19 < dberkholz@> amne: whether we're ready to vote or still need more info. are you ready to vote?
-20:20 < dberkholz@> the vote will be to allow versions >8 digits.
-20:20 <      amne@> as proposed in the glep, not the other stuff (future eapis etc as just been said)?
-20:20 <      amne@> in any case, i'm ready to vote
-20:20 < dberkholz@> as proposed for pms
-20:21 < dberkholz@> ok, vote: should >8-digit versions be allowed? yes or no.
-20:21 < dberkholz@> yes
-20:21 <   lu_zero@> yes
-20:21 <     jokey@> yes
-20:21 <    Cardoe > yes
-20:21 <Betelgeuse@> heh that's enough
-20:21 <      amne@> yes
-20:21 <Betelgeuse@> +1
-20:22 < dberkholz@> good. the next topic is appeals.
-20:22 <     ferdy > [ remember, portage-utils and versionator.eclass need to be fixed with respect to that decision ]
-20:22 < dberkholz@> do you like my proposal for handling them, or do you want to propose another one on the list?
-20:22 < dberkholz@> as a reminder, it's on the -council list
-20:23 <     jokey@> dberkholz: sounds reasonable to me
-20:23 <   lu_zero@> I'm fine with it
-20:23 <    Cardoe > dberkholz: you proposal sounded the most reasonable
-20:24 <      amne@> as already posted on the list, ++
-20:24 <     jokey@> I doubt rush there would help now
-20:24 <     jokey@> hence all for it
-20:24 < dberkholz@> ok. the appeals will proceed as described in http://archives.gentoo.org/gentoo-council/msg_d7c402fb577a3d5b1707e2bdf4b0a264.xml
-20:24 <      zlin > did this mean max 18, 19 or unlimited number of digits?
-20:24 <Betelgeuse@> dberkholz: sounds good
-20:25 < dberkholz@> there is currently no limitation. if people want one, that should be a separate request
-20:25 < dberkholz@> the next topic is turning on --as-needed by default
-20:26 <jmbsvicett > dberkholz: I understand you not wanting to make a decision on this, but you have the authority to do it and I had hoped you would do it
-20:26 < dberkholz@> jmbsvicetto: let's talk in #-dev
-20:26 <jmbsvicett > dberkholz: ok
-20:27 <     jokey@> dberkholz: if I read it correctly, it would be suggesting that as a default in make.conf.example, right?
-20:27 < dberkholz@> antarus: describe. =)
-20:28 <    Cardoe > a short summary would be good here since the agenda only said read the thread.
-20:29 <    Cardoe > the thread also bounced between profiles and make.conf{,.example}
-20:29 <   antarus > I believe the intent was to use profiles
-20:30 <   antarus > to set LDFLAGS
-20:30 <     jokey@> as genone said it, we only suggest stuff in make.conf.examples as people override it either way
-20:30 < dberkholz@> my interpretation was setting it as a default just like our default CFLAGS
-20:30  *  antarus is open to either way
-20:31 <Betelgeuse@> Does tinderbox for example have as-needed?
-20:31 <Betelgeuse@> Would rather see the whole tree built with it before putting it on by default
-20:31 < dberkholz@> `grep CFLAGS /usr/portage/profiles/arch -r` to get a feel for what the default CFLAGS look like
-20:31 <    Cardoe > right. This is the question. Since if it's in profiles it'll be turned on for a lot more people then how we currently suggest CFLAGS to users
-20:32 <   antarus > Cardoe: As stated, I'll go either way
-20:32 <   antarus > I'm more concerned with the challenges regarding --as-needed itself
-20:32 <   antarus > not how it is deployed
-20:32 < dberkholz@> Betelgeuse: that sounds pretty reasonable.
-20:33 <  ColdWind > Betelgeuse: if you want to know the current status of the tree, it's that it doesn't work fully with as-needed right now
-20:33 < dberkholz@> not necessarily fixing every package, but having a bug for every package that needs to not build with it
-20:33 <Betelgeuse@> ColdWind: most likely
-20:33 < dberkholz@> i think flameeyes posted that you could append -Wl,--no-as-needed or so
-20:33 <   lu_zero@> there is an open bug about it iirc
-20:34 < dberkholz@> to do that means someone would need to build every stable and ~arch package in the tree
-20:34 <Betelgeuse@> ~arch doesn't matter
-20:34 <   antarus > http://bugs.gentoo.org/show_bug.cgi?id=129413
-20:34 <   antarus > is the tracker, for your reference
-20:34 <    Cardoe > I think getting the data Betelgeuse suggested would be something very useful. That being said, I know a good portion of the tree does build with --as-needed
-20:34 < dberkholz@> what i'm seeing here is that this is still being discussed and we're not really sure what should happen
-20:35 < dberkholz@> so i suggest we refer this to the lists for hashing out the details
-20:35 <Betelgeuse@> Cardoe: Yeah I run with it too.
-20:35 <    Cardoe > I build my corporate tinderbox with it.
-20:36 <   antarus > dberkholz: I believe the only argument is: 'is the savings for rebuilding packages worth the risk of some packages being broken' ?
-20:36 <   antarus > dberkholz: do you feel we are not doing enough to mitigate breakage?
-20:36 <     jokey@> *subtle broken at worst
-20:36 <   antarus > or what questions do you have that prevent you from voting?
-20:37 < dberkholz@> there's the question of what the prerequisites are for doing this
-20:37 <  ColdWind > note that enabling it would mean that maintainers and AT should always test --as-needed, otherwise this will do a lot of harm
-20:37 <   antarus > so you want some kind of deployment plan?
-20:37 < dberkholz@> pretty much, yes
-20:37 <   antarus > ColdWind: a valid point
-20:37 <   antarus > dberkholz: ok
-20:37 <     ferdy > jokey: subtly broken is worse than outright fucked up :)
-20:38 <     jokey@> ferdy: depends but yeah ;)
-20:38 <jmbsvicett > fwiw, I have 947 packages on this laptopt built with --as-needed
-20:38 < dberkholz@> ok, let's just get a feel for this
-20:38 <   antarus > jmbsvicetto: you are a poor sample set, sorry ;)
-20:38 <    Cardoe > antarus: can you quickly sum up a deployment plan?
-20:38 <   antarus > Cardoe: no
-20:38 <   antarus > Cardoe: I will come back next month with some concrete stuff
-20:38 <   antarus > move on
-20:38 < dberkholz@> let's not wait till next month
-20:38 < dberkholz@> let's make it happen on the lists
-20:38 <     jokey@> +1
-20:39 < dberkholz@> there's no reason we can't vote on this within the next week on-list
-20:39 <   antarus > dberkholz: i will put a plan together on-list then
-20:39 <     jokey@> signed mails on -council ML should be enough
-20:39 <    Cardoe > this needs very little work to make it happen. Much less then a month.
-20:39 <   antarus > better? :)
-20:39 <   lu_zero@> yup
-20:39 < dberkholz@> sounds good to me. just post it to -dev for discussion
-20:40 < dberkholz@> next topic is glep 54
-20:41 < dberkholz@> lu posted an alternate plan about 12 hours ago
-20:42 <Betelgeuse@> dberkholz: have a link handy?
-20:42 < dberkholz@> yep
-20:42 <Ford_Prefe > http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
-20:42 < dberkholz@> http://archives.gentoo.org/gentoo-dev/msg_05614741b3942bfdfb21fd8ebb7955e0.xml
-20:42 <    Cardoe > Can I just say as an aside, it'd be nice if someone would summarize the final discussion on the dev ML and post that finalized item as a complete deployment plan (as we just requested of antarus) to the council ML to be the official agenda item instead of "read this thread."
-20:43 <   antarus > Cardoe: I think the idea of 'throwing something to the council' should perhaps be slightly defined
-20:43 <   antarus > Cardoe: and if the guy running the meeting gets teh feeling that somethnig isn't well specified (as my proposal was not) it would just not get put on the agenda
-20:44 <    Cardoe > precisely
-20:44 < dberkholz@> since we now have two competing plans, one of which hasn't been around long enough to get much feedback, it doesn't seem like the best time to approve one
-20:44 <     jokey@> right, I at least wouldn't vote for one
-20:45 < dberkholz@> i suggest that we let them develop and see if they somehow merge
-20:45 <      amne@> agreed
-20:45 <    Cardoe > I'd say this is a July agenda item.
-20:45 <    TFKyle > lu_zero: sorry if it's slightly OT, but how would the revision be communicated to the PM from the eclass? or do they do that currently?
-20:45 < dberkholz@> could you guys talk about that in #-dev?
-20:45 <     ferdy > careful, it is very easy to DoS the council this way.....
-20:45 <   lu_zero@> TFKyle better move on -dev
-20:45 <    TFKyle > ah, sorry
-20:45 <   antarus > Cardoe: I think they can vote earlier
-20:45 <     ferdy > you can propose someting 'alternative' a couple of hours before something is going to be discussed
-20:46 <    Cardoe > ferdy: let's remain constructive. Thank you.
-20:46 <Betelgeuse@> ferdy: Well we don't have a rule saying we need to postpone it with alternatives
-20:46 <     ferdy > Cardoe: this IS constructive
-20:46 <      amne@> let's move on please
-20:46 < dberkholz@> again, i want to emphasize that once they finalize somewhat, the council can vote without waiting around for a meeting
-20:46 <     ferdy > Betelgeuse: which is why I said 'careful'
-20:47 <    Cardoe > I think the council members agree that lu's proposal has some merit and should be discussed further as a potential path to take
-20:47 <    Cardoe > If they looked at it and were able to quickly dismiss it as not being viable, we would have had a vote now.
-20:47 <    Cardoe > moving on
-20:47 < dberkholz@> the next two topics are gleps 55 and 56. i suggested that both of them still need further discussion on -dev.
-20:48 <   lu_zero@> agreed
-20:48 < dberkholz@> in my opinion, the council's next action should be all of us posting our feedback to both gleps
-20:48 <    Cardoe > What are the outstanding discussions on glep 56?
-20:49 <     jokey@> 56 doesn't have some I think, given there hasn't been feedback for some days now
-20:49 <Betelgeuse@> glep 56 makes PMS look like something valid
-20:50 < dberkholz@> i outlined my reasons in http://archives.gentoo.org/gentoo-dev/msg_54ee20d2b1d8122370afdd4b3d7aafc9.xml and they basically agree with what genone was saying
-20:50 <  ColdWind > lu_zero: you may want to extend your proposal, with the 'Backwards compatibility' section if we are going to discuss it in the list
-20:50 <   lu_zero@> ColdWind sure
-20:50 <    Cardoe > dberkholz: that doesn't disregard the GLEP from being voted on
-20:50 <    Cardoe > dberkholz: the council can say approve this GLEP to deprecate X
-20:51 <    Cardoe > I left that up to the council to decide
-20:51 <    Cardoe > as my e-mail to genone stated
-20:52 <    Cardoe > obviously I abstain from voting but if everyone would like to kick it back to the list I'll create a new summary.
-20:52 <    Cardoe > I agree Betelgeuse did raise a valid point.
-20:54 < dberkholz@> i didn't quite follow the reasoning
-20:54 < dberkholz@> maybe i need more coffee
-20:54 <   lu_zero@> Cardoe could you please summarize?
-20:55 <NeddySeago > 5 mins left
-20:55 < dberkholz@> till 1 hour =)
-20:55 <    Cardoe > lu_zero: surely
-20:55 <NeddySeago > Oops - sorry
-20:55 <    Cardoe > GLEP 56 aims to fill a gap that currently exists in Gentoo's USE flag documentation
-20:56 <    Cardoe > Essentially use.local.desc can not be used to override our description of a use.desc flag as per our QA Project's policy
-20:56 <    Cardoe > All those overlaps were removed from the tree a few months back
-20:56 <    Cardoe > This has resulted in a loss of information for users (that includes devs) about how certain USE flags affect their system.
-20:57 <    Cardoe > The goal is to allow these global and even non-global USE flags to be documented with clarity. Additionally, it also allows the lang attribute so that in the future we may internationalize our tree better to support non-English speakers with this information.
-20:58 <    Cardoe > The information is wrapped in XML using a simple tag structure that tools can take an advantage of. Tools like packages.gentoo.org and other command line utilities and provides additional measures to cross-reference to other packages when describing a USE flag.
-20:58 <  dev-zero > Cardoe: sorry to interrupt, did you get my mail wrt changes for GLEP 56
-20:58 <     jokey@> as said, feedback was quite silent, though nothing negative and I personally don't see anything questionable either
-20:58 <  dev-zero > ?
-20:59 <    Cardoe > dev-zero: yes.
-20:59 <    Cardoe > For every one else, the feedback that dev-zero provided was to remove the following: "* The default ``'lang'`` attribute value is "C", which is equivilent to "en"."
-21:00 <    Cardoe > Which is currently defined in the devmanual's section on metadata.xml
-21:00 < dberkholz@> Cardoe: is there a way to say which flags are local vs global?
-21:00 <    Cardoe > So putting that into the GLEP is redundant, so dev-zero would like it removed.
-21:00 <  dev-zero > Cardoe: then you missed a bigger part of it
-21:00 <    Cardoe > dberkholz: Not in the current version of the GLEP
-21:01 <    Cardoe > dberkholz: it merely defines what USE flags affect this package
-21:01 < dberkholz@> if you wanted to be able to build up a use.local.desc from this, would you need such a thing?
-21:01 <   lu_zero@> dev-zero could you point us a link or a quick summary?
-21:01 <    Cardoe > dberkholz: I discussed it with infra. Effectively the process would be to build up a use.local.desc and subtract use.desc from it.
-21:01 < dberkholz@> right, that's the other way i was thinking.
-21:01 <  dev-zero > lu_zero: http://rafb.net/p/FI6bdj29.html
-21:02 < dberkholz@> there may be a danger in allowing local descriptions of globals, which diverge over time until they no longer mean the same thing
-21:03 < dberkholz@> but they again, the meaning within a package generally doesn't change much
-21:03 < dberkholz@> then*
-21:03 <Ford_Prefe > dberkholz: besides, that would be a QA violation and as such should be discouraged/caught
-21:03 <     jokey@> should we send it back to ml for discussion?
-21:03 <     jokey@> as we agreed to vote on ML, it should be safe for this too
-21:04 <     ferdy > Cardoe: sorry for not bringing this earlier (I probably missed the thread). The fact that a USE flag *might* change meaning in the lifetime of a package has been discussed and covered?
-21:04 < dberkholz@> The 'restrict' atttribute can limit to specific versions of the package
-21:05 <Ford_Prefe > ferdy: I'd assume the USE flag itself would change then, as it would be expecteed to today
-21:05 <    Cardoe > what dberkholz said
-21:05 <     ferdy > thanks. Sorry for the noise.
-21:05 < dberkholz@> good question. i had to check the glep for it
-21:05 < dberkholz@> there's 3 t's in attribute, btw.
-21:06 <    Cardoe > dberkholz: thank you
-21:06 < dberkholz@> i think there is still room for improvement in this glep, not so much in its technical aspects but in the way it promotes itself, the possible generation of legacy files, and the tools to use it. 
-21:08 <    Cardoe > Well I abstain from voting on it due to conflict of interest, but as I said before. I'm game for kicking it to the ML and I'll address all the concerns and provide a follow up e-mail to the list.
-21:08 < dberkholz@> we already agreed to allow the flags without a glep a few months back <http://www.gentoo.org/proj/en/council/meeting-logs/20071213-summary.txt>, so that's not the purpose of this one ...
-21:09 < dberkholz@> if the point isn't to allow them, the point should be something else beyond saying they're possible
-21:10 <    Cardoe > I just wanted to write a GLEP to address some council member's concerns about a lack of a GLEP.
-21:10 < dberkholz@> i can certainly see the value of a specification
-21:10 < dberkholz@> does anyone want to vote on glep 56 now?
-21:11 <   lu_zero@> I'd look forward improvements
-21:13 < dberkholz@> could i actually get a yes or no response to that question?
-21:13 <     jokey@> no
-21:13 <   lu_zero@> no
-21:13 <      amne@> no
-21:13 < dberkholz@> great, thanks.
-21:13 <     jokey@> ML vote++
-21:14 < dberkholz@> i'm going to talk with cardoe more about my concerns. i encourage you all to do the same, on-list or off
-21:14 <   lu_zero@> (sorry but I keep reloggin on d.g.o every 40s average...)
-21:14 <     jokey@> screen ftw ;)
-21:14 < dberkholz@> the last topic is PMS status
-21:15 < dberkholz@> i really think you all need to post your opinions to that mailing-list thread i mentioned in the agenda
-21:15 <     jokey@> I raised my concerns today on the ML already
-21:16 <   lu_zero@> I voiced them already as well
-21:16 <      amne@> i don't think i sent an email, but jokey's really summed up my concerns
-21:17 < dberkholz@> what i'd like to do is wrap up this meeting now and since we're under the 2-hour cutoff, see all of us with email access spend the remaining time posting to the list about the topics we sent there
-21:17 <     jokey@> sounds good to me
-21:17 < dberkholz@> in particular glep 54, glep 56, pms
-21:18 < dberkholz@> those should all be resolvable quickly. glep 55 as well, if you have any ideas
-21:18 <     jokey@> then we don't have a topic left, do we?
-21:19 < dberkholz@> nope, that's it if everyone agrees with my suggestion
-21:19 <     jokey@> k' then
-21:19 < dberkholz@> amne, Betelgeuse, lu_zero, Cardoe ?
-21:19 <      amne@> wfm
-21:19 <     jokey@> note to dberkholz: nice meeting style idea, feels good
-21:19 <    Cardoe > dberkholz: I agree with your suggestion
-21:19 <Betelgeuse@> dberkholz: I might write something but as it gets late.
-21:20 <   lu_zero@> dberkholz just back, let me sync back
-21:20 < dberkholz@> Betelgeuse: right, understood. it would be good if everyone could post within the next day, 2 tops
-21:20 <Betelgeuse@> For the next council I will try to get the meetings earlier.
-21:20 <    Cardoe > I've summarized my feelings on the ML. Which really was an extension of jokey's.
-21:20 <Betelgeuse@> Winter is fine but DST is a bit late.
-21:22 <jmbsvicett > dberkholz: As you've covered all the topics for the meeting, you might want to make some comments about CoC and the tone of mails to the -dev ml
-21:23 < dberkholz@> the meeting's officially over. thanks for playing, everyone, and i'll see your posts on the lists in the next day or two. anyone who would like to talk about conduct on the lists can stick around for a little bit =)
-
---- Meeting ends. Brief discussion of recent on-list behavior and CoC follows. ---
-
-21:24 < dberkholz@> jmbsvicetto: what in particular did you have in mind?
-21:25 <jmbsvicett > dberkholz: I saw your comment in the morning, but I didn't had the time to reply to the list then
-21:25 <jmbsvicett > dberkholz: First, do you still think there's any interest, purporse or need for CoC?
-21:25 < dberkholz@> to catch everyone up here...
-21:25 < dberkholz@> 23:00 <jmbsvicett > No. But it wouldn't hurt if people were able to express  their views or points in 2 mails instead of 20
-21:25 < dberkholz@> Day changed to 12 Jun 2008
-21:25 < dberkholz@> 06:22 < dberkholz@> jmbsvicetto: since you remarked upon the problem, perhaps  you'd like to post to the list. =)
-21:25 < dberkholz@> 06:22 < dberkholz@> the whole idea is getting people outside the council to  participate ... peer pressure to maintain a good working  environment
-21:25 <jmbsvicett > Second, do you think any of the mails to the -dev ml in the last 2 days violates the CoC?
-21:26 <jmbsvicett > dberkholz: You missed the first comment
-21:26 <      rane > they probably didn't even read them
-21:26 < dberkholz@> you basically just repeated it, didn't you?
-21:26 <      rane > i know cause i didn't myself
-21:26 <jmbsvicett > I think so
-21:26 < dberkholz@> personally, i wasn't terribly impressed with some of the recent back-and-forth threads in the past few days
-21:27 < dberkholz@> on either end, not just one person or the other
-21:27 <jmbsvicett > dberkholz: I think there were at least 2 messages that should not be tolerated
-21:27  * NeddySea would like to thank the outgoing council for their efforts
-21:27 <jmbsvicett > The one with the link to the "idiot" definition on wikipedia
-21:28  * Ford_Pre echoes NeddySeagoon 
-21:28 <jmbsvicett > I also want to thank the council members for their work
-21:28 < dberkholz@> jmbsvicetto: bheekling did an outstanding job of stepping in on that thread and one or two others. he's setting a great role model for what the rest of us should do
-21:30 <jmbsvicett > let me read the mails again.
-21:30 <Ford_Prefe > I guess peer-directed intolerance for bad behaviour is really the ideal solution for this
-21:30 <jmbsvicett > skim*
-21:33 <jmbsvicett > dberkholz: hmm, I can't find any mesage from bheekling on the -dev ml. Different name on the from address?
-21:33 <Ford_Prefe > http://archives.gentoo.org/gentoo-dev/msg_4211dc4054de30f2ff52f6f8a2e2466e.xml might be it
-21:33 <      rane > Nirbheek
-21:34 < dberkholz@> yeah, that's him.
-21:34 <Ford_Prefe > (name is right, this might be the thread dberkholz is referring to)
-21:34 <      rane > or sth like that
-21:34 <      rane > no idea if it's his real name
-21:34 <jmbsvicett > thanks
-21:34 < dberkholz@> the specific post i had in mind was a wikipedia reference to flames and personal attacks
-21:35 <      rane > yeah, this new idea of people telling others they are behaving like jerks
-21:35 <      rane > it looks like it worked
-21:35 <Ford_Prefe > Indeed
-21:40 <      rane > silent majority stepping in and kicking ass
-21:40 <      rane > a great idea indeed
-21:47 <Ford_Prefe > Maybe we can have a won't-tolerate-bad-behaviour pledge. :P
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080710-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080710-summary.txt
deleted file mode 100644
index 72c9b0c8cb..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080710-summary.txt
+++ /dev/null
@@ -1,125 +0,0 @@
-Quick summary
-=============
-
-GLEP 54: There were numerous questions that apparently were not brought 
-         up on the mailing list in advance or were not addressed.
-
-GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may be, 
-         but that's unclear until it's been revised.
-
-GLEP 56: Approved. Cardoe will get repoman changes made, followed by a 
-         server-side script to generate use.local.desc from 
-         metadata.xml.
-
-
-The meeting wrapped up in under 1 hour again. We still need to work 
-harder to push more discussion and questions to the mailing list, 
-though.
-
-
-Topics
-======
-
-GLEP 54
--------
-Preparation: Post your opinion to the -dev thread "A few questions to 
-our nominees" 4+ hours before the meeting.
-
-Last month: 
-	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml
-	lu_zero: http://archives.gentoo.org/gentoo-dev/msg_05614741b3942bfdfb21fd8ebb7955e0.xml
-
-Goal: Status check at meeting to see who's ready to vote. Vote on-list 
-no later than July 17.
-
-<Betelgeuse@> dberkholz: with GLEP 55 EAPI X can add the support for scm
-<Betelgeuse@> dberkholz: and older Portage versions work just fine
-
-<Betelgeuse@> dberkholz: In general I oppose adding things to EAPI 0
-
-<   lu_zero@> dberkholz problem: if you have -scm installed
-<   lu_zero@> and then switch to a pm not knowing it
-<   lu_zero@> you have a nice recipe for inconsistency
-
-<   Halcy0n@> I would really like to see a list of features that we would 
-                    end up having after implementing this GLEP.  The GLEP 
-                    mentions possible enhancements, but I'd like to see what we 
-                    would have planned if we go forward with this change.
-<   Halcy0n@> Well, it only mentions one enhancement, I'd like to see 
-                    what else we could do to judge if it is worth it.
-Halcy0n@> Betelgeuse: yes, I know there are some things we could do,
-                    but I'd like to see a more extensive list of possibilities, 
-                    what are other possible ways of doing this (like a metadata 
-                    tag for the ebuild), and why those other methods aren't 
-                    sufficient.
-
-< dberkholz@> i think the point here is that the glep should address what 
-                    made its implementation superior to other possible ones, 
-                    which it also describes
-
-< dberkholz@> ok, i've noted the issues raised here
-< dberkholz@> once they're address, the glep can be revised and we'll 
-                    consider it again
-
-Summary: Specific questions and requests are above.
-
-
-GLEP 55
--------
-Preparation: Post your opinion to the -dev thread "GLEP 55" 4+ hours 
-before the meeting.
-
-Last month:
-	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml
-
-Goal: Status check at meeting to see who's ready to vote. Vote on-list 
-once we're ready.
-
-<Betelgeuse@> But I don't see the use of accepting it before we a) 
-                    Portage has something that would make use of it b) some 
-                    other pkg manager is made official
-<   Halcy0n@> So, can we vote on postponing a GLEP of this nature until 
-                    another glep requires such changes?
-
-Summary: On hold pending a concrete requirement for it. GLEP 54 may be, 
-but that's unclear until it's been revised.
-
-
-GLEP 56
--------
-Preparation: Post your opinion to the -dev thread "[GLEP56] USE flag 
-descriptions in metadata" 4+ hours before the meeting. (Cardoe: Did the 
-requested updates ever get made?)
-
-Last month:
-	dberkholz: http://archives.gentoo.org/gentoo-dev/msg_54ee20d2b1d8122370afdd4b3d7aafc9.xml
-
-Goal: Status check at meeting to see who's ready to vote. Vote on-list 
-no later than July 17, if requested changes are made.
-
-Requested changes were made: 
-http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0056.txt?r1=1.1&r2=1.2
-
-<    Cardoe > Well the first step of making that portion happen is going 
-                    to be to add a check to repoman that if use.local.desc is 
-                    not present in the repo, do new QA check.
-<    Cardoe > Once that's in place that developers can use, then the 
-                    infra script will happen.
-<    Cardoe > I've already discussed it with the Portage folks and the 
-                    infra folks.
-
-Summary: Approved.
-
-
-Roll call
-=========
-
-(here, proxy [by whom] or slacker?)
-
-betelgeuse  here
-dberkholz   here
-dertobi123  here
-flameeyes   here
-halcy0n     here
-jokey       here
-lu_zero     here
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080710.txt b/xml/htdocs/proj/en/council/meeting-logs/20080710.txt
deleted file mode 100644
index 099170ba28..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080710.txt
+++ /dev/null
@@ -1,208 +0,0 @@
-20:01 < dberkholz@> looks like lu just got kicked offline
-20:01 <     jokey@> yep
-20:02 <     jokey@> he should really use screen ;)
-20:02 < Flameeyes@> jokey: or quassel :P
-20:02 <dertobi123@> screen ftw.
-20:03 < dberkholz@> ok. one more time, agenda for the meeting is here: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
-20:03 -!- Irssi: #gentoo-council: Total of 53 nicks [6 ops, 0 halfops, 0 voices, 47 normal]
-20:03 <Betelgeuse@> Flameeyes: some kind of backgrounding IRC client?
-20:03 < Flameeyes@> Betelgeuse: yeah it's a (core+client) client
-20:03 < dberkholz@> who's here: Betelgeuse , Flameeyes , jokey , dertobi123 
-20:03 < Flameeyes@> I am
-20:03 < dberkholz@> and me
-20:03 <   Halcy0n@> Me
-20:03 < dberkholz@> Halcy0n, lu need to speak up (and show up again in lu's case)
-20:03 < dberkholz@> ah, there you are
-20:04 <     jokey@> hi lu_zero
-20:05 <dertobi123@> luca!
-20:05 <    fmccor > You might op him  :)
-20:05 <     jokey@> he can do that himself ;)
-20:05 < dberkholz@> lu_zero: back for good?
-20:06 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
-20:06 <   lu_zero@> sigh
-20:06 <   lu_zero@> let the damn thing sync
-20:06 <   lu_zero@> and I will
-20:06 <   lu_zero@> ok
-20:08 < dberkholz@> ok, everyone's here now
-20:08 < dberkholz@> sorry for the lag
-20:08 < dberkholz@> first topic is glep 54
-20:10 < dberkholz@> anyone got anything to say?
-20:10 <     jokey@> short statement for the logs? ;)
-20:11 <     jokey@> doesn't look like it
-20:11 <Betelgeuse@> dberkholz: Well as older Portage versions don't handle it correctly, it can't yet be used in the tree so what's the use of making it official?
-20:11 <   lu_zero@> I don't feel the glep changed any way
-20:11 < Flameeyes@> I still haven't heard anything that moves me from my original position of not liking it
-20:12 <Betelgeuse@> dberkholz: glep 55 should be handled before 54
-20:12 < dberkholz@> Betelgeuse: your reasoning, please?
-20:12 <Betelgeuse@> dberkholz: 23:11 <@Betelgeuse> dberkholz: Well as older Portage versions don't handle it correctly, it can't yet be used in the tree so what's the use of making it official?
-20:12 <Betelgeuse@> dberkholz: with GLEP 55 EAPI X can add the support for scm
-20:13 <Betelgeuse@> dberkholz: and older Portage versions work just fine
-20:13 <   lu_zero@> glep 55 -> http://dev.gentoo.org/~lu_zero/glep/migrationpath.rst
-20:13 < dberkholz@> glep 54 claims backwards compat is quite reasonable
-20:13 < dberkholz@> "Portage versions prior to 2.1.2.12 (included in 2007.0) don't handle arbitrary version suffixes and die during various tasks making portage hard or impossible to use. Later versions just ignore them displaying warnings. Hence use of scm suffixes in gentoo-x86 tree will probably have to wait till 2008.0 release or later."
-20:13 < Flameeyes@> so let's say virtual/eapi-migration-method
-20:14 < Flameeyes@> [so glep55 or something providing the same interface]
-20:14 <   lu_zero@> dberkholz problem: if you have -scm installed
-20:14 <   lu_zero@> and then switch to a pm not knowing it
-20:14 <   lu_zero@> you have a nice recipe for inconsistency
-20:14 <Betelgeuse@> dberkholz: In general I oppose adding things to EAPI 0
-20:15 <Betelgeuse@> although zmedico seems to be doing it every once in a while
-20:15  *  lu_zero in general opposes having non-definitions
-20:15 <      igli > if it doesn't break anything.. ;)
-20:16 <   Halcy0n@> I would really like to see a list of features that we would end up having after implementing this GLEP.  The GLEP mentions possible enhancements, but I'd like to see what we would have planned if we go forward with this change.
-20:16 <   Halcy0n@> Well, it only mentions one enhancement, I'd like to see what else we could do to judge if it is worth it.
-20:16 <   lu_zero@> Halcy0n that had been requested
-20:16 < Flameeyes@> Halcy0n: that was my concern in the first place
-20:16 <   lu_zero@> the feedback hadn't be that helpful
-20:16 < dberkholz@> (fyi, i'm writing down the exact questions we have for posting to the list afterwards)
-20:17 <   Halcy0n@> Okay, I'm still catching up with everything that has gone on, so ignore me if I repeat something that happened already :)
-20:17 <Betelgeuse@> Halcy0n: Adding global scope functions.
-20:17 <Betelgeuse@> Halcy0n: But that can also be done by cleaning profile bashrcs and adding stubs
-20:17 < Flameeyes@> Betelgeuse: I _think_ Halcy0n was referred to 54
-20:17 < dberkholz@> are we on 55 or 54 here? we seem to be bouncing around
-20:17 <   Halcy0n@> I thought we were discussing 54.
-20:17 <     jokey@> 54
-20:17 <   antarus > 54
-20:17 < Flameeyes@> 42
-20:18 < Flameeyes@> [sorry couldn't help it]
-20:18 <   antarus > Flameeyes: hike!
-20:18 <   antarus > Flameeyes: also good to see you here ;)
-20:18 <Betelgeuse@> Halcy0n: periodit reinstalls
-20:18 <   lu_zero@> Betelgeuse I wasn't aware the package manager has cron capabilities...
-20:19 <Betelgeuse@> lu_zero: lol
-20:19 -!- lu_zero changed the topic of #gentoo-council to: glep 54 discussion || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
-20:19 <   Halcy0n@> Betelgeuse: yes, I know there are some things we could do, but I'd like to see a more extensive list of possibilities, what are other possible ways of doing this (like a metadata tag for the ebuild), and why those other methods aren't sufficient.
-20:21 <   lu_zero@> Halcy0n I started to write down alternatives with features that interest me in http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
-20:22 < dberkholz@> i think the point here is that the glep should address what made its implementation superior to other possible ones, which it also describes
-20:22 <   Halcy0n@> Do we all agree that we should wait to make a decision on this until we have a list of actual features, and why its the best solution?
-20:22 <     jokey@> (and make sure that it is the best option)
-20:22 <     jokey@> ++
-20:23 < Flameeyes@> agreed again
-20:23 <dertobi123@> Halcy0n: agreed
-20:23 <   lu_zero@> agreed
-20:23 <Betelgeuse@> Halcy0n: We can wait any way as it can't be used in the main tree.
-20:24 <   antarus > s/can't/should not be/
-20:24 <   antarus > but I'm a pedant
-20:24 < dberkholz@> ok, i've noted the issues raised here
-20:25 < dberkholz@> once they're address, the glep can be revised and we'll consider it again
-20:25 < dberkholz@> addressed*
-20:25 < dberkholz@> let's move on to glep 55
-20:25 -!- lu_zero changed the topic of #gentoo-council to: glep 55 discussion || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
-20:26 < dberkholz@> who likes it?
-20:27  *    jokey doesn't, solves a non-existant problem
-20:27  *  lu_zero doesn't solves a non-existant problem in an unclean fashion
-20:27 <   lu_zero@> missing coma
-20:27  *  lu_zero doesn't, solves a non-existant problem in an unclean fashion
-20:27 <   Halcy0n@> Not I, same reason.
-20:28 < Flameeyes@> ibid.
-20:28 <     jokey@> maybe we should just vote
-20:28 <gentoofan2 > what about the reasons mentioned in the glep?
-20:28 < dberkholz@> 4 of us just said they don't like it because it solves a nonexistent problem
-20:28 <   antarus > I disagree with your wording
-20:28 <   antarus > it certainly solves a problem
-20:28 <dertobi123@> dberkholz: agreed on that, make it 5
-20:28 <Betelgeuse@> I agree with antarus
-20:29 <   antarus > the problem is not a blocker for Gentoo
-20:29 <   antarus > (to my knowledge)
-20:29 < dberkholz@> is it a problem for gentoo in any fashion at all? are there any other features we want that depend on it? if so, i haven't seen a glep for 'em
-20:29 <Betelgeuse@> But I don't see the use of accepting it before we a) Portage has something that would make use of it b) some other pkg manager is made official
-20:30 <   Halcy0n@> antarus: I can agree with that wording as well. :)  I think we were implying it wasn't a problem for Gentoo when we were saying it solved a non-existant problem.
-20:30 <   antarus > I imagine the kde and java people have odd ideas rolling around
-20:30 <   lu_zero@> Alternatives anyway -> http://dev.gentoo.org/~lu_zero/glep/migrationpath.rst
-20:30 <   Halcy0n@> So, can we vote on postponing a GLEP of this nature until another glep requires such changes?
-20:31 <Betelgeuse@> Halcy0n: agreed
-20:31 <gentoofan2 > Halcy0n: like glep 54?
-20:33 <     jokey@> gentoofan23: nah, we want more input on that glep... 55 we just want to defer until we need something like that
-20:33 <   Halcy0n@> gentoofan23: you could say that, yes.  If we want to introduce features, and actually have features that need these changes, then I'm all for it.
-20:33 <   Halcy0n@> Just changing things for the sake of changing them though...
-20:33 <dertobi123@> jokey: until we have a pÃroblem this glep would solve, yeah
-20:34 <     jokey@> dertobi123: yep, :)
-20:34 < dberkholz@> like one implementation of the overall idea in glep 54
-20:34 < dberkholz@> since we just decided we want to hear about why that is better than the other ones, 55 may or may not be required
-20:34 <   Halcy0n@> Flameeyes: lu_zero, dberkholz:  do you agree with postponing 55 as well?
-20:34 < Flameeyes@> I do
-20:34 <   lu_zero@> Halcy0n 55 or any other migration paths
-20:35 <   lu_zero@> I don't like the one proposed in glep55
-20:35 <   lu_zero@> and I think there are nicer alternatives
-20:35 <Betelgeuse@> dberkholz: the implementation is called paludis
-20:36 < dberkholz@> Betelgeuse: i'm not talking about a PM that implements that feature. i'm talking about whether -scm is the best way to solve the problem.
-20:36 <gentoofan2 > dberkholz: you mean like a repo using said features?
-20:36 <     jokey@> no, the way the problem is solved
-20:36 <  DrEeevil > I still say a tag in the ebuild (like RESTRICT) is all you need
-20:37 <     jokey@> dberkholz: so we deferred this until we have use?
-20:38 < dberkholz@> so, glep 54 in its current state is likely to depend on either glep 55 or some other eapi bump to allow -scm
-20:38 <   lu_zero@> DrEeevil please expand the reasoning in ml
-20:39 <  DrEeevil > lu_zero: ok
-20:40 < dberkholz@> looks like this is postponed at least till we've got a solid 54 
-20:40 <     jokey@> okay
-20:40 <     jokey@> next topic then?
-20:40 <   lu_zero@> jokey yup
-20:40 < dberkholz@> glep 56
-20:41 -!- jokey changed the topic of #gentoo-council to: glep 56 discussion || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
-20:41 < Flameeyes@> dberkholz: for the logs, I don't see any change in the reasoning for discussing the two of these again since last time -- we might want to decide to not discuss them again until there's a need for them]
-20:42 <   Halcy0n@> Cardoe posted some updates to the GLEP a little while ago, did everyone have a chance to look at them?
-20:42 < dberkholz@> Flameeyes: 54 & 55, you mean?
-20:42 < Flameeyes@> dberkholz: yes
-20:43 < dberkholz@> i like 56's current backwards compat section
-20:43 < Flameeyes@> Halcy0n: have you the link handy of the exact changes?
-20:43 <   Halcy0n@> http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0056.txt?r1=1.1&r2=1.2  is the diff
-20:43 < Flameeyes@> thanks
-20:44 <     jokey@> glep is good from my pov
-20:44 <   Halcy0n@> I like this one
-20:45 <     jokey@> anyone having questions about it?
-20:45 <   lu_zero@> got pointed that useflag definitions should be bound to a matching atom
-20:45 < Flameeyes@> good for me [well was good for me before too]
-20:46 <   lu_zero@> and that is yet not completely crystal clear (even if present)
-20:46 <dertobi123@> i also like it, but in the last paragraph of backwards compatibility it is unclear to me what "approving" the glep has to do with auto-generation of use.local.desc
-20:46 <   Halcy0n@> lu_zero: I believe that's the restrict attribute?
-20:46 < dberkholz@> dertobi123: by moving local flags to metadata.xml, instead of duplicating information in two places that gets out of sync we want to autogenerate the old location for legacy tools
-20:46 <    Cardoe > sorry all.. I mentally overslept.
-20:47 <dertobi123@> dberkholz: might make more sense to change the wording from "approved" to "fully implemented" or "implemented for local use-flags" then?
-20:47 <   lu_zero@> Halcy0n as I said, it is a nit
-20:48 < dberkholz@> i don't even see that it's a nit. it looks already addressed to me
-20:49 <     jokey@> indeed
-20:49 <    Cardoe > Well the first step of making that portion happen is going to be to add a check to repoman that if use.local.desc is not present in the repo, do new QA check.
-20:49 <    Cardoe > Once that's in place that developers can use, then the infra script will happen.
-20:50 <    Cardoe > I've already discussed it with the Portage folks and the infra folks.
-20:50 <jmbsvicett > Cardoe: Won't devs require updated validation tools?
-20:50 <   lu_zero@> good
-20:50 <    Cardoe > jmbsvicetto: right. which is why we're going to update repoman first.
-20:50 <   Halcy0n@> I am for approving this one.
-20:50 < dberkholz@> dertobi123: i guess my reading is a little different .. was reading the "will work to remove" part as implementing
-20:50 <jmbsvicett > Cardoe: ok
-20:51 <     jokey@> Halcy0n: make it more formal and "request for vote" :)
-20:52 < dberkholz@> ok, let's vote: approve glep 56, yes or now
-20:52 < dberkholz@> no*
-20:52 <     jokey@> yes
-20:52 <   Halcy0n@> yes
-20:52 < dberkholz@> yes
-20:52 <dertobi123@> dberkholz: the "will work to remove" part works for me as implementing, too
-20:52 <Betelgeuse@> \o/
-20:52 <dertobi123@> so, yes
-20:52 < Flameeyes@> yes
-20:52 < dberkholz@> wb Betelgeuse =)
-20:53 <Betelgeuse@> windzor: wherw was I?
-20:53 <     jokey@> okay, glep accepted :)
-20:53 <Betelgeuse@> s/windzor/dberkholz/
-20:53 < dberkholz@> i dunno, not talking during the 56 discussion. figured you were elsewhere
-20:53 < dberkholz@> that's all the agenda topics. two more quick things i wanted to mention
-20:54 < dberkholz@> 1 -- we're moving to biweekly meetings, so the next one will be july 24
-20:54 < dberkholz@> 2 -- we are actively discussing the appeals and will get decisions out asap
-20:55 <jmbsvicett > dberkholz: Where do you plan to announce the decisions?
-20:56 <     jokey@> dev-announce and council imho
-20:56 <   lu_zero@> agreed
-20:56 <     jokey@> dunno though ;)
-20:56 < dberkholz@> via private email to them, certainly. not sure exactly where on the public side yet
-20:58 <jmbsvicett > Can you please update the topic here and or make a note on the council ml when you decide where to make the annoucement?
-20:58 < dberkholz@> sure
-20:58 <   lu_zero@> dberkholz summary link?
-20:58 -!- jokey changed the topic of #gentoo-council to: Next council session july 24 || Agenda: http://dev.gentoo.org/~dberkholz/20080710-agenda-mini.txt
-20:58 <     jokey@> actually...
-20:58 < dberkholz@> lu_zero: i'll post it later this evening
-20:58 <   lu_zero@> ok
-20:58 -!- jokey changed the topic of #gentoo-council to: Next council session july 24
-20:59 < Flameeyes@> dberkholz: is the meeting still open? [mostly because I have to run]
-20:59 < dberkholz@> we're done for today
-20:59 <   lu_zero@> btw my vote for 56 is yes ^^
-20:59 <   antarus > dberkholz: well run meeting; thanks all
-20:59 < Flameeyes@> sorry guys, I run away then :) have a nice weekend all of you :P
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080724-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080724-summary.txt
deleted file mode 100644
index c8379a6b19..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080724-summary.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-== Quick summary ==
-
-Item 1: userrel authority: Does userrel have the ability to enforce the
-        CoC on users like devrel does for developers?
-
-It was decided that userrel does have this authority.
-
-
-Item 2: coc extent
-
-All council members will review the CoC thread and comment on it by the
-next meeting (7 August 2008).  We will get a status update in that
-meeting to see if we can vote on any of the proposals brought up in that
-thread.
-
-
-Roll call:
-
-dberkholz       proxied by musikc
-jokey           here
-dertobi123      here
-betelgeuse      proxied by caster
-halcy0n         here
-lu_zero         here
-flameeyes       absent (no slacker mark due to personal reasons)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080724.txt b/xml/htdocs/proj/en/council/meeting-logs/20080724.txt
deleted file mode 100644
index faa6e566dd..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080724.txt
+++ /dev/null
@@ -1,128 +0,0 @@
---- Log opened Thu Jul 24 15:59:35 2008
-15:59 <@dertobi123> jmbsvicetto: yes, we're going to first mail to the people in question, then make the decision public. should happen soonish.
-15:59 < Caster> I'm for Betelgeuse but pls give me 5 minutes
-15:59  * dertobi123 is here
-15:59 < jmbsvicetto> dertobi123: thanks
-16:00 <@Halcy0n> Alright, so: musick (for donnie), jokey, dertobi123, caster (for betelgeuse), me 
-16:01 <@Halcy0n> We'll give lu_zero and Flameeyes a few minutes
-16:06  * jokey notes flameeyes is away on jabber as well
-16:06 <@dertobi123> let's start?
-16:06 <@Caster> ok
-16:06 <@musikc|laptop> ready whenever you folks are
-16:06 <@Halcy0n> Yea, I sent lu_zero and Flameeyes something on jabber a few minutes ago.  We can start now and just mark them as not here (unless they show up in the next few minutes)
-16:07 <@jokey> go for it
-16:07 <@jokey> who takes chair for donnie? ;)
-16:07 <@Halcy0n> I can if no one else wants to.
-16:07 -!- dertobi123 changed the topic of #gentoo-council to: Council meeting today - July 24th 2000UTC | agend: 1) userrel authority 2) coc extent
-16:07 -!- dertobi123 changed the topic of #gentoo-council to: Council meeting today - July 24th 2000UTC | agenda: 1) userrel authority 2) coc extent
-16:07 <@dertobi123> bleh
-16:08 <@jokey> Halcy0n: then do so :)
-16:08 <@Halcy0n> Alright, first thing to get out of the way is to announce that we have come to a decision on the appeals.  We will be sending emails to the parties involved directly before sending anything out publically.  Just for everyone that was wondering.
-16:09 <@musikc|laptop> good to hear, thx
-16:10 <@Halcy0n> So, for item #1:  When does everyone think they can reply to the thread on council with your ideas and concerns?  Is there anything in there that you would like to note as something that needs to be clarified.
-16:11 < antarus> coc!
-16:11 < jmbsvicetto> Halcy0n: In case you're considering my "proposal", let me know if you need me to clarify anything
-16:11 <@musikc|laptop> Halcy0n, are some council members already noted as having commented?
-16:12 <@Halcy0n> musikc|laptop: looking at the thread, it looks like myself, Donnie, Luca, and Petteri have commented.
-16:13 <@musikc|laptop> Halcy0n, cool i just wanted to be sure that people knew who did so those folks didnt think they had to again :)
-16:13 <@dertobi123> from my pov there's not that much to discuss there, "our house, our rules" as luca stated. therefore the coc is in place for users as well, except technical limitations when it comes to disciplinary actions
-16:13 <@dertobi123> i.e. we can ban names but not people
-16:14 <@Halcy0n> So, can we say that everyone will have read the thread and atleast posted what they agree with on there by August 1st?  That way by the next meeting we should have something to vote on.
-16:14 <@dertobi123> agreed
-16:15 <@Caster> yup
-16:15 <@musikc|laptop> Halcy0n, so waiting on dertobi123, flameeyes, and jokey right?
-16:15 <@jokey> yap
-16:15 <@jokey> luca!
-16:15 <@lu_zero> hi
-16:16 <@lu_zero> Diego got hospitalized again
-16:16 <@Halcy0n> Alright, Diego won't be making it due to situations outside of his control.
-16:16 <@Halcy0n> What he said
-16:16  * lu_zero got him on phone
-16:16 <@jokey> oh noes
-16:16 <@Caster> :(
-16:16 <@lu_zero> tomorrow he will know for how long hopefully
-16:16 <@musikc|laptop> lu_zero, serious condition or recovering?
-16:16 <@lu_zero> unknown so far =|
-16:17  * musikc|laptop nods
-16:17 <@lu_zero> hm
-16:17 <@musikc|laptop> so crew, not to be callous, with the other two responding by 8/1 is that sufficient?
-16:18 <@lu_zero> musikc|laptop what's the subject?
-16:18 <@Halcy0n> Yes, that's fine.  lu_zero we were discussing when everyone can reply to the userrel thread.
-16:18 <@musikc|laptop> <Halcy0n> So, for item #1:  When does everyone think they can reply to the thread on council with your ideas and concerns?  Is there anything in there that you would like to note as something that needs to be clarified.
-16:18  * jokey has no questions on the thread so vote works for me
-16:18 < jmbsvicetto> musikc|laptop: 01/08/2008 for us non-USians ;)
-16:18 <@musikc|laptop> lu_zero, waiting on dertobi123 and jokey i believe
-16:19 <@musikc|laptop> jmbsvicetto, ya i speak non-us before 9am and after 5pm
-16:19 < jmbsvicetto> musikc|laptop: I had to read that three times to understand what you meant ;)
-16:19 <@musikc|laptop> ;)
-16:19 <@dertobi123> as i said, no need for discussion for me - i'm ready to vote if we want to
-16:19 <@musikc|laptop> jmbsvicetto, just gotta keep you on your toes
-16:19 <@Halcy0n> Alright, so by the next meeting (in 2 weeks) we should be ready to make a decision on that issue, correct?
-16:20 -!- Halcy0n changed the topic of #gentoo-council to: Council meeting today - July 24th 2000UTC | agenda: 1) userrel authority (decision by next meeting, council members to post by Aug 1st) 2) coc extent
-16:20 <@jokey> ++
-16:20 <@musikc|laptop> Halcy0n, do we wait two weeks when the remaining two folks said they need no more time or is it best to have them post their views first?
-16:21 < fmccor> Hard to discuss if they don't post.
-16:21 <@Halcy0n> musikc|laptop: we can make that decision before the next meeting if there seems to be outstanding issues that need further discussion.
-16:22 <@jokey> well dertobi123, any questions left or should we just vote?
-16:22 <@dertobi123> 22:20 <@dertobi123> as i said, no need for discussion for me - i'm ready to vote if we want to
-16:22 <@musikc|laptop> fmccor, not much to discuss i suppose as the thread is dead
-16:22 <@Halcy0n> Okay, then we can vote if everyone is ready.
-16:23 < fmccor> Which are you voting on, please?
-16:23 <@Halcy0n> We are still on #1.
-16:25 <@Halcy0n> So, we are voting on this single point: Does userrel have the authority to enforce the CoC on users like devrel does with developers?
-16:25 <@Halcy0n> Everyone here is ready to vote on that?
-16:25 <@Caster> ready
-16:25 <@musikc|laptop> user rel has done bans on users before, this really isnt a new precident (rbrown for example was done for a week)
-16:26  * musikc|laptop is also ready on dberkholz's behalf
-16:26 <@dertobi123> ready
-16:27  * lu_zero is ready as well
-16:28 <@Halcy0n> Okay, then lets vote:
-16:28 <@Halcy0n> Yes
-16:28 <@jokey> Yes
-16:28 <@musikc|laptop> Yes
-16:28 <@Caster> Yes
-16:29 <@lu_zero> yes]
-16:30 <@dertobi123> yes
-16:31 <@Halcy0n> Alright, so #1 has been approved.  Lets move on to #2, extent of CoC enforcement.
-16:31 -!- Halcy0n changed the topic of #gentoo-council to: Council meeting today - July 24th 2000UTC | agenda: 1) userrel authority (approved) 2) coc extent
-16:33 <@Halcy0n> This one definitely needs discussion on the lists so we can come up with some concrete proposals for the questions Donnie posted.  Would this be something everyone is able to comment on by the next meeting and we can check the status to see if everyone is ready to vote?
-16:34 <@jokey> sounds good to me, given discussion is still ongoing there
-16:34 <@lu_zero> fine as well
-16:35 <@musikc|laptop> would be nice, no one has responded to that discussion since my last post
-16:35 < fmccor> May I suggest something as well?
-16:35 <@musikc|laptop> perhaps someone on council could kick it back into discussion
-16:35 <@Halcy0n> musikc|laptop: I'll post something later tonight after I read through the most recent posts.
-16:35 <@Halcy0n> fmccor: ?
-16:36 < fmccor> One problem here is that Code of Conduct as posted is badly out of date (talks of proctors and such), and probably incomplete as well.
-16:37 <@musikc|laptop> fmccor, look up the word proctor
-16:37 <@musikc|laptop> i suspect you read it as a position and not its literal meaning
-16:37 <@Halcy0n> fmccor: this sounds like something that should be brought up in that discussion (if it hasn't been already).  I'd suggest having that conversation on the mailing list though.
-16:37 < fmccor> No, I read it as meant at the time and as implemented.
-16:37 <@musikc|laptop> "an official charged with various duties, esp. with the maintenance of good order."
-16:38 <@musikc|laptop> fmccor, you werent around for  the conversations about the chosen word, it was quite dilberate
-16:39 < fmccor> I remember that we established a proctors project, and now don't have one, and I remember discussions last year about updating it.
-16:39 <@musikc|laptop> fmccor, perhaps before we revise the CoC, we should continue the conversation about to what extent it should be enforced so we could make a single revision instead of one this week and one in two weeks
-16:40 <@Halcy0n> musikc|laptop: agreed.  Revising the CoC will likely be a part of any decision we make.
-16:40 <@jokey> so definitely defer it to ml
-16:40 < jmbsvicetto> fmccor / musikc|laptop: If by extent you include my proposal, as I've stated, it doesn't need to be directly tied to CoC
-16:41 <@dertobi123> jokey: yup
-16:41 < jmbsvicetto> fmccor / musikc|laptop: I see it as the final line for gentoo involvement, so it could be under userrel/devrel policy
-16:42 <@Halcy0n> Okay, so lets have everyone please comment on the CoC thread by next meeting and we will get a status update at that point to see if everyone is ready to vote, or if more discussion needs to take place.
-16:42 < fmccor> jmbsvicetto, More userrel, probably, because as written, your proposal (I think) does not apply to developers?
-16:42 <@Caster> Halcy0n: right
-16:42 <@jokey> ++
-16:42 <@Halcy0n> If everyone agrees to that, then we are done since that was everything on the agenda.
-16:43 <@musikc|laptop> Halcy0n, sounds good. same question as last time. do we know who has already commented and who remains?
-16:43 <@Halcy0n> musikc|laptop: looks like myself and dertobi123 were the only ones to comment.
-16:43 < wolf31o2> if anybody wants any information on the "intent" behind CoC stuff, feel free to ask me... since I was one of the primary people pushing it and was involved in all aspects of its creation, rather than listening to anyone who has only heard things "second hand" and wasn't involved...
-16:44 <@Halcy0n> wolf31o2: good to know.  We may have questions for you if anything comes up in the discussion on the mailinst list then
-16:44 <@musikc|laptop> wolf31o2, not sure. fmccor has mentioned a few times to see christel or kloeri regarding intent, ive advised that you and kingtaco really led it
-16:44 < wolf31o2> I've had fun over the last few days reading other people pushing their own ideas as if they were some kind of golden ticket to the intentions of the people involved, rather than simply *asking* said people
-16:45 < fmccor> I  had thought that last council had revised it or were going to, but I can't find the changes if they ever did.
-16:46 < wolf31o2> musikc|laptop: christel was acting as a secretary... she had no real part in the creation of it other than being present and being the one tasked with writing it and editing it... she did the first... the latter had to be reassigned to someone else because we couldn't track her down to work on it... when we finally did, she was off drinking with somebody (Astinus, I think, actually) and couldn't be bothered to participate
-16:46 <@musikc|laptop> cant that be found in CVS?
-16:46 < wolf31o2> so using her as a reference for something she barely had part of isn't exactly the best method for getting accurate responses
-16:46 < wolf31o2> ;]
-16:46 < igli> ugh
-16:47 <@Halcy0n> Alright, and with that I think we can say this meeting is adjourned :)  Thanks everyone.
-16:47 <@musikc|laptop> thanks for chairing Halcy0n :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080814-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080814-summary.txt
deleted file mode 100644
index da4b5314cc..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080814-summary.txt
+++ /dev/null
@@ -1,182 +0,0 @@
-Roll call:
-betelgeuse here
-dberkholz  here
-dertobi123 here
-flameeyes  here [cardoe]
-halcy0n    here
-jokey      here
-lu_zero    here
-
-
-Dates, or nothing to add:
-betelgeuse Monday
-dberkholz  Monday
-dertobi123 Monday
-flameeyes  Cardoe will ask
-halcy0n    Monday
-jokey      Today
-lu_zero    ??? (Having sporadic power issues)
-
-
-Unplanned topics
-================
-
-All the council members should nominate default proxies.
-
-
-New topics
-==========
-
-Reactions to dev banned from freenode
--------------------------------------
-rane:
-I'd like to ask Council to discuss possible reactions to our developer 
-being banned from Freenode without providing us with a reason. ... It 
-would be good if Council officially protested against that ban and 
-demanded a detailed explanation from Freenode staff.
-
-Q/C:
-
-20:14 <   Halcy0n@> Do we have a history of how many times this has happened?  
-                    I believe another dev was klined after this was initially 
-                    brought up.
-20:14 <    musikc > ive spoken with the second dev actually
-20:16 <    musikc > the guy said he'd done what he was told to do and was still 
-                    waiting for some resolution
-20:17 <    musikc > i last spoke to him on the 10th
-
-
-
-Moving meetings to a location we control
-----------------------------------------
-rane:
-I want Council to consider moving their meetings somewhere where third 
-parties can't control who in Gentoo can attend and who can't. Like our 
-own small and created just for this purpose IRC server.
-
-Q/C:
-
-20:26 <    Cardoe > We already have a public ML where predominately a lot of 
-                    the discussion takes place. Is there really any actual 
-                    supression occurring because of our use of Freenode?
-20:26  *    jokey is still not in favour of running an irc network
-20:27 < dberkholz@> Halcy0n: motivation is that when our devs get klined, it's 
-                    really hard for them to work with others on irc
-20:28 < dberkholz@> antarus: as i was saying earlier, freenode is a tool for 
-                    us. if that tool is getting in our way, it needs to change
-20:29 <    Cardoe > dberkholz: the question is the tool getting in our way or 
-                    hindering us. Or will devising our own tool hinder us more..
-20:30 <   Halcy0n@> Cardoe: I think us having to maintain it will be more of a 
-                    headache.
-20:30 <    Cardoe > Halcy0n: I'm in agreement with you on that.
-20:30 <dertobi123@> dito
-20:31 <     jokey@> indeed, let's discuss this there
-20:32 <    Cardoe > We have other things to use manpower on, like developing a 
-                    distribution.
-
-
-We currently have 2 freenode group contacts: fmccor and rane.
-
-
-Favor irc.gentoo.org alias in docs, etc
----------------------------------------
-rane:
-I want Council to consider creating and using irc.gentoo.org alias 
-instead of irc.freenode.net in our docs, news items and so on. The alias 
-would allow us to move out of the network more easily should we ever 
-decide to do so.
-
-Q/C:
-
-spb brought up a good point to think about.
-
-20:35 <       spb > as people connect to irc.gentoo.org and assume that 
-                    generic-sounding channel names are all about gentoo
-20:35 <Betelgeuse@> spb: And people connect to freenode and assume gentoo-java 
-                    is about generic Java
-20:37 <     jokey@> I'd say at least one user every 3-4 days over in #gentoo-php
-20:37 <Betelgeuse@> jokey: Quite common on #gentoo-java too even with the 
-                    warnings all over the place.
-
-
-Why aren't fired developers banned from the channels where they 
-displayed this behavior?
----------------------------------------------------------------
-yngwin:
-It really baffles me that some developers are forcefully retired for 
-anti-social behavior, but are not consequently banned from the places 
-where they display this behavior, such as our MLs and IRC channels. What 
-good is it to retire developers, but allow them to continue to be 
-disruptive? I would like the Council to decide for a change in our 
-policy on this point.
-
-Q/C:
-
-20:44 <dleverton_ > As I said on the list (maybe too late for anyone to have 
-                    noticed), since yngwin said there were're actually any devs 
-                    that this applies to, is there anything to discuss?
-20:45 < dberkholz@> dleverton_: i must've interpreted his response differently 
-                    from you
-20:45 <    yngwin > i didnt say it like that, dleverton_
-20:45 < dberkholz@> what i understood was that we should ban them from the same 
-                    communication channel
-20:46 < dberkholz@> and allow other ones where they handled themselves 
-                    differently
-
-spb commented that the three fired devs were actually banned from
-#gentoo-dev for quite some time.
-
-20:51 <    musikc > from a devrel perspective, we do not give voice to every 
-                    dev who is retired so why should a forcibly retired dev be 
-                    any different?
-
-20:51 <     tomaw > Is the council interested in the autodevoice feature or is 
-                    this rambling off topic?
-20:51 <jmbsvicett > tomaw: As long as we stick to freenode, -1 is something 
-                    that interests us
-
-20:52 <    Cardoe+> Standardize a policy for what happens to voluntarily 
-                    retired devs and forcibly retired devs.
-20:53 <    Cardoe+> Can we actually tweak it?
-20:53 <    Cardoe+> the council direct devrel to come up with a proposed 
-                    solution/policy
-20:55 <    musikc > dberkholz, your call. happy to assist by doing work or by 
-                    just stating current process and devrel stance :)
-
-
-PMS as a draft standard of EAPI 0
----------------------------------
-spb:
-It should be treated as a draft standard, and any deviations from it 
-found in the gentoo tree or package managers should have a bug filed 
-against either the deviator or PMS to resolve the differences.
-
-Alternatively, what (specific) changes are required to PMS before such a 
-statement can be made?
-
-Q/C:
-
-The portage devs need to commit to it. How do conflicts get resolved?
-
-20:56 < dberkholz@> we were talking about this earlier today in here
-<20:57 < dberkholz@> to quickly summarize, EAPI 0 and portage need to agree. 
-                    there are some conflicts of opinion, and the question is 
-                    how do they get resolved?
-20:58 < dberkholz@> 17:24 <   zmedico > dberkholz: mainly these two:  
-                    http://bugs.gentoo.org/show_bug.cgi?id=222721  
-                    http://bugs.gentoo.org/show_bug.cgi?id=232990
-20:58 < dberkholz@> 17:25 <   zmedico > In both cases I consider something to 
-                    be negligible that  the pms folks do not
-
-20:59 <    Cardoe+> potentially creating a PMS editor post.
-21:00 <    Cardoe+> Put it in the hands of a third party
-21:00 <    Cardoe+> and if there's a conflict, let the council decide
-
-21:01 <    musikc > dberkholz, conflict in that some feel PMS is biased?
-
-21:07 <       spb > differences will be resolved by filing a bug, so what needs 
-                    to be sorted is what sort of escalation/mediation mechanism 
-                    there is
-
-We ran past the 1-hour mark, so this is pushed back to the list. It will 
-be on the next agenda in 2 weeks if it's not resolved by then.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080814.txt b/xml/htdocs/proj/en/council/meeting-logs/20080814.txt
deleted file mode 100644
index 270cbf3143..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080814.txt
+++ /dev/null
@@ -1,430 +0,0 @@
-20:00 < dberkholz@> ok, it's time
-20:00 < dberkholz@> roll call please, who's here?
-20:00 <dertobi123@> <-
-20:00 <dertobi123@> heya btw
-20:00 -!- Irssi: #gentoo-council: Total of 72 nicks [6 ops, 0 halfops, 0 voices, 66 normal]
-20:01 <    Cardoe > Cardoe for Flameeyes
-20:01 <Betelgeuse@> yes
-20:01  *  Halcy0n is here
-20:01 < dberkholz@> jokey, lu_zero: are you here?
-20:03  * dberkhol  waits
-20:03 <   strites > hello
-20:03 < dberkholz@> jokey's been idle for almost 2 days, lu's around somewhere
-20:04 <   Halcy0n@> I just IM'd jokey
-20:04 <NeddySeago > dberkholz, just go for it, you have a quorum
-20:04 <   strites > I am here to say lu_zero's neighborhood got a black out
-20:04 <    musikc > dberkholz, i was just talking to lu and he said he has the flu atm
-20:04 <    musikc > wow, that sucks
-20:04 <      rane > flu and blackout, what a day
-20:04 < dberkholz@> apparently he's doubly excused.
-20:04 <   strites > just called me with cell
-20:04 < dberkholz@> that reminds me, we really need to get default proxies for everyone 
-20:04 <   strites > he told he'll be back asap ^^'
-20:05 <dertobi123@> can't get jokey  on his mobile phone, so yeah ... seems he's away
-20:05 <      rane > so two out
-20:05 <   Halcy0n@> dertobi123: he just answered me on IM.
-20:05 <   Halcy0n@> He's coming.
-20:05 <dertobi123@> ok
-20:06  *    jokey looks up
-20:06 <     jokey@> sorry for being late
-20:06 < dberkholz@> hopefully people had a chance to see what i suggested we should do during the meeting today
-20:07 < dberkholz@> if not, it's at the top of http://dev.gentoo.org/~dberkholz/20080814-agenda.txt
-20:07  *   musikc hands lu_zero some juice and puts him the corner away from the others :-P
-20:08 < dberkholz@> to start off, i'd like to get commitments from everyone about when you'll reply on -dev to all the agenda topics (or -council for the CoC one)
-20:08  *    jokey read the points already and formed an opinion
-20:08 <     jokey@> next hour
-20:08 <     jokey@> (given we have a meeting atm; was catching up on mails)
-20:08 < dberkholz@> i'm going to commit to monday, although i hope to get it done earlier
-20:09 -!- mode/#gentoo-council [+o lu_zero_] by ChanServ
-20:09 <dertobi123@> i can comment on the threads until end of the weekend
-20:09 <   Halcy0n@> dberkholz: I'll respond to them all by the end of the weekend.  I haven't read through everything yet since my DSL was out for 4 days.
-20:09 -!- lu_zero_ is now known as lu_zero
-20:09 <   lu_zero@> uff
-20:09 < dberkholz@> lu_zero: 20:08 < dberkholz@> to start off, i'd like to get commitments from everyone  about when you'll reply on -dev to all the agenda topics  (or -council for the CoC one)
-20:09 <   lu_zero@> I was missing thunderstorm....
-20:09 <   lu_zero@> dberkholz I'll be flickering at best
-20:10 <    Cardoe > dberkholz: I've obviously got to confer with Flameeyes on that. Not sure how much keyboard time he's got right now.
-20:10 < dberkholz@> Betelgeuse, dertobi123, jokey...
-20:10 < dberkholz@> jokey: did i understand correctly? you're going to send emails for all of them in the next hour?
-20:11 <dertobi123@> dberkholz: as i said, until the end of the weekend
-20:11 <Betelgeuse@> dberkholz: weekend is fine
-20:11 <     jokey@> dberkholz: yeah, I read up on most topics so I should be able to send them soonish
-20:11 < dberkholz@> jokey: is soonish today?
-20:11 <     jokey@> unless you have points to add that need other commenting
-20:12 < dberkholz@> yes, if there's ongoing discussion, we aren't setting a deadline on that
-20:12 < dberkholz@> just on getting your initial points out there
-20:13 < dberkholz@> lu_zero: please respond whenever you've got a reliable connection
-20:13 < dberkholz@> let's move on
-20:13 <   lu_zero@> I'll try
-20:13 -!- dberkholz changed the topic of #gentoo-council to: Reactions to dev banned from freenode
-20:14 < dberkholz@> who's got a comment or question right now?
-20:14 <   Halcy0n@> Do we have a history of how many times this has happened?  I believe another dev was klined after this was initially brought up.
-20:14 <    musikc > yes
-20:14 <    musikc > ive spoken with the second dev actually
-20:15 <dertobi123@> who's the second one and when did that happen?
-20:15 <   Halcy0n@> And is there any other informatino you can share with us in public, or is best to talk about this on council@?
-20:15 <    musikc > he's still banned but i was able to speak to tomaw and kloeri who told me what to tell him. they said all info was in the ban message but the dev indicated otherwise. no real proving that
-20:16 <    kloeri > I can confirm the info is in the ban message fwiw
-20:16 <    kloeri > or was, whatever is the case - I don't know if they kline is expired or not
-20:16 <    musikc > the guy said he'd done what he was told to do and was still waiting for some resolution
-20:17 <    Cardoe > Halcy0n: council@ is a public ML.
-20:17 <   Halcy0n@> Cardoe: not g-council, but the council alias
-20:17 <    musikc > i last spoke to him on the 10th
-20:17 <    Cardoe > Halcy0n: mm. my bad. you're right
-20:18 <KungFuJesu > ahoy
-20:18 < dberkholz@> alright
-20:18 <    musikc > the guy is on another network if council wishes to speak with him
-20:18 <    musikc > i can share info privately
-20:18 <   Halcy0n@> I know who it is and can relay whatever I get from him to the rest of you.
-20:19 <KungFuJesu > who are the "dev banned from ferenode"?
-20:19 <   Halcy0n@> I didn't connect dots :)
-20:19 <KungFuJesu > "freenode"*
-20:19 < dberkholz@> is there some particular reason we aren't mentioning whoever it is?
-20:19 <KungFuJesu > is this really a worthy discussion for the gentoo council?
-20:20 <   antarus > it was requested they talk about it
-20:20 <   Halcy0n@> dberkholz: it was ricmm.  I don't see a problem with mentioning the name since the quit message clearly said he was klined.
-20:20 <KungFuJesu > I mean, it's just an IRC related issue, why aren't we discussing gentoo?
-20:20 <   antarus > if they didn't want to discuss it they would just skip it
-20:20 <KungFuJesu > well, what was the reason he/she was banned?
-20:20 < dberkholz@> KungFuJesus: irc is a critical tool uses to do our job. if that tool is broken, it needs to be fixed. 
-20:20 <   Halcy0n@> KungFuJesus: this is a Gentoo related issue since its affecting one of our communication mediums for a dev.
-20:20 < dberkholz@> s/uses/gentoo uses/
-20:20  *   fmccor has never herd of him.
-20:21  * KungFuJe hasn't either
-20:21 <KungFuJesu > heh, probably because he can't join our IRC
-20:21 <    musikc > i dont think it matters who the dev is or if anyone heard of him fwiw, he's a dev all the same
-20:21 <   Halcy0n@> dberkholz: I will talk to him and see if he wants to share why he was banned so we can discuss the specifics.  If no one has anything else to add to this conversation point, I suggest we move on.
-20:22  * KungFuJe seconds that
-20:22 <dertobi123@> anyways, can we get the facts some of us have posted to council@, please?
-20:22 <   Halcy0n@> KungFuJesus: please, unless you have something to add, can you refrain from commenting?  Thank you
-20:22 <   Halcy0n@> dertobi123: I will find out how he wants me to share the details and let you guys know either way.
-20:22 <     tomaw > This issue was resolved on the day I was made aware of it.  The dev in question is aware of that, and the reasons for the kline.  I suggest you discuss with him to find out if he's willing to share.
-20:22 <    musikc > dertobi123, i'll share the background that i have
-20:23 < dberkholz@> i don't really have more to add on this topic. more relevant to the next ones.
-20:23 <dertobi123@> Halcy0n, musikc: thanks :)
-20:23 <     tomaw > Also, please /whois ricmm.
-20:23 <KungFuJesu > Halcy0n: Sorry, I just feel that there's not much to add as many details aren't being shared about
-20:23 <   Halcy0n@> KungFuJesus: if you have nothing to add, you don't need to say anything then, so please, consider that.
-20:24 -!- dberkholz changed the topic of #gentoo-council to: Moving meetings to a location we control
-20:24 <   antarus > Halcy0n: I think he gets the point ;p
-20:24 <   Halcy0n@> antarus: I'm not sure he does ;)
-20:24 <   lu_zero@> anyway
-20:24 <   lu_zero@> back to the topic
-20:24 <     tomaw > dberkholz: Could you just confirm my lines made it to the channel?  Noone responded :)
-20:24 < dberkholz@> tomaw: yes
-20:24 <   Halcy0n@> tomaw: yup, we saw.
-20:24 <     tomaw > Thanks.
-20:24 < dberkholz@> tomaw: we haven't +q'd you yet. =)
-20:24 <     jokey@> :D
-20:24 <       spb > wouldn't make much difference if you had
-20:24 <   markand > hi there
-20:25 < dberkholz@> anyone got a question/comment about the next topic?
-20:25 <    musikc > dberkholz, all of these topics will be discussed on lists as well so voting can take place hopefully next mtg?
-20:26 <    Cardoe > We already have a public ML where predominately a lot of the discussion takes place. Is there really any actual supression occurring because of our use of Freenode?
-20:26 <jmbsvicett > dberkholz: That issue should be discussed at the same time as having a gentoo irc network, imho
-20:26  *    jokey is still not in favour of running an irc network
-20:26 <KungFuJesu > now that I agree on, if gentoo hosts the IRC server, these problems won't happen
-20:26 <   Halcy0n@> dberkholz: I need to read all of the emails to understand what the motivation is for this, so I can't give any useful comments at this point in time.
-20:27 <KungFuJesu > honestly is there any reason to use freenode other than the fact it's easier than hosting it yourself?
-20:27 < dberkholz@> Halcy0n: motivation is that when our devs get klined, it's really hard for them to work with others on irc
-20:27 <    musikc > motivation being that devs have asked for it?
-20:27 <   Halcy0n@> musikc: I meant the reasoning behind asking for it.
-20:27 <    musikc > been a bit of dialog on the lists for that
-20:27 <   Halcy0n@> I haven't read it all yet.  I have a backlog of emails I'm still sifting through :)
-20:27 <    yngwin > also, the situation with the group contacts
-20:27 <   antarus > dberkholz: I think our devs should be motivated to not get klined ;)
-20:27 <    musikc > honestly, though wolf tried to calm it, i suspect the conversation started b/c of that incident
-20:28 <       spb > all of which can be summed up with paranoia, conspiracy theories and general storm-in-a-teacup
-20:28 <KungFuJesu > antarus: you gotta point there, I wish I knew the reason he was klined
-20:28 < dberkholz@> antarus: as i was saying earlier, freenode is a tool for us. if that tool is getting in our way, it needs to change
-20:28 <       spb > yngwin: the situation is that gentoo has two active group contacts
-20:28 <   Halcy0n@> spb: who are those 2?  I thought it was musikc and rane?
-20:28 <    musikc > spb, yes. i had to quit before that took place though
-20:28 <       spb > ferris and rane
-20:29 <   Halcy0n@> spb: oh, when was ferris added?  I thought there was quite a backlog to getting GCs added?
-20:29 <       spb > ferris was there all along
-20:29 <    musikc > Halcy0n, this morning
-20:29 <       spb > he was never properly removed
-20:29 <    Cardoe > dberkholz: the question is the tool getting in our way or hindering us. Or will devising our own tool hinder us more..
-20:29 <    fmccor > Halcy0n, Turns out I have been all along, but didn't know I was still active.
-20:29 <       spb > so when musikc left, he asked to be reactivated, as it were
-20:29 <   Halcy0n@> spb: ah, okay.
-20:29 <KungFuJesu > Cardoe: how hard could it possibly be to run an irc server?
-20:30 <       spb > ha. ha. ha.
-20:30 <   Halcy0n@> Cardoe: I think us having to maintain it will be more of a headache.
-20:30 <KungFuJesu > I understand porting some of the bots may be a pain
-20:30 <       spb > it's easy, if you have no users
-20:30 <    Cardoe > Halcy0n: I'm in agreement with you on that.
-20:30 <dertobi123@> dito
-20:30 <KungFuJesu > does irc really eat that much bandwidth?  Or are we talking about moderation issues?
-20:30 <   Halcy0n@> But, I think these are all things that we should bring up on the list to figure out what is possible.
-20:31 <   Halcy0n@> KungFuJesus: maintainence, legal issues, trolls, DoS attacks, etc
-20:31 <     jokey@> indeed, let's discuss this there
-20:31 <   Halcy0n@> There is a lot involved that we shouldn't waste the manpower on.
-20:31 <KungFuJesu > the DoS I can see as an issue, I don't know about legality, and trolls will troll
-20:31 <    yngwin > but we could still move to oftc
-20:31 <    Cardoe > Halcy0n: exactly
-20:31 <KungFuJesu > ban them when they're out of line, ignore them otherwise
-20:31 <   Halcy0n@> yngwin: that is a possibility, but again, something we should discuss on the mailing lists to see if we do indeed want to move, how many people will do so.
-20:32 <    Cardoe > We have other things to use manpower on, like developing a distribution.
-20:32 <    yngwin > sure
-20:32 <   Halcy0n@> I'd hate to see us get into a situation where half of our channels are on one networks, and half on the other.
-20:32 <jmbsvicett > Halcy0n: That has been raised in the mls
-20:32 < dberkholz@> KungFuJesus: you might want to bring up your questions on the gentoo-dev list once the meeting is over
-20:32 <   Halcy0n@> jmbsvicetto: okay, good to know :)
-20:32 <Betelgeuse@> dberkholz: -project rather
-20:33 <KungFuJesu > Halcy0n: the division of networks I can see as a huge problem, as freenode is pretty much a wild west of channels
-20:33 < dberkholz@> suppose we should try to bounce that thread over
-20:33 < dberkholz@> next topic
-20:33 -!- dberkholz changed the topic of #gentoo-council to: Favor irc.gentoo.org alias in docs, etc
-20:33 <Betelgeuse@> +1
-20:33 <   Halcy0n@> I agree with this, without even having to read anything on it
-20:33 <   lu_zero@> fine with it
-20:34 < dberkholz@> in general, i like this idea regardless of the migration thing.
-20:34 <jmbsvicett > dberkholz: We already have the dns alias and should really use it instead of irc.freenode.org everywhere
-20:34 <dertobi123@> i guess we can easily vote on that, right?
-20:34  * KungFuJe agrees
-20:34 < dberkholz@> i like it for branding reasons
-20:34 < dberkholz@> kinda like irc.gnome.org actually goes to gimpnet
-20:34 <   Halcy0n@> KungFuJesus: please, if you have something of substance to add to the conversation, do so, otherwise let us have our meeting.
-20:34 <KungFuJesu > I like it for consistency's sake, many distros follow the same trend
-20:34 <     jokey@> ++
-20:35 <       spb > experience from other networks shows that it becomes a pain in the arse for other random channels on that network, though
-20:35 <       spb > as people connect to irc.gentoo.org and assume that generic-sounding channel names are all about gentoo
-20:35 <Betelgeuse@> spb: And people connect to freenode and assume gentoo-java is about generic Java
-20:36 <       spb > less commonly
-20:37 <     jokey@> I'd say at least one user every 3-4 days over in #gentoo-php
-20:37 <     jokey@> so not that uncommon
-20:37 <   Halcy0n@> spb: is this something that has caused a lot of pain for others already?  And do you think if in our documentation we mention that Gentoo specific channels are #gentoo-* that would help?
-20:37 <Betelgeuse@> jokey: Quite common on #gentoo-java too even with the warnings all over the place.
-20:37 <       spb > it happens quite a lot on other networks i oper/admin on
-20:38 <       spb > and it wastes quite a lot of time talking completely at cross purposes before discovering what the person in question thinks he's on about
-20:38 <dleverton_ > People assuming that a #gentoo- channel is generic is pretty clearly a PEBKAC, whereas assuming that anything on irc.gentoo.org would be gentoo related seems a lot more reasonable.
-20:38 <KungFuJesu > I have seen some ubuntu-trolls come in from time to time
-20:38 <       spb > plus, someone asking a generic java question in #gentoo-java is easily recognised and easily directed elsewhere
-20:39 <    jilles > the 'independence' of a particular IRC network is rather good though
-20:39 <       spb > someone asking about how to do something on a gentoo system in a red hat channel that he thinks is a gentoo channel, on the other hand, is apt to cause massive confusion
-20:39 < dberkholz@> alright, we've got some points worth thinking about here, so we might want to hold off on an instant vote and finish it up on-list
-20:39 <   Halcy0n@> dberkholz: I agree.
-20:40 <   Halcy0n@> spb: thanks for the insight.
-20:40 < dberkholz@> thanks for bringing that up, spb 
-20:40 <     jokey@> dberkholz++
-20:40 <KungFuJesu > spb: I admit to doing this myself
-20:40 < dberkholz@> anything else new on this topic?
-20:40 <KungFuJesu > let's try to consider the IRC client, though.  If one isn't aware of what channel they're typing into this same problem will happen anyway
-20:41 <Betelgeuse@> KungFuJesus: ?
-20:41 < dberkholz@> are there many popular irc clients that don't display the channel?
-20:41 < dberkholz@> that seems a bit hard for me to grasp
-20:41 <KungFuJesu > they display it, but it's easy to forget it's there sometimes
-20:41 <  blackace > uhh, we're still talking about this?  if someone is too stupid to realize where they are, they're too stupid no matter what we do
-20:41 <Betelgeuse@> blackace: yeah exactly
-20:41 <KungFuJesu > I'm using irssi, and maybe I'm just stupid, but I've done it
-20:41 <  blackace > we should do what is best for Gentoo, not what is best for stupid people
-20:42 <   Halcy0n@> blackace: I agree, but its worth considering the impact we'll have on other users of the network.
-20:42 <Betelgeuse@> dberkholz: Some people come around to IRC via some Java applets for example and don't really know what they are doing.
-20:43 <Betelgeuse@> But that's not the point here.
-20:43 <       spb > blackace: sometimes what's best for gentoo is not pissing off the people who host services for you
-20:43 <  blackace > Halcy0n: I don't see what impact we'll have, if a gentoo user joins ##php and asks a php question, it's probably still on-topic
-20:43 < dberkholz@> yeah, i don't really think any of this part is relevant
-20:43 <KungFuJesu > spb: would freenode be angry if we left their network?
-20:43 <  blackace > spb: I don't really care
-20:43 < dberkholz@> if people type iwthout reading, then they do
-20:43 <       spb > so i noticed
-20:43 < dberkholz@> without*
-20:43 <   Halcy0n@> (random aside, its now pouring here, so if I disconnect, I lost power)
-20:43 < dberkholz@> so let's move on to the next topic
-20:43 -!- dberkholz changed the topic of #gentoo-council to: Why aren't fired developers banned from the channels where they displayed this behavior?
-20:44 < dberkholz@> anyone have a question/comment/response?
-20:44 <  blackace > isn't that kind of up to the individual channel owners except in the case of #gentoo-dev?
-20:44 <KungFuJesu > sorry for my ignorance, but what behavior?
-20:44 < dberkholz@> KungFuJesus: if you don't have the context for this discussion, you might want to sit it out
-20:44 <  blackace > KungFuJesus: the behavior that got them fired?
-20:44 <    musikc > blackace, what about the common ones like #-dev? would that be different?
-20:44 <KungFuJesu > oh I see
-20:44 <dleverton_ > As I said on the list (maybe too late for anyone to have noticed), since yngwin said there were're actually any devs that this applies to, is there anything to discuss?
-20:45 <  blackace > musikc: err, I said, except for -dev :)
-20:45 <dleverton_ > *weren't
-20:45 <    musikc > hehe, sorry blackace
-20:45 < dberkholz@> dleverton_: i must've interpreted his response differently from you
-20:45 <    yngwin > i didnt say it like that, dleverton_
-20:45 <    musikc > ive been asked about specific devs
-20:45  * dleverto will read it again.
-20:45 < dberkholz@> what i understood was that we should ban them from the same communication channel
-20:45 <   Halcy0n@> dberkholz: I will post my feedback on the thread.
-20:46 <       spb > can i just point out at this point that the majority of "evidence" presented against the three of us that were removed came from #gentoo-dev
-20:46 < dberkholz@> and allow other ones where they handled themselves differently
-20:46 <       spb > and that we were banned from there for quite some time
-20:46 <    musikc > ok, from a devrel perspective it is not a right for retired devs to automatically get voice in #-dev
-20:46 <  blackace > musikc: the only issue I see with -dev is that since they're not banned they rely on another dev voicing them and two devs could get into a +v/-v war over it
-20:46 <dleverton_ > I asked who he was referring to, aballier said "nowhere have I seen any accusation", and yngwin said he agreed (and certainly didn't ganswer my question directly).
-20:47 <    musikc > blackace, thats a recent freenode limitation
-20:47 <dleverton_ > If there is no accusation, that presumably no-one is being accused.
-20:47 <    musikc > blackace, and maybe a bot could take care of that
-20:47 <    yngwin > dleverton_: because i dont want to talk about specific cases, but about policy
-20:47 <   antarus > I used to get annoyed when spb trolled #gentoo-dev often
-20:47 <  blackace > musikc: yeah, there are more than a few ways to skin that cat :)
-20:47 <KungFuJesu > if they're fired, I can see why they shouldn't be able to speak in the *-dev channels, however if they quit on their own volition, there is a sense of welcomed experience for a veteran developer to come back and give input
-20:47 <   antarus > but I find now that I'm not on irc as much i don't care
-20:47 <dertobi123@> i think this topic belongs to the CoC discussion as its a part of that discussion
-20:48 <    fmccor > Isn't there already a policy question on this sort of thing floating around?
-20:48 <    musikc > fmccor, the policy discussion i think you refer to is the extent of CoC enforcement?
-20:49 <  blackace > if the CoC is violated, wouldn't they have already been banned prior to being fired?
-20:49 <    kloeri > musikc: I don't get your comment about a recent freenode limitation - you can ban and unvoice people if you like just as you've always been able to
-20:49 <jmbsvicett > dertobi123: I think you'll be restricting it much if you put it under CoC - it's a larger issue
-20:49 <dleverton_ > yngwin: so it's purely a hypothetical question, then?
-20:49 <    fmccor > I think so.  As I said, I'm not even sure what that iw about anymore.
-20:49 <    musikc > kloeri, tomaw knows what i refer to, long conversation about it
-20:49 <   Halcy0n@> kloeri: she means the -1 access level to automatically remove ops/voice.
-20:49 <jmbsvicett > kloeri: mode -1, iirc
-20:49  *   musikc nods and hands cookies to Halcy0n and jmbsvicetto 
-20:49 <  blackace > mind readers!
-20:50 <       spb > there is a general principle on which almost all IRC-based software is designed
-20:50 <       spb > and that is that if you don't trust someone, you don't give them operator access
-20:50 <  blackace > spb: which probably has nothing to do with this meeting
-20:50 <       spb > which makes access level -1 redundant
-20:50 <    musikc > blackace ++
-20:50 <    kloeri > there's a rather easy solution to that.. don't give +o to people that can't follow gentoo decisions and keeps removing bans and voicing people who're not supposed to be voiced
-20:50 <       spb > blackace: quite true, but then nor did the comment to which i was responding
-20:51 <   Halcy0n@> dberkholz: I think we aren't getting much here, so I suggest we bring this to the ML to discuss any points people want to bring up.
-20:51 < dberkholz@> does anyone have a new question or comment that's directly related to the topic?
-20:51 <     tomaw > Is the council interested in the autodevoice feature or is this rambling off topic?
-20:51 <    Cardoe >  ok wrangling this back on topic...
-20:51 <     tomaw > If you are then I have a simple explanation.  If not, I won't bother.
-20:51 <    musikc > from a devrel perspective, we do not give voice to every dev who is retired so why should a forcibly retired dev be any different?
-20:51 -!- mode/#gentoo-council [+v Cardoe] by Halcy0n
-20:51 <jmbsvicett > tomaw: As long as we stick to freenode, -1 is something that interests us
-20:51 <    Cardoe+> This needs to be kicked back to the list.
-20:52 <   Halcy0n@> Cardoe: agreed.
-20:52 <     tomaw > Well, I can tell you that the feature isn't present on OFTC either ;)
-20:52 <    Cardoe+> It probably even belongs in devrel's level.
-20:52 <  blackace > OFTC isn't our only option
-20:52 <     tomaw > True, but it is one, hence me mentioning it.
-20:52 <    Cardoe+> Standardize a policy for what happens to voluntarily retired devs and forcibly retired devs.
-20:52 <   Halcy0n@> This is all a bit off topic, so if we could please go back to the topic at hand.
-20:52 <  blackace > sorry :)
-20:52 <     tomaw > Halcy0n: sure, sorry.
-20:53 < dberkholz@> since nobody's adding anything on the topic, let's move on
-20:53 < dberkholz@> feel free to discuss the other stuff on -dev or wherever you like besides right here and right now =)
-20:53 <    Cardoe+> Can we actually tweak it?
-20:53 <    Cardoe+> the council direct devrel to come up with a proposed solution/policy
-20:53 <    Cardoe+> and move along
-20:53 <    musikc > Cardoe, im happy to do so
-20:54 <     jokey@> deal then ;)
-20:54 <    musikc > dberkholz, declare it an action item and im there :)
-20:54 <dertobi123@> heh
-20:54 < dberkholz@> i don't agree with having a written policy for everything
-20:54 < dberkholz@> Cardoe: i added your point to the summary, i'd like to discuss it more
-20:55 <    musikc > dberkholz, your call. happy to assist by doing work or by just stating current process and devrel stance :)
-20:55 < dberkholz@> (outside the meeting)
-20:56 <    musikc > sold!
-20:56 < dberkholz@> if there aren't any other questions/suggestions, let's move on
-20:56 <    musikc > hehe
-20:56 -!- dberkholz changed the topic of #gentoo-council to: PMS as a draft standard of EAPI 0
-20:56 < dberkholz@> we were talking about this earlier today in here
-20:56 <    Cardoe+> I'd say we're pretty close on this
-20:57 <    musikc > dberkholz, i propose taking it to the list due to discussion from prior to this meeting
-20:57 <    Cardoe+> save for the PMS guys feel one way and ${package_manager} feels another way
-20:57 < dberkholz@> to quickly summarize, EAPI 0 and portage need to agree. there are some conflicts of opinion, and the question is how do they get resolved?
-20:57 <   ciaranm > specific examples please?
-20:57 <       spb > ciaranm: --jobs breaking invariancy was one example given
-20:58 <    Cardoe+> my proposal is open a specific bug and have a specific bug at hand and let the council decide which way as far as conflict resolution.
-20:58 < dberkholz@> 17:24 <   zmedico > dberkholz: mainly these two:  http://bugs.gentoo.org/show_bug.cgi?id=222721  http://bugs.gentoo.org/show_bug.cgi?id=232990
-20:58 < dberkholz@> 17:25 <   zmedico > In both cases I consider something to be negligible that  the pms folks do not
-20:58 <   ciaranm > ah. well, the way portage does --jobs is broken. so pms is right there and someone needs to make zmedico fix portage
-20:58 <jmbsvicett > dberkholz: There must also be a way for future updates to the doc to take input from all PMs and not to be at the discretion of the current people behind PMS
-20:58 <   ciaranm > portage is breaking existing stuff in the tree, so portage is in the wrong there
-20:58 <    musikc > jmbsvicetto, makes sense
-20:58 <   ciaranm > jmbsvicetto: examples of where we've rejected input please?
-20:59 <   zmedico > ciaranm: I haven't seen any evidence to support you claims
-20:59 <    Cardoe+> potentially creating a PMS editor post.
-20:59 <   ciaranm > zmedico: it's on the bug
-20:59 <   Calchan > ciaranm, broken from whose point of view besides yours ?
-20:59 <    Cardoe+> That person can not be a developer on ANY package manager
-20:59 <    musikc > i liked Halcy0n's idea about some kind of third party work on it
-20:59 <   zmedico > ciaranm: not good enough
-20:59 <   ciaranm > Calchan: objectively broken
-20:59 <   zmedico > subjectively
-20:59 <   ciaranm > Cardoe: examples of where the current editors aren't doing well enough?
-20:59 <    Cardoe+> Halcy0n: You and I discussed this long ago
-20:59 <    musikc > dberkholz, definitely sounds like a take it to the list item
-20:59 <   Halcy0n@> Cardoe: the mediation thing?  Yes, and I brought it up again earlier :)
-20:59 <   ciaranm > zmedico: no no. causing system breakage is not subjective.
-20:59 <    Cardoe+> ciaranm: no situation where the current editors are not
-21:00 < dberkholz@> what we're trying to do here is not have a discussion, but figure out where the conflicts and questions are
-21:00 <    Cardoe+> ciaranm: It's just the logical solution.
-21:00 <   Halcy0n@> dberkholz: I think the mailing list would be best to get all of these things straightened out.
-21:00 <    Cardoe+> Put it in the hands of a third party
-21:00 <   zmedico > ciaranm: you don't have enough evidence to show it's not neglible
-21:00 <   antarus > indeed too much talking here ;p
-21:00 <    Cardoe+> and if there's a conflict, let the council decide
-21:00 <       spb > it's the logical solution based on an irrational set of premises
-21:00 <    Cardoe+> however there should be an explicit bug.
-21:00 <   ciaranm > Cardoe: i'd say the logical solution is using what's available, given limited manpower...
-21:00 <   ciaranm > zmedico: two different packages running eselect opengl to save and restore in pkg_*. b0rk!
-21:00 <    Cardoe+> fine. I'll volunteer to be the PMS editor
-21:00 <    Cardoe+> everyone can submit patches to me
-21:01 <   ciaranm > Cardoe: what are your qualifications?
-21:01 <    musikc > dberkholz, conflict in that some feel PMS is biased?
-21:01 <    Cardoe+> and when there's a specific conflict
-21:01 <   ciaranm > musikc: specific examples of bias please
-21:01 <   zmedico > ciaranm: I've never seen it happen
-21:01 <    Cardoe+> I'll create a specific bug and ask the council to decide
-21:01 <   ciaranm > zmedico: so? it can happen
-21:01 <jmbsvicett > ciaranm: What are *your* qualifications?
-21:01 <   ciaranm > jmbsvicetto: i wrote the only independent implementation of EAPIs 0 and 1
-21:01 <Betelgeuse@> Well we shouldn't be changing EAPI 0 stuff in the first place. We should be creating new EAPIs.
-21:01 <   ciaranm > jmbsvicetto: and i wrote more than half of PMS
-21:01 <    musikc > ciaranm, he asked what the conflict was and i was commenting to conversations you were not present for prior to meeting hence my previous statement of a 'take it to the list' item for further discussion
-21:01 <KungFuJesu > later
-21:01 <jmbsvicett > ciaranm: really?
-21:01 <   zmedico > ciaranm: I doubt it
-21:02 <   ciaranm > zmedico: explain how portage prevents the scenario i described frmo happening
-21:02 <   ciaranm > jmbsvicetto: really to which one?
-21:02 <jmbsvicett > ciaranm: To writting the "only independent" implementation
-21:02 <   zmedico > ciaranm: explain an upgrade scenario where it will happen
-21:02 <   antarus > ciaranm: I thinnk the answer is 'it does not' and 'he does not care'
-21:02 <   Halcy0n@> dberkholz: are we done? :)
-21:02 < dberkholz@> does anyone have a new point here?
-21:02 <   antarus > just +m the channel and get on with it ;)
-21:02 <       spb > or rather, does the council have an answer to the question that i posed?
-21:02 < dberkholz@> all i'm seeing is the same argument going back and forth
-21:03 <   lu_zero@> sigh
-21:03 <   ciaranm > jmbsvicetto: pkgcore uses a lot of portage stuff, which is why it doesn't find a lot of the issues paludis does
-21:03 <   ciaranm > zmedico: two packages do the save / restore stuff in pkg_*. portage parallelises them. splat.
-21:03 < dberkholz@> ciaranm, zmedico: could you discuss this somewhere else, please?
-21:03 <    Cardoe+> seriously. We need to hash out a proper channel
-21:04 <     jokey@> yep
-21:04 <   ciaranm > dberkholz: i'd like the council to discuss it, since zmedico is being deliberately ignorant
-21:04 <   ciaranm > in that he knows it's possible for breakage to happen, and he chooses to say "i haven't seen it so it doesn't exist"
-21:04 <    Cardoe+> dberkholz: we can legitimately discuss the two bugs that zmedico and ciaranm have pointed out.
-21:04 <   Halcy0n@> We've hit our one hour mark, so I'd like to slate this for our next meeting.  I have to call into a meeting for work right now.
-21:04 < dberkholz@> Cardoe: on the list...
-21:05 <     jokey@> Halcy0n: ++
-21:05 <Betelgeuse@> spb: Doesn't look like it.
-21:05 <       spb > somehow i'm not overly surprised
-21:05 < dberkholz@> ok.
-21:05 <    Cardoe+> spb: what was the question?
-21:05 <   ciaranm > does the current council even still consider pms a priority?
-21:05 < dberkholz@> It should be treated as a draft standard, and any deviations from it
-21:05 < dberkholz@> found in the gentoo tree or package managers should have a bug filed
-21:05 < dberkholz@> against either the deviator or PMS to resolve the differences.
-21:05 < dberkholz@> Alternatively, what (specific) changes are required to PMS before such a
-21:05 < dberkholz@> statement can be made?
-21:06 < dberkholz@> ok.
-21:06 <Betelgeuse@> In general I agree that we should push for this to get things forward.
-21:06 < dberkholz@> as Halcy0n said, we've hit the one-hour mark
-21:06 <    Cardoe+> I'd vote for that statement to be true as long as we can specify the method to resolve differences.
-21:06 <   Halcy0n@> spb: with everything going back and forth, I can't make a decision on it until we figure out how differences will be resolved and/or handled.
-21:06 < dberkholz@> so we'll push this to the list, and bring it up again in 2 weeks if we haven't gotten it resolved on-list
-21:07 <   Halcy0n@> Which seems to need further discussion.
-21:07 <Betelgeuse@> Cardoe: I would just put the council actively involved.
-21:07 <   lu_zero@> fine
-21:07 < dberkholz@> i look forward to seeing everyone's responses to all these topics on the list by monday
-21:07 <       spb > differences will be resolved by filing a bug, so what needs to be sorted is what sort of escalation/mediation mechanism there is
-21:07 <Betelgeuse@> At least something technical to talk about instead of the project stuff.
-21:07 <jmbsvicett > spb: I think there's a bit more to discuss than that
-21:08 <   ciaranm > jmbsvicetto: specifically what?
-21:08 <   Halcy0n@> dberkholz: thanks for chairing.
-21:08 < dberkholz@> feel free to continue discussion, although this meeting is over
-21:08 <jmbsvicett > specifically that the document doesn't reflect what the authors want to reflect instead of what is the reality or what people around gentoo want it to reflect
-21:08 < dberkholz@> and please post anything important to the list
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080828-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080828-summary.txt
deleted file mode 100644
index 2bd1887eae..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080828-summary.txt
+++ /dev/null
@@ -1,91 +0,0 @@
-Roll call
-=========
-betelgeuse here
-dberkholz  here
-dertobi123 here
-flameeyes  here [cardoe]
-halcy0n    here
-jokey      here
-lu_zero    here
-
-
-Old topics
-==========
-
-Reactions to dev banned from freenode
--------------------------------------
-Update: none. Assume lack of interest.
-
-
-Moving meetings to a location we control
-----------------------------------------
-Update: none. Assume lack of interest.
-
-
-Favor irc.gentoo.org alias in docs, etc
----------------------------------------
-Update: Freenode acknowledgments page thanks people for doing this, so 
-the potential issue with confusion apparently isn't a large problem.
-
-Goal: Can we decide today?
-
-Decision: Update all our pointers to IRC to use irc.gentoo.org. (But 
-please mention FreeNode is our provider.)
-
-
-Why aren't fired developers banned from the channels where they
-displayed this behavior?
----------------------------------------------------------------
-Update:
-
-For banning from those channels: halcy0n, dertobi123 (on gentoo-dev)
-No opinions from the rest of us
-
-Goal: Get yes or no on banning from the same channels. If no, ask for 
-alternate suggestions if there are any. (Example: let devrel decide)
-
-Summary: halcy0n, dertobi123, lu_zero think fired devs should be banned 
-from the places where they behaved in the way that got them fired. 
-dberkholz and cardoe think that this should be handled by devrel and 
-council shouldn't set policy on it. halcy0n later agreed with letting 
-devrel address it, as did lu_zero and betelgeuse.
-
-
-PMS as a draft standard of EAPI 0
----------------------------------
-What changes are required before this is true?
-
-Update: The main thing that needs to get figured out is conflict 
-resolution.
-
-Idea: Ask portage devs & PMS authors to develop a process that both 
-groups will respect, then present it to the council for approval. 
-Options include a "neutral" third party as PMS czar, having council 
-decide, just trying harder to come to agreement, deciding that e.g. 
-portage's choice always wins, random, etc.
-
-spb and ciaranm agree that a third party or council would work well. 
-Since such a third party would probably be better invested in actually 
-working on the spec, the council seems reasonable if PMS editors & PM 
-developers can't work it out.
-
-20:46 < dberkholz@> zmedico, ferringb, ciaranm, spb: so you'll all agree to 
-                    follow council decisions on conflicts you aren't able to 
-                    resolve otherwise?
-20:46 <   zmedico > dberkholz: I agree
-20:47 <  ferringb > dberkholz: either way, game to attempt something different- 
-                    what's in place doesn't particularly work imo
-20:47 <   ciaranm > dberkholz: so long as the council's prepared to follow 
-                    through with its resolutions
-20:49 <  ferringb > either way, council as arbitrator flies.
-
-Decision: Council will vote to resolve conflicts that the PMS editors 
-and PM developers weren't able to resolve.
-
-zmedico, ferringb & ciaranm (developers of each PM) all agree that 
-having a written specification is worthwhile.
-
-Next meeting is Sept 11, and we request that everyone involved with PM 
-development or the spec email gentoo-dev about any issues with it. 
-Otherwise, it's likely to be approved as a draft standard.
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080828.txt b/xml/htdocs/proj/en/council/meeting-logs/20080828.txt
deleted file mode 100644
index b731ee8f50..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080828.txt
+++ /dev/null
@@ -1,310 +0,0 @@
-19:56 < dberkholz@> are folks around?
-19:56 <   lu_zero@> \o/
-19:56 < dberkholz@> if it starts to get out of hand like last time, i'm gonna have to +m it.
-19:56 -!- Irssi: #gentoo-council: Total of 59 nicks [6 ops, 0 halfops, 0 voices, 53 normal]
-19:58 <Betelgeuse@> dberkholz: yes
-20:00  * dertobi1 is around
-20:00 < dberkholz@> ok, it's 2000
-20:00 -!- mode/#gentoo-council [+v Cardoe] by dberkholz
-20:01  *    jokey looks up
-20:01 < dberkholz@> Halcy0n: ping
-20:02 < dberkholz@> we've got 6, let's get started. hopefully he shows up in the next few min
-20:02 <   Halcy0n@> Present :)
-20:02 < dberkholz@> oops, never actually saw Cardoe respond
-20:03 <    Cardoe+> I'm here
-20:03 < dberkholz@> ok
-20:03 < dberkholz@> agenda's in /topic if anyone hasn't had a chance to look it over
-20:03 <    Cardoe+> Was just zoned out staring at the wall waiting for the meeting to begin :-D
-20:03 < dberkholz@> sorry for the delay in getting it out, i've got a lot on my mind
-20:04 < dberkholz@> (new baby showing up in a few days)
-20:04 <     jokey@> congrats ;)
-20:04 -!- dberkholz changed the topic of #gentoo-council to: Favor irc.gentoo.org alias in docs, etc
-20:04 <   lu_zero@> I think we are all fine with this
-20:04 < dberkholz@> so, folks on -dev pointed out that apparently freenode folks like when other domains point to them
-20:04 <   lu_zero@> (congrats btw)
-20:04 <   Halcy0n@> congrats :)
-20:04 <Betelgeuse@> dberkholz: congrulations/condolences
-20:05 < dberkholz@> heh, that's more accurate, no doubt.
-20:05 <   Halcy0n@> I think we are ready to vote on this one.
-20:05 <Betelgeuse@> yes
-20:05 < dberkholz@> yes
-20:05 <Betelgeuse@> and yes
-20:05 <dertobi123@> yes
-20:05 <    Cardoe+> I was ready last week.. ;)
-20:05 <    Cardoe+> yes
-20:06 <     jokey@> yes
-20:06 <     jokey@> :D
-20:06 <   Halcy0n@> yes
-20:06 < dberkholz@> cool
-20:06 -!- dberkholz changed the topic of #gentoo-council to: Why aren't fired developers banned from the channels where they displayed this behavior?
-20:07 <Betelgeuse@> I don't think banning is necessary if the behaviour in question was misusage of power.
-20:07 < dberkholz@> Halcy0n & dertobi123 already replied on -dev saying they think fired devs should be banned from that place
-20:07 <     jokey@> same here
-20:07 <   lu_zero@> +1
-20:07 < dberkholz@> my opinion is that devrel should decide
-20:07 <       spb > the obvious answer is that they should be banned from any place where they've shown behaviour that would get any normal person banned
-20:08 <Betelgeuse@> I agree with spb.
-20:08 < dberkholz@> and if anything, we should just say devrel (or whoever's in charge of a certain place) has the right to do so
-20:08 <       spb > and, therefore, not from any place where they haven't
-20:08 <   Halcy0n@> spb: I think that's what I was trying to say, if I didn't word it in that exact way. :)
-20:08 <    Cardoe+> dberkholz: as I suggested last week. empower devrel to make the proper decision and to create a policy on this.
-20:08 <       spb > given that, i don't really see what being fired has to do with it
-20:09 <   Calchan > I don't agree, they've shown inapropriate behavior, the place doens't matter, they could have done it anywhere
-20:09 < dberkholz@> that's beyond the scope of this topic, which is a bit more focused
-20:09 <dleverton_ > So now we're punishing people for what they "could" have done?
-20:10  * musikc|l is back
-20:11 <musikc|lap > "saying they think fired devs should be banned from that place" +1
-20:11 <    Cardoe+> dberkholz: so what's the formal question asked of the council.. cause why isn't something for the council to answer since the council doesn't do the banning
-20:11 <    Cardoe+> devrel does
-20:11 <musikc|lap > Calchan, do you think a fired dev should be banned from all channels? not sure i understand and want to clarify
-20:12 <    Cardoe+> so the question should be why don't we empower devrel to establish a policy and enforce it
-20:12 <      rane > devrel or userrel?
-20:12 <   Calchan > musikc|laptop, the problem is the behavior, not the channel
-20:12 <Betelgeuse@> Cardoe: I don't think we need to be handling fired devs any different from other users.
-20:12 <   antarus > Calchan: I disagree; the day the coucil says I have to ban a user from a channel I own is the day I resign
-20:12 <musikc|lap > Calchan, that makes sense but no one team has the authority unless council opts to grant it to control every #gentoo-*
-20:13 <Betelgeuse@> If our policies on banning users aren't clear then they can be improved.
-20:13 <    Cardoe+> Betelgeuse: and that policy is to have userrel have a policy and enforce it
-20:13 <   antarus > s/says/forces/
-20:13 <   antarus > they are free to make a compelling argument for a ban of course ;)
-20:13 <musikc|lap > Cardoe, i think it depends actually
-20:14 <musikc|lap > if the dev is being fired for a certain behavior such as inappropriate channel behavior, perhaps devrel is being asked why we dont automatically remove them from that channel, or as Calchan points out all channels.
-20:14 <musikc|lap > if its a former dev who later exhibits that behavior it's totally user rel
-20:14 <       spb > the most obvious response to which is that it's up to the channel owners who they allow in their channels
-20:15 <musikc|lap > spb, see my previous comment about how no one team has that authority currently
-20:15 <   ciaranm > in the same way that a gentoo developer spamming one irc channel is removed from all of freenode, you mean?
-20:15 <dleverton_ > musikc|laptop: the authority to let channel owners decide how to run their channels?
-20:15 < dberkholz@> this clearly has the potential to run forever, so let's set a 15-minute time limit on discussion here.
-20:15 < dberkholz@> starting now
-20:15 <musikc|lap > dleverton_, im merely stating that no one team has absolute authority in every channel
-20:15 <   Calchan > antarus, the question is should you own an official gentoo channel or should gentoo own it ?
-20:16 <musikc|lap > dberkholz, can you define if the question pertains to only certain channels or all?
-20:16 <   antarus > Calchan: perhaps gentoo should trust its developers to make good choices ;)
-20:16 <musikc|lap > Calchan, Gentoo owns it. when someone leaves the project the channel is handed over to another person, not left with ownership to the previous
-20:16 <       spb > Calchan: and gentoo's policy has long stated that individual teams and/or developers own and run their channels
-20:17 < dberkholz@> musikc|laptop: the question is pretty specific. it's just banning from the place where they showed that kind of behavior
-20:17 <musikc|lap > dberkholz, then perhaps we should stick to just that question for now.
-20:17 <       spb > dberkholz: in which case it's up to the channel owner to decide what sort of behaviour warrants a ban from that channel
-20:17 <       spb > that seems fairly obvious to me
-20:17 <musikc|lap > i agree that if the person is removed from gentoo for such behavior that we should remove them from that channel
-20:18 < dberkholz@> each irc channel isn't a separate organization, though. we're all part of gentoo
-20:18 <musikc|lap > dberkholz, so you want to change the question to apply to all channels then?
-20:18  * blackace doesn't see the issue, if they get fired for misbehaving somewhere they were probably removed from that somewhere before being fired, if they then misbehave somewhere else as a user, ban them from there, and so on...
-20:18 <       spb > and each channel is part of freenode, but we know enough to leave management of them to the channel owner
-20:18 < dberkholz@> i'm still trying to figure out the best way to go. i'm just making some points
-20:18 <      rane > it's unrealistic to ban a person in all #gentoo-* channels
-20:18 <dleverton_ > Can we define what exactly we mean by "channel"?  IRC, or more general?
-20:19 <musikc|lap > spb, a channel owner owns the channel as granted by Gentoo. otherwise it wouldnt be an official Gentoo channel
-20:19 < dberkholz@> more general for the whole topic -- a mailing list, the forums, etc
-20:20 <jmbsvicett > One point that has been raised is whether the council want to treat ex-devs differently from other users
-20:20 <jmbsvicett > If not, devrel doesn't deal with users.
-20:20 <     jokey@> the only difference is that they get auto+v in #-dev afaik
-20:20 <musikc|lap > jmbsvicetto, i think the topic is upon removing them, not later. if it's later then its definitely not a dev rel issue and they should be treated as any user
-20:21 <musikc|lap > jokey, devrel doesnt grant +V to everyone, first they must ask and second it must be approved
-20:21 <jmbsvicett > musikc|laptop: I understand. Another question is if we're talking about #gentoo-dev, #gentoo or specific projects channels
-20:21 <dertobi123@> dberkholz: i disagree, if this topic would be about lists, forums, #gentoo-* we're back at the "total ban from gentoo" discussion
-20:22 < dberkholz@> dertobi123: not really. it's just saying that banning from a specific place applies equally to a single irc channel or a single mailing list.
-20:22 <musikc|lap > jmbsvicetto, the question per dberkholz's explanation is for just #-dev but the discussion could include thoughts on all mediums and channels
-20:22 < dberkholz@> we're not at all addressing right now whether people should be additionally banned from other places
-20:23 <musikc|lap > council, so to the question at hand, only dberkholz and Halcy0n have shared their views. any others?
-20:23 < dberkholz@> dertobi123 did too, on list. =)
-20:23 <dertobi123@> yep
-20:24 <   lu_zero@> and I just said that I agreed
-20:24 <    Cardoe+> my opinion is that it should be up to devrel
-20:24 <dertobi123@> it's a logical step to ban someone from a place where he showed misbehaviour
-20:24  * musikc|l agrees
-20:24 <jmbsvicett > musikc|laptop: If it's #gentoo-dev, then I think it's up to devrel
-20:24 <dertobi123@> i don't see what needs to be discussed there besides the way of the how this if enforced
-20:25 <musikc|lap > dertobi123, how about enforced upon removal?
-20:25 <   Halcy0n@> I'm fine with just saying that this is up to devrel to decide on their policy and if someone wishes to question that policy, we address it at that point in time.
-20:26 <musikc|lap > Halcy0n, im ok with that. however id hope if someone wants to discuss a devrel policy they discuss it with ... you know... devrel first
-20:26 <dertobi123@> musikc|laptop: ack. it should be part of the retirement process from my pov (except when the person in question already has been banned from this places)
-20:26 <     jokey@> ++
-20:26 <musikc|lap > dertobi123, +1
-20:27 <    Cardoe+> seems like there's a reasonable consensus.... now on to technical things..
-20:28 <musikc|lap > agreed, ill work with rane and jmbsvicetto to hammer out any details from a devrel pov and we'll run it through the rest of devrel for feedback
-20:28 < dberkholz@> we haven't gotten agreement from a council majority on that
-20:28 < dberkholz@> that's me, Cardoe, Halcy0n 
-20:28 <musikc|lap > haha, sorry!
-20:29 < dberkholz@> lu_zero hasn't agreed & i'm not entirely clear on dertobi123 
-20:29 <musikc|lap > <Cardoe> my opinion is that it should be up to devrel
-20:29 < dberkholz@> Betelgeuse is probably eating popcorn
-20:29 <Betelgeuse@> :D
-20:29 <Betelgeuse@> I really should by some.
-20:29 <    Cardoe+> dberkholz: are you waiting on me?
-20:29 <   lu_zero@> dberkholz I consider it part of the retirement process
-20:29 < dberkholz@> Cardoe: nope
-20:30 < dberkholz@> lu_zero: ok, so you're fine with devrel deciding how to handle it?
-20:30 <musikc|lap > Cardoe, i was just posting your comment as it was the shortest one to sum it all up :)
-20:30 <   lu_zero@> dberkholz it's devrel task to retire people
-20:30 < dberkholz@> i'll take that as a yes
-20:30 <Betelgeuse@> I think it probably should be in the retirement process if the question is being retired due the continuing bad behaviour.
-20:31 <Betelgeuse@> s/probably//
-20:31 < dberkholz@> ok. now it indeed does seem that we've reached agreement
-20:31 < dberkholz@> right on time, too
-20:31 <musikc|lap > ;)
-20:31 <   lu_zero@> good
-20:32 -!- dberkholz changed the topic of #gentoo-council to: PMS as a draft standard of EAPI 0: Conflict resolution
-20:32 <    fmccor > How far back does this go?  Would you ban someone fro #gentoo-dev, say, today for something that happened 2 years ago?
-20:33 <    fmccor > That strikes me as silly.
-20:33 < dberkholz@> devrel's making the policy
-20:33 < dberkholz@> discuss it amongst yourselves =)
-20:33 < dberkholz@> we're talking about EAPI 0
-20:33 <Betelgeuse@> fmccor: The retirement process is done for those people as far as I am concerned.
-20:34 < dberkholz@> ok, the main thing we came up with last meeting on PMS is figuring out how to handle conflict resolution
-20:34 <Betelgeuse@> I vote that we start voting on issues one by one.
-20:34 <   lu_zero@> ?
-20:34 < dberkholz@> i tossed some ideas into the agenda
-20:35 <Betelgeuse@> Bugzilla should work as a platform.
-20:35 < dberkholz@> Betelgeuse: "we" being council?
-20:35 <   ciaranm > i didn't see the promised "we'll mail the list with opinions" emails for this. where should i have been looking?
-20:35 <Betelgeuse@> dberkholz: yes
-20:35 <    Cardoe+> I had suggested (but not mentioned on the ML yet) that a 3rd party is appointed by the council to be the "merge master" to merge in changes to the PMS. When a conflict arises, the merge master will attempt to work with the parties involved and the issue resolved. If no resolution can be easily reached, the issue is referred to the council who will direct the merge master which way to go.
-20:35 < dberkholz@> ciaranm: yeah, that was full of fail.
-20:35 <   ciaranm > heh, fairy nuff
-20:36 < dberkholz@> i threw the idea i just thought of into the agenda
-20:36 < dberkholz@> which is asking PMS & portage devs to come up with a process for conflict resolution that they both agree to follow
-20:36 <   Halcy0n@> I think I hit all of the topics except this on the mailing list because I wanted to put some thought into it.  I have some ideas that I need to write up and I want to see discussed though.
-20:37 < dberkholz@> seems like everyone might be happier going along with a process you came up with yourselves
-20:37 <Betelgeuse@> dberkholz: but is that likely to happen?
-20:37 <   ciaranm > part of the problem with conflict resolution is what to do when portage makes non-EAPIed changes that break lots of existing packages
-20:37 < dberkholz@> and i tried to put some ideas out there for what that process might be
-20:37 < dberkholz@> but i think agreement has to begin with the involved people
-20:37 <       spb > ciaranm: you file a bug, and it gets marked WONTFIX
-20:37 <musikc|lap > ciaranm, wouldnt that not be part of the problem but the main reason being when any PM does that?
-20:37 <   lu_zero@> ciaranm do you have a list?
-20:38 < dberkholz@> we were talking about the list last meeting and wasted a lot of time on details that aren't relevant to us
-20:38 <   ciaranm > musikc|laptop: you could argue that, yes
-20:38 <   ciaranm > lu_zero: er, phase order changes and --jobs are the canonical examples
-20:38 <       spb > lu_zero: --jobs and phase ordering changes will do to start with
-20:38 <musikc|lap > ciaranm, just seems to be the basis for a need for a conf res
-20:38 <   lu_zero@> a list of ebuilds
-20:38 <   lu_zero@> anyway unrelated to the current topic
-20:39 < dberkholz@> ciaranm & spb: while you're here, do you have any good ideas for the resolution process?
-20:39 <Betelgeuse@> lu_zero: It's not totally unrelated.
-20:39 <   ciaranm > dberkholz: i've yet to get anything out of zac that isn't "i'll do whatever i want with portage, even if it breaks existing ebuilds and even if it goes completely against the gentoo documentation"
-20:39 <dleverton_ > lu_zero: no-one can know which ebuilds are broken without carefully examining the entire tree.
-20:40 <       spb > dberkholz: the most obvious is if some person can be found with enough knowledge of the problems in question to act as a sensible arbitrator
-20:40 <   ciaranm > dberkholz: really, "throw anything we can't agree upon to the council" would be fine, if i get assurances that the council will override zac if he does something stupid, and that the council will step in if zac decides to ignore PMS anyway on something the council's decided upon
-20:40 <Betelgeuse@> ciaranm: I am willing to do that.
-20:40 <       spb > unfortunately most such people that i can think of are already working on pms, so the next option is just to refer disputes to the council
-20:41 < dberkholz@> ok, basically the first two mentioned in the agenda
-20:41 <   ciaranm > the problem with resolving conflicts is that anything we do currently that isn't "whatever zac says, even if it means breaking lots of existing packages" gets turned into "pms has to document what portage does, for some random version of portage that most people aren't using"
-20:41 <   ciaranm > which i don't see as being a sensible way of getting things done
-20:41 <       spb > even when that contradicts the version of portage that people are using
-20:42 <musikc|lap > dberkholz, it seems that the suggestion of neutral third party for PMS sounds sane since ciaranm continually points out his concerns with working with zac
-20:42 < dberkholz@> yes, we clearly need zac, genone, and anyone else to buy into whatever the process is
-20:42 <   ciaranm > do we even need a neutral third party? the volume of things where there are conflicts is probably low enough not to overload the council
-20:42 <Betelgeuse@> musikc|laptop: I don't really see how a gentoo dev would be totally neutral.
-20:42 <   ciaranm > it'll give you a technical topic to discuss every other month or so if nothing else :P
-20:42 <     ferdy > musikc|laptop: how does a 'neutral' (who decides upon neutrality?) person help there?
-20:43 <   ciaranm > also, if we had a neutral person to spare, their time could be better spent contributing content
-20:43 < dberkholz@> i agree, actually. i think the council is a pretty reasonable group to do this
-20:43 <   lu_zero@> looks like at least some like the idea to have the council handle conflicts
-20:44 <musikc|lap > what about having non PM's work on the PMS doc so it reflects the opinions of the community?
-20:44 <   ciaranm > make that "have the council handle conflicts if the pms editors can't sort it out"
-20:44 <   lu_zero@> zmedico and ferringb is that ok for you as well?
-20:44 <   ciaranm > musikc|laptop: there shouldn't be opinion in pms
-20:44 <   zmedico > lu_zero: seems fair enough to me
-20:44 <musikc|lap > ciaranm, a standard is a collection of opinions put to 'law' as it were
-20:44 <   ciaranm > musikc|laptop: and we've never rejected a patch (except "resend with this fixed", which has always happened) from non PM people
-20:44 <       spb > musikc|laptop: frankly, the opinion of the community is irrelevant to a purely technical document
-20:44 <musikc|lap > spb, depends on who the community is imo
-20:45 <       spb > it documents existing behaviour
-20:45 <       spb > there's no room for opinion in that
-20:45 <   ciaranm > the problem with asking the community is that people say what they think *should* happen, which isn't what pms is dealing with
-20:45 <musikc|lap > spb, if it documents existing behavior then existing behavior of which PM?
-20:45 <   ciaranm > pms has to deal with what *does* happen wherever possible
-20:45 <  ferringb > lu_zero: what, punting up to council?
-20:45 < dberkholz@> ferringb: yeah
-20:46 <   ciaranm > what *should* happen is "future EAPI" territory
-20:46 <       spb > musikc|laptop: the best compromise that can be made between all vaguely recent portage versions and the tree
-20:46 <  ferringb > dberkholz: not sure you'll like the volume, going by past disagreements tbh.  things may've changed (these days I stay out of orbit) however.
-20:46 < dberkholz@> zmedico, ferringb, ciaranm, spb: so you'll all agree to follow council decisions on conflicts you aren't able to resolve otherwise?
-20:46 <       spb > where vaguely recent means "is likely to be in use by someone somewhere, or was stable some time in the last six months to a year"
-20:46 <   zmedico > dberkholz: I agree
-20:47 <  ferringb > dberkholz: either way, game to attempt something different- what's in place doesn't particularly work imo
-20:47 <   lu_zero@> ferringb do you have alternative proposals?
-20:47 <   ciaranm > dberkholz: so long as the council's prepared to follow through with its resolutions
-20:47 <   ciaranm > ferringb: please provide a list of patches of yours that we've rejected
-20:48 <musikc|lap > ciaranm, or could you provide a list of packages you accepted? might be just as easy :)
-20:48 <musikc|lap > s/packages/patches
-20:49 <       spb > that's only meaningful when compared to the list of patches that were submitted
-20:49 <Betelgeuse@> musikc|laptop: I can say for myself that I havent' had problems getting my patches in.
-20:49 <  ferringb > ciaranm: past discussions
-20:49 <   ciaranm > musikc|laptop: we've accepted (sometimes after asking for revisions) every patch that's been sent
-20:49 <  ferringb > ciaranm: not much point in pushing a patch up if it's already estabilished it has zero chance of getting in w/ folk in control.
-20:49 <musikc|lap > ciaranm, just saying either party could validate
-20:49 < dberkholz@> ok
-20:49 <   ciaranm > musikc|laptop: well, i've rejected exactly zero of ferringb's contributions so far
-20:49 <  ferringb > either way, council as arbitrator flies.
-20:50  * ferringb sighs; now we're getting into word play re: definition of 'contributions'
-20:50 <   lu_zero@> looks like this topic could be voted on
-20:50 <     jokey@> better do not do it here and now
-20:50 <     jokey@> lu_zero++
-20:50 < dberkholz@> ok, we've gotten people from all the groups to buy in
-20:51 < dberkholz@> it's definitely worth trying something new, and if this doesn't work, we can try to make the whole neutral person thing work
-20:51 < dberkholz@> i'm for it
-20:51 <dertobi123@> let's give it a try and see if that process works
-20:51 <dertobi123@> so yes
-20:52 <   lu_zero@> anybody against?
-20:52 <musikc|lap > so council will vote on any conflicts that arise from the PMS not being followed?
-20:52 <    Cardoe+> might as well just do a formal yes so no one says someone was asleep at the wheel.
-20:52 <   ciaranm > does this also mean we're taking pms as being definitive except where there're disagreements? which was the original question, really
-20:53  * ferringb notes management of pms vs it being definitive are two seperate questions
-20:53 <jmbsvicett > If that's the case, then perhaps it would be a good idea to have people mail their disagreements so they can be worked out
-20:53 < dberkholz@> you're right, that was the original question
-20:54 <musikc|lap > ferringb, yes that makes sense to me as well
-20:54 <    Cardoe+> ciaranm: I'd say yes
-20:54 <   lu_zero@> but isn't what's on topic...
-20:54 <       spb > ferringb: and when the original question was put to the council last time around, the answer that i can recall was that what still needed sorting out was a conflict resolution method
-20:54 <musikc|lap > we're well past the 15 minutes, will council be voting on the conf res process or should that wait 2 weeks?
-20:54 <   lu_zero@> could we just close one and move to the other ^^?
-20:54 <Betelgeuse@> Cardoe: yes
-20:54 < dberkholz@> ok. conflict resolution is handled
-20:55 -!- dberkholz changed the topic of #gentoo-council to: PMS as a draft standard of EAPI 0: Other issues?
-20:55 <musikc|lap > dberkholz, not to be confused with management of PMS as ferringb pointed out?
-20:55 < dberkholz@> we have about 5 minutes, so just bring up anything that's holding it back and we won't try to discuss it now
-20:56 <musikc|lap > i dont think anyone agrees, or if so i apologize for forgetting, that it is good to have a package manager standard. just how that is managed seems to be in disagreement.
-20:56 <  ferringb > musikc|laptop: think you screwed up your phrasing there
-20:56 <   zmedico > s/agrees/disagrees/
-20:56 <musikc|lap > hahah
-20:56 <musikc|lap > yes and yes
-20:57 < dberkholz@> so ferringb & zmedico think having a standard is worthwhile. that's accurate, yes?
-20:57 <  ferringb > dberkholz: I'd add a few adjectives in there, but yes
-20:57 < dberkholz@> and by standard i mean a written spec
-20:57 <   zmedico > yes, it's useful
-20:58 < dberkholz@> since we've had some vague discussions in the past about that, so i'm glad all the relevant people are on the same page
-20:58 <   lu_zero@> still I have concern of the form of the spec
-20:58 <   ciaranm > lu_zero: specifics please?
-20:58 <   lu_zero@> ciaranm in short?
-20:58 <   ciaranm > lu_zero: something concrete so i can say either "yes, we can improve that" or explain why i think it's correct the way it is
-20:58 <   lu_zero@> an article/scientific paper isn't a spec, an rfc comes closer
-20:59 <   Halcy0n@> We are about to hit 5pm, and I have a meeting right now (at work), so I must run.
-20:59 <   ciaranm > the reason we're not writing it to rfc standards is that we don't have the manpower to produce a loophole-free spec
-20:59 <   ciaranm > i'd take patches to rephrase individual sections to be more watertight if people think they can do it
-20:59 <musikc|lap > dberkholz, meeting officially wraps up on the hour, correct?
-21:00 < dberkholz@> zmedico, ferringb: i'd really love to see emails from you and any other PM developers describing what you think about PMS being a draft standard of EAPI 0.
-21:00 <   ciaranm > but producing a spec that can't be deliberately misinterpreted would take a hell of a lot longer than producing one that assumes a sensible and cooperative reader
-21:00 <       spb > and there's little point making it utterly free from loopholes when there's a well defined process for handling disagreements
-21:00 <   lu_zero@> ciaranm I recall I asked abnf sections
-21:00 < dberkholz@> we need to wrap up now
-21:00 <   ciaranm > lu_zero: abnf ends up being less readable than the written form
-21:00 <NeddySeago > ciaranm there is no such thing as a loophole-free spec, someone sometime will always find a meaning that was not intended
-21:00 <   lu_zero@> but is machine parsable
-21:01 <   lu_zero@> and it's quite easy get a checker out of it
-21:01 < dberkholz@> zmedico, ferringb: there's already the existing thread on gentoo-dev for the last council meeting, so you can just reply there
-21:01 <   ciaranm > NeddySeagoon: 'loophole-free' is what ISO aims for
-21:01 <       spb > NeddySeagoon: which is precisely why we're not trying to write one
-21:01 <NeddySeago > ciaranm Yep ... its a good aim
-21:01 <   ciaranm > lu_zero: the problem is, a grammar for specs ends up being very very horrid
-21:01  * musikc|l also has a RL meeting now
-21:01 <   lu_zero@> ciaranm rfc2234 isn't _THAT_ ugly
-21:01 <musikc|lap > verifying this one is done?
-21:01 <    Cardoe+> now we're arguing semantics
-21:02 < dberkholz@> it's past 2100, so the meeting is over. everyone with a stake in the spec really needs to email -dev about any issues with it becoming a draft standard
-21:02 <  ferringb > dberkholz: presume 2 week window or so?
-21:02 <   ciaranm > lu_zero: try, say, iso c++ draft n2723 section 14.7 if you want an example of just how bad formal specs get
-21:02 < dberkholz@> we'll resume at the next meeting and approve it unless there are objections between now and then
-21:02 <jmbsvicett > If there's an agreement about EAPI-2 in the mls prior to the next council meeting, will you be willing to vote on it?
-21:02 < dberkholz@> that'll be ... sept 11
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080911-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080911-summary.txt
deleted file mode 100644
index 849b0c7753..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080911-summary.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-Roll call
-=========
-betelgeuse here [calchan]
-dberkholz  here
-dertobi123 here
-halcy0n    here
-jokey      slacker
-lu_zero    slacker
-
-
-First
-=====
-
-Filling the empty slot
-----------------------
-Last time there was an empty slot, we voted on whether to fill the slot 
-with the next person from the original rankings. Let's do the same this 
-time. It's Cardoe.
-
-Goal: Vote whether to approve Cardoe for the empty council slot.
-
-Result: Cardoe is a new council member.
-
-
-Old topics
-==========
-
-PMS as a draft standard of EAPI 0
----------------------------------
-Next meeting is Sept 11, and we request that everyone involved with PM 
-development or the spec email gentoo-dev about any issues with it. 
-Otherwise, it's likely to be approved as a draft standard.
-
-Goal: Vote whether to approve PMS as a draft standard of EAPI 0.
-
-Requirements:
-
-  - There needs to be a PMS lead who is a Gentoo dev [calchan].
-    Both cardoe & antarus volunteered if this was needed.
-  - Document the conflict resolution process that we agreed upon last 
-    week [calchan].
-  - Document the patch acceptance process [halcy0n].
-  - Create a public mailing list so discussions & patches aren't lost on 
-    the pms-bugs alias [cardoe].
-
-Result: PMS is a draft standard of EAPI 0, with acceptance conditional 
-upon resolution of the above 4 requirements. They should be resolved 
-within 2 weeks.
-
-
-New topics
-==========
-
-None.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080911.txt b/xml/htdocs/proj/en/council/meeting-logs/20080911.txt
deleted file mode 100644
index 8885430c35..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080911.txt
+++ /dev/null
@@ -1,317 +0,0 @@
-20:00 <   Halcy0n@> Alright, so roll-call...who is here?
-20:01 -!- mode/#gentoo-council [+v Cardoe] by Halcy0n
-20:01 <dertobi123@> <-
-20:02  *  Calchan is proxying for Betelgeuse 
-20:02 -!- mode/#gentoo-council [+v Calchan] by Halcy0n
-20:02 <   Halcy0n@> Yup, saw the email earlier as well.  Thanks
-20:02 <dberkholz|@> here
-20:03 <   Halcy0n@> jokey or cardoe?
-20:04 <    Cardoe+> sorry
-20:04 <    Cardoe+> Halcy0n: technically I'm not on the roll call yet since Diego resigned so I'm not officially taking his position
-20:05 <    Cardoe+> Halcy0n: and you guys have to vote for the next person on the ballot to take his place
-20:05 <   Halcy0n@> Cardoe: true, but its good you are here anyhow since that's the first discussion point.
-20:05 <dertobi123@> i tried to call jokey on his cellÃphone, no success :/
-20:05 <   Halcy0n@> Well, is everyone that is here ready to start then?  jokey and lu_zero seem to be MIA.
-20:07 -!- Halcy0n changed the topic of #gentoo-council to: Next meeting: 2000 UTC Sept. 11 - Agenda: http://archives.gentoo.org/gentoo-dev/msg_619e8ac19efadb77a5c24add7a7b529b.xml - #1 Filling the empty slot
-20:07 <    Cardoe+> oo Halcy0n has the shiny gavel today
-20:07 <   Halcy0n@> Cardoe: well, since it looks like dberkholz|bb is on his blackberry, I figured it would be easier if I took the lead :P
-20:09 <   Halcy0n@> So, last time the council voted in the next person in line when a council member retired.  Is everyone that is present ready to vote on whether or not to follow what was done last time?  This would mean Cardoe would become our 7th council member in Diego's place.
-20:09 <dberkholz|@> we only need 4 to vote
-20:10 <    Cardoe+> as a reference point, http://article.gmane.org/gmane.linux.gentoo.devel.announce/243 are the results from the election officials
-20:10 <dberkholz|@> I'm ready
-20:10 <dertobi123@> <- ready to vote
-20:10 <   Calchan+> ready too
-20:11 <dberkholz|@> mark?
-20:11 <   Halcy0n@> Yup.  It has a yes from me.
-20:11 <dberkholz|@> Same here -- yes
-20:11 <   Calchan+> yes from me too
-20:11 <dertobi123@> yes here, too
-20:12 <   Halcy0n@> Congrats Cardoe :)
-20:12 <dberkholz|@> cardoe: welcome to the caba... er, council!
-20:12 <    Cardoe+> heh thank you
-20:12 <   Calchan+> Cardoe, all other choices were worse ;o)
-20:13 <    Cardoe+> Calchan: hah. Sounds like a Futurama quote
-20:13 <dberkholz|@> remember to get the mail alias updated
-20:13 <   Calchan+> is this effective now ?
-20:13 <dberkholz|@> yep
-20:13 <   Calchan+> ok
-20:13 -!- Halcy0n changed the topic of #gentoo-council to: Next meeting: 2000 UTC Sept. 11 - Agenda: http://archives.gentoo.org/gentoo-dev/msg_619e8ac19efadb77a5c24add7a7b529b.xml - #2 PMS as a draft standard of EAPI 0
-20:14 <dberkholz|@> since we got conflict resolution figured out, I haven't heard any other blockers
-20:15 <   Halcy0n@> I haven't seen any issues raise, so I'm assuming the PM developers are fine with it.
-20:15 <   Calchan+> dberkholz|bb, do we have gentoo dev in charge ?
-20:16 <dberkholz|@> does it matter, if we have a way to resolve conflicts with portage, and the council has to approve it?
-20:16 <    Cardoe+> Calchan: not exactly. It's technically a sub-project of QA, which is Halcy0n's dept.
-20:16 <    Cardoe+> Calchan: however, it's something that's being driven by the developers of the Package Managers with a conflict resolution policy in place
-20:17 <    Cardoe+> which is they try to work it out among themselves, there are 3 after all so that's a pretty easy way to get a majority vote
-20:17 <   Calchan+> I haven't seen the mail on the conflict resolution thing
-20:17 <    Cardoe+> and if it doesn't work, it gets kicked up to the council
-20:17 <   ciaranm > a majority isn't enough. we're not microsoft...
-20:18 <   Calchan+> who are the 3 ?
-20:18 <    Cardoe+> Calchan: Portage, Paludis, and pkgcore
-20:18 <   ciaranm > zac for portage, ferringb for pkgcore, about ten of us for paludis
-20:18 <   Calchan+> oh, I thought you were talking about persons
-20:19 <   Calchan+> and who's doing the conflict resolution ? (anybody got a pointer to the mail ?)
-20:20 <   ciaranm > Calchan: the pms editors, if possible, and the council if we can't get everyone to agree
-20:20 <   Calchan+> ciaranm, thanks, and who are the pms editors ?
-20:20 <   Halcy0n@> This still seems like somewhat of a undocumented process to me.  I'd really like there to be some structure to something as important as this.
-20:20 <    musikc > so PMS is maintained by zmedico, ferringb, and ciaranm? i thought it was just ciaranm and spb?
-20:20 <   Calchan+> Halcy0n, this is where I was getting at
-20:20 <   ciaranm > Calchan: me and spb are editors at the moment
-20:20 <   Calchan+> musikc, this was my impression too
-20:20 <    Cardoe+> Halcy0n: I was going to suggest a patch to the pms.xml
-20:21 <    musikc > ciaranm, shouldnt all of you be editors?
-20:21 <   ciaranm > musikc: anyone who sends lots of good patches can be an editor if they want
-20:21 <    musikc > since it's a collaboration and not led by any one PM?
-20:21 <   antarus > musikc: no one else has asked...
-20:21 <       spb > pms is just like any other open source project
-20:21 <   Calchan+> ciaranm, please define "lots of good patches" and who will decide
-20:21 <       spb > it's developed by those who develop it
-20:21 <    musikc > so zmedico and ferringb have access to edit it as well then?
-20:22 <jmbsvicett > antarus: Are you sure they were willing or they had reasons to expect becoming editors?
-20:22 <    musikc > they should have the same access to edit the doc since its a group effort
-20:22 <   ciaranm > Calchan: i'll define that when someone asks
-20:22 <   ciaranm > musikc: they can send patches, same as everyone else
-20:22 <    musikc > why patches?
-20:22 <    musikc > why cant they edit it?
-20:22 <    musikc > who gets to decide what goes in and what doesnt?
-20:22 <  ColdWind > musikc: if they haven't sent patches, why would they need access?
-20:22 <   ciaranm > because nothing gets committed to pms without peer review
-20:22 <    musikc > who gets to say what a good patch is?
-20:22 <   zmedico > honestly I'm perfectly happy leaving others to edit PMS. I've got other things to work on.
-20:23 <   Calchan+> ciaranm, you'll define ? sorry, unacceptable
-20:23 <   ciaranm > musikc: anyone who wants to can review patches and raise objections
-20:23 <    musikc > ciaranm, ok that makes sense. who are the peers?
-20:23 <   ciaranm > musikc: anyone who wants to do reviewing can do so
-20:23 <       spb > anyone who's watching the pms-bugs alias
-20:23 <   antarus > I should correct that
-20:23 <   antarus > 'anyone knowledgeable who wants to do reviewing' ;p
-20:23 <       spb > since any changes go there for people to complain before they're committed
-20:23 < dberkholz@> ok, i'm on my laptop now
-20:23 <    musikc > ciaranm, so only you and spb have commit access and final say unless someone wants to escalate to council?
-20:23 <   ciaranm > Calchan: why? it's not an issue yet, and if it ever becomes one we can raise it to the council if necessary
-20:24 <   ciaranm > musikc: for now, yes, since no-one else has asked
-20:24 <   Calchan+> Halcy0n, we obviously need a gentoo dev in charge here, and if that's not you we need somebody to volunteer
-20:24 <Philantrop > musikc: The same discussion was held during the last meeting and that's how the escalation process got created.
-20:24 <   antarus > Calchan: why is it obvious?
-20:24 <dleverton_ > "Obviously"?
-20:24 <       spb > musikc: ultimately, the council has final say since any disagreements can get escalated there
-20:24 <   ciaranm > Calchan: what's wrong with the current process? specific examples of where it's gone wrong please.
-20:24 <    musikc > Philantrop, i thought the escalation process was for any conflicts. i recall ciaranm stating what if PM's didnt follow PMS, hence the need for resolution process
-20:25 < dberkholz@> it seems clear to me that as a QA subproject, Halcy0n would have the final say on who could commit to it, although if there happens to be a specific pms lead, or consensus by the existing pms team, that would also be fine
-20:25 <   ciaranm > musikc: you mean the resolution process being "if we can't work it out then we send it to the council", which is what's being discussed?
-20:25 <   Calchan+> ciaranm, if it's a gentoo project it needs a gentoo dev as lead, if it's an external project I don't know why we're discussing it
-20:25 <   ciaranm > Calchan: uh, since when?
-20:26 <  ColdWind > Calchan: what does that gentoo dev need to do?
-20:26 <    musikc > dberkholz, ya, it'd make sense if there was a lead or representation from all PM's
-20:26 <       spb > there's representation from anyone who sees bugs and writes patches
-20:26 <   ciaranm > *if* anyone ever has a problem that can't be resolved, they can just ask the council to discuss it. what's the problem?
-20:26 <   Halcy0n@> dberkholz: to me, this seems to still be a hot topic that clearly isn't getting the discussion it deserves on the mailing lists.  I'd recommend the council members bringing up their concerns so its all documented somewhere.
-20:27 <   antarus > this is all irrelevant to the actual question
-20:27 <   antarus > which was is PMS the draft spec for EAPI 0
-20:27 <   antarus > yes/no?
-20:27 <Philantrop > antarus++
-20:27 <    Cardoe+> I'm actually working on a revised pms page for the QA sub-project
-20:27 <   antarus > I don't think 'who can commit to PMS' has anything to do with that
-20:27 <    musikc > Halcy0n, makes sense to me
-20:27 <   Calchan+> Halcy0n, makes sense to me too
-20:28 <      lack > antarus: 'PMS' as in a snapshot of what the repository is now, or 'PMS' as in the entire future of the repository's contents?
-20:28 <   antarus > you can discuss all teh beauracratic bullshit later ;p
-20:28 <   ciaranm > wasn't this "sent to the mailing lists" last month?
-20:28 <   ciaranm > why weren't objections raised then?
-20:28 <jmbsvicett > antarus: Last time there were 2 or 3 issues on the draft that were raised as not being accepted by all parties
-20:28 < dberkholz@> that's a good question.
-20:28 <    musikc > ciaranm, that was 2 weeks ago, perhaps peoples obligations delayed responses?
-20:28 <jmbsvicett > antarus: There was also a request to present all such issues to the mls - I didn't notice any mails about them
-20:28 <   ciaranm > musikc: for two weeks?
-20:28 <    musikc > seems to spark questions again, whats the problem with suggesting it goes to the mailing list
-20:29 <Philantrop > jmbsvicetto: Which seems to imply that these issues were resolved.
-20:29 <    musikc > ciaranm, sure. i myself was on vacation and in the middle of a lot of project work. just one person's example.
-20:29 <   ciaranm > musikc: i was hoping for a decision three months ago...
-20:29 <    Cardoe+> musikc: You seem to have some objections. Please send them to the list.
-20:29 <   antarus > Philantrop: no it implies no one talked about them ;)
-20:29 <Philantrop > antarus: Actually, I know they were talked about. :-)
-20:29 <   antarus > if it goes back to the lists you should set a deadline
-20:29 <    musikc > Cardoe, not so much objections as thoughts and interest in wht other people think
-20:29 <  ColdWind > the same problem is going on since way before the last meeting iirc, and it never gets discussed on the ML
-20:29 <    musikc > antarus, that makes complete sense also
-20:29 <   antarus > such that issusea are actively being resolved before the deadline
-20:29 <   antarus > otherwise we will discuss this forever
-20:30 <  ColdWind > it seems you've entered a deadlock
-20:30 < dberkholz@> at least having a council meeting every 2 weeks forces people to bring it up that often.
-20:30 <   ciaranm > every two weeks people ask the same questions that were asked four weeks ago
-20:30 <   antarus > so we are not ready to vote because there were issues from last meeting that were not resolved?
-20:30 <   antarus > you have 2 weeks to fix them
-20:30 <   antarus > lets move on ;p
-20:30 < dberkholz@> i'm trying to put together a list of things people say are blockers
-20:30 < dberkholz@> could whoever had one please say it again, directed at me?
-20:31 <    musikc > blockers?
-20:31 < dberkholz@> we don't want to delay this without specific things that need to be resolved before approving it
-20:31 <   Calchan+> dberkholz, lead, doc on structure and processes
-20:31 <Philantrop > dberkholz: Please consider the topic and the iussues that were raised here today.
-20:31 < dberkholz@> otherwise it goes into the nebulous nowhere
-20:31 <    musikc > ahhhh, agree with Calchan
-20:31 <   Calchan+> dberkholz, was the conflict resolution discussed on council@ ?
-20:31 <   Halcy0n@> dberkholz: what calchan said.  I'd like to see a process since it seems people aren't clear on it.
-20:31 <   antarus > I will volunteer as lead if you need for one some reason
-20:32  *  antarus shrugs
-20:32 < dberkholz@> Halcy0n: a process for what?
-20:32  *   musikc votes Halcy0n for lead :)
-20:32 <    musikc > HEHE
-20:32 <   ciaranm > antarus: i've already got a volunteer gentoo developer to be an arbitrary and pointless figurehead if anyone needs one
-20:32 <   antarus > ciaranm: ok :)
-20:32 <   Calchan+> dberkholz, I was talking about conflict resolution, I haven't seen anything
-20:32 < dberkholz@> Calchan: it was agreed upon at the last meeting. first PM devs & PMS editors try to resolve, and they request council to resolve by vote if they cannot
-20:32 <   ciaranm > Calchan: did you see what was discussed at the last meeting?
-20:32 <jmbsvicett > dberkholz / Halcy0n: People should also raise any objection to the current content of the PMS draft, before it gets approved
-20:33 <   ciaranm > jmbsvicetto: did you see what the question was?
-20:33 <    Cardoe+> ciaranm: me? or someone else. Cause I volunteered a few weeks back if that would ease the approval of this.
-20:33 <    musikc > jmbsvicetto, good point. has that been raised by anyone yet?
-20:33 <   ciaranm > Cardoe: oh, you're number three then :P
-20:33 <   ciaranm > musikc: why is it a good point? include references to the question in your answer
-20:33 <jmbsvicett > ciaranm: I did. That's why I'm saying anyone with any objection has a last chance to present it before the doc gets approved - "speak now, ..."
-20:33 <   Calchan+> dberkholz, then who are the pms editors ? where is this documented ?
-20:33 <   ciaranm > jmbsvicetto: er, why is there a last chance?
-20:33 <    Cardoe+> Does anyone have any objections to the current content of the PMS?
-20:33 <    musikc > ciaranm, what was my question? i think you confised me with someone else
-20:34 <   ciaranm > jmbsvicetto: clearly you *didn't* read the question
-20:34 <   ciaranm > musikc: you agreeing with jmbsvicetto. i want to know why you're doing that.
-20:34 <   ciaranm > especially given how spb specifically covered it being ok to find issues with the EAPI 0 definition even after the level of approval being requested
-20:35 <    musikc > b/c i agree with him saying that people should raise any objections to the current content before it gets approved. sounds reasonable to me. :)
-20:35 <   Calchan+> Cardoe, I have no problem with the content
-20:35 <   ciaranm > except that we're not asking for and never will ask for "this will never change" approval
-20:35 <jmbsvicett > ciaranm: Let me be clear. dberkholz is trying to collect issues about PMS and its approval. I'm suggesting that in the next 2 weeks anyone having the slightest objection to the current content of the draft should sent it to the ml and have it discussed before the doc is approved - otherwise, they'll have to live with the doc. This is all I'm saying
-20:35 <    musikc > ciaranm, i understand the concept of 'fluid' documents, thanks though
-20:35 <   ciaranm > musikc: then why are you agreeing with jmbsvicetto over "last chance"?
-20:35 <Philantrop > jmbsvicetto: That has been the case for *months* now and nothing was brought up.
-20:36 <   ciaranm > jmbsvicetto: how does that differ from the last three times that's been said?
-20:36 <   Halcy0n@> Lets get back on topic here.  The underlying question is should we approve PMS as a draft for EAPI 0 only.  We seem to have some other major concerns, and we should leave it open for us to amend this decision later.
-20:36 <    musikc > ciaranm, b/c if someone has an objection currently, wouldnt it make sense that they bring it up? why wait. seems silly if they already know they have an objection.
-20:36 < dberkholz@> ok, i have 2 issues as blockers right now
-20:36 <    musikc > Halcy0n ++
-20:36 <Philantrop > Halcy0n: The concerns are about process, not the contents, though.
-20:36 < dberkholz@> one is a PMS lead who is a gentoo dev, and the other is documenting conflict resolution
-20:36 <jmbsvicett > Philantrop: true, but it seems no one has ever felt it as a "deadline"
-20:37 <   antarus > Philantrop: processes are important
-20:37 <   ciaranm > every time we do this a different group of people jumps up and asks the same questions that were asked at the previous meeting, and then it's always postponed to the next meeting for the same questions to be asked over again
-20:37 <   antarus > (certainly I'm with you that this should have been approved months ago)
-20:37 <Philantrop > antarus: Yes, if they don't work.
-20:37 <    musikc > dberkholz, i dont see the process for approval of patches, etc documented. that'd probably be worthwhile as well
-20:37 <   antarus > that doesn't mean we shouldn't attempt to document how things work now ;p
-20:37 <   Halcy0n@> Can we stay on topic please?  I have other things I need to run to after this.
-20:38 <  ColdWind > So, on one hand, people is not discussing problems with the contents even when that's what's council requested for months. On the other hand, people can still bring up those concerns after PMS approval as a draft standard... that's why it's a draft. Is there any reason to block the approval of the draft forever?
-20:38 <    musikc > ColdWind, forever? of course not. postponed while ppl still work to understand the process? sure.
-20:38 <   Halcy0n@> Calchan, Cardoe, dberkholz|bb : Are you guys comfortable with the statement I made above?  Lets vote on whether or not to approve PMS as a draft for EAPI 0 only, and leave it open for us to amend the decision later should we find the need to.
-20:38 <   antarus > ColdWind: thats what the two week deadline is for ;)
-20:38 <    Cardoe+> Halcy0n: yes
-20:39 < dberkholz@> do any council members think that documenting a process for patch acceptance is a requirement?
-20:39 <   Halcy0n@> dertobi123: ^  that was directed to you as well
-20:39 <  ColdWind > musikc: there will be *always* someone who still doesn't understands the process, so yes, with this dynamic... this is effectively blocked forever.
-20:40 <    musikc > ColdWind, agreed so documentation helps :)
-20:40 <   Halcy0n@> dberkholz: I don't see it as a blocker for approving it as an initial draft right now, but I want it documented.
-20:40 <    Cardoe+> alright. everyone let's take a breather for a second. Let's us wrap up the actual question at hand. Further concerns can be approached on list.
-20:40 <dertobi123@> Halcy0n: yep
-20:40 <Calchan|Ho > sorry, apparently my irc proxy went down
-20:41 <    musikc > so post poned until documented Halcy0n?
-20:41 <   Calchan+> ColdWind,
-20:41 <    Cardoe+> ciaranm: what's the official ml to bring up discussions about patches? or should it remain on the bug?
-20:41 <   ciaranm > Cardoe: we're using the pms-bugs alias for now
-20:41 <   Halcy0n@> musikc: no, I don't mind doing the initial approval, and getting the documentation laid down afterwards.
-20:41  *   musikc nods
-20:42 <    Cardoe+> ciaranm: any requirements to join the alias? or just get someone with commit access to that file to add you?
-20:42 <    musikc > Halcy0n, that makes sense and goes with ciaranm's expressed view of PMS always up for change
-20:42 <   ciaranm > Cardoe: the only requirement is that you not be so amazingly annoying that we feel obliged to move somewhere else
-20:42 < dberkholz@> could you tone it down a bit, ciaranm ..
-20:42 <    musikc > ciaranm, any gentoo dev should be welcome since PMS is a standard for Gentoo :)
-20:43 <   Halcy0n@> Council people, are we ready to vote?
-20:43 <    Cardoe+> Halcy0n: yes
-20:43 <   Calchan+> I'm ready to vote
-20:43 <   ciaranm > dberkholz: mm? what did i say?
-20:43 <dertobi123@> yes
-20:43 <   ciaranm > musikc: any qualified gentoo developer
-20:43 <    musikc > ciaranm, who determines who is qualified?
-20:43 <   ciaranm > any qualified anyone. being a gentoo developer is neither here not there
-20:43 <    musikc > Gentoo has determined any dev is qualified as this is a standard for Gentoo so they should all be welcome
-20:43 <   ciaranm > musikc: it's yet to be an issue, so we haven't had to determine it
-20:44 <   Halcy0n@> dberkholz: are you?
-20:44 <    musikc > ciaranm, so all Gentoo devs should be welcome
-20:44 < dberkholz@> Halcy0n: i'm thinking
-20:44 <   ciaranm > musikc: dunno. does gentoo still have developers who don't know what 'grep' is?
-20:44 -!- mode/#gentoo-council [+m] by Halcy0n
-20:44 <   Halcy0n@> Just to reduce the noise so we can make a decision on the original topic.
-20:45 <dertobi123@> thanks Halcy0n
-20:45 < dberkholz@> here's what i'm thinking. we have these 2 blocking issues. will either of them have an impact on pms as a draft standard?
-20:45 <    Cardoe+> dberkholz: what do you see as the two?
-20:45 < dberkholz@> the two i said earlier
-20:46 < dberkholz@> 20:36 < dberkholz@> one is a PMS lead who is a gentoo dev, and the other is  documenting conflict resolution
-20:47 <dertobi123@> one of these issues is about having a puppet or not having a puppet as a lead, this is a non-issue from my pov
-20:47 < dberkholz@> what exact benefits would having a pms lead as a gentoo dev gain us?
-20:47 <   Calchan+> dberkholz, a half baked pms project is the best way to have it crash into a wall, so we want this ?
-20:47 <   Calchan+> s/so/do/
-20:47 <   Halcy0n@> dberkholz: if we want the project to remain useful, I think we should document it before we start pushing it on people as a standard, in draft form or any other.
-20:48 <    Cardoe+> While people might feel emotional about a PMS lead that is a Gentoo dev, it's not necessarily a requirement. It's a Gentoo project controlled by the Gentoo QA project as a whole. Who runs the PMS sub-project is no consequence to how good or bad it is.
-20:48 < dberkholz@> document what?
-20:48 <   Halcy0n@> dberkholz: sorry, the conflict resolution and patch approval process.
-20:49 <    Cardoe+> Halcy0n: do we want to create a pms ML so that the pms-bugs alias isn't being used/abused?
-20:49 <    Cardoe+> bugzilla can mail changes to the ML for affected bugs
-20:49 <dertobi123@> Cardoe: agreed, ideally there would be a gentoo dev interested in that - but as long there's noone ...
-20:49 <   Halcy0n@> Cardoe: it would be best so others could join the list and conversations.
-20:50 <    Cardoe+> and publicly provide archives
-20:50 < dberkholz@> are there discussions happening on pms-bugs rather than just bugs posted to it?
-20:50 <   Halcy0n@> dberkholz: that has been the case in the past, yes.
-20:52 <    Cardoe+> Halcy0n: can you tell us the last e-mail across it?
-20:52 <    Cardoe+> actually never mind
-20:53 <    Cardoe+> Creating a mailing list I don't believe would be opposed (anyone opposing can PM me now) and would allow public transparency into the process and would allow for review of the process in the future so I think it's a plus moving forward.
-20:53 <   Halcy0n@> Cardoe: its mostly been submitted patches.
-20:53 <   Halcy0n@> And discussions of those patches.
-20:53 <    Cardoe+> which sounds a bit like a ML already
-20:54 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080911-agenda.txt has the list of requirements i've collected
-20:54 <   Halcy0n@> dberkholz: that looks good to me.
-20:55 <   Calchan+> dberkholz, yes, looks good
-20:55 <    Cardoe+> So from that list does anyone see any that would prevent you from voting yes today to the PMS as a draft standard for EAPI 0 and 1?
-20:55 <    Cardoe+> I don't see any that would prevent me from voting yes today. Of course, I reserve the option to change that going forward since we are working with a live document.
-20:56 <   Calchan+> Cardoe, yes, I don't see the point voting for something unfinished when we could vote for the same finished thing in 2 weeks
-20:56 < dberkholz@> by making it a draft standard, what we're saying is that it is now a requirement to resolve conflicts between it and package managers
-20:56 < dberkholz@> there's not much value in approving a spec that doesn't match reality
-20:57 <    Cardoe+> correct
-20:57 <    Cardoe+> I think we have 2 outstanding issues between Portage/pkgcore & PMS/Paludis
-20:58 <    Cardoe+> Which can be a very good test to see how people will resolve this.
-20:59 <   Halcy0n@> Alright, we are at the end, can we vote?
-20:59 <   Calchan+> Halcy0n, yes
-20:59 <   Calchan+> I mean, yes I can vote
-21:00 <    Cardoe+> let's do it
-21:00 < dberkholz@> ok
-21:00 <dertobi123@> yep, let's vote
-21:00 < dberkholz@> do we want to specify that our acceptance is conditional upon those requirements being resolved?
-21:00 <    Cardoe+> 3 choices..
-21:01 <    Cardoe+> Yes, Yes conditional upon requirements being resolved, No
-21:01 < dberkholz@> i'm gonna go with #2.
-21:01 <   Halcy0n@> I'm with #2 as well
-21:02 <    Cardoe+> #2 here
-21:02 <dertobi123@> #2 too
-21:02 <   Calchan+> I vot 3 in the present state
-21:02 <dertobi123@> being solved until the next meeting i'd suggest in addition
-21:02 <   Calchan+> s/vot/vote/
-21:02 < dberkholz@> i agree w/ dertobi123 -- 2 weeks to resolve. there's nothing major there
-21:03 <    Cardoe+> Do we want to vote on creating a ML now or let it be discussed on the ML first?
-21:03 <dertobi123@> creating that ML sounds like a logical thing to me, so vote and yes please
-21:03 < dberkholz@> i'm pretty sure that's what we just did. making a list was one of the reqs, and we just voted to accept given the reqs.
-21:04 <   Halcy0n@> dberkholz: agreed.  I have to run now.
-21:04 < dberkholz@> ok
-21:04 <   Calchan+> thanks Halcy0n
-21:05 < dberkholz@> that's it for this meeting
-21:05 <    Cardoe+> I agree with creating the ML
-21:05 <   Calchan+> dberkholz, weren't we supposed to discuss eapi2 ?
-21:05 < dberkholz@> do people not read my posts?
-21:05 < dberkholz@> that kind of discussion is for lists, not meetings
-21:05 < dberkholz@> plus we hit our hourly limit
-21:06 <   Calchan+> dberkholz, ah sorry, I understood we'd discuss it here
-21:06 <    Cardoe+> dberkholz: The discussion was over.. the final list was submitted afaik
-21:06 < dberkholz@> there have been multiple replies on it today
-21:07 < dberkholz@> that just isn't enough time
-21:07 < dberkholz@> i'm happy to vote on it on -council though
-21:07 < dberkholz@> if not, we can vote it in 2 wks
-21:07 <   Calchan+> somebody should reopen the channel then
-21:08 -!- mode/#gentoo-council [-m] by dberkholz
-21:08 < dberkholz@> meeting's over
-21:08 < dberkholz@> thanks for playing
-21:08 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080911-agenda.txt has summary
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080925-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20080925-summary.txt
deleted file mode 100644
index 8eb3465738..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080925-summary.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Roll call
-=========
-betelgeuse here
-cardoe     here [dang]
-dberkholz  here
-dertobi123 here
-halcy0n    here
-jokey      here
-lu_zero    slacker
-
-New topics
-==========
-
-EAPI-2
-------
-Goal: Vote on approval
-
-Requirements: 
-
-  - Put a generated copy (preferably HTML) in the PMS project webspace. 
-    People who want to refer to an EAPI=2 reference don't necessarily 
-    want to install all the dependencies to build it.
-  - Let's tag the git repository something like 
-    eapi-$EAPI-approved-$DATE.
-
-Result: EAPI=2 is approved.
-
-
-PROPERTIES in cache
--------------------
-Goal: Vote: Does council need to approve cache changes?
-  Goal: Vote on approval
-
-Result: Since it's related to the EAPI, this should be another issue 
-that package-manager developers resolve amongst themselves and only 
-present to council if they can't agree.
-
-They agree on adding it to the cache as a value that package managers 
-can ignore, so it is.
-
-
-PROPERTIES=interactive in ebuilds
----------------------------------
-Goal: Vote: Does council need to approve global-variable changes in 
-      ebuilds?
-
-Result: This is a retroactive, backwards-compatible EAPI change and thus 
-is handled the same as any other EAPI change -- it requires council 
-approval.
-
-Goal: Vote on approval
-
-Result: PROPERTIES=interactive is approved.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080925.txt b/xml/htdocs/proj/en/council/meeting-logs/20080925.txt
deleted file mode 100644
index ad35fa78f9..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20080925.txt
+++ /dev/null
@@ -1,213 +0,0 @@
-20:00 < darksiide > ding!
-20:00 <Betelgeuse@> dong
-20:00 <   ciaranm > the witch is dead
-20:02 < dberkholz@> who's here?
-20:02 < dberkholz@> lost track of time for a sec
-20:03 <Betelgeuse@> dberkholz: \o/
-20:03 <dertobi123@> <- here
-20:03  *  Halcy0n is here
-20:03 <     jokey@> plop
-20:03 <      dang > <- is Cardoe today
-20:03 <     jokey@> dang: oh, reincarnation? ;)
-20:03 <      dang > jokey: More like astral projection...
-20:04 < dberkholz@> where's lu?
-20:04 -!- jokey changed the topic of #gentoo-council to: Next meeting: now
-20:06 < dberkholz@> ok, let's get started without him
-20:06 < dberkholz@> can someone try to contact him somehow?
-20:06 -!- mode/#gentoo-council [+v dang] by Halcy0n
-20:06 < dberkholz@> (and speak up so i know who you are)
-20:06 <Betelgeuse@> dberkholz: Shouldn't you have his number :D
-20:06 <Betelgeuse@> I can dig it out too of course.
-20:06 < dberkholz@> it would be nice for someone else to step up and do something occasionally..
-20:07 < dberkholz@> here's a brief agenda -- http://dev.gentoo.org/~dberkholz/20080925-agenda.txt
-20:08 < dberkholz@> so let's get rolling on eapi-2
-20:08 < dberkholz@> anyone not ready to vote?
-20:08 <Betelgeuse@> dberkholz: txt msg sent
-20:08 <   Halcy0n@> I am ready.
-20:08 -!- thargor__ is now known as thargor
-20:08 < dberkholz@> as i mentioned before the meeting, i stuck a pdf at http://dev.gentoo.org/~dberkholz/pms/pms_eapi-2_no-kdebuild-1_20080925.pdf -- see the appendix
-20:09 <Betelgeuse@> So we would move a copy like that to the PMS project pages then?
-20:10 <Betelgeuse@> Or the html output generated for better linking from stuff like devmanual would work too.
-20:10 < dberkholz@> i'd like to just stick a tag in git
-20:10 <      dang+> An html copy somewhere would be *really* nice.
-20:10 <     jokey@> dberkholz++
-20:11 <     jokey@> one of us should just add a gpg signed one there and be done with it
-20:11 < dberkholz@> putting a copy in the pms project space would make sense to me, so people have somewhere simple to get this info
-20:11 < dberkholz@> any pms folks can comment on that?
-20:11 <   ciaranm > app-doc/pms
-20:11 <      dang+> That's what I meant, of course.  The official one could still be in git.
-20:11 <     jokey@> maybe add a generated one to the project page as well so people don't need to install texlive just to take a look at it
-20:12 <dertobi123@> jokey: pdf and html (as dang suggested) would be nice, yeah
-20:12 <   ciaranm > ferdy: ^^ you can do that, right?
-20:13 <      dang+> and an app-doc/pms-2 for people who do want a local copy.
-20:13 <  nirbheek > app-doc/pms-bin? :)
-20:13 <      dang+> Heh.
-20:13 <   ciaranm > dang: i was just going to merge the eapi-2 branch into master...
-20:14 <   ciaranm > the only reason eapi 2 is on a branch just now is to avoid giving the impression it's been finalised
-20:14 <     jokey@> anyway, nothing else required for vote, right? ;)
-20:14 <      dang+> ciaranm: Sure, I have no problem with that.
-20:14 <      dang+> But cutting a tarball, sticking it on the mirror, and having a pms-2 version in portage would be a nice touch.
-20:14 <      dang+> Not required, but nice.
-20:15 <   ciaranm > do we do a new tarball when we write some more of the EAPI 0 stuff, then?
-20:15 <Betelgeuse@> ciaranm: Well pms-2 would isntall the tag
-20:15 <      dang+> Good question...
-20:15 <Betelgeuse@> ciaranm: if coming from git
-20:15 <      dang+> tag may be better, I'd forgotten about that. :P
-20:15 <   ciaranm > a tag doesn't really make sense to me
-20:16 <   ciaranm > i mean, what'd it tag? the first eapi 2 commit? the last eapi 2 commit? the most recent eapi 2 related fix? the most recent fix that is some way relevant to eapi 2? and once it's there it's stuck
-20:16 <Betelgeuse@> ciaranm: For EAPI 0 of course not, but we aren't approving that atm.
-20:16 <   Halcy0n@> So, can we vote?  The specifics of what we do with PMS can be discussed separately.
-20:17 <dertobi123@> indeed
-20:17 <      dang+> Fine with me.
-20:17 <Betelgeuse@> ciaranm: Well we can tie the ebuild to particular commits too.
-20:17 <   Halcy0n@> So, yes from me.
-20:18  *     Sput thinks people mean a branch rather than a tag
-20:18 <Betelgeuse@> ciaranm: And increase it as fixes come I guess.
-20:18 <   ciaranm > Betelgeuse: so how's that different from just pointing the ebuild at master?
-20:18 <Betelgeuse@> ciaranm: council approval for changes
-20:18 <Betelgeuse@> ciaranm: if wanted
-20:18 < dberkholz@> if we approve one thing, the wording could later change so that it actually means something else
-20:19  *    jokey is for it too
-20:19 <   ciaranm > in which case the conflict resolution process kicks in
-20:19 <      dang+> But a signed tag specifying what was actually the state at approval time would help a lot...
-20:20 <      dang+> Just as a historical record, if nothing else.
-20:20 <      dang+> Anyway, I vote to approve, too.
-20:20 < dberkholz@> i would like to see a tag that says something like eapi-$EAPI-approved-$DATE
-20:20  *    jokey got a note that lu went to bed already
-20:20 <   ciaranm > it would? *shrug* sign and tag away all you like. tags are cheap.
-20:20 < dberkholz@> but yes, i am also for eapi 2
-20:20  * dertobi1 is too
-20:20 <Betelgeuse@> +1
-20:20 <     jokey@> ++
-20:21 < dberkholz@> who agrees with the tag?
-20:21 <   Halcy0n@> Please tag it :)
-20:22 <Betelgeuse@> I do
-20:22 < dberkholz@> (btw, just to make it clear for the record, EAPI=2 is approved.)
-20:22  * dertobi1 agrees
-20:22  *    jokey too
-20:22  *     dang too
-20:23 <   ciaranm > ok, someone please make a signed tag then and mail it to the list which doesn't exist yet
-20:23 < dberkholz@> is it merged to master already?
-20:23 <      dang+> Heh.
-20:23 <   ciaranm > is now!
-20:24 < dberkholz@> updated agenda/summary -- http://dev.gentoo.org/~dberkholz/20080925-agenda.txt
-20:24 < dberkholz@> please verify the EAPI=2 section
-20:25 <   Halcy0n@> Sounds good to me Donnie.
-20:25 < dberkholz@> ok, let's move on to the next topic
-20:25 < dberkholz@> PROPERTIES in cache
-20:26 <     jokey@> no need to approve cache changes imho as long as they don't break older versions of portage
-20:26 < dberkholz@> there were zero objections on-list
-20:26  *     dang agreed with jokey
-20:26  * dertobi1 too
-20:26 < dberkholz@> yeah, that's my feeling
-20:26 <Betelgeuse@> cache changes should be needed because of tree wide changes which should go through us
-20:26 <   Halcy0n@> Fine by me.
-20:26 <Betelgeuse@> not always of course
-20:27 <Betelgeuse@> So why not do both?
-20:27 <   zmedico > the cache is a community asset
-20:27 < dberkholz@> cache changes aren't just needed because of changes to the tree, but because portage is just tracking more data
-20:27 <   zmedico > so I don't really think it's all my decision
-20:28 < dberkholz@> that's why i think the ebuild PROPERTIES section is more relevant to us directly, because that part always impacts the tree
-20:28 <   ciaranm > cache is an EAPI / PMS thing, and all sorts of third party apps rely upon it, so changing it isn't something to be done without proper discussion
-20:28 <   zmedico > nod
-20:29 <Betelgeuse@> The council hasn't had that much technical stuff to decide any way so I don't see why we would need to cut down the list.
-20:30 <     jokey@> ciaranm: that's why I added "as long as it doesn't break older stuff"
-20:30 <     jokey@> if one just adds fields, it shouldn't be a real issue anywhere
-20:30 < dberkholz@> you can only cut down the list if something was on the list to start with ... cache changes have never gone through council in the past to my knowledge
-20:30 <   ciaranm > that's not entirely true...
-20:30 <   zmedico > note that there is currently an upper limit on the number of cache entries
-20:31 <   zmedico > 22 max, 7 unused
-20:31 <   zmedico > adding PROPERTIES leaves 6 unused
-20:31 <   ciaranm > you can use things that are currently defined as unused without breaking things. you can't *add* without breaking portage
-20:31 <   ciaranm > dberkholz: the last cache change was pre-council, wasn't it?
-20:32 < dberkholz@> i don't think so
-20:32 <   ciaranm > wasn't the last cache change the addition of the EAPI field?
-20:32 <   zmedico > last addition was EAPI
-20:32 <   zmedico > few years back
-20:34 < dberkholz@> seems like if anything, this should be another issue that PM devs resolve amongst themselves and only present to council if they can't agree
-20:34 < dberkholz@> is there a lack of agreement?
-20:35 <   ciaranm > there's no disagreement on PROPERTIES, just some of the proposed values for it
-20:35 < dberkholz@> ok
-20:36 < dberkholz@> do council people agree with what i said?
-20:36 <     jokey@> sure
-20:36 <dertobi123@> yep
-20:36  *    jokey notes a bunch of stuff falls into that category actually
-20:36 <      dang+> Sure.
-20:36 <Betelgeuse@> the majority has spoken
-20:37 <Betelgeuse@> So let's go with that then.
-20:37 <     jokey@> right
-20:37 < dberkholz@> ok, if you guys agree on PROPERTIES in cache, go for it.
-20:37  *  ciaranm shall add it to pms
-20:38 < dberkholz@> let's move on to the PROPERTIES=interactive
-20:39 <     remi` > quick question: PROPERTIES is added to which EAPI ?
-20:40 <   ciaranm > remi`: PROPERTIES is retroactively added to 0, 1 and 2 with the restriction that it can't be used for anything that package managers can't safely ignore
-20:40 <     remi` > great, thanks for the clarification
-20:41 <   Halcy0n@> Are there any disagreements on having PROPERTIES=interactive from any of the PM people?
-20:41 <   ciaranm > interactive was the one we didn't disagree on
-20:41 < dberkholz@> i'm presuming zmedico agrees with it too =)
-20:42 <   zmedico > nod
-20:42 < dberkholz@> council members, do you think this is something that should require council approval?
-20:44 <   Halcy0n@> I think it makes sense for us to approve it.
-20:44 <dertobi123@> i'm unsure, so it wouldn't hurt to approve it. i'm for it :)
-20:44 <Betelgeuse@> yes
-20:44 <     jokey@> yes
-20:44 <     jokey@> ;)
-20:44 < dberkholz@> to generalize, new global variables in ebuilds that are used by the PM
-20:45 <      dang+> Probably a good idea.
-20:45 <     jokey@> anything global imho
-20:45 <     jokey@> so it expands to vars and functions
-20:45 <   ciaranm > vars and functions would be an EAPI thing anyway
-20:46 < dberkholz@> unless they're optional again
-20:46 < dberkholz@> seems like an odd use case though
-20:46 < dberkholz@> pkg_pretend() anyone?
-20:46 <     jokey@> eapi stuff
-20:47 <     jokey@> so handled within pms group as usual
-20:47 <   ciaranm > pkg_pretend is a lot easier if you can be sure it'll get used... so it's a lot easier as an EAPI thing...
-20:47 < dberkholz@> reasonable
-20:48 < dberkholz@> what we're saying is that new ebuild features that aren't covered by PMS/EAPIs still need to be approved by the council
-20:49 <     jokey@> eh, isn't all this global ebuild stuff (to be) covered by pms?
-20:49 <   ciaranm > there aren't going to be many things done that way, so it's probably easier to just send every new EAPI and every carefully done retroactive EAPI change to the council...
-20:50 <Betelgeuse@> indeed
-20:50 <     jokey@> ++
-20:50 < dberkholz@> ciaranm: so you're classifying this as a retroactive EAPI change?
-20:51 < dberkholz@> i'm a bit underslept lately
-20:51 <   ciaranm > dberkholz: PROPERTIES? yeah
-20:51 <   ciaranm > PROPERTIES is an EAPI thing that we just happen to be able to get away with doing retroactively by carefully weasel wording it
-20:51 < dberkholz@> yeah, ok, that way we can just say it's just a standard pms/eapi thing and not deal with setting new policies and whatnot
-20:52 < dberkholz@> so let's move on to the approval vote
-20:52 <   Halcy0n@> How are we determining which properties are allowed though?  Is that tied to a particular EAPI at this point, or are you wording it up in such a way that new ones can be introduced at any time?
-20:53 < dberkholz@> since PROPERTIES handling is optional, i was assuming that support for any given value of it was also optional
-20:53 <   Halcy0n@> I just wanted to make sure :)
-20:53 < dberkholz@> and any new value would require council approval the way we've said it
-20:53 <   ciaranm > what dberkholz said
-20:53 <   Halcy0n@> Okay, thanks.
-20:54 <   Halcy0n@> I vote to approve it.
-20:54 < dberkholz@> so do i
-20:54 <Betelgeuse@> +1
-20:54 <      dang+> ++
-20:55 < dberkholz@> ok, that's our agenda for today
-20:55 < dberkholz@> and right on time too!
-20:55 <      Sput > nice work *clap*
-20:55 <   Halcy0n@> Awesome.  Thanks for getting everything organized Donnie.
-20:55 < dberkholz@> less so every week, as i get less and less sleep...
-20:55 < dberkholz@> adios, gotta run!
-20:56 <     jokey@> ++
-20:56 <Betelgeuse@> I can make the tag.
-20:56  *    jokey thinks donnie should get some choclate and cookies for free
-20:56 <   ciaranm > Betelgeuse: do you know how to mail tags for git? i've never had to done that
-20:57  * dertobi1 hands donnie some swiss chocolate i bought in zurich yesterday :)
-20:57 <    maekke > dertobi123: =)
-20:57 <Betelgeuse@> ciaranm: Hmm. True.
-20:58 <Betelgeuse@> ciaranm: I can try the normal way.
-20:58 <     remi` > oh, I had one tiny question : when can we start using EAPI=2 in ~ and/or stable ebuilds ?
-20:58 <Betelgeuse@> remi`: You shouldn't commit something you haven't tested so after a pkg manager is committed with support for it
-20:58 <Betelgeuse@> remi`: zmedico probably does a release today
-20:58 <     remi` > Betelgeuse, of course, but once portage is out, we can start using it?
-20:59 <   ciaranm > paludis will probably be tomorrow, unless my laptop speeds up...
-20:59 <Betelgeuse@> remi`: yes
-20:59 <    Caster > remi`: and in stable ebuilds when a portage that supports it is stable, I guess
-21:00 <   ciaranm > zmedico / anyone else: please review the properties branch i just committed to pms
-21:00 <   zmedico > sure
-21:01 <     remi` > Betelgeuse, Caster, ok thanks
-21:02 <jmbsvicett > council: thanks for approving EAPI-2
-21:03 <   zmedico > thanks for approving the PROPERTIES stuff too
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081023-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20081023-summary.txt
deleted file mode 100644
index 335ca95389..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20081023-summary.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-Roll call
-=========
-betelgeuse here
-cardoe     here
-dberkholz  here
-dertobi123 here
-halcy0n    here
-jokey      slacker
-lu_zero    here
-
-Running through open bugs
-=========================
-
-Process: For each bug, come up with a concrete next step and who's going 
-to do it. If it's the council, a specific member should take 
-responsibility. The bug should be assigned to whoever needs to take the 
-next step and council@ should be in CC.
-
-Bugs handled:
-185572 - As the proctors no longer exist the code of conduct needs an upate
-234705 - Document of being an active developer
-234706 - Slacker arches
-234708 - Can the council help fewer bugs get ignored by arm/sh/s390 teams?
-234710 - as-needed by default
-237381 - Document appeals process
-
-Bugs remaining:
-234711 - GLEP 54: scm package version suffix
-234713 - GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
-234716 - Extent of Code of Conduct enforcement
-
-Meeting scheduling conflicts
-============================ 
-The 2nd meetings in November and December 
-conflict with holidays. If there are open bugs, we will hold them on the 
-3rd Thursday instead of the 4th Thursday; otherwise, they will be 
-canceled.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081023.log b/xml/htdocs/proj/en/council/meeting-logs/20081023.log
deleted file mode 100644
index a7d7fe0973..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20081023.log
+++ /dev/null
@@ -1,218 +0,0 @@
-19:10 <NeddySeago > Is there an agenda for tonight ?
-19:10 <    fmccor > I haven't seen one, although someone requested a review of all open Council bugs.
-19:12 <   lu_zero@> ^^
-19:22 < darksiide > Cardoe requested it and commented on some i think.
-19:24 < dberkholz@> that is the agenda
-19:28 < dberkholz@> here's how i think we can make this most useful
-19:29 < dberkholz@> for each bug, come up with a concrete next step and who's going to do it. if it's the council, a specific member should take responsibility
-19:32 <dertobi123@> sounds good to me :)
-19:33 < dberkholz@> and i think the bug should actually get reassigned to that person with council in cc
-19:54 < dberkholz@> i'm wandering to another building. brb
-20:01 <Betelgeuse@> hiihoo
-20:01 <   lu_zero@> hi Betelgeuse
-20:03 <dertobi123@> heya
-20:03 <   lu_zero@> who's missing?
-20:03 <Betelgeuse@> Cardoe at least
-20:03 <Betelgeuse@> jokey:
-20:03 <Betelgeuse@> Halcy0n:
-20:03 <Betelgeuse@> !expn council
-20:03 < Willikins > Betelgeuse: council = (private)
-20:03 <    Cardoe@> I'm here
-20:04 <    Cardoe@> I tried to comment on a few of the bugs to see where we're at
-20:06 <   Halcy0n@> Here.
-20:08 < dberkholz@> back, sorry
-20:08 < dberkholz@> first building had a congested network
-20:08 < dberkholz@> so, are people on board with what i suggested?
-20:09 <   Halcy0n@> Yup.
-20:09 <dertobi123@> jokey has his cellphone switched off, tried to reach him
-20:09 <dertobi123@> dberkholz: yep
-20:11 <   Halcy0n@> I went through some of the bugs and identified where they are at: http://dev.gentoo.org/~halcy0n/council_bugs.txt
-20:11 < dberkholz@> i'll repaste quick, since i said it before 2000
-20:11 < dberkholz@> 20:01 <   lu_zero@> hi Betelgeuse
-20:11 < dberkholz@> err.
-20:11 < dberkholz@> 19:28 < dberkholz@> here's how i think we can make this most useful
-20:11 < dberkholz@> 19:29 < dberkholz@> for each bug, come up with a concrete next step and who's  going to do it. if it's the council, a specific member  should take responsibility
-20:11 < dberkholz@> 19:32 <dertobi123@> sounds good to me :)
-20:11 < dberkholz@> 19:33 < dberkholz@> and i think the bug should actually get reassigned to that  person with council in cc
-20:12 < dberkholz@> dertobi123 & Halcy0n agree, waiting on others' input
-20:12 <Betelgeuse@> yeah having someone in charge could help
-20:12 <   lu_zero@> sounds fine
-20:13 < dberkholz@> ok, let's just run through 'em in order
-20:13 < dberkholz@> bug #185572
-20:13 < Willikins > dberkholz: https://bugs.gentoo.org/185572 "As the proctors no longer exist the code of conduct needs an upate"; Doc Other, Project-specific documentation; NEW; neddyseagoon@g.o:council@g.o
-20:14 <dertobi123@> i agree to Cardoe, re-assigning to devrel
-20:14 < dberkholz@> i'm fine with letting devrel members update it to reflect reality of how it's enforced, as cardoe said
-20:14 <   lu_zero@> I do agree as well
-20:14 <   Halcy0n@> Agreed.
-20:15 <Betelgeuse@> fine
-20:15 < dberkholz@> ok, saying so on the bug
-20:16 < dberkholz@> bug #234705
-20:16 < Willikins > https://bugs.gentoo.org/234705 "Document of being an active developer"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-20:17 < dberkholz@> seems like a good way forward is letting araujo finish his prototype, then reassign to devrel
-20:18 <   lu_zero@> yup
-20:18 <   Halcy0n@> Sounds reasonable.
-20:18 <Philantrop > dberkholz: araujo raised a few questions on the bug for the council (?) to answer, though.
-20:18 < dberkholz@> i don't think the council should be the group answering them. i think devrel should
-20:18 <dertobi123@> is it already decided who's going to sign the documents later on? the prototype reads like it is being by the trustees
-20:18 < dberkholz@> i really don't think that bug has anything to do with the council at all
-20:19 <dertobi123@> if the trustees are going to sign the documents then they should deal with the questions araujo raised
-20:19 <dertobi123@> dberkholz: indeed
-20:19 < dberkholz@> here's what i suggest. we assign to araujo, CC devrel and trustees, and tell them to decide amongst themselves which of them should handle it
-20:20 < dberkholz@> and un-CC council because it isn't our thing
-20:20 <   lu_zero@> I'd rather have devrel sign
-20:20 <dertobi123@> dberkholz: agreed
-20:20 <   Halcy0n@> dberkholz: I agree with that.  Doesn't make sense for us to be involved really.
-20:20 <Betelgeuse@> Well probably someone with a legal status should do it.
-20:21 < dberkholz@> i also have an opinion who should sign but i don't want to bikeshed about it
-20:21 < dberkholz@> we don't handle legal issues, so talking about legal status within the council doesn't make sense
-20:21 <NeddySeago > lu_zero, what is the legal status of this certificate ?
-20:21 <   lu_zero@> NeddySeagoon selfcertification from gentoo I think
-20:21 <   lu_zero@> or otherwise a formal reference
-20:22 <NeddySeago > lu_zero, I mean, if a developer users it in applying for a job ... like a reference
-20:23 < dberkholz@> araujo's requirement was that mentioning gentoo on his résumé requires some sort of proof in the form of written documentation
-20:24 <NeddySeago > cc the trustees, we will discuss it
-20:24 <   lu_zero@> NeddySeagoon ok
-20:24 <dertobi123@> it's like a lpic or microsoft certification reference, imho it should be signed by one of the trustees
-20:24 <dertobi123@> but that's something devrel and trustee can discuss
-20:24 <NeddySeago > dertobi123, I don't have a prolem with that
-20:25 < dberkholz@> anyone in addition to dertobi123 & Betelgeuse with me on pushing the open questions to devrel+trustees?
-20:25 <   Halcy0n@> I agreed :)
-20:25 <NeddySeago > heh
-20:25 <   lu_zero@> I'm fine
-20:25 < dberkholz@> err, Betelgeuse didn't agree. that was a typo.
-20:25 < dberkholz@> ok, that's 4
-20:26 <dertobi123@> NeddySeagoon: of course, didn't meant it that way
-20:26 <Betelgeuse@> Well does someone else besides trustees have legal status?
-20:26 <NeddySeago > Not as far as I know
-20:26 <    fmccor > No, I don't think so.
-20:27 <Betelgeuse@> ok so I agreed :D
-20:27 <dertobi123@> heh
-20:28 < dberkholz@> ok
-20:28 < dberkholz@> bug #234706
-20:28 < Willikins > https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-20:29 <dertobi123@> that bug sounds like ping timed-out?
-20:29 <   lu_zero@> vapier had something?
-20:29 < dberkholz@> he never actually got around to writing it
-20:30 <   Halcy0n@> This came up on the list the other day again, so one of us should really try to get this resolved in some way.
-20:30 < dberkholz@> i understand he was basing it off something richard freeman about it
-20:30 < darksiide > that was raised on the gentoo-dev list
-20:30 < dberkholz@> s/about it/said about it/
-20:30 <   Halcy0n@> I can take it as something to try and get some input from the masses.
-20:31 < darksiide > its rather annoying to cc the "slackers" for no reason, they don't have the manpower to maintain a stable tree
-20:31 < darksiide > not a fault of there, but..if you are using s390, you should be prepared to deal with package.keywords, etc
-20:32 < dberkholz@> i would expect the annoying part is that it leaves the maintaining teams with lots of open bugs that are hard to hide if you want to see "real" stabilization requests
-20:32 <   lu_zero@> well I'd do s/slacker/understaffed/
-20:32 <   lu_zero@> and keep arch as transient and ignore ~ for those
-20:33 < dberkholz@>  http://article.gmane.org/gmane.linux.gentoo.devel/54103
-20:33 <   lu_zero@> with a bit fat warning telling that
-20:34 < dberkholz@> that's rich0's proposal from a while back
-20:34 < dberkholz@> Halcy0n: ok. you want to take this bug and follow it through?
-20:35 <   Halcy0n@> dberkholz: Yea, I'll handle it.
-20:35 < darksiide > well, break the stable tree with understaffed arches or just remove the stable tree (ala ~mips)
-20:35 <    Cardoe@> dberkholz: I got rich0's proposal in my mail
-20:36 <    Cardoe@> I think we need to establish some reasonable rules.
-20:36 <    Cardoe@> i.e. for an arch not to be considered "understaffed" they need a dedicated security liaison
-20:37 <dertobi123@> having a security liaison doesn't prevent an arch from not being understaffed
-20:37 <    Cardoe@> no
-20:37 <dertobi123@> -not
-20:37 <    Cardoe@> But I'm just saying that we need a set of rules
-20:38 < dberkholz@> what purpose does defining an arch as understaffed serve?
-20:38 <dertobi123@> first of all we'd need some input from those so-called slacker arches
-20:38 <    Cardoe@> if an arch can not reasonable handle security bugs in 120 days... what's the point of having that arch be stable?
-20:38 < darksiide > how about not 200 stablereqs open? ;)
-20:38 <    Cardoe@> dberkholz: once we define an arch as understaffed, we drop the stabilization for that arch
-20:38 < dberkholz@> i think people are interested in how to handle individual packages, so let's approach it from that perspective
-20:38 <   Halcy0n@> I think it would be best to put together an actual proposal before we discuss this any further.
-20:38 <dertobi123@> darksiide: using this as a criteria we'd be starting to drop ppc stable keywords soonish *cough*
-20:38 <    Cardoe@> Halcy0n: who's volunteering?
-20:39 < dberkholz@> he is, read your scrollback
-20:39 <    Cardoe@> ok
-20:39 <    Cardoe@> so let's update the bug with Mark writing a proposal
-20:39 < dberkholz@> done
-20:39 <    Cardoe@> Are we going to set a suspense for it?
-20:40 < darksiide > ty for addressing it guys. maintainers need something here (ie. i don't give a rip about s390, sh, etc especially when they never get done)
-20:40 < dberkholz@> is a "suspense" supposed to mean a due date?
-20:40 <    Cardoe@> yes and no
-20:40 <    Cardoe@> a date when we revisit the issue if no feedback is received
-20:41 < dberkholz@> i like your idea about running through open bugs at meetings so much that i think any time we don't have suggested topics, we should do this
-20:41 <dertobi123@> yep
-20:41 <    Cardoe@> thanks.
-20:42 < dberkholz@> would've been nice to do it at the last meeting too, since it looks like we won't get through all of them today
-20:42 <dertobi123@> what about setting the second november meeting as a due date?
-20:42 <   Halcy0n@> How many more do we have?  I have a meeting at 2100UTC that I have to attend.
-20:42 < dberkholz@> 6
-20:42 <    Cardoe@> Halcy0n: we can cut it short and discuss some more next meeting
-20:42 < dberkholz@> i think we could dupe bug #234708 on the slacker bug though
-20:43 < Willikins > https://bugs.gentoo.org/234708 "Can the council help fewer bugs get ignored by arm/sh/s390 teams?"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-20:43 <   Halcy0n@> I just have to walk 40 feet to the conference room, so I can go right until 2100.
-20:43 <   Halcy0n@> dberkholz: yea, I agree.
-20:43 <dertobi123@> dberkholz: agreed
-20:43 <    Cardoe@> I figured if we can just keep the idea of these opened bugs somewhere in our minds, we drive the community to resolve them quicker.
-20:43 <    Cardoe@> I agree with dup'ing.
-20:43 <   lu_zero@> fine
-20:43 < dberkholz@> k, done
-20:44 < dberkholz@> Halcy0n: how about you tell us on the bug when we should expect something? 
-20:44 < dberkholz@> might be more meaningful if we can get dates from the people doing the work than arbitrarily setting them
-20:44 <    Cardoe@> that'd be even better
-20:45 < dberkholz@> so, next is bug #234710
-20:45 < Willikins > https://bugs.gentoo.org/234710 "as-needed by default"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-20:46 <   Halcy0n@> dberkholz: done.
-20:46 < dberkholz@> ColdWind: you seem to know what's required here. do you want to put it together?
-20:46 < dberkholz@> perhaps bonsaikitten would help with the tree testing since he's already compiling stuff all the time
-20:47 < darksiide > (or diego)
-20:47 <    Cardoe@> I believe he's using as-needed in his compiling tests. So his feedback would be helpful.
-20:47 <    Cardoe@> bonsaikitten's that is
-20:47 < dberkholz@> eh, ColdWind has been idle for almost a day.
-20:47 <    Cardoe@> I assume Diego uses it as well
-20:47 < dberkholz@> i use it too, but i don't build the entire tree
-20:47 <Betelgeuse@> yeah same here
-20:48 < darksiide > someone said something about gcc-spec files? put it in ~arch gcc and call for testers
-20:48 <Betelgeuse@> but it hasn't caused any problems in ages
-20:48 < darksiide > (same with my ldflags - no isses)
-20:48 <Betelgeuse@> But to turn it on by default I would rather have some comprehensive runs.
-20:48 < dberkholz@> ok, so how do we proceed with this bug?
-20:49 <Betelgeuse@> It's not like the benefit to normals users it earth shaking.
-20:49 <    Cardoe@> Betelgeuse: it will reduce the amount of rebuilt packages
-20:49 < dberkholz@> we can CC bonsai and ask what he's doing. is anyone here willing to take the lead on getting this done? you don't necessarily have to do the work yourself, just get other people to do it
-20:49 <    Cardoe@> Betelgeuse: i.e. next time I bump cairo, the entire X stack won't have to be rebuilt
-20:49 <Betelgeuse@> Cardoe: I don't consider that earth shaking as you can just leave those running int he background.
-20:50 <Betelgeuse@> Stupid typos.
-20:50 <    Cardoe@> dberkholz: You can assign it to me.
-20:51 <    Cardoe@> I'll get something together within the next 30 days.
-20:51 < darksiide > i condsider that earth shattering on my 1ghz laptop
-20:51 <    Cardoe@> I had an "emergency" agenda item.
-20:52 <Betelgeuse@> darksiide: Bigger rebuilds really don't come that often.
-20:52 <Betelgeuse@> Or then I have missed them.
-20:52 <    Cardoe@> 2nd meeting in November is Thanksgiving in the US and a decent portion of the council is US-ian.
-20:52 <   Halcy0n@> Yea...that isn't going to work :)
-20:53 <    Cardoe@> and the 2nd meeting in December is Christmas
-20:53 <dertobi123@> so we move that meeting to the 3rd thursday in november or just skip it?
-20:54 < dberkholz@> let's do 3rd if we have any open bugs, otherwise skip
-20:54 <dertobi123@> sounds good
-20:54 <   lu_zero@> ok
-20:54 <dertobi123@> for the 2nd december meeting it should be safe to just skip
-20:54 <dertobi123@> probably everyone of us has other things to do in that time ;)
-20:54 <Betelgeuse@> Not really.
-20:55 <NeddySeago > playing with new toys :)
-20:55 < dberkholz@> dertobi123: all the more reason to get those bugs closed. =)
-20:55 <Betelgeuse@> Nothing happens here on the 25th around midnight.
-20:55 <   lu_zero@> Betelgeuse =)
-20:55 <dertobi123@> oh, neddy is going to send us new toys? =)
-20:55 <Betelgeuse@> Santa Claus comes on Christmas Eve.
-20:56 < dberkholz@> does a 4th person agree with moving the 2nd meeting in nov & dec one week earlier?
-20:56 <   Halcy0n@> Yes
-20:56 <    Cardoe@> I agree with it.
-20:56 <NeddySeago > dertobi123, Oh ... Father Christmas, if you are good and get your bugs closed
-20:56 < dberkholz@> ok, good
-20:56 <    Cardoe@> I say we address the remaining bugs next meeting.
-20:56 < dberkholz@> we're just about out of time, so i just wanted to say i'll take bug #237381 because i've already started working on it
-20:56 <dertobi123@> NeddySeagoon: we'll see :)
-20:56 < Willikins > https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-20:57 <Betelgeuse@> dberkholz: go ahead
-20:57 <    Cardoe@> great
-20:57 <   Halcy0n@> Cool, thanks
-20:57 <dertobi123@> fine :)
-20:57 < dberkholz@> that leaves 3 unhandled bugs
-20:57 < dberkholz@> good enough for today
-20:58 <   Halcy0n@> Sounds good.  Now I have to run to another meeting.
-20:59 < dberkholz@> ok, that's it for today
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081113-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20081113-summary.txt
deleted file mode 100644
index c3b9939548..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20081113-summary.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-Roll call:
-==========
-dberkholz: absent, 40 minutes lates
-Halcy0n: absent
-Cardoe: here
-dertobi123: here
-lu_zero: here
-Betelgeuse: here
-jokey: absent, slacker
-
-Topics:
-=======
-
-    No topics for the meeting were proposed.
-
-Open Bugs:
-==========
-
-    Slacker Arches(bug 234706):
-        
-        Mark sent a proposal to gentoo-dev about this. No other discussion or
-	decision.
-
-    GLEP 55(.ebuild-$eapi extension, bug 234713):
-        
-        Conclusion:
-            This bug has been RESO LATER'ed pending concrete need and
-            consensus(GLEP 54 being the main one).
-
-    Code of Conduct Update(Proctors no longer exist, bug 185572):
-        
-        Conclusion:
-            Jorge(jmbsvicetto) will talk to other members of devrel about this
-            bug.
-
-    Extent of Code of Conduct enforcement(Banning people entirely from Gentoo,
-    bug 234716):
-
-        Conclusion:
-            Userrel is responsible for establishing these policies. Since each
-            developer is also a user at some point, these policies will apply
-            to developers as well as users.
-
-    GLEP 54(-scm package suffix. bug 234711):
-    
-        Conclusion:
-            No decision. David Leverton commented that portage's current
-            method for identifying 'live' ebuilds was hackish, as it depends
-            on the list of inherited eclasses, which could change. Also, it
-	    was pointed out that some ebuilds use scm eclasses to check out
-	    specific revisions(mythtv). PROPERTIES=live was considered
-            as another option.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081113.txt b/xml/htdocs/proj/en/council/meeting-logs/20081113.txt
deleted file mode 100644
index 3d02f60885..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20081113.txt
+++ /dev/null
@@ -1,240 +0,0 @@
-<13.11.2008 20:01> <@Betelgeuse> Cardoe, dberkholz, Halcyon, jokey, lu_zero 
-<13.11.2008 20:01> <@lu_zero> hi Betelgeuse
-<13.11.2008 20:03> <@Betelgeuse> So the agenda is to look at open issues again?
-<13.11.2008 20:04> <@dertobi123> with a turnout of 3 out 7 ...
-<13.11.2008 20:04> <@Cardoe> hello
-<13.11.2008 20:04> <@dertobi123> 4 out 7 then :P
-<13.11.2008 20:04> <@Cardoe> had to use the restroom, sorry
-<13.11.2008 20:04> <@lu_zero> ^^
-<13.11.2008 20:04> <@Betelgeuse> dertobi123: well dberkholz set the topic a little while ago
-<13.11.2008 20:04> <@lu_zero> who's missing?
-<13.11.2008 20:05>  * dertobi123 tried to call jokey on his cellphone - no luck 
-<13.11.2008 20:05> <@Cardoe> forgot the meeting started an hour earlier with the time change here in the states
-<13.11.2008 20:05> <@Betelgeuse> Halcyon, jokey, dberkholz 
-<13.11.2008 20:05> <@Cardoe> I'm willing to bet they did as well
-<13.11.2008 20:05> <@dertobi123> Betelgeuse: yep, sure
-<13.11.2008 20:09> <@dertobi123> so, how do we proceed?
-<13.11.2008 20:09> <@Betelgeuse> well at least there's more than half of us here 
-<13.11.2008 20:10> <@Cardoe> I have nothing to report on as-needed
-<13.11.2008 20:10> <@lu_zero> I'd wait 20min
-<13.11.2008 20:10> <@Cardoe> None of the users wanted to contribute
-<13.11.2008 20:11> < darksiide> define 'contribute'
-<13.11.2008 20:12> <@dertobi123> lu_zero: *shrugs* ... i think that won't help
-<13.11.2008 20:12> <@Betelgeuse> I wasn't in charge of any of the  issues.
-<13.11.2008 20:12> <@Betelgeuse> lu_zero, dertobi123 Did you have any?
-<13.11.2008 20:12> < jmbsvicetto> Cardoe: flameeyes is/was building his system with forced --as-needed on the specs - so he might have some info
-<13.11.2008 20:12> <@lu_zero> no
-<13.11.2008 20:12> <@dertobi123> Betelgeuse: no ...
-<13.11.2008 20:12> <@lu_zero> I'm prodding diego right now
-<13.11.2008 20:12> <@Betelgeuse> Then not much we can do without dberkholz, Halcyon around
-<13.11.2008 20:13> <@Cardoe> Well we can assign some new issues
-<13.11.2008 20:13> <@lu_zero> I didn't further my alternate gleps
-<13.11.2008 20:13> <@dertobi123> Cardoe: yep
-<13.11.2008 20:13> <@Cardoe> lu_zero: You want to take over bug #234711?
-<13.11.2008 20:13> <@lu_zero> since zmedico autoset for live ebuild sound to me a good solution for at least one problem
-<13.11.2008 20:13> < Willikins> Cardoe: https://bugs.gentoo.org/234711 "GLEP 54: scm package version suffix"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-<13.11.2008 20:13> <@dertobi123> shall we gave a quick view at the open bugs and it's current state?
-<13.11.2008 20:13> <@lu_zero> ok
-<13.11.2008 20:14> <@lu_zero> Cardoe I could be considered overbiased on it
-<13.11.2008 20:14> <@Cardoe> lu_zero: alright well let's work on getting that finalized and get the work for that ticket to be wrapped up
-<13.11.2008 20:14> <@Cardoe> alright
-<13.11.2008 20:14> <@Cardoe> Do you still have your alternative glep handy?
-<13.11.2008 20:14> <@lu_zero> Cardoe it's in my devspace
-<13.11.2008 20:14> <@Cardoe> Betelgeuse? dertobi123? You guys wanna take GLEP 54?
-<13.11.2008 20:15> <@dertobi123> it fits best for lu_zero i think
-<13.11.2008 20:15> <@lu_zero> http://dev.gentoo.org/~lu_zero/glep/
-<13.11.2008 20:15> <@Betelgeuse> Cardoe: I would rather not take any stuff if possible.
-<13.11.2008 20:15> <@Betelgeuse> Cardoe: Can take stuff when we have another recruiters.
-<13.11.2008 20:15> <@Cardoe> Betelgeuse: well it's more like being the council's point man
-<13.11.2008 20:15> <@Cardoe> ok
-<13.11.2008 20:15> <@Cardoe> dertobi123: ?
-<13.11.2008 20:15> <@lu_zero> I'd open a bug about recruiters for council and assign it to Betelgeuse
-<13.11.2008 20:15> <@lu_zero> so he could use it to track the situation
-<13.11.2008 20:16> <@dertobi123> Cardoe: ?
-<13.11.2008 20:16> <@lu_zero> and we'll have to look at it every 2 weeks ^^
-<13.11.2008 20:16> <@Betelgeuse> lu_zero: Well can the council do anything concrete for the situation?
-<13.11.2008 20:16> <@Betelgeuse> I have a couple people interested so let's just hope they deliver.
-<13.11.2008 20:16> <@lu_zero> Betelgeuse sounds great
-<13.11.2008 20:19> <@dertobi123> so we have #234711 for luca, right?
-<13.11.2008 20:19> <@lu_zero> if you all agree about that
-<13.11.2008 20:19> <@dertobi123> guess we do ;)
-<13.11.2008 20:19> <@lu_zero> I'll try to update my alternate proposal and document the portage status
-<13.11.2008 20:19> <@Cardoe> lu_zero: sounds good
-<13.11.2008 20:19> <@Cardoe> lu_zero: re-assign it to yourself please
-<13.11.2008 20:20> <@Cardoe> and CC the council
-<13.11.2008 20:20> <@lu_zero> doing
-<13.11.2008 20:20> <@dertobi123> ok
-<13.11.2008 20:20> <@dertobi123> bug #234706 is the next one then
-<13.11.2008 20:20> < Willikins> dertobi123: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:halcy0n@g.o
-<13.11.2008 20:21> <@dertobi123> current state: proposal sent to -dev, discussion ongoing
-<13.11.2008 20:21> <@Cardoe> Halcyon has posted his proposal to the ML and it's being discussed
-<13.11.2008 20:21> <@dertobi123> yep ;)
-<13.11.2008 20:21> <@Cardoe> !herd devrel
-<13.11.2008 20:21> <@Cardoe> !expn devrel
-<13.11.2008 20:21> < Willikins> Cardoe: devrel = (private)
-<13.11.2008 20:22> <@lu_zero> Mid-air collision detected!
-<13.11.2008 20:22> <@lu_zero> bad Cardoe =P
-<13.11.2008 20:22> <@Cardoe> bug #185572 is waiting on devrel
-<13.11.2008 20:22> < Willikins> Cardoe: https://bugs.gentoo.org/185572 "As the proctors no longer exist the code of conduct needs an upate"; Doc Other, Project-specific documentation; NEW; neddyseagoon@g.o:devrel@g.o
-<13.11.2008 20:22> <@Cardoe> dberkholz isn't around to discuss bug #237381
-<13.11.2008 20:22> < Willikins> Cardoe: https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:dberkholz@g.o
-<13.11.2008 20:23> < jmbsvicetto> Cardoe: I'll talk with other members of devrel about 185572
-<13.11.2008 20:23> <@Cardoe> jmbsvicetto: thank you
-<13.11.2008 20:25> <@dertobi123> so we have bug #234713 and bug #234716 left
-<13.11.2008 20:25> < Willikins> dertobi123: https://bugs.gentoo.org/234713 "GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-<13.11.2008 20:25> <@dertobi123> bug #234716
-<13.11.2008 20:25> < Willikins> dertobi123: https://bugs.gentoo.org/234716 "Extent of Code of Conduct enforcement"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-<13.11.2008 20:25> <@Betelgeuse> dertobi123: for GLEP 55 I don't think there is any change 
-<13.11.2008 20:26> <@Cardoe> for 234716, I'd like to see some members of userrel step up
-<13.11.2008 20:26> <@Cardoe> !expn userrel
-<13.11.2008 20:26> < Willikins> Cardoe: userrel = (private)
-<13.11.2008 20:26> <@dertobi123> Betelgeuse: dito ... i see no need for glep 55 now
-<13.11.2008 20:27> <@dertobi123> for 234716 discussions took place months ago, noone seems to be interested in that bug/problem these days
-<13.11.2008 20:27> <@Cardoe> I've commented on every bug
-<13.11.2008 20:28> <@dertobi123> thanks Cardoe
-<13.11.2008 20:28> <@Cardoe> Does anyone have any other topics to bring up?
-<13.11.2008 20:29> <@Betelgeuse> What to do with slacker marks?
-<13.11.2008 20:29> < fmccor> dertobi123, I thought much of 234716 had been resolved one way or another.  I am a member of userrel, but I for one have zero interest in revisiting any of that.
-<13.11.2008 20:29> <@Cardoe> fmccor: what has been resolved?
-<13.11.2008 20:30> <@Cardoe> fmccor: do you guys have a firm policy or document in hand that can be linked to?
-<13.11.2008 20:30> <@Cardoe> I honestly would like to vote 234716 be put in the hands of userrel
-<13.11.2008 20:30> <@Cardoe> Because at some point or another, every Gentoo developer is a user as well
-<13.11.2008 20:30> <@Cardoe> so the same policies apply to them
-<13.11.2008 20:31> <@dertobi123> would that help to get that bug resolved?
-<13.11.2008 20:31> < fmccor> Cardoe, I don't.  I think some of it was considered infeasible, and parts of it are addressed now at retirement, but I don't recall which Council meeting discussed the second.
-<13.11.2008 20:31> <@dertobi123> instead of reassigning to userrel@ i'd say mark this one as cantfix, from a technical pov
-<13.11.2008 20:32> < jmbsvicetto> Cardoe: A few of us have already exchanged "quite" some mails about that subject
-<13.11.2008 20:32> < jmbsvicetto> Cardoe: 234716
-<13.11.2008 20:32> <@Cardoe> jmbsvicetto: Where'd you guys get?
-<13.11.2008 20:32> < jmbsvicetto> I mean all those mails between userrel, devrel, council and trustees
-<13.11.2008 20:32> < fmccor> jmbsvicetto, I assure you I am not going to revisit that episode in Gentoo. :)
-<13.11.2008 20:33> < jmbsvicetto> fmccor: I'm just saying we already "watched" that show ;)
-<13.11.2008 20:33> < fmccor> jmbsvicetto, Indeed. :)
-<13.11.2008 20:33> <@Cardoe> so from userrel and devrel's perspective it's a cantfix?
-<13.11.2008 20:33> < jmbsvicetto> I don't think it's a cantfix
-<13.11.2008 20:34> < jmbsvicetto> I think it's mostly a arenotwillingtofix
-<13.11.2008 20:34> < NeddySeagoon> jmbsvicetto, don't loose the knowledge - summarise it on the bug and resolve CANTFIX.  Then its there for next time
-<13.11.2008 20:34> <@Cardoe> That's the best solution
-<13.11.2008 20:35> <@dertobi123> :)
-<13.11.2008 20:35> < NeddySeagoon> jmbsvicetto, there will be a niext time ... :(
-<13.11.2008 20:35> < jmbsvicetto> Cardoe: There are substantial "philosophical" divergences about this subject inside all those teams (and likely all of Gentoo)
-<13.11.2008 20:35> <@Cardoe> jmbsvicetto: write that on the bug please
-<13.11.2008 20:36> <@dberkholz> crap, time change.
-<13.11.2008 20:36> <@lu_zero> ^^
-<13.11.2008 20:36> <@dertobi123> heh
-<13.11.2008 20:36> <@dberkholz> google calendar is wrong
-<13.11.2008 20:36> <@lu_zero> you are still in time to discuss your bugs ^^
-<13.11.2008 20:37> < jmbsvicetto> Cardoe: I'll add a few comments there later
-<13.11.2008 20:37> <@dberkholz> i would blame flameeyes but he resigned
-<13.11.2008 20:37> <@Cardoe> jmbsvicetto: thank you
-<13.11.2008 20:37> <@Cardoe> dberkholz: time change got me too
-<13.11.2008 20:38> <@Cardoe> I'm willing to bet the same situation for Mark as well
-<13.11.2008 20:38> <@dertobi123> for markus too
-<13.11.2008 20:38> <@Cardoe> dberkholz: if ya want, take a minute or two to go through the scrollback
-<13.11.2008 20:39> <@dertobi123> i guess
-<13.11.2008 20:39> <@Cardoe> dertobi123: is he in a place where the time changed?
-<13.11.2008 20:39> <@dertobi123> Cardoe: same timezone i'm in
-<13.11.2008 20:39> <@dertobi123> though the change was some ~14 days ago
-<13.11.2008 20:39> <@dertobi123> *shrugs*
-<13.11.2008 20:40> <@dberkholz> anyone keeping a running summary?
-<13.11.2008 20:40> <@dertobi123> Cardoe: seeing your comment on 234713 - i think that's a perfect summary for marking this one later
-<13.11.2008 20:40> <@dertobi123> dberkholz: i can send a short summary tomorrow
-<13.11.2008 20:40> <@dberkholz> i'm wondering for the purposes of catching up
-<13.11.2008 20:41> <@dberkholz> if nobody's started one at all, i'll just write it
-<13.11.2008 20:41> <@dertobi123> well, there's not that much to note, sadly
-<13.11.2008 20:41> <@Cardoe> dberkholz: I was going to write one at the end
-<13.11.2008 20:41> <@Cardoe> dertobi123: O
-<13.11.2008 20:42> <@Cardoe> dertobi123: I'd have to agree
-<13.11.2008 20:42> <@Cardoe> I'd vote for marking #234713 as LATER
-<13.11.2008 20:42> <@Cardoe> Anyone else?
-<13.11.2008 20:42> <@dertobi123> <- too
-<13.11.2008 20:43> <@lu_zero> fine from my side
-<13.11.2008 20:44> <@dberkholz> that's fine with me
-<13.11.2008 20:48> <@Betelgeuse> fine
-<13.11.2008 20:48> <@Betelgeuse> but then again I don't really like LATER in general
-<13.11.2008 20:48> <@Betelgeuse> I don't see anything wrong with open bugs
-<13.11.2008 20:49> <@Betelgeuse> in this case LATER works as I doubt it gets forgotten
-<13.11.2008 20:49> <@dberkholz> i would like open bugs assigned to council@ to be only things requiring action from us
-<13.11.2008 20:49> <@dertobi123> open bugs would be regularly checked, LATER bugs would need to be reopened if action is required
-<13.11.2008 20:50> <@dertobi123> dberkholz: exactly
-<13.11.2008 20:50> <@dberkholz> on that note, anyone mind if i reassign bug 234716 to userrel for the meanwhile?
-<13.11.2008 20:50> < Willikins> https://bugs.gentoo.org/234716 "Extent of Code of Conduct enforcement"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-<13.11.2008 20:51> <@dberkholz> and perhaps we should go LATER or WONTFIX on bug #234711 too
-<13.11.2008 20:51> < Willikins> https://bugs.gentoo.org/234711 "GLEP 54: scm package version suffix"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:lu_zero@g.o
-<13.11.2008 20:52> <@Cardoe> for 234716 gonna say
-<13.11.2008 20:53> <@Cardoe> "The council charges the userrel team with establishing these policies and guidelines and enforcing them. Since, each developer is also a user, the userrel policies affect them as well."
-<13.11.2008 20:53> <@Cardoe> good?
-<13.11.2008 20:53> <@lu_zero> sounds fine
-<13.11.2008 20:54> <@lu_zero> got Diego on jabber
-<13.11.2008 20:54> <@Cardoe> lu_zero: same here
-<13.11.2008 20:54> <@Betelgeuse> yes
-<13.11.2008 20:55> <@dberkholz> i'm ok with that
-<13.11.2008 21:00> <@Cardoe> alright. posted
-<13.11.2008 21:00> <@dberkholz> since a few of us were running late from daylight savings, anyone want to keep going till 21:30?
-<13.11.2008 21:01> <@Cardoe> sure
-<13.11.2008 21:01> <@dberkholz> or sooner, if we get through the couple of other bugs
-<13.11.2008 21:01> <@Cardoe> I figured some users and developers might have made the same mistake so let's keep the floor opened as well
-<13.11.2008 21:01> <@lu_zero> ok
-<13.11.2008 21:01> <@dertobi123> guess we were through the bugs already, but well ...
-<13.11.2008 21:02> <@dertobi123> except 237381
-<13.11.2008 21:02> <@dberkholz> i'm still working on documenting the appeals thing, most of my gentoo time has gone into planning for a distributed vcs
-<13.11.2008 21:02> <@dberkholz> if anyone wants to help draft something up, you're welcome to work with me
-<13.11.2008 21:04> <@dberkholz> speak up now. =)
-<13.11.2008 21:06> <@dberkholz> ok, then, i'll keep it going.
-<13.11.2008 21:06> <@lu_zero> ^^;
-<13.11.2008 21:07> <@dberkholz> my main other question was should we just close the GLEP 54 bug somehow, because of the live sets?
-<13.11.2008 21:07> <@lu_zero> dberkholz I tend to agree about this
-<13.11.2008 21:07> <@dberkholz> or are we waiting for someone to definitely say it's obsolete?
-<13.11.2008 21:07> <@lu_zero> I'd wait other 2 weeks and then close the but
-<13.11.2008 21:07> <@Cardoe> I was kind of waiting for Zac to say it's obsolete
-<13.11.2008 21:08> < dleverton> Why would it be obsolete because of sets?
-<13.11.2008 21:09> <@dberkholz> the concrete reasoning presented for glep 54 is that you could use it to reinstall live ebuilds periodically. if a live set does this already, what additional purpose does it serve?
-<13.11.2008 21:10> < dleverton> It helps to identify which packages should be in the set in the first place, for one thing.
-<13.11.2008 21:10> < jmbsvicetto> dberkholz: Portage still needs a way to only reinstall packages if there was an update in the source tree
-<13.11.2008 21:10> <@lu_zero> dleverton portage does that already
-<13.11.2008 21:10> < dleverton> The other reason is to provide sane ordering relative to non-live ebuilds.
-<13.11.2008 21:11> < dleverton> lu_zero: IIRC it does that by recognising particular eclasses, which is rather hackish.
-<13.11.2008 21:11> <@lu_zero> works perfectly
-<13.11.2008 21:11> < dleverton> There's talk of introducing PROPERTIES=live support, which is better, but still not as good as -scm IMHO.
-<13.11.2008 21:11> < dleverton> It doesn't work when someone introduces a new scm eclass, unless either portage is updated or the user modifies the st definition himself.
-<13.11.2008 21:12> < jmbsvicetto> dleverton: There's a proposal to add a live PROPERTIES
-<13.11.2008 21:16> <@dberkholz> and it won't work for ebuilds using a new scm unless they're named as such ... either way involves a change somewhere or other..
-<13.11.2008 21:16> <@Cardoe> dberkholz: -scm tag or PROPERTIES=live?
-<13.11.2008 21:17> <@Cardoe> Cause I would think -scm would be more fraile
-<13.11.2008 21:17> <@lu_zero> and having the eclasses for live ebuild reside on a directory apart would solve that
-<13.11.2008 21:17> < dleverton> If we go with -scm, then that'll be the rule for live ebuilds, end of story.
-<13.11.2008 21:17> <@lu_zero> dleverton mine is simpler, just a specific path.
-<13.11.2008 21:17> < dleverton> If we keep with recognising particular eclasses, then things have to be updated whenever someone wants to add a new one.
-<13.11.2008 21:18> <@lu_zero> no
-<13.11.2008 21:18> < dleverton> No what?
-<13.11.2008 21:18> <@lu_zero> if you move all the live eclasses in the same paths
-<13.11.2008 21:18> <@lu_zero> you don't have to do anything else
-<13.11.2008 21:20> < dleverton> Well, you also have to consider ebuilds that check out a particular revision or tag, and therefore shouldn't be considered live even though they use a scm eclass.
-<13.11.2008 21:20> < dleverton> But I think at this point, the potential future solution is between -scm and PROPERTIES=live
-<13.11.2008 21:21> <@lu_zero> not really
-<13.11.2008 21:21> <@lu_zero> if they checkout something specific they should use a static snapshot and not hammering the upstream server.
-<13.11.2008 21:22> <@dberkholz> regarding upstream code updates, i just stumbled across bug #182028
-<13.11.2008 21:22> < Willikins> dberkholz: https://bugs.gentoo.org/182028 "[Future EAPI] About managing CVS/SUBVERSION version of software"; Gentoo Hosted Projects, PMS/EAPI; NEW; StormByte@gmail.com:pms-bugs@g.o
-<13.11.2008 21:22> < dleverton> lu_zero: "should", perhaps, but there are ebuilds that use the eclasses for that.
-<13.11.2008 21:22> < dleverton> lu_zero: and for things like local overlays, it's far more convenient than making a snapshot manually.
-<13.11.2008 21:22> <@Cardoe> lu_zero: MythTV is a perfect example of a package that downloads straight from SVN
-<13.11.2008 21:23> <@Cardoe> upstream prefers people use straight SVN
-<13.11.2008 21:23> <@lu_zero> Cardoe that's hammering upstream resources.
-<13.11.2008 21:23> <@lu_zero> and isn't really that kind
-<13.11.2008 21:23> <@dberkholz> not if upstream specifically requests that ...
-<13.11.2008 21:23> <@Cardoe> lu_zero: upstream has a fit when I made tarballs
-<13.11.2008 21:23> <@Cardoe> they want users to use svn
-<13.11.2008 21:23> <@lu_zero> live svn
-<13.11.2008 21:23> <@Cardoe> yes
-<13.11.2008 21:23> <@lu_zero> then it's unrelated to the discussion with dleverton
-<13.11.2008 21:24> <@Cardoe> their own shipping tarballs contain the necessary .svn stuff to just svn up
-<13.11.2008 21:24> <@Cardoe> lu_zero: well MythTV are specific revisions
-<13.11.2008 21:26> <@lu_zero> then it's pointless having them checked out from svn
-<13.11.2008 21:26> <@dberkholz> ok, we're off on a tangent here
-<13.11.2008 21:26> <@lu_zero> apparently
-<13.11.2008 21:27> <@dberkholz> obviously there is still some debate about the best way to move forward, so let's leave the bug open.
-<13.11.2008 21:27> <@dberkholz> i'm putting a quick summary in there
-<13.11.2008 21:29> <@dberkholz> that seems like enough for today
-<13.11.2008 21:29> <@dberkholz> want to end this?
-<13.11.2008 21:30> <@Cardoe> lu_zero: it's about 100mb of data
-<13.11.2008 21:30> <@Cardoe> dberkholz: sounds good
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081211-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20081211-summary.txt
deleted file mode 100644
index 2f3b0686dd..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20081211-summary.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-Roll Call:
-==========
-Betelgeuse: here
-Cardoe: absent, 25 minutes late
-dertobi123: here
-dev-zero: here
-dberkholz: here
-Halcy0n: here
-lu_zero: here
-
-Meeting Topics:
-===============
-
-Technical Issues:
-
-    - Label profiles with EAPI for compatibility checks:
-        Should there be labels in the profiles telling package managers what
-        EAPI the profile uses. This proposal raised some concerns that
-        developers would modify current profiles and bump the EAPI which would
-        harm users' systems.
-
-	    Conclusion:
-	        Profile EAPI files are approved for use in gentoo-x86 profiles.
-            The file for use in profiles is 'eapi'. All current profiles
-            are EAPI="0" and only new profiles can be marked with the profile
-            EAPI markers. Any developer profiles can be marked with a new
-            EAPI.
-
-    - Retroactive EAPI change: Call ebuild functions from trusted working
-      directory:
-        Donnie(dberkholz) commented that it may not be needed to add something
-        to EAPI=0 that is in all the Package Managers.
-
-        Conclusion:
-            Approved. This change applies to all current EAPIs(0,1,2).
-
-    - Metadata variable for DEFINED_PHASES
-    	Should a metadata variable be added containing the list of all phases
-	defined in the ebuild or eclasses?
-
-        Conclusion:
-            Approved. Infra will do a full regen of the metadata cache once
-            portage has support for it.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20081211.txt b/xml/htdocs/proj/en/council/meeting-logs/20081211.txt
deleted file mode 100644
index a47cc6a16b..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20081211.txt
+++ /dev/null
@@ -1,169 +0,0 @@
-<11.12.2008 22:04> <@dberkholz> who's here?
-<11.12.2008 22:04>  * Halcy0n is
-<11.12.2008 22:04> <@dertobi123> <-
-<11.12.2008 22:04>  * lu_zero waves
-<11.12.2008 22:05> <@dberkholz> Cardoe: ?
-<11.12.2008 22:05>  * dev-zero is here as well
-<11.12.2008 22:07> <@dberkholz> Cardoe: council meeting starting, you might want to speak up soon
-<11.12.2008 22:07> <@dberkholz> let's get started
-<11.12.2008 22:07> <@Betelgeuse> yeah
-<11.12.2008 22:08> -!- dberkholz changed the topic of #gentoo-council to: Label profiles with EAPI for compatibility checks (revised)
-<11.12.2008 22:08> <@dberkholz> anyone not ready to vote?
-<11.12.2008 22:09> <@dberkholz> let's vote then
-<11.12.2008 22:09> <@dberkholz> yes from me
-<11.12.2008 22:09> <@dev-zero> second that
-<11.12.2008 22:09> <@lu_zero> ok from me
-<11.12.2008 22:09> <@dertobi123> yes, too
-<11.12.2008 22:09> <@Halcy0n> yes
-<11.12.2008 22:09> <@Betelgeuse> Do we want to say something about when it's allowed to start using later EAPis?
-<11.12.2008 22:10> < ciaranm> "whenever stable portage has had it for three months"?
-<11.12.2008 22:10> < ciaranm> strictly speaking, you can probably get away with it earlier. portage currently just allows everything it supports, and paludis merely warns for 0non-0 things in profiles...
-<11.12.2008 22:11> <@dberkholz> presumably we're only using it in new profiles, so we won't break existing ones
-<11.12.2008 22:11> <@Betelgeuse> dberkholz: But is that really useful? There's hardly any stuff in the end of the stack.
-<11.12.2008 22:11> <@Betelgeuse> Unless we want to start duplicating stuff.
-<11.12.2008 22:12> <@Betelgeuse> ciaranm: What about people installing from stages?
-<11.12.2008 22:12> <@Betelgeuse> ciaranm: But yeah for that we can just get away then.
-<11.12.2008 22:12> <@dberkholz> well, look at zac's email
-<11.12.2008 22:12> <@dev-zero> well, we could perhaps add a sanity check to "eselect profile" before switching profiles
-<11.12.2008 22:12> <@dberkholz>  For example, the base profile can remain at
-<11.12.2008 22:12> <@dberkholz> EAPI 0 and can thus be shared between some older profiles that
-<11.12.2008 22:12> <@dberkholz> conform to EAPI 0 (in all directories of the stack) and some newer
-<11.12.2008 22:12> <@dberkholz> profiles that contain some directories which require EAPI 1 or EAPI
-<11.12.2008 22:12> <@dberkholz> 2. By allowing a mixture of directories with different EAPIs, the
-<11.12.2008 22:12> <@dberkholz> intention is to promote code sharing such that it will be possible
-<11.12.2008 22:12> < ciaranm> Betelgeuse: they get a portage that allows EAPIs 0 and 1 in profiles anyway, so it doesn't really matter
-<11.12.2008 22:12> <@dberkholz> to use a common base profile between older and newer profiles, yet
-<11.12.2008 22:12> <@dberkholz> still be able to use new EAPIs in newer profiles.
-<11.12.2008 22:12> <@Betelgeuse> ah yeah multi parent sounds good to me
-<11.12.2008 22:13> <@Betelgeuse> We can put a version of Portage that supports the labeling to packages.
-<11.12.2008 22:14> <@dberkholz> it makes sense to me that profile EAPIs would be treated a lot like ebuild EAPIs, since we do have concepts of stable & dev profiles
-<11.12.2008 22:15> < ciaranm> Betelgeuse: don't even really need to. portage's current "anything it recognises" behaviour means this only starts to be an issue if we want to use EAPI 3 stuff in profiles, and by then i strongly suspect profile EAPIs will be a done thing
-<11.12.2008 22:15> <@dberkholz> anyway, it seems like zac's pretty well addressed your concern
-<11.12.2008 22:15> < ciaranm> 0 and 1 are supported in stages, and 2 doesn't add anything that makes sense in profiles
-<11.12.2008 22:15> <@Betelgeuse> ciaranm: but my scheme would work for paludis :D
-<11.12.2008 22:15> < ciaranm> paludis just moans noisily unless you set profile_eapi = 2 in the repo .conf file
-<11.12.2008 22:16> <@dberkholz> Betelgeuse: are you ready to move on, or do you have another concern?
-<11.12.2008 22:16> < ciaranm> and paludis users upgrade much more quickly than portage users, so assuming it's approved everyone using paludis will be using a profile_eapi supporting version within a week
-<11.12.2008 22:16> <@Betelgeuse> dberkholz: sure
-<11.12.2008 22:17> <@Betelgeuse> But let's say that a random dev should not go marking profiles EAPI 1
-<11.12.2008 22:17> <@Betelgeuse> Withour prior discussion on gentoo-dev.
-<11.12.2008 22:17> <@lu_zero> ok
-<11.12.2008 22:17> <@dev-zero> Betelgeuse: I don't think that's a problem
-<11.12.2008 22:20> <@dberkholz> dev-zero: do you want to explain why?
-<11.12.2008 22:20> <@dev-zero> ah, sorry. Well, I think that we all got enough training that people who really do change things in profiles know what they do
-<11.12.2008 22:21> <@Betelgeuse> dev-zero: Well I would think it to be quite easy to read the decision as allowed to use.
-<11.12.2008 22:21> <@dev-zero> Betelgeuse: that's true as well
-<11.12.2008 22:22> <@dberkholz> i don't think you can get away with adding higher eapi requirements to existing profiles.
-<11.12.2008 22:22> <@dev-zero> let's put it like that: non-dev-profiles need prior discussion
-<11.12.2008 22:22> <@dertobi123> i'd like to see the prior discussion on gentoo-dev, trained people tend to break things as well and some kind of review wouldn't hurt
-<11.12.2008 22:22> <@dberkholz> otherwise you're breaking users without giving them a clear path to fixing their setup
-<11.12.2008 22:23> <@dberkholz> say someone has an old portage version, they sync their tree, and suddenly their profile's busted and they can't do anything
-<11.12.2008 22:24> <@dberkholz> i think you can only add the eapi files to new or dev profiles
-<11.12.2008 22:25> <@Cardoe> I'm here.
-<11.12.2008 22:25> <@Cardoe> dang time change
-<11.12.2008 22:25> <@lu_zero> Cardoe still discussing the first item ^^
-<11.12.2008 22:26> <@dberkholz> Cardoe: i updated the google calendar last month, fyi
-<11.12.2008 22:26> <@dev-zero> dberkholz: agreed, otherwise you'll always have the possibility that someone ends up with a broken profile
-<11.12.2008 22:27> <@Cardoe> dberkholz: I don't use Google Cal
-<11.12.2008 22:27> <@Cardoe> I was at lunch with my wife and forgot I had to take an earlier lunch today due to the time change.
-<11.12.2008 22:28> <@dberkholz> Cardoe: to catch you up quickly, we're in favor of the profile eapis and are discussing when they are ok to add.
-<11.12.2008 22:28> <@Cardoe> I'm in support of labeling profiles with EAPI markers. However all current profiles need to be EAPI=0
-<11.12.2008 22:29> <@Cardoe> 2008.0 could potentially be EAPI=1
-<11.12.2008 22:29> <@Betelgeuse> s/8/9/
-<11.12.2008 22:30> < ciaranm> Cardoe: 1's safe now
-<11.12.2008 22:30> < ciaranm> Cardoe: 2 isn't, but there's nothing in 2 that's useful in profiles
-<11.12.2008 22:30> <@dberkholz> it seems like we always need to have some basic EAPI=0 profile around so that old users can upgrade to a newer portage
-<11.12.2008 22:30> <@Cardoe> ciaranm: exactly
-<11.12.2008 22:30> <@dberkholz> otherwise they sync and get stuck
-<11.12.2008 22:30> <@Cardoe> ciaranm: I can't see a reason for EAPI=2 appearing in profiles
-<11.12.2008 22:30> <@Cardoe> dberkholz: yeah the very base profile. I agree.
-<11.12.2008 22:31> <@dev-zero> dberkholz: or we get some kind of a pre-sync check
-<11.12.2008 22:31> <@Betelgeuse> dev-zero: how would that end to users?
-<11.12.2008 22:32> <@dev-zero> hmm, would probably only apply to a post eapi-2 era
-<11.12.2008 22:32> <@dberkholz> i don't see how that would work
-<11.12.2008 22:32> <@Betelgeuse> Can we vote on what we have now so that we can move on.
-<11.12.2008 22:33> <@dev-zero> jup
-<11.12.2008 22:33> <@Betelgeuse> Marker files => fine, Current profiles => EAPi 0, New profiles => higher.
-<11.12.2008 22:34> <@dberkholz> dev profiles higher too would be fine, i think
-<11.12.2008 22:34> <@Betelgeuse> sure
-<11.12.2008 22:34> <@Halcy0n> Sounds fine to me.
-<11.12.2008 22:35> <@dev-zero> sounds good
-<11.12.2008 22:35> <@dertobi123> sounds good to me
-<11.12.2008 22:35> <@dberkholz> good enough
-<11.12.2008 22:36> -!- dberkholz changed the topic of #gentoo-council to: EAPI change: Call ebuild functions from trusted working directory
-<11.12.2008 22:36> <@dberkholz> i don't really think it needs council approval to add something to EAPI=0 that exists in all the PMs, but i'm fine with rubber-stamping it
-<11.12.2008 22:37> <@Halcy0n> It has my approval
-<11.12.2008 22:37> <@dertobi123> second that
-<11.12.2008 22:37> <@lu_zero> +1
-<11.12.2008 22:37> <@Betelgeuse> ++
-<11.12.2008 22:37> <@dev-zero> ok from me
-<11.12.2008 22:39> -!- dberkholz changed the topic of #gentoo-council to: DEFINED_PHASES magic metadata variable
-<11.12.2008 22:40> <@dberkholz> anyone got an improvement for this?
-<11.12.2008 22:40> <@dberkholz> or other comment?
-<11.12.2008 22:40> <@Cardoe> hang on
-<11.12.2008 22:40> <@Halcy0n> No, it seemed fine to me.
-<11.12.2008 22:40> <@dberkholz> ciaranm: do you know whether there were any uses of USE-conditional functions in the tree?
-<11.12.2008 22:41> < ciaranm> dberkholz: there aren't
-<11.12.2008 22:41> <@dberkholz> excellent.
-<11.12.2008 22:41> <@Betelgeuse> I remember seeing some global scope use calls at some point.
-<11.12.2008 22:41> <@Cardoe> Well that covers question one..
-<11.12.2008 22:41> <@Betelgeuse> Don't remember specifics.
-<11.12.2008 22:41> < ciaranm> Betelgeuse: those *should* all have gone
-<11.12.2008 22:41> < ciaranm> unless they haven't...
-<11.12.2008 22:42> <@Cardoe> I think you mentioned it should optionally start to roll out into the cache, ciaranm.
-<11.12.2008 22:42> < ciaranm> Cardoe: yup
-<11.12.2008 22:42> <@Cardoe> Any reason why we shouldn't have infra regen the whole cache with that info?
-<11.12.2008 22:42> < ciaranm> well you could
-<11.12.2008 22:43> < ciaranm> it just isn't necessary
-<11.12.2008 22:43> <@Cardoe> I'm for it as well as just regenning the whole thing.
-<11.12.2008 22:43> <@Cardoe> Cause god only knows what packages might not be touched for a year or some such
-<11.12.2008 22:44> <@Halcy0n> Well, since the proposal says you shouldn't assume it is there for existing EAPIs, I don't see a reason to forcefully regen everything.
-<11.12.2008 22:44> < ciaranm> probably wouldn't hurt, if infra don't mind shutting off rsync updates for the six hours or whatever it is that it takes to do a regen
-<11.12.2008 22:44> <@Betelgeuse> ciaranm: find -name "*.ebuild" -exec egrep '^use' {} +
-<11.12.2008 22:44> <@Betelgeuse> ciaranm: Doesn't come out empty
-<11.12.2008 22:45> <@Betelgeuse> same false positives but at least one user in global scope
-<11.12.2008 22:45> < ciaranm> Betelgeuse: most of those look like they won't do what people expect anyway
-<11.12.2008 22:46> < ciaranm> and none of them seem to affect the proposal either
-<11.12.2008 22:46> <@dev-zero> open a tracker bug and give people two weeks time to fix those ebuilds?
-<11.12.2008 22:47> <@Cardoe> I could fix those right now if the power would come back on at home...
-<11.12.2008 22:47> < ciaranm> dev-zero: well, the proposal won't affect any of those anyway
-<11.12.2008 22:47> <@lu_zero> dev-zero if the number if small enough
-<11.12.2008 22:47> <@Betelgeuse> ciaranm: They are probably leftovers from when Portage did not preserve env properly.
-<11.12.2008 22:47> < ciaranm> so really it's just something that should get fixed because it's horrible, not something that has to be fixed before the phases cache can go ahead
-<11.12.2008 22:48> <@Cardoe> ciaranm's right.
-<11.12.2008 22:49> <@Halcy0n> So, is everyone ready to vote on it?
-<11.12.2008 22:50> <@dberkholz> i am
-<11.12.2008 22:50> <@dev-zero> yes
-<11.12.2008 22:50> <@dertobi123> yes and yes
-<11.12.2008 22:50> <@Betelgeuse> yes
-<11.12.2008 22:51> <@Halcy0n> Alright, so vote for it.  I'm in favor of it.
-<11.12.2008 22:51> <@dev-zero> me too
-<11.12.2008 22:51> <@dberkholz> yep
-<11.12.2008 22:51> <@dertobi123> so, yes again
-<11.12.2008 22:51> <@Cardoe> yep
-<11.12.2008 22:51> <@Betelgeuse> fine
-<11.12.2008 22:52> <@Halcy0n> Alright, that should be it then, right Donnie?
-<11.12.2008 22:52> <@Cardoe> ciaranm: you wanna open a bug for infra to turn that on?
-<11.12.2008 22:52> < ciaranm> Cardoe: gotta wait until portage has support first
-<11.12.2008 22:52> < ciaranm> then i think it's automatic
-<11.12.2008 22:53> <@lu_zero> sounds good
-<11.12.2008 22:55> <@dberkholz> i checked beforehand to make sure zac had said he sounded ok with this on that src_fetch_extra bug
-<11.12.2008 22:56> <@dberkholz> let's wrap it up, then.
-<11.12.2008 22:57> <@Halcy0n> Cya later guys, I have to go.  Thanks Donnie.
-<11.12.2008 22:57> <@dertobi123> when's the next meeting? i think we could drop the 25th?
-<11.12.2008 22:57> <@dev-zero> sorry, just a sec
-<11.12.2008 22:57> <@dberkholz> next week if we have bugs open. because of xmas, as we decided last month
-<11.12.2008 22:57> <@dev-zero> got some questions
-<11.12.2008 22:58> <@dev-zero> is the council page going to be updated?
-<11.12.2008 22:58> <@dberkholz> i'll take care of getting things updated tonight
-<11.12.2008 22:58> <@dev-zero> does somebody mind if we're going to write down the new voting rules?
-<11.12.2008 22:58> <@dberkholz> now that we have some actual news to send out
-<11.12.2008 22:59> <@dev-zero> I'm asking because I still didn't see any decision whether the council might consist of only 1,2,3 people in case _reopen_nominations is ranked that high
-<11.12.2008 22:59> <@dev-zero> and I'd rather like to have that cleared before the next elections
-<11.12.2008 22:59> <@dberkholz> we still need to have that discussion
-<11.12.2008 23:00> <@dberkholz> we're out of time for today, though. feel free to propose it for the next meeting in response to the announcement
-<11.12.2008 23:00> <@dev-zero> good, can we discuss it on the council-ml until next meeting?
-<11.12.2008 23:00> <@dberkholz> yep
-<11.12.2008 23:00> <@dev-zero> good
-<11.12.2008 23:00> < ciaranm> http://dpaste.com/98260/ <-- not really in danger of becoming an issue for a while
-<11.12.2008 23:01> <@dberkholz> meeting is over, for anyone who's been waiting for that.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090122-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090122-summary.txt
deleted file mode 100644
index c713e8b2e1..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090122-summary.txt
+++ /dev/null
@@ -1,4 +0,0 @@
-The council discussed potential changes to GLEP 39 and
-whether prep* functions are part of the public Portage API
-and as such would belong to EAPI. No votes were taken during
-the meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090122.txt b/xml/htdocs/proj/en/council/meeting-logs/20090122.txt
deleted file mode 100644
index b006e38929..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090122.txt
+++ /dev/null
@@ -1,266 +0,0 @@
-21:00 <@dberkholz> ok, 2000
-21:01 <@dberkholz> who's here?
-21:01 <@dertobi123> <-
-21:01 <@lu_zero> <-
-21:01 <@dertobi123> obviously
-21:01 <@lu_zero> dertobi123 hmm
-21:01 <@lu_zero> project
-21:01  * lu_zero is afraid to open that maildir
-21:01 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
-21:02 <@dberkholz> project is cool
-21:02 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
-21:02 <@dberkholz> anyone know what's up with cardoe this meeting?
-21:02 <@dberkholz> dev-zero, Betelgeuse, Halcy0n -- check in please
-21:03 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
-21:03 <@Halcy0n> I am here (mostly).  We had a power outage, so I'm bringing up my main desktop.
-21:03 <@Betelgeuse> \o/
-21:03 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
-21:03 <@lu_zero> cardoe or flameeyes?
-21:03 <@dev-zero> dberkholz: hee
-21:04 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
-21:04 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
-21:04 <@dberkholz> well, flameeyes didn't even know there was a council meeting so i'm presuming he wasn't asked to proxy for it
-21:05 <@dberkholz> i know cardoe also asked dang to proxy at least once
-21:05 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
-21:05 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
-21:06 <@dberkholz> dang also heard no proxy request
-21:06 <@dberkholz> well, let's get rolling
-21:06 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
-21:06 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
-21:07 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
-21:07  * fmccor wonders if there's any way to get billie to stay or to go.
-21:07 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
-21:07 <@dberkholz> cardoe's got a .away saying he has little internet access
-21:07 <@dev-zero> maybe timesavings again
-21:07 < tanderson> fmccor: +b ;-)
-21:07 <@dberkholz> ok -- wrt the council size, what are council members' opinions?
-21:08 <@dberkholz> keep as is or let it change somehow?
-21:08 <@dev-zero> well, mine is that there should be a minimum of 3 and a maximum of 7
-21:08 <@dev-zero> and we shall try to reach 7 but not enforce it
-21:09 <@Betelgeuse> I have nothing against adding an option to vote for a smaller council. Not really sure how that voting works though.
-21:09 <@dertobi123> as is, if it needs to changed i'd like to see at least 5 council members
-21:09 <@dertobi123> +be
-21:09 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
-21:10 < darkside_> w
-21:10 <@dev-zero> but if we decide to do staggered votes, the probability of having too less "worthy" candidates decreases
-21:10 <@dberkholz> i think we should also let it change, from 1-7
-21:10 <@lu_zero> I'd keep 5+
-21:10 <@dberkholz> upper limit to make it small enough to be effective, lower limit to let devs decide on what kind of leadership they want
-21:11 <@dev-zero> if you want them to decide what leadership they want you don't set a lower limit
-21:11 <@dev-zero> but in the end they voted once for a council and should therefore get a council and not a single person
-21:11 <@lu_zero> dev-zero I guess he was referring to the 1-7 range
-21:12 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
-21:12 <@dertobi123> dev-zero: agreed, i see no reason nor request nor $whatever to change our leadership model
-21:13 <@dberkholz> Halcy0n: any opinion on whether the council size should be variable, and if so, what ranges?
-21:13 <@Halcy0n> I don't see a reason to make it variable, and I think it would just complicate things.  If the size should change, I think it should be static.
-21:13 <@Halcy0n> (i'm completely back now, I was just catching up)
-21:14 <@Halcy0n> I guess I'm not seeing the reason for changing it, or a big request to change the size of the council.
-21:15 <@dertobi123> fully ack
-21:15 <@dberkholz> well, each additional person makes coming to a decision about anything more difficult
-21:16 <@dev-zero> the reason why this was brought up was that since we now have to _reopen_nominations person determining the allowed candidates we might get to the point where we have too less candidates
-21:16 <@dertobi123> was it that difficult in the past to get some decisions?
-21:16 <@dberkholz> when a vote takes 2 weeks, that's way too long.
-21:16 <@dev-zero> agreed
-21:16 <@dberkholz> when it takes forever to get everyone to post their thoughts on a mailing list, it cripples progress
-21:16 <@Halcy0n> dberkholz: then I'd say we should have people that can be involved and make decisions faster.
-21:18 <@dberkholz> even on irc. we've got 7 people, and waiting for everyone to speak up on an issue means the rest of us are just wasting time
-21:18 <@dertobi123> dberkholz: well, democracy does take it's time ... if we *need* to make quick decision i'm very confident that we are able to make quick decisions
-21:18 <@dev-zero> dberkholz: listening to other's people opinion is not wasting time
-21:18 <@Halcy0n> dev-zero: he means it takes some people 5 minutes to finally respond to something.
-21:18 <@dberkholz> dev-zero: it is when they aren't even at the computer, and you're waiting for them to look at the screen again
-21:19 <@dev-zero> ok, then you've lost me
-21:19 <@dberkholz> if 6 of us are waiting 5 minutes for the 7th person to speak up, that's 30 minutes (6*5) that just got wasted
-21:19 <@dev-zero> I don't see those people around here
-21:19 <@dberkholz> how long does it take us to do attendance at the beginning of a meeting?
-21:20 <@dberkholz> that should literally take 30 seconds
-21:20 <@dev-zero> 3 minutes
-21:20 <@dev-zero> dberkholz: then lets say so
-21:20 <@dertobi123> dberkholz: then the solution would be to move to an ansynchronous medium like email ...
-21:20 <@dertobi123> but still then you won't come to quicker decisions
-21:20 <@Halcy0n> That makes it take even more time.  We want to streamline.
-21:20 <@dberkholz> the solution would be for people to actually devote their time when we've got a meeting
-21:20 < tanderson> *sigh*, think of all the time that's being wasted right now over this discussion
-21:20 <@dertobi123> and who of us isn't doing this?
-21:21 <@dberkholz> we get people together at the same time because we're trying to make progress faster, not sit here
-21:21 <@dertobi123> tanderson: right, this discussion is a plain waste of time
-21:21 <@dev-zero> dberkholz: yeah, so lets do it and stop talk talking about it
-21:22 <@Halcy0n> Then no one get pissed when one of us points out that we are completely waiting on you to respond.
-21:22 <@dberkholz> ok, we'll just stop waiting for people's responses during meetings from now on and move ahead
-21:22 <@dev-zero> good
-21:23 <@Halcy0n> Moving this along, I like the idea of longer terms and staggered elections.  I think a 2 year term and having elections every year is a great idea.
-21:23 <@dev-zero> dito
-21:23 <@dberkholz> i thought solar made a good point
-21:23 <@dev-zero> or just when it's needed and to encourage people to stay at least a half a year
-21:24 <@dertobi123> staggered terms++, i still think 2 year terms are way too long seeing how many council members we loose within a one year term
-21:24 < darkside_> 2 years is too long, think about this year alone.
-21:24 < darkside_> right, dertobi123
-21:24 <@dberkholz> when we're always replacing a couple of people, doesn't that mean the continuity of the others becomes that much more important?
-21:25 <@dev-zero> yes
-21:25 <@dev-zero> on staggered terms, the 2 years is just a maximum time until someone has to take a revote
-21:26 <@dberkholz> i'm really on the fence about this.
-21:26 <@dev-zero> and yes, I think people will still take matters serious enough to not just quit just when they're tired about it
-21:26 < darkside_> another point. i think 2 year terms might scare off people from even running for council. not sure if that is good or bad
-21:26 <@Halcy0n> I see the arguments for both sides as well.
-21:26 <@Halcy0n> darkside_: that might be a good thing actually.
-21:27 <@Halcy0n> darkside_: since it would mean that people that actually go through with it are interested in doing the job.
-21:27 < darkside_> perhaps, or you lose valuable input from "good people that don't commit to it"
-21:27  * darkside_ shrugs and sits back down
-21:27 <@lu_zero> darkside_ input?
-21:27 <@Halcy0n> darkside_: just because they are not on the council doesn't mean they can't give their input.
-21:28 <@dev-zero> darkside_: if they're good people they'd find a way to bring themselves in
-21:28 <@dberkholz> re Halcy0n, look at you talking now. =)
-21:28 <@dberkholz> (you = darkside_ )
-21:28 <@dberkholz> since i'm not convinced there are definite benefits to changing, i'd rather leave things the way they are (pending further convincing, of course)
-21:29 <@dberkholz> i believe solar's argument that continuity is provided by good people getting re-elected
-21:29 <@dertobi123> ack
-21:29 <@dertobi123> that's always been a case in the past and will be in the future
-21:29 < ciaranm> most people who stand for reelection end up getting reelected
-21:30 < ciaranm> not like it's a whole new council every term, and if that did happen it'd indicate something being severely wrong anyway
-21:30 <@dev-zero> well, that's true. Until a council member didn't screw up completely, the probability is high he gets reelected
-21:31 <@dberkholz> i think the best point about a longer term is Halcy0n's. 2 years is an awfully long time in gentoo, and i think it would make people really think about the commitment
-21:32 <@dev-zero> no, I don't think that it would
-21:33 <@dberkholz> ok
-21:33 <@Halcy0n> I'm don't feel strongly either way right now, and it doesn't seem that others do either.  I think this should be tabled until it does become an issue.
-21:33 <@dev-zero> good
-21:33 <@dertobi123> maybe ... but i do expect people to think about a one year commitment, too - and even that didn't work in 2-3 of 7 cases in the past
-21:33 < tanderson> I think the oftener the gentoo community gets to pick their council members the better
-21:34 <@dberkholz> ok. seems like there's not a whole lot of force for change, as Halcy0n says, so let's move on
-21:34 <@dberkholz> that's it for the council meta blah
-21:34 <@dberkholz> anyone want to say something about that PMS bug that they didn't have time to get onto the lists?
-21:35 <@dev-zero> yes, I don't want prep* in the PMS
-21:35 < ciaranm> i'd like the council to make an executive decision to remove prep* from the tree and have done with it
-21:35 <@dberkholz> i left a comment on the bug <http://bugs.gentoo.org/show_bug.cgi?id=250077> asking whether vapier & ciaranm were going to reach agreement
-21:36 < ciaranm> we could agree on some horribly convoluted weasel wording that essentially allows prep* to do absolutely anything
-21:36 < ciaranm> but that's really not something i'd like to see in a specification
-21:36 <@dev-zero> yeah, let's cross beams
-21:36 <@dberkholz> from my reading, it seems like having a way to tell the PM to compress or not compress docs can be useful
-21:37 < ciaranm> dberkholz: it's pointless
-21:37 < dleverton> dberkholz: as far as I remember vapier hasn't commented at all since I pointed out that prepalldocs /did/ change behaviour between portage versions.
-21:37 <@dev-zero> I'd say that people thinking that prepalldocs is something useful should write a proper spec for a function/way it should work and then have it in a future eapi
-21:37 < ciaranm> anyone who cares whether the docs get compressed only cares because it's another pointless option they can change in their config
-21:37 < ciaranm> it has no practical effect, beyond giving users the illusion of choice
-21:38 <@dberkholz> so the assertion is that packages won't care about the compression status of non-html things in their doc directory
-21:39 < ciaranm> if packages care about the compression status, they can't use prepalldocs anyway
-21:39 < ciaranm> because prepalldocs can do undefined things
-21:39 <@lu_zero> as in?
-21:39 < ciaranm> lu_zero: check dleverton's most recent description of its behaviour
-21:39 <@dberkholz> my understanding is that you're saying the PM should handle compression on the backend and the EAPI will not provide for any way to control what it does
-21:40 < ciaranm> depending upon portage version and user config, prepalldocs can make arbitrary changes or no changes to arbitrary files, and it can do it at a later stage than when it's called
-21:40 < ciaranm> dberkholz: i'm saying the package manager shouldn't compress anything
-21:40 <@dberkholz> ok, so how should compression happen?
-21:40 < ciaranm> if an ebuild genuinely needs something compressed, it should explicitly compress it in whichever way it needs it
-21:41 -!- Arfrever [n=Arfrever@gentoo/user/arfrever] has joined #gentoo-council
-21:41 <@dberkholz> as in bzip2 doc/* ?
-21:41 < ciaranm> except that bzip2ing docs is by and large pointless
-21:41 -!- tomaw [i=tom@freenode/staff/tomaw] has quit [Remote closed the connection]
-21:42 <@lu_zero> depending on what is in docs...
-21:42 <@lu_zero> anyway
-21:42 <@dberkholz> i've got half a gig of crap in my doc directory
-21:42 < ciaranm> if docs are huge, they can be made optional
-21:42 <@Halcy0n> I guess I don't really understand the point to compressing the documents either, and if it should happen, it seems like something the package manager should just do automatically if the user asks for it.
-21:42 < ciaranm> dberkholz: and compression makes no practical difference to that
-21:42 <@lu_zero> ...
-21:42 < ciaranm> compressing a 1KByte file gives you a file that takes up the same amount of real disk space
-21:43 <@lu_zero> anyway
-21:43 < ciaranm> if you care about space at all, just remove the docs entirely
-21:43 <@lu_zero> the issue is about having prepalldocs exposed to ebuilds
-21:43 < ciaranm> actually, if you care about space at all, focus on something more useful
-21:43 <@lu_zero> or having a way to say "do not compress/compress"
-21:43 <@lu_zero> ?
-21:44 < ulm> lu_zero: the issue is about properly documenting it
-21:44 <@dev-zero> lu_zero: well, then write a function "docdocs" which does that in a clear and documented way
-21:44 < ciaranm> the issue is whether the council's prepared to mandate "nuke all prep* calls from the tree and then pretend it never existed"
-21:44 < ciaranm> or whether we have to stick with weasel wording that says "prepalldocs can do anything it wants to, or nothing at all"
-21:45 <@dertobi123> "but maybe does compress some files"
-21:45 < ciaranm> dertobi123: not that simple
-21:45 <@dertobi123> heh
-21:45 < ciaranm> that's not even what it does when it works
-21:45 < ciaranm> it really is "anything it wants to"
-21:46 <@dev-zero> so lets nuke it
-21:46 <@lu_zero> dev-zero that isn't an answer to my question, ciaranm's is better =P
-21:46 -!- tomaw [i=tom@freenode/staff/tomaw] has joined #gentoo-council
-21:46 <@Halcy0n> This came up rather late for me to give any useful feedback.  I'm not seeing the great advantage to using it though.
-21:46 <@dberkholz> i'm reading through the bug again
-21:46 <@dberkholz> so far i've made it to comment #27
-21:47 < ciaranm> dberkholz: comment #42 is the useful one
-21:47 <@dberkholz> well, let's lay out some possible options
-21:48  * lu_zero is grepping the tree out of curiosity
-21:48 <@dberkholz> we could get rid of it, and then docs would be compressed or not by the PM, and we don't know if anything breaks till we get bugs
-21:48 <@dertobi123> lu_zero: heh ... /me too ... damn slow sata-drives :(
-21:48 <@dev-zero> lu_zero: there are a lot of ebuilds using prepalldocs
-21:48 < ciaranm> dberkholz: no, then docs would not be compressed at all except where ebuilds say to do so
-21:48 <@dberkholz> we could keep it in EAPI=0 and drop it in EAPI=3 or whatever
-21:48 < ciaranm> dberkholz: the package manager can't safely compress things unless it's told to
-21:49 <@dertobi123> dev-zero: well ... not even a more than handful of packages
-21:49 <@dertobi123> -a
-21:49 <@lu_zero> dev-zero I was more interested on who is using it
-21:50 <@dberkholz> ok, so the consequence of option 1 is that we use extra space. right now we don't really know how much or which packages are affected, and why either of those matter
-21:50 < darkside_> fwiw, prepalldocs is not on devmanual.g.o according to google and at least i do not know how/why to use it
-21:51 <@Halcy0n> darkside_: none of the prep functions are on there.
-21:51 <@lu_zero> from what I see it should force docs to be compressed
-21:51 <@lu_zero> or at least comments say that
-21:51 < ciaranm> lu_zero: except that compression might be a no-op
-21:52 < darkside_> Betelgeuse: i don't think prep*() is on the dev quizzies either, right?
-21:52 < ciaranm> lu_zero: also, you have to check both stable and scm portage
-21:52 < ciaranm> lu_zero: because it does different things in each
-21:52 <@Betelgeuse> darkside_: It's not and has never been asked in reviews either.
-21:52 <@lu_zero> ciaranm dual xor is still encryption
-21:52 <@Betelgeuse> Ideally it would not show up in public APIs either.
-21:52 <@Betelgeuse> If people really need something let's get a new EAPI with it.
-21:53 <@lu_zero> ciaranm I think the prep stuff should stay private
-21:53 < ciaranm> unfortunately portage doesn't split private and public stuff up too well
-21:53 < ciaranm> so it's not always obvious which is which, and some people assume that if it's there it's ok to use it
-21:54 <@lu_zero> nothing that cannot be addressed
-21:54 <@lu_zero> still
-21:54 <@dberkholz> i don't think we're going to get this figured out in the next 7 minutes
-21:54 < ciaranm> you could go with the "nuke prep* and pretend it didn't ever exist" solution right now!
-21:54 <@lu_zero> ciaranm too easy =P
-21:54 <@dberkholz> here's what i want to understand. what concrete benefits do we get from prepalldocs?
-21:55 < ciaranm> *cough* absolutely none *cough*
-21:55 <@dberkholz> if you install every package that runs it, how much space do you save?
-21:55 <@lu_zero> dberkholz I wanted to know that from people using it
-21:55 <@dberkholz> is the other option adding a bunch of code to run dodoc 80 times?
-21:55 < ciaranm> the other option is to just do nothing
-21:56 < ciaranm> there's no guarantee that prepalldocs isn't a no-op anyway
-21:56 < ulm> dberkholz: the other option is to remove any files installed by the build system of a package and reinstall them using dodoc
-21:56 <@lu_zero> ciaranm no-op isn't a problem
-21:56 <@dev-zero> ciaranm: I think dberkholz meant if people want to install compressed docs
-21:56 <@lu_zero> ulm doesn't sound that nice
-21:56 < ciaranm> if you *need* compression, you can't rely upon dodoc either
-21:56 < ciaranm> dodoc isn't guaranteed to compress
-21:57 < ciaranm> the only thing you gain by doing what ulm said is using the user's choice of compression, and that should never have been given to the user as a choice to begin with
-21:57 <@lu_zero> but marks them as docs
-21:57 < ciaranm> dodoc doesn't mark anything
-21:58 <@lu_zero> ciaranm if I make dodoc just a no-op
-21:58 < ciaranm> dodoc can't be a no-op
-21:58 <@lu_zero> (say I do not care about docs)
-21:58 < ciaranm> dodoc has to at least copy the docs
-21:58 <@lu_zero> rm is a compressor as well =P
-21:58 < ciaranm> if you don't care about docs, you nuke them *after* src_install
-21:58 < ciaranm> i'm fairly sure some ebuilds will break if you make dodoc use rm as compression
-21:59 < ciaranm> because ebuilds assume that dodoc's side effects will happen
-21:59 <@lu_zero> ciaranm there are some?
-21:59 <@lu_zero> is that expected?
-21:59 < ciaranm> dodoc makes directories
-21:59 <@dberkholz> we've gotta finish this up on the -dev list
-21:59 <@lu_zero> apparently so
-21:59 <@dertobi123> yep
-21:59 <@dev-zero> unfortunately it seems like, yes
-22:00 <@lu_zero> and I think it will lead to more interesting ends
-22:00 <@dberkholz> i'm going to post the things i think need to happen for us to make a decision
-22:00 <@dberkholz> after i eat lunch
-22:00 <@lu_zero> 2 min left
-22:00 < ciaranm> is anyone going to update http://www.gentoo.org/proj/en/council/ ?
-22:00 <@Halcy0n> dberkholz: sounds good.  I'm going to do a little investigation to see what this actually does give us.
-22:00 <@Halcy0n> ciaranm: I would love to, but I don't have the logs.  If someone has them, I'll do it.
-22:01 <@dberkholz> http://dev.gentoo.org/~dberkholz/20080122_summary.txt is a very rough summary that i'm still working on
-22:01 <@dberkholz> with more my thoughts than an actual summary at the end
-22:01 < tanderson> Halcy0n: I have them for some meetings, not all
-22:01 <@Betelgeuse> Halcy0n: I can send the logs of this channel for the last couple years
-22:01 <@Halcy0n> Are we missing any meetings from that page?  Or did none of them happen?
-22:01 <@dberkholz> there are some other summaries in the same place too
-22:02 <@dberkholz> woops, s/2008/2009 up there
-22:02 <@dev-zero> Halcy0n: the one from December 11th is missing there
-22:03 <@dberkholz> Halcy0n: the only interesting one is http://dev.gentoo.org/~dberkholz/20081211-summary.txt
-22:03 <@dberkholz> i need to leave now
-22:04 <@dberkholz> meeting's over, continue prepalldocs talk on -dev and postpone bug checks to lists/next meeting
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090212-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090212-summary.txt
deleted file mode 100644
index b88b943e4a..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090212-summary.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: here
-Cardoe: here
-dberkholz: here
-dertobi123: here
-dev-zero: here
-Halcy0n: absent
-lu_zero: here
-tanderson(secretary): here
-
-Topics:
-===========
-
-Secretary:
-    - Should the council have a dedicated secretary?
-        Previously dberkholz fulfilled this roll, but he became busy.
-	Because fulfilling the secretary duties can distract from the
-	meeting, a dedicated, non-council member secretary is ideal.
-
-	Conclusion:
-	   tanderson is the new secretary. Logs and summary are to be
-	   posted on the -council mailing list. If no objections to it
-	   are raised in 1 day, it is posted to the council page and lists.
-
-Elections:
-    - Staggered elections
-    	Should there be staggered elections every 6 months where half the
-	    council members stand for reelection?
-
-	Conclusion:
-	    Leave as-is, elections every 6 months is too cumbersome. Full elections
-        will be held once a year.
-
-    - Lack of nominated candidates
-    	What happens if there aren't enough candidates nominated to fill all
-	    the council seats?
-
-	Conclusion:
-	    If the pseudo-candidate '_reopen_nominations' appears in 7th place
-	    or higher those candidates that rank above '_reopen_nominations'
-	    will be the current council. A second period of nominations will
-	    be opened for the remaining council seats. No third period of
-	    nominations will be opened in the event '_repoen_nominations'
-	    ranks higher than the candidates necessary to fill the council.
-
-Technical Issues:
-    - Prepalldocs
-        Should the 'prepalldocs' be allowed in current EAPIs?
-
-        Conclusion:
-            Prepalldocs is banned in current EAPIs(0,1,2). It should be
-            removed from ebuilds. Petteri Räty(Betelgeuse) will make QA
-            checks for repoman.
-
-    - BASH version allowed in the tree.
-        PMS states that ebuilds can only rely on BASH 3.0 features. However,
-        some code in gentoo-x86 uses BASH 3.1 features('+=' being the most
-        notable) and so is not in conformance with PMS. It was suggested that
-        BASH versions newer than 3.0 be allowed in a future EAPI. Ciaran
-        Mccreesh, however, commented that this would require GLEP 55 being
-        accepted so that a package manager would not have to source the ebuild
-        before knowing what BASH version it requires.
-
-        Conclusion:
-            No decision. Doug(Cardoe) will follow this up with
-            Tiziano(dev-zero) as a backup.
-
-Open Bugs
-=========
-
-Technical:
-    - GLEP 54(-scm package version suffix, bug 234711[1])
-	    GLEP 54 solves two problems, version ordering and periodic reinstall
-	    of live packages. The Live Template proposal[2] overlaps in that it also
-	    allows for periodic reinstall of live packages. Luca(lu_zero)
-        maintains that Live Template provides proper version ordering, while
-        Ciaran(ciaranm) maintains that it does not. 
-
-        Conclusion:
-            No decision. The council cracked the whip on Luca(lu_zero) and
-            he's going to handle the issue.
-
-    - GLEP 55(.ebuild-$eapi ebuild suffix)
-        Should .ebuild-$eapi be approved? This ties in with "BASH version
-        allowed in the tree" issue mentioned above.
-
-        Conclusion:
-            No decision. Tiziano(dev-zero) will be handling this bug.
-
-Non-Technical:
-    - Code of Conduct
-        No discussion.
-
-        Conclusion:
-            No decision. Donnie(dberkholz) will be handling this bug.
-
-References:
-[1]: http://bugs.gentoo.org/show_bug.cgi?id=234711
-[2]: http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090212.txt b/xml/htdocs/proj/en/council/meeting-logs/20090212.txt
deleted file mode 100644
index f3fc8600b6..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090212.txt
+++ /dev/null
@@ -1,345 +0,0 @@
-20:03 < dberkholz> Betelgeuse, cardoe, dberkholz, dertobi123, dev-zero, Halcy0n, lu_zero -- who's here?
-20:03 <@dertobi123> <-
-20:03 <@lu_zero> \o
-20:03 < dev-zero> me
-20:03 < dberkholz> Halcy0n informed me half an hour ago that he couldn't make it because of work obligations that came up
-20:03 -!- piotao [i=piotao@p323.math.univ.gda.pl] has joined #gentoo-council
-20:04 < dberkholz> didn't have time to find a proxy
-20:04 -!- Atigo [n=atigo@azx122.neoplus.adsl.tpnet.pl] has joined #gentoo-council
-20:04 < dev-zero> where is cardoe?
-20:05 < dberkholz> i just pinged him in #-dev
-20:05 < dberkholz> ok, we've got 5 because Betelgeuse was here 6 minutes ago
-20:06 < dberkholz> let's get rolling on the secretary thing
-20:07 < dev-zero> should I summarize it?
-20:07 < dberkholz> sure
-20:07 < dev-zero> ok
-20:07 < dev-zero> we need someone doing the summary and upload the logs
-20:07 < dev-zero> in the past dberkholz did it but he got busy
-20:08 < dev-zero> so, to ensure we get those things done I proposed the job of a Secretary
-20:08 < dev-zero> option 1) have someone of use doing it
-20:08 < dev-zero> possibly in a rotating scheme
-20:08 < dev-zero> option 2) have a dedicated person doing it
-20:08 < dev-zero> luckily tanderson volunteered
-20:09 < dev-zero> has someone a better idea?
-20:09 <@dertobi123> no, i like it (that being option 2)
-20:09 -!- Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #gentoo-council
-20:09 -!- mode/#gentoo-council [+o Cardoe] by ChanServ
-20:09 <@Cardoe> sorry
-20:09 <@lu_zero> I'm fine with both
-20:09 < dberkholz> i agree that we should have a dedicated, non-council member do the secretary tasks
-20:10 <@Cardoe> Did we have any volunteers?
-20:10 < rane> -> tanderson
-20:10 < dberkholz> yes, tanderson volunteered
-20:10 < dev-zero> I think that's always up to the council deciding what they want
-20:10 < dev-zero> since we got a volunteer I'd say we accept the offer :)
-20:11 <@Cardoe> I'd agree with that
-20:11 < dev-zero> but I think (and that's what I meant with rules) that every council has to clear that question at the beginning of their term
-20:11 < dev-zero> and stick to it
-20:11 < dberkholz> which question?
-20:11 < dev-zero> the question who's doing the job of the Secretary
-20:11 -!- en0x [i=en0x@unaffiliated/en0x] has left #gentoo-council ["*Dead girls don't say no*"]
-20:11 < dberkholz> oh, sure.
-20:12 <@lu_zero> and in what it consists
-20:12 < dev-zero> yes
-20:12 < dberkholz> ok, here's what i think
-20:13  * dev-zero thinks it would be useful to see when someone's typing
-20:13 < dberkholz> we should make a decision now about how it works. obviously later councils could change the process if they want, but making them rethink the whole thing every time doesn't make sense
-20:13 < dev-zero> good
-20:13 < dberkholz> so we should say, at the beginning of each council term, you pick a secretary who is not a council member (for justification previously provided)
-20:14 < dberkholz> and you have to pick someone who actually volunteers for it
-20:14 -!- PapaDelta [n=PapaDelt@p5B025427.dip.t-dialin.net] has joined #gentoo-council
-20:14 < dev-zero> I already prepared something like this: "the council should appoint a Secretary. If possible, a volunteer who's not council member. If not, they can decide whether a council-member is doing it every time or whether they stick to a rotating scheme."
-20:14 <@lu_zero> I think you can pick as many people as they voluteer
-20:14 <@Betelgeuse> lost connection
-20:14 < dev-zero> no, maximum two
-20:15 <@lu_zero> dev-zero why?
-20:15 <@Betelgeuse> stupid 3G is slow as hell atm
-20:15 < dev-zero> lu_zero: avoiding a mess and you surely get the "what, it wasn't my turn, it was his" play
-20:15 < dberkholz> i really think you need to give each person sufficient experience to do a good job at it.
-20:15 < NeddySeagoon> You want consistancy ... 1 or 2 people max
-20:16 <@lu_zero> ok then it's 2
-20:16 < dev-zero> ok, do we need to discuss it here or can we just decide that we have a Secretary now and phrase it out on the ml?
-20:17 < dev-zero> sorry, shouldn't have been so rude
-20:17 < dberkholz> who's ok w/ tanderson as secretary?
-20:17 < dev-zero> me
-20:17 < dberkholz> i am
-20:17  * dertobi123 is
-20:17  * lu_zero is
-20:17 < dberkholz> ok.
-20:18 <@lu_zero> tanderson are you really _sure_ ?
-20:18 < dberkholz> i would like a 1-day review period on -council before summaries get posted everywhere else
-20:18 < tanderson> lu_zero: yes
-20:18 < dev-zero> dberkholz: agreed
-20:18 <@dertobi123> dberkholz: agreed
-20:18 <@lu_zero> dberkholz ok
-20:18 < dberkholz> tanderson: ok it's all you baby. show us what you've got!
-20:18 < dev-zero> dberkholz: but organized as "published if no complaints"
-20:18 < dberkholz> agreed.
-20:18 < tanderson> dberkholz: I'm working on it1
-20:18 < tanderson> s/1/!
-20:19 < dberkholz> tanderson: just waiting to be impressed after the meeting. =)
-20:19 < dev-zero> tanderson: s/1/\!
-20:19 < tanderson> dev-zero: hrmph
-20:20 < dberkholz> to summarize: tanderson is the new secretary. he will post summaries for 1 day of review on council, after which they default to being posted everywhere. we will work out further details about the process on the list, if people care enough to do so.
-20:20 < dev-zero> perfect :)
-20:20 <@lu_zero> next item
-20:21 < dev-zero> staggered elections?
-20:21 -!- comprookie2000 [n=david@gentoo/contributor/comprookie2000] has joined #gentoo-council
-20:21 < dberkholz> my opinion's already up =)
-20:21 < dberkholz>         DB: Leave as is if 1-year terms. Don't want 6-month staggering.
-20:22 <@dertobi123> leave it as is, 6-month are way too short
-20:22 <@lu_zero> leave it as is.
-20:22 < dev-zero> agreed, 6-month are too short
-20:22 < dberkholz> ok, sounds good.
-20:22 <@Betelgeuse> as is is fine
-20:22 < dberkholz> let's move on then
-20:22 < dberkholz> What if we don't get enough candidates?
-20:22 < dev-zero> good
-20:22 -!- quantumsummers|a [n=quantums@gentoo/developer/quantumsummers] has joined #gentoo-council
-20:23 < dberkholz> my thoughts -- Deal with it when it happens. No rules for hypothetical situations.
-20:23 < dev-zero> I think this question is important because if you once get there not having enough candidates it might get messy
-20:23 <@Betelgeuse> boohoo those running do a reduced council
-20:24 < dev-zero> well, it would already help if you would do a second nomination-period for the remaining slots
-20:24 < dev-zero> after that we can still say we deal with it when it happens
-20:24 <@lu_zero> ok
-20:25 <@dertobi123> sounds good
-20:25 < dberkholz> fine
-20:26 <@Cardoe> trying to come up with every hypothetical situation will waste everyone's time
-20:26 <@Betelgeuse> I don't see a need but majority rules
-20:26 <@Cardoe> look at most governing bodies, they allow this flexibility
-20:26 < dberkholz> we're pretty much just specifying what already happens
-20:26 < dev-zero> Cardoe: no, they ruled it all out
-20:27 < dev-zero> but we're not a governing body
-20:27 < dev-zero> so, simple rules should be applied
-20:27 <@Cardoe> dev-zero: we're governing ourselves and our election process
-20:28 < dev-zero> Cardoe: allright
-20:29 < dev-zero> next?
-20:29 < dberkholz> i want to clarify this
-20:29 < dev-zero> sorry
-20:29 < dberkholz> are we saying that if "reopen noms" turns up in position #6, we will run with the new 5-person council and hold a 2nd election for the last 2 spots?
-20:29 < dev-zero> I'd say so
-20:30 <@lu_zero> could work
-20:30 < dev-zero> put rephrase it to "if not all slots are filled after the first election period a second one should be held"
-20:30 < darkside_> and a third? etc
-20:30 < dev-zero> no
-20:31 < dberkholz> i'd like to avoid a ton of "what if's", so let's move on
-20:31 < dev-zero> agreed
-20:31 < darkside_> just stop at 2 until the next year
-20:31 < dberkholz> we can deal with other stuff if it actually comes up
-20:31 < dev-zero> exactly
-20:31 < dev-zero> if we get to that point something's wrong anyway
-20:32 < dberkholz> ok, i'd like to move on to the next topic, prepalldocs.
-20:32 < dberkholz> dev-zero had 2 questions. do we need more info, and should we ask for discussion on -dev?
-20:32 < dev-zero> I asked because we didn't decide last time
-20:33 < dev-zero> my opinion is basically set, what about yours?
-20:33 <@Cardoe> dev-zero: I say we just allow it to happen twice, total
-20:33 <@Betelgeuse> The less the better
-20:34 -!- Atigo [n=atigo@azx122.neoplus.adsl.tpnet.pl] has left #gentoo-council ["Konversation terminated!"]
-20:35 < dberkholz> ok, sure.
-20:35 < dberkholz> opinions on prepalldocs in pms (bug #250077)?
-20:35 < Willikins> dberkholz: https://bugs.gentoo.org/250077 "prepalldocs should be documented in PMS"; Gentoo Hosted Projects, PMS/EAPI; ASSI; ulm@g.o:pms-bugs@g.o
-20:35 < dev-zero> prepalldocs should be kept internal and usage should be avoided
-20:36 < dev-zero> reason: internal function and change of it's implementation prooves it
-20:36 < dev-zero> if someone want's it's functionality he should propose a solution for a future eapi
-20:36 <@Betelgeuse> agreed
-20:37 <@dertobi123> dito, agreed on that
-20:37 <@lu_zero> sounds sensible
-20:37 < dberkholz> Cardoe: any thoughts?
-20:38 <@Cardoe> yeah getting a little caught up
-20:38 <@Cardoe> but I think dev-zero hit it on the head
-20:39 < dberkholz> ok, so what we're saying is prepalldocs won't be in any current EAPI and needs to be removed from ebuilds. is that accurate?
-20:39 <@Betelgeuse> I can make a check for repoman
-20:39 < dev-zero> yes
-20:40 < dev-zero> Betelgeuse: great :)
-20:40 <@dertobi123> dberkholz: yep
-20:41 < dberkholz> alrighty then
-20:41 < dberkholz> open bug status
-20:41 < dberkholz> glep 54, any change?
-20:42 < ciaranm> most of the objectors to glep 54 have surrendered
-20:42 <@Cardoe> putting it that way makes it sounds like something that we'd really want to adopt
-20:43 <@Cardoe> "we've managed to beat down anyone opposing until they just can't care anymore or have quit the project"
-20:43 <@lu_zero> nobody updated the bug according my thunderbird
-20:43 < ciaranm> Cardoe: the person doing the objecting wasn
-20:43 < ciaranm> Cardoe: 't a gentoo developer
-20:43 < ciaranm> the objections to 54 came from igli aka slong aka ranjit singh
-20:43 < ciaranm> and he objected to it because it came from the wrong people
-20:43 <@Cardoe> I'm just saying. How you put it wasn't the most positive light possible
-20:44 <@Betelgeuse> doesn't 54 still come bundled with 55?
-20:44 < ciaranm> Betelgeuse: 54 works best if 55 is also accepted
-20:44 < dev-zero> a possibility to avoid *.ebuild-123456789 would be to have it as a separate number being incremented only when needed
-20:44 < ciaranm> dev-zero: you're confusing 54 and 55
-20:44 < ciaranm> 54's -scm
-20:44 < dev-zero> yes
-20:45 <@Betelgeuse> ciaranm: there's probably still opposition to that around
-20:45  * tanderson confused them in the summary too, dangit
-20:45 < dberkholz> i like PROPERTIES=live
-20:45 <@Betelgeuse> but if their arguments have merit is an another matter
-20:45  * lu_zero likes that too
-20:45  * dev-zero likes -scm
-20:45 < ciaranm> properties=live doesn't solve anything
-20:45 < ciaranm> you can't have proper version numbers just through properties
-20:45 <@lu_zero> "proper"
-20:46 < dberkholz> you can't put git tag names in a version either
-20:46 < ciaranm> there's no way of using the existing version number syntax to correctly express scm versions
-20:46 <@Betelgeuse> ciaranm: but it does give some of the things that scm is used to provide
-20:46 < ciaranm> Betelgeuse: it doesn't, though
-20:46 < ciaranm> scm's designed to solve the lack of proper ordering with existing version syntax
-20:46 <@Cardoe> I'm in favor of PROPERTIES=live myself.
-20:46 < dleverton> And scm gives all of the things that scm is used to provide.
-20:46 <@lu_zero> depends on what you want to put in the tree
-20:47 < ciaranm> properties=live does nothing
-20:47 <@lu_zero> ciaranm -scm does the same nothing
-20:47 < ciaranm> lu_zero: no, -scm provides correct ordering
-20:47 < dberkholz> looking at this from a bit different approach
-20:47 <@lu_zero> live templates do something
-20:47 < dberkholz> having some way to do this seems like a good thing
-20:47 <@lu_zero> ciaranm "correct"
-20:47 < dberkholz> and having someone who will actively work on finding a solution would be nice
-20:47 < dev-zero> and you can't have foo-1.2.ebuild and foo-1.2.ebuild where one of them has "properties=live" in it
-20:47 < ciaranm> lu_zero: yes, correct
-20:48 <@lu_zero> dev-zero why not?
-20:48 < dev-zero> lu_zero: because they're named the same
-20:48 <@Cardoe> Again.. people are bringing up hypothetical without any real need or defect discussed
-20:48 < dev-zero> Cardoe: wrong, they're not hypothetical
-20:48 < ciaranm> Cardoe: the real was covered the first ten times the glep was discussed
-20:49 <@lu_zero> and again everything got up in the last 1/2 hour
-20:49 < ciaranm> Cardoe: you are aware of the original justifications, right?
-20:49 < ciaranm> lu_zero: you too, since you seem to have forgotten them
-20:49 < dev-zero> ok, people, let's stop it
-20:49 < dberkholz> if they aren't in the glep, they might as well not exist
-20:49 < dev-zero> won't have a conclusion now
-20:49 < ciaranm> dberkholz: they are in the glep
-20:50 < dberkholz> it would be better if it had a comparison with the other suggestions
-20:50 < dev-zero> dberkholz: not the point of a glep
-20:50 < ciaranm> it's the only suggestion that solves the problem. there. easy.
-20:50 < dberkholz> the point of a solution isn't to say why it's the best solution?
-20:50 <@lu_zero> false
-20:50 < dberkholz> that seems ludicrous to me
-20:50 <@lu_zero> and there is a problem defined
-20:51 < dberkholz> anyway, i do agree with dev-zero that we won't suddenly resolve this during the meeting
-20:51 < dev-zero> good
-20:51 < dberkholz> lu_zero: will you pick this up more actively and run with it, or should someone else?
-20:51 -!- hparker [n=hparker@gentoo/developer/hparker] has joined #gentoo-council
-20:51 <@lu_zero> dberkholz I was waiting for zmedico
-20:51 <@Betelgeuse> yeah we should at least put someone actively wroking on these
-20:51 < dev-zero> yes
-20:51 <@lu_zero> and/or other getting input
-20:51 < dev-zero> this is what I proposed on the -ml as well
-20:51 < ciaranm> for as long as people think PROPERTIES=live and -scm have anything to do with each other, this won't get solved because they don't have a frickin' clue what the point of either is
-20:52 < dev-zero> good, then the person who's taking care of should investigate this
-20:52 <@lu_zero> apparently the people using -9999 are happy with it
-20:52 < ciaranm> lu_zero: -9999 is a hack and it's wrong
-20:52 <@Betelgeuse> ciaranm: from end user view they can be used to provide same things
-20:52 <@lu_zero> ciaranm people using it disagree
-20:52 < tanderson> my question: does properties=live solve version ordering issues?
-20:52 < dev-zero> lu_zero: I agree with ciaranm there
-20:52 <@Betelgeuse> ciaranm:  but not all what each other enables of course
-20:52 < dev-zero> lu_zero: I'm using it and I agree
-20:52 < ciaranm> Betelgeuse: no, they're not the same for end users
-20:52 < ciaranm> lu_zero: people using -9999 use it because they have to
-20:52 <@lu_zero> dev-zero you hadn't update the related bug
-20:53 < ciaranm> lu_zero: they do not use it because it is right
-20:53 <@lu_zero> please do now
-20:53 < ciaranm> the implications of PROPERTIES=live and -scm are entirely different and largely unrelated
-20:53 <@Betelgeuse> ciaranm: what's the problem with doing periodic reinstalls with properties live?
-20:53 < dev-zero> ok, people, please
-20:53 < ciaranm> Betelgeuse: nothing, but that's not the entire point of -scm, and -scm isn't the only time you'd want periodic reinstalls
-20:53 < dev-zero> we have other things to discuss
-20:54 <@Betelgeuse> ciaranm: so you validate my earlier point?
-20:54 < ciaranm> Betelgeuse: uh, no
-20:54 < dberkholz> could you guys bounce this over to #-dev?
-20:54 <@Betelgeuse> ciaranm: first you say what I say is wrong and then right?
-20:54 <@Betelgeuse> You lost me.
-20:54 <@lu_zero> better ml-dev
-20:54 < dberkholz> i have another meeting coming up, and i'd like to at least mention the other topics first
-20:54 <@lu_zero> next one
-20:55 < dev-zero> yes
-20:55 < ciaranm> Betelgeuse: i'm saying you've missed the mark by about three miles and are about to fly into a wall
-20:55 < dev-zero> lu_zero: are you taking care of this topic?
-20:55 < tanderson> Who should I put down as responsible for handling glep 54?
-20:55 <@lu_zero> dev-zero I'll poll ml-dev and people and hopefully get the thing discussed again
-20:55 <@Cardoe> The only thing you've said so far is "-scm is the only right solution. people don't have a clue about prop=live vs -scm"
-20:56 < dev-zero> lu_zero: ok, thanks
-20:56 <@Cardoe> the only thing we've gotten thus far are fear mongering statements
-20:56 < dberkholz> tanderson: put luca, and say something about us cracking the whip at him
-20:56 < ciaranm> Cardoe: read the GLEP
-20:56 < ciaranm> PROPERTIES=live and -scm should not be mentioned within the same meeting because they'll just lead to people thinking they're somehow related
-20:56 <@Cardoe> ciaranm: I was asking you to provide us with a reasonable issue and how -scm fixes it while prop=live does not
-20:56 < ciaranm> Cardoe: ordering
-20:56 < tanderson> dberkholz: k
-20:57 <@Cardoe> instead we just had 15 minutes of time wasting
-20:57 <@Cardoe> next topic since we can't seem to get any info
-20:57 < ciaranm> Cardoe: ordering. which part don't you get?
-20:57 < dev-zero> the point is that we currently do all ordering by comparing names of the ebuild, prop=live breaks that
-20:57 -!- hparker [n=hparker@gentoo/developer/hparker] has left #gentoo-council ["uhm.... bye!"]
-20:57 < dberkholz> ciaranm: feel free to continue bringing up glep 54 on the list, since it would be nice to see some progress there
-20:57 < dev-zero> good
-20:58 <@Cardoe> when I say bring up a concrete example with some details.. providing a one word answer doesn't suffice
-20:58 < ciaranm> Cardoe: have you read the glep?
-20:58 < dev-zero> Cardoe, ciaranm: stop it -> ml
-20:58 < dberkholz> the only real thing left besides glep 54 is glep 55, and i think we'll have to push that to the list, much to my regret.
-20:58 < ciaranm> dberkholz: i don't think we're going to get anywhere until Cardoe reads the glep... we're back to my email earlier about people doing their homework...
-20:58 < dev-zero> I'd like to know who's going to take care of GLEP-55 and the bash-issue
-20:59 <@Cardoe> ciaranm: I have read the GLEP.
-20:59 <@Betelgeuse> dberkholz: my opinion still is that 55 needs something using it when it goes in
-20:59 <@Cardoe> ciaranm: I'm asking for a concrete example here in the council discussion
-20:59 < dberkholz> i really think that glep needs more enhancement. if you keep saying nobody gets it, that means it needs to be improved so people do get it
-20:59 < ciaranm> Cardoe: ordering
-20:59 <@Cardoe> to explain it clearly to everyone
-20:59 <@Cardoe> I think the GLEP is lacking and needs work
-20:59 < dev-zero> Cardoe: 55?
-20:59 < ciaranm> there's a whole section in the glep on ordering
-21:00 < darkside_> 55 is the best glep i have seen =/
-21:00 < ciaranm> do you really not understand it?
-21:00 -!- Ken69267 [n=Ken69267@gentoo/developer/ken69267] has joined #gentoo-council
-21:00 <@lu_zero> Cardoe I'm reading again what was the first thing happened when 54 got proposed
-21:00 < dberkholz> i need to go now. dev-zero, could you wrap up the meeting either now or whenever people finish talking?
-21:00 < tanderson> which glep are you guys talking about?
-21:00 < dev-zero> dberkholz: sure
-21:01 <@Cardoe> at this point I would say the meeting is over since there won't be any productive discussion happening on either GLEP
-21:01 < dev-zero> tanderson: of 54 and 55 at the same time, thus the mess
-21:01 < dev-zero> Cardoe: not yet
-21:01 < dev-zero> do we have someone taking care of GLEP-55?
-21:01 < tanderson> dev-zero: exactly my dilemma for the summary
-21:01 <@Cardoe> dev-zero: we haven't had anyone taking care of it for ages because no one has been interested.
-21:02 < tanderson> darkside apparently is
-21:02 < dev-zero> Cardoe: then you do the bash-3.1 issue?
-21:02 <@Betelgeuse> I will be writing a new GLEP soon so I would like to focus on that.
-21:02 <@Betelgeuse> Itäs not related to 54 or 55.
-21:02 < ciaranm> no, we haven't had anyone taking care of 55 because every time it gets pushed the same already-answered questions get raised
-21:02 < dev-zero> dberkholz is taking care of CoC
-21:02 <@lu_zero> ciaranm basically not enough people wants anything about it
-21:02 <@Betelgeuse> ciaranm: probably also because zac has not been interested
-21:03 <@lu_zero> so is a non-issue to most of the people
-21:03 < dev-zero> Betelgeuse: so, do you mind bringing GLEP 55 up on the mailing-list? I'll also join in
-21:03 < ciaranm> 55's necessary, it's just that every time it comes along it gets trolled to death by a couple of malcontents
-21:03 < dev-zero> ciaranm: can you please step aside for a moment
-21:03 <@lu_zero> ciaranm statistics say otherwise
-21:03 < ciaranm> lu_zero: please point me to the legitimate technical objections to 55
-21:04 <@lu_zero> ciaranm I do not need any
-21:04 <@Cardoe> Just because there's no technical objectives to something doesn't mean there's a need for someone.
-21:04 <@Cardoe> er something
-21:04 <@lu_zero> I could plug it getting portage scream about non undersandable files in it's dirs
-21:04 < dev-zero> tanderson: I think we have someone for every point, don't we?
-21:04 < ciaranm> which of the many reasons for 55 being necessary do you not accept?
-21:04 <@lu_zero> and that is a good behaviour.
-21:05 <@Betelgeuse> dev-zero: I thought I said to the contrary
-21:05 <@lu_zero> ciaranm the fact it started as a solution looking for a problem
-21:05  * NeddySeagoon is reminded of VHS vs Betamax ... marketing beat technical excellence
-21:05 <@lu_zero> an hack over a fail tolerance measure
-21:05 <@lu_zero> and so on.
-21:05 < dev-zero> Betelgeuse: then I didn't understand you :)
-21:05 < ciaranm> lu_zero: which of the many problems listed for 55 do you not consider legitimate?
-21:05 < dev-zero> Betelgeuse: I'll take care of it then
-21:05 < tanderson> dev-zero: would that be you for glep 55?
-21:05 < dev-zero> tanderson: yes
-21:05 < ciaranm> lu_zero: 55 came about to solve a half dozen real and nasty problems
-21:05 < tanderson> ok
-21:05 <@lu_zero> ciaranm there is a list of 6 points in the glep?
-21:06 < dev-zero> we're done then
-21:06 <@Betelgeuse> good I need to go as it's getting late
-21:06 < ciaranm> lu_zero: yup
-21:06 <@lu_zero> no
-21:06 <@Cardoe> Additionally, I would oppose the acceptance of both GLEPs until we had sample code for Portage to implement them as well.
-21:06 < ciaranm> lu_zero: the glep lists three bullet points that cover at least six real problems
-21:07 < dev-zero> ok, the meeting is over
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090226-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090226-summary.txt
deleted file mode 100644
index bb3cce5d5f..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090226-summary.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: here
-Cardoe: here
-dberkholz: here
-dertobi123: here
-dev-zero: here
-leio: here
-lu_zero: here
-tanderson(secretary): here
-
-Topics:
-===========
-
-Open Council Spot:
-    - Should leio fill the empty council spot?
-        Since Mark(halcy0n) resigned from the council there is an empty spot.
-        Since Mart Raudsepp(leio) is ranked next from the last election, he is
-        eligible to fill the spot.
-
-        Conclusion:
-            Mart Raudsepp is unanimously approved for the council.
-
-Technical Issues:
-    - GLEP 55
-        There had been quite a bit of discussion on this topic recently.
-        Within hours of the council meeting new proposals were being proposed
-        and discussion was ongoing. 
-
-        Conclusion:
-            No decision as of yet. Ciaran Mccreesh(ciaranm) and Zac
-            Medico(zmedico) volunteered to benchmark the various proposals on
-            the package managers they maintain(paludis and portage
-            respectively. Petteri(Betelgeuse) will assist with the portage
-	    benchmarks. Tiziano(dev-zero) and Alec Warner(antarus) will write
-            up a comparison of the various proposals and their various
-            advantages and disadvantages within a week.
-
-    - GLEP 54
-        There had been some discussion on gentoo-dev since last meeting,
-        though no consensus or agreement had been reached(surprise!)
-
-        Conclusion:
-            Thomas Anderson(tanderson) and Luca Barbato(lu_zero) will write up
-            a comparison of the advantages and disadvantages of the two
-            proposals(-scm and _live). This will be completed within a week.
-
-    - Overlay Masking in Repositories.
-        Brian Harring(ferringb) asked for discussion for when overlays
-        attempted to unmask packages provided by the master 
-        repository(gentoo-x86). Because this is only available in portage
-        (it is contrary to PMS), Brian thought it should not be allowed.
-        
-        Numerous suggestions were made to the effect that if a standardized
-        set format was agreed upon for repositories and package.unmask was
-        allowed to contain sets, then this problem would be fixed.
-
-        Conclusion:
-            No decision, as only discussion was requested. Mart Raudsepp(leio)
-	    will follow up on this with discussion on gentoo-dev
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090226.txt b/xml/htdocs/proj/en/council/meeting-logs/20090226.txt
deleted file mode 100644
index 6cb82a9326..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090226.txt
+++ /dev/null
@@ -1,458 +0,0 @@
-20:00 <@dberkholz> roll call, please
-20:00 <@Cardoe> dberkholz: we might have to moderate this one....
-20:01 < ciaranm> ferringb: you can do that just with assignment too if you impose restrictions upon where the assign occurs... if you need details prod me in another channel
-20:01 < dev-zero> dberkholz: here
-20:01 < tanderson> <--- here
-20:01 <@Cardoe> dberkholz: here
-20:01 <@dertobi123> <- here
-20:01 <@Betelgeuse> \o/
-20:02 <@dberkholz> leio: here?
-20:02 < leio> yes
-20:02 <@dberkholz> alright, first topic is the open spot
-20:02 <@dberkholz> leio accepted, we need confirmation votes from Cardoe and dev-zero
-20:02 < dev-zero> go for it! :)
-20:02 <@Cardoe> dberkholz: good by me
-20:02 <@dberkholz> excellent
-20:03 -!- mode/#gentoo-council [+o leio] by dberkholz
-20:03  * lu_zero is here btw..
-20:03 <@dberkholz> leio: welcome to the council!
-20:03 <@lu_zero> =)
-20:03 <@leio> Thanks :)
-20:03 <@lu_zero> thank you for being here ^^
-20:03 < tanderson> dev-zero: now don't you feel special :P
-20:04 < dev-zero> tanderson: why?
-20:04 < tanderson> dev-zero: no @
-20:04 < tanderson> ;-)
-20:04 -!- mode/#gentoo-council [+o dev-zero] by dertobi123
-20:04 <@dev-zero> dertobi123: thx :)
-20:04 <@dberkholz> i've updated the channel access to reflect halcy0n's resignation and leio's joining
-20:05 <@dberkholz> let's move on to the next topic -- progress toward a solution for glep 55 etc.
-20:05 <@dberkholz> people see my email?
-20:05 <@dberkholz> if not, http://archives.gentoo.org/gentoo-dev/msg_8125876cd6a1e7c3cea3385f02c1ea6f.xml
-20:05 <@leio> dev-zero is not in access list
-20:06 <@Cardoe> dberkholz: thanks. I need to get with infra about missing mail
-20:06 <@dertobi123> "my email" doesn't specify any of this hundreds of mails, but i guess i did read the one you're speaking of
-20:06 <@dberkholz> leio: and updated again. =)
-20:06 <@dberkholz> dertobi123: thus the link =)
-20:06 <@dertobi123> heh
-20:06 <@dertobi123> so yeah, seen that mail
-20:07 <@leio> yes, have read that mail
-20:07 <@dberkholz> antarus: here, by chance?
-20:07 <@Betelgeuse> The features are quite easy to implement so I could work with zmedico to implement both glep 55 and lock in and see how performance goes with Portage in practise.
-20:08 <@lu_zero> that sounds good
-20:08 <@Betelgeuse> If we don't make a decision today I would like us to decided that we will decide in the next meeting unless the sky falls down or something.
-20:08 <@dev-zero> agreed
-20:08 <@dberkholz> well, considering people were still proposing new solutions in the past 2 hours, that would be pretty hard.
-20:09 <@dertobi123> exactly
-20:09 <@dberkholz> (to decide today)
-20:09 <@Cardoe> everytime I open my e-mail there's a new solution proposed
-20:09 <@dberkholz> since i don't think we can decide today, what i suggested instead is concrete action that will move us closer to a decision and make it much easier to decide by having the relevant info all in one place
-20:09 < darkside_> i would like to point out that even EAPI-1 is still bricking people systems today. allenJB reports 4 threads in the forums this month about people bringing systems up to date and haveing to reinstall. i know we can't support people forever, but there it is for your consideration
-20:10 <@dev-zero> darkside_: jup, G55 would solve that as long as pm's ebuild are being kept on EAPI=0
-20:10 <@lu_zero> darkside_ reinstall or update from a stage3 unpacked there?
-20:11 <@dberkholz> basically what i'd like to see is something much like http://dev.gentoo.org/~antarus/projects/gleps/glep-0055.html that stops short of actually proposing a single solution, just compares all of them and how well they accomplish what we need.
-20:11 <@Betelgeuse> dev-zero: I don't see how G55 is related
-20:11 <@Betelgeuse> It just depends on EAPI values
-20:11 <@dberkholz> what do the rest of you think about that?
-20:11 <@Betelgeuse> not how EAPI is specified
-20:11 < tanderson> I don't see how EAPI 1 is related at al really
-20:11 < bonsaikitten> dev-zero: actually system, not only pm ...
-20:12 <@Cardoe> dberkholz: I like it
-20:12 <@dertobi123> dberkholz: i do agree
-20:12 <@leio> dberkholz: yes please
-20:12 < tanderson> I would like Betelgeuse's suggestion about a mandatory decision deadline to be considered as well
-20:12 <@dev-zero> dberkholz: well, why don't you like a proposal for a solution after the comparison?
-20:12 <@dev-zero> tanderson: second that
-20:12 <@Betelgeuse> We really should setup something for regularly testing upgrade paths but discussion about that is for an another day
-20:13 <@dberkholz> dev-zero: because i'd prefer to make my decision based on the data instead of following someone's conclusion
-20:13 <@dberkholz> maybe only 1 solution will actually fit the requirements, in which case it's pretty obvious.
-20:13 <@dev-zero> ok then, let's do it
-20:13 <@Betelgeuse> But the issue here hasn't really been technical merits.
-20:13 <@Betelgeuse> But what people like.
-20:14 <@lu_zero> Betelgeuse yet numbers could help
-20:14 <@Betelgeuse> If we ruled based on technical merits we could just vote 55 in now.
-20:14 <@Cardoe> Betelgeuse: that's why we're looking for a decent comparison. I would expect technical merits to be considered in the comparison
-20:14 <@dberkholz> not everyone shares that point of view
-20:14 < tanderson> lu_zero: not really if the alternate proposals are just bikeshedding( I don't mean that in a bad way)
-20:14 <@lu_zero> given much had been said about embedding in ebuild the information would be a detriment to performances
-20:14 <@leio> I'd have technical objection to 55, and non-technical objections matter as well.
-20:14 <@dberkholz> i've really been enjoying richard freeman's emails
-20:15 <@Betelgeuse> leio: If you have technical do share, as I don't remember seeing any.
-20:15 <@dev-zero> leio: jup, me neither
-20:15 < ciaranm> leio: please provide me a summary of the technical objections to 55, because i seem to have missed them
-20:16 <@leio> I discussed stuff pre-meeting here, I'll try to write something up to the list. I just started catching up with these things today, sorry.
-20:16 <@dev-zero> dberkholz: ok, so what are we going today then?
-20:16 <@dberkholz> i don't think it particularly matters whether objections are "technical" or not
-20:16 <@dberkholz> only that enough of us agree that they are important
-20:17 <@Betelgeuse> It could go down to the opposition easier if we already have it implemented in Portage when we approve it.
-20:17 <@dberkholz> on that note, ferringb also offered to prototype things in pkgcore.
-20:17  * ciaranm already has implementations of everything in paludis
-20:17 <@lu_zero> as long they could be tried and inspected easily
-20:17 <@dberkholz> ciaranm: implementations of every proposal?
-20:17 -!- [equilibrium] [n=[equilib@gentoo/contributor/equilibrium] has quit [Remote closed the connection]
-20:18 < ciaranm> dberkholz: yup
-20:18 <@dberkholz> man, you must have a lot of free time. i'm jealous.
-20:18 < ciaranm> naah, just a nice clean codebase
-20:18 <@Betelgeuse> ciaranm: even eapi 2 || die?
-20:18 <@Betelgeuse> :)
-20:18 < ciaranm> Betelgeuse: that one's trivial
-20:18 <@Cardoe> Betelgeuse: That's another thing I'd like... a Portage implementation ready at approval time.
-20:18 < ciaranm> you can cover every proposal with three implementations
-20:18 <@Cardoe> I'm very much a fan of having code provided along with the proposal.
-20:18 < ferringb> dberkholz: 20 minutes an implementation or so is all thats really required.  it's simple, the slow part is testing each scenario (old manager, new manager, perf, etc)
-20:19 < ciaranm> and one of those implementations differs from another only by three lines of bash
-20:19 <@dberkholz> in a week from now, i'd like to see an updated version similar to http://dev.gentoo.org/~antarus/projects/gleps/glep-0055.html with the changes i suggested and updates for the latest discussion
-20:19 <@dberkholz> that way we have a reasonable chance of actually making a decision by next meeting
-20:19 < NeddySeagoon> and some test resuts ?
-20:19 <@Betelgeuse> ciaranm: Ok should be easy to create the same results for Paludis then
-20:20 < dleverton> Betelgeuse: the benchmarking?
-20:20 < ciaranm> test results: 55 is the only one that solves a whole bunch of problems, and anything involving pre-parsing the ebuild gives a 25% to 50% slowdown for -pi world
-20:20 <@dberkholz> well, if having test results is a requirement, any option that doesn't have them can't be selected. =P
-20:20 < tanderson> dberkholz: handy ;-)
-20:21 <@Betelgeuse> ciaranm: Can't you use the cache for lock down as you can just check mtime of the ebuild?
-20:21 <@leio> note that performance isn't a metric that can be taken easily. An implementation of a method previous much slower could potentially be made almost as quick or quicker with further optimization work
-20:21 < ciaranm> Betelgeuse: how do you mean?
-20:21 <@lu_zero> leio the implementations have to be comparable indeed
-20:21 <@Betelgeuse> ciaranm: If EAPI can only be set by the ebuild in one place then the cache is valid according to the same rules as now
-20:21 < ciaranm> leio: it's a legitimate concern when you have i/o bound processes that've already been carefully optimised for i/o
-20:22 <@Betelgeuse> ciaranm: Or did I get somethign wrong?
-20:22 <@leio> it is not necessarily a concern that can't be overcome
-20:22 < ciaranm> Betelgeuse: that's not actually true for future EAPIs
-20:22 <@Betelgeuse> ciaranm: But if we make it so
-20:22 < jmbsvicetto> Betelgeuse: one could also think about reviewing the cache - something like has been talked in the -scm ml
-20:22 < ciaranm> Betelgeuse: then we need a new cache format, with a second level of EAPI-like-thing... CAPI or whatever
-20:22 < ferringb> all proposals at this point require a single authorative "this is my eapi" setting somewhere (whether filename, invocation, or var setting)
-20:22 <@leio> or putting the EAPI in Manifest, you touch it anyway
-20:22 <@leio> (read it)
-20:23 <@leio> (but probably not in all cases needed, so it does inflict some extra I/O in some situations)
-20:23 <@Betelgeuse> ciaranm: Why as long as we don't run over the available entries?
-20:23 <@Betelgeuse> s/over/out/
-20:23 < ciaranm> Betelgeuse: because the rules used to determine whether a cache entry is valid can change
-20:23 < ciaranm> leio: manifest stops people handing out .ebuild files
-20:23 < ferringb> ciaranm: and the new mechanism will use keys as needs be for it.  that doesn't require flat_hash (even though I prefer flat_hash)
-20:24 < zmedico> Betelgeuse: worst case is that you have the parse the head of the ebuild to pull the eapi which is about the same cost as parsing a cache entry
-20:24 <@leio> it does not, the EAPI is still in the ebuild. ebuild .. manifest caches it in Manifest
-20:24 < ciaranm> zmedico: you mean double the cost
-20:24 <@leio> handing out .ebuild's means the receiving end needs to run ebuild manifest on it anyway
-20:24 < ciaranm> leio: under current rules you can't get the EAPI until you know the EAPI
-20:24 < zmedico> ciaranm: sure but that's only worst case, and not so bad
-20:24 < ciaranm> zmedico: no, it's the normal case
-20:24 -!- spitfire_ [n=quassel@acom231.neoplus.adsl.tpnet.pl] has joined #gentoo-council
-20:25 <@leio> what I'm discussing is an optimization method, it goes along a set of rules for a new method
-20:25 -!- strites [n=Nebula@host34-123-dynamic.8-87-r.retail.telecomitalia.it] has joined #gentoo-council
-20:25 < zmedico> ciaranm: it's the case when unsupported eapis are in the tree.
-20:25 <@Betelgeuse> ciaranm: but you can now if the cache is valid for EAPI
-20:25 <@Betelgeuse> ciaranm: not for other entries of course
-20:25 < ciaranm> zmedico: that needs a real fix (*cough* 55 *cough*) anyway
-20:26 <@lu_zero> a real fix wouldn't involve having also a cache format migration ?
-20:26 < ciaranm> Betelgeuse: if you introduce any new global scope functions in a new EAPI, you also have to introduce a new cache format
-20:26 < ferringb> no you don't
-20:26 < ciaranm> Betelgeuse: unless you go with 55, in which case you don't need to
-20:26 -!- Qlawy [n=marcin@gentoo/user/qlawy] has joined #gentoo-council
-20:26 < zmedico> ciaranm: the only thing I really dislike about glep 55 is the infinite series of file extensions because it's highly unconventional
-20:26 <@Betelgeuse> ciaranm: please xplain why
-20:26 <@dberkholz> i would expect that the main tree is primarily composed of ebuilds that stable portage users can parse and use
-20:26 < ciaranm> zmedico: no more infinite than having PV in there, which we do already
-20:26 < ciaranm> dberkholz: 'primarily' is the problem. it's not 'exclusively'.
-20:27 < zmedico> ciaranm: PV isn't currently part of the file extension
-20:27 <@dberkholz> so having a slot path for minority users doesn't seem too terrible
-20:27 <@leio> I don't think discussion of this during meeting time is a good approach here. I think scheduling an IRC discussion about this could be (e.g, after the meeting)
-20:27 <@dberkholz> slow path*
-20:27 < tanderson> zmedico: or more important as far as gentoo goes, -rX is quite similar
-20:27 < zmedico> ciaranm: I'm talking about moving eapi to the left of the file extension
-20:27 < ciaranm> Betelgeuse: new global scope functions can invalidate the cache in ways that current package managers won't detect
-20:27 < ferringb> err
-20:27 < ciaranm> zmedico: you mean .eapi3.eb?
-20:27 < zmedico> ciaranm: right
-20:27 < ciaranm> zmedico: and PV is part of the file name, which is effectively the same as part of the file extension
-20:28 < ferringb> zmedico: redundant.  just do it as the extension if you're going to try that.
-20:28 <@Betelgeuse> ciaranm: sure but the cache ist ill valid for EAPI from which you get the cache validation rules
-20:28 < ferringb> zmedico: only benefit that gets is being able to still do *.ebuild globbing, which is questionably benefit.
-20:28 < zmedico> ciaranm: when I say "file exension" I'm talking about the part to the right of the last period
-20:28 < ciaranm> Betelgeuse: nope. if you have an ebuild that's EAPI 1, generate cache for it and then do one of these new style changes, the cache entry can show up as still valid
-20:28 < ciaranm> zmedico: how is having a short number in the file extension any different from having a short number in the middle of the filename?
-20:29 <@Betelgeuse> ciaranm: The mtime of the ebuild changes and the cache entry is not valid any more
-20:29 < ciaranm> Betelgeuse: not if the ebuild isn't what changes
-20:29 < jmbsvicetto> ciaranm: last time I read EAPI was defined as being a string - not a number
-20:29 <@Betelgeuse> ciaranm: But you must change EAPI
-20:29 < ferringb> ciaranm: all proposals require the ebuild to specify the eapi
-20:29 <@Betelgeuse> ciaranm: And EAPI can only be set in the ebuild
-20:29 <@dev-zero> jmbsvicetto: pms requires eapis used in Gentoo being numbers
-20:29 < ferringb> ciaranm: all *non g55* to be clear.
-20:29 < ciaranm> jmbsvicetto: it's defined as number for gentoo stuff, and not number for everyone else
-20:29 < ciaranm> Betelgeuse: that's not true, though
-20:29 <@dev-zero> jmbsvicetto: other projects/overlays need to use strings
-20:29 <@Betelgeuse> ciaranm: why not?
-20:30 < zmedico> ciaranm: glep 55 proposes an infinite series of file extensions (the part after the righmost period). I think it's too unconventional. I've never seen anybody do that.
-20:30 <@leio> ability to do *.ebuild globbing is an important aspect
-20:30 < ciaranm> Betelgeuse: you don't know what future EAPIs say, and there're plenty of things they could say that invalidates that
-20:30 < tanderson> zmedico: I have
-20:30 -!- Qlawy [n=marcin@gentoo/user/qlawy] has left #gentoo-council []
-20:30 <@leio> I can not define a MIME type for ebuilds if *.ebuild doesn't match
-20:30 < ciaranm> zmedico: ok, so if we say "after EAPI 99, glep 55 must be reevaluated" you'll be happy?
-20:30 <@Betelgeuse> ciaranm: Well isn't GLEP 55 more restrictvive than that?
-20:30 <@Betelgeuse> ciaranm: Because it's in the file name so it can't be set anywhere else
-20:30 < ciaranm> Betelgeuse: glep 55 removes the problem
-20:30 < ferringb> ciaranm: future eapis will still be reliant on the digest/mtime of the ebuild being a component of it however, combined w/ eapi having to be specified in the ebuild that's enough to detect and recheck the eapi
-20:30 <@dberkholz> let's give this discussion another 10 minutes, then finish up the meeting and let discussion on glep 55/etc continue afterwards
-20:31 <@Cardoe> I happen to agree with leio. That's really my only reservation with GLEP 55 from the start.
-20:31 < ferringb> ciaranm: trying to do *all* other form of cache validation on an unsupported eapi is not possible, thus it's a nonissue you're pointing at
-20:31 < zmedico> ciaranm: no, even a finite series of file extensions is unconventional
-20:31 < ciaranm> you shouldn't be doing *anything* with any ebuild EAPI you don't understand
-20:31 <@leio> this is basically my currently only known technical objection, but I'm still working through everything
-20:31 < ciaranm> zmedico: you mean like .mp3 and .mp4?
-20:31 < ferringb> ciaranm: they cycle significantly slower then eapi one might note
-20:32 <@Betelgeuse> ciaranm: How does it remove it?
-20:32 < jmbsvicetto> ciaranm: that's a good point - don't try to guess what an unknown EAPI does
-20:32 < ciaranm> Betelgeuse: because package managers don't see anything they can't support
-20:32 < zmedico> ciaranm: what ferringb said
-20:32 <@Betelgeuse> ciaranm: They can see the EAPI with lock down just as well
-20:32 < ciaranm> zmedico, ferringb: you can have a cache entry with a set and valid looking current EAPI that ends up being invalid under new EAPI rules
-20:33 < ciaranm> Betelgeuse: if you make the lock strict enough, yes. except that still doesn't let you fix MY_PV.
-20:33 < ferringb> ciaranm: no one is arguing that.  the cache for that specific eapi however will contain the additional chksum info
-20:33 < ciaranm> ferringb: sure, but current package managers don't know that
-20:33 <@Betelgeuse> ciaranm: What is the fix to that?
-20:33 < ferringb> ciaranm: current manageres don't need to know  anything further
-20:34 < zmedico> ciaranm: I think debian has something called an "version epoc" in the file name which they use to change version rules. we sould do the same for eapi
-20:34 < ciaranm> Betelgeuse: the fix is to implement glep 55, and then relax a lot of restrictions that're currently only on PV for historical reasons
-20:34 < jmbsvicetto> ciaranm: but how are current package managers going to apply the rules in a new EAPI they don't know?
-20:34 < ferringb> ciaranm: the cache entry, if the eapi is something they don't know, they should *not* be fucking around with.  it's a nonissue
-20:34 < ciaranm> zmedico: that's what 55 is
-20:34 <@dev-zero> Betelgeuse: allow foo-1.2.3-1.ebuild for example
-20:34 < jmbsvicetto> ciaranm: or are you proposing we can make incompatible changes to an existing EAPI?
-20:34 < ciaranm> ferringb: but the cache entry can contain an EAPI that they know, and still be invalid
-20:34 < ferringb> ciaranm: the only thing they should be doing at best, is checking mtime/digest of the ebuild against a guranteed value in the cache- the existing mtime field
-20:34 < zmedico> ciaranm: right, but the eapi shouldn't go in the extension
-20:34 < ciaranm> jmbsvicetto: the issue is that there can be invalid cache entries that look valid to current package managers
-20:35 < ferringb> ciaranm: again, ebuilds mtime/digest solves this.  this is the first step of cache validation for all years of portage.
-20:35 < ciaranm> zmedico: if you want to push for .eapi3.eb instead of .ebuild-3, i'm not going to argue it
-20:35 < ciaranm> ferringb: only if the ebuild's mtime changes. you don't know that it will in future.
-20:35 <@Betelgeuse> we do
-20:35 < zmedico> ciaranm: well, filename or parsed from head of ebuild are both fine with me
-20:35 < ferringb> ebuild sets the eapi.
-20:35 < ciaranm> Betelgeuse: nnnnnope
-20:35 < ferringb> yep
-20:36 < ferringb> the other example is git.  notice how I kept saying "digest"
-20:36  * tanderson cries at summarising this
-20:36 <@Betelgeuse> ciaranm: If EAPI is in the first line of the ebuild how come ebuild mtime does not change when EAPI is changed?
-20:36 < ferringb> ciaranm: it's addressed; if you think otherwise, give the example now please.
-20:36 <@dberkholz> tanderson: on the bright side, perhaps you'll have done much of the work for the comparison we need =)
-20:36 < tanderson> dberkholz: I volunteered for glep54, not 55 though
-20:36 < ciaranm> Betelgeuse: if you're talking adding in new restrictions that current ebuilds don't follow, then yes, you can fix it
-20:37 < ciaranm> ferringb: change where inherit looks. splat.
-20:37 < jmbsvicetto> ciaranm: that is one alternative proposal
-20:37 <@Betelgeuse> ciaranm: If we arent' changing things why are we talking?
-20:37 < ferringb> ciaranm: irrevelant
-20:37 < ciaranm> Betelgeuse: we're talking about changing some things without changing others too, which you can't do
-20:37 <@Betelgeuse> 20:22 <@Betelgeuse> ciaranm: Can't you use the cache for lock down as you can just check mtime of the ebuild?
-20:38 < ferringb> ciaranm: that's getting into global scope explosions, which aren't related to checking if an existant cache entry for an unknown eapi is valid
-20:38 <@Betelgeuse> I talked about that from the start. Don't know what you are talkinga bout.
-20:38 < ciaranm> Betelgeuse: rephrase that please
-20:38 < jmbsvicetto> Betelgeuse / ciaranm: also, what restrictions could be raised if we started using digests?
-20:39 < ciaranm> jmbsvicetto: if we ditch the current cache format we can fix the validation issues by using a second sub-EAPI. still stinks when you introduce new ebuilds into the tree though.
-20:39 -!- Naib [n=j@fu/hw/naib] has joined #gentoo-council
-20:39 < ferringb> ciaranm: we don't need to ditch the cache format
-20:40 < ferringb> you've been ducking each point I've made contradicting your validation logic justifying ditching the format
-20:40 <@Betelgeuse> I will just see if I hit what ciaramn says when coding it.
-20:40 < ferringb> address those before claiming we need a new format
-20:40 < ciaranm> the mtime rules on the current format aren't enough if you're allowed to change where inherit looks
-20:40 <@dberkholz> let's put this discussion on pause for about 10 minutesf
-20:40 <@Betelgeuse> But inherit has no effect on EAPI
-20:40 < ciaranm> Betelgeuse: currently it does
-20:40 <@Betelgeuse> ciaranm: not with new eapis if we make it so
-20:40 <@dberkholz> we need to get through a couple of quick things
-20:40 < ciaranm> Betelgeuse: still need to deal with existing cases
-20:40 < zmedico> Betelgeuse: we can version the cache like I said here: http://archives.gentoo.org/gentoo-dev/msg_d667a0dd748b2fefa5a5378000104974.xml
-20:41 <@dev-zero> dberkholz: like?
-20:41 < jmbsvicetto> ciaranm: let's just make it a rule - mandatory EAPI setting in ebuild's 1st line and no overriding
-20:41 < ferringb> dev-zero: repositories that aren't pms compliant
-20:41 < ciaranm> the problem with zmedico's versioned cache is that it still imposes the icky performance penalty when new EAPIs with new cache rules come along. 55 fixes that.
-20:41 < nelchael> jmbsvicetto: non-comment line maybe?
-20:41 <@Betelgeuse> ciaranm: I don't see how it makes a difference wrt cache if it's in the file name or the first line for eample
-20:41 <@dberkholz> dev-zero: like, do we agree about the writeup on 55?
-20:41 < ciaranm> jmbsvicetto: see the email i sent to the list
-20:41 < ferringb> ciaranm: every proposal for changing eapi relies on the ebuild specifying the eapi (and being authorative) for all >eapi2 eapis.
-20:41 < jmbsvicetto> ciaranm: (if we choose to keep EAPI as a var or make it a call in the 1st line if we move to EAPI as a function)
-20:41 < ciaranm> Betelgeuse: we don't normally open the ebuild file at all
-20:41 <@Betelgeuse> ciaranm: yes sure
-20:42 < ferringb> ciaranm: meaning inherit no longer matters.  meaning chksum on the ebuild is enough to deal w/ staleness checks on unknown eapis.
-20:42 < jmbsvicetto> nelchael: whatever we can agree on
-20:42 < ciaranm> Betelgeuse: the speed of paludis -pi world is determined almost entirely by how many files it has to open
-20:42 <@dberkholz> seriously, we need to get through 2 things besides this discussion in the next 15 minutes. so if you guys could hold off for a few, that would really help.
-20:42 < zmedico> ciaranm: as said 2 x cache parsing hit isn't bad for worst case
-20:42 <@dev-zero> dberkholz: yes
-20:42 < ciaranm> zmedico: not worst case. normal case. and it's horrid.
-20:43 <@dev-zero> dberkholz: you shouldn't have started with G55 :)
-20:43 < ferringb> dev-zero: yep.
-20:43 < zmedico> ciaranm: no, general case is that tree only contains supported eapis
-20:43 < ferringb> zmedico: stop.
-20:43 < tanderson> dev-zero: haha, good point
-20:43 < ferringb> resume in 15
-20:43 <@dberkholz> i phrased it in a way explicitly designed to avoid this, but it seems that this is impossible.
-20:43 <@lu_zero> ciaranm zmedico will implement it and you'll test it and provide data and script to test ourselves
-20:43 <@lu_zero> there isn't that much to discuss I guess
-20:43 < ciaranm> zmedico: 2x slowdown when the tree contains only supported EAPIs
-20:44 < ciaranm> zmedico: that's unacceptable
-20:44 <@Betelgeuse> Well let's code and see the results.
-20:44 < ciaranm> already did
-20:44 < ferringb> post it
-20:44 < ferringb> test cases included
-20:44 < ferringb> meanwhile the other managers will do the same
-20:44 <@Betelgeuse> ciaranm: Ok. I will test with trunk then.
-20:44 < ferringb> specifically portage so that we can see how the majority are affected
-20:44 <@Betelgeuse> And do the same with Portage.
-20:44 < ciaranm> 8s -> 13s for -pi world on the cache valid case
-20:44 < zmedico> ciaranm: no, all supported eapis + validatable cache -> no slowdown
-20:44 < tanderson> er, +m until 2100?
-20:45 < jmbsvicetto> dberkholz: you may want to start talking about the next subject or we won't move forward ;)
-20:45 < ciaranm> zmedico: slowdown, because you have to open the .ebuild, which you normally wouldn't have to do
-20:45 <@dberkholz> council folks -- do you agree with the writeup of comparisons? if so, who will help on it?
-20:45 <@Betelgeuse> dberkholz: If you need silnce for something else use +m
-20:45 <@dev-zero> dberkholz: I will
-20:45 < zmedico> ciaranm: you don't have to open the ebuild if the cache is validatable
-20:45 < ciaranm> zmedico: you don't know that until you open the ebuild
-20:45 <@dertobi123> dberkholz: yes, I'd like to see the writeup
-20:45 <@dberkholz> 2 minutes to wrap up cleanly without moderation, or +m we go
-20:45 <@lu_zero> dberkholz summarize the scope of the comparisons and the voluteers
-20:46 <@lu_zero> I got a bit swamped and I no more sure about this
-20:46 <@leio> dberkholz: I'd like to see that writeup. I can't help on it as I have to be on devaway for a week
-20:46 < zmedico> ciaranm: you don't have to open the ebuild, you just have to validate it's identity
-20:46 <@dberkholz> btw, feel free to move your discussion over to #gentoo-dev.
-20:46 < ciaranm> dberkholz: heh, funny
-20:47 < ahf> haha
-20:47 < zmedico> ciaranm: for example, by comparing a digest from the cache with a digest in the manifest. that's good enough for dep calc time
-20:47 -!- mode/#gentoo-council [+v tanderson] by ChanServ
-20:47 -!- mode/#gentoo-council [+m] by dberkholz
-20:47 <@lu_zero> ok
-20:47 <@dberkholz> 10 minutes ,then you guys can continue playing
-20:48 <@dberkholz> for those of you who haven't replied yet
-20:48 <@dberkholz> 20:45 < dberkholz@> council folks -- do you agree with the writeup of  comparisons? if so, who will help on it?
-20:48 <@dev-zero> 21:45 <@dev-zero> dberkholz: I will                                                                                                                                                              keytoast~
-20:48 <@Cardoe> I would like to see the write up
-20:48 <@lu_zero> so leio+dev-zero ?
-20:48 <@dev-zero> lu_zero: thought that leio is on devaway for the next week
-20:49 <@lu_zero> oh, right
-20:49 <@dberkholz> Betelgeuse?
-20:49 <@leio> yeah, visiting relatives the first half of my vacation, sporadic internet access and "laptop usage allowance"
-20:49 <@Betelgeuse> I can work with zmedico to get code in and run benchmakrs.
-20:50 <@dberkholz> ok
-20:50 <@lu_zero> please post them on -dev
-20:50 <@lu_zero> so more people could try firsthand
-20:50 <@dberkholz> dev-zero: you're on the writeup, let's see an update by this time next week, using the framework we talked about earlier
-20:50 <@dberkholz> dev-zero: sound good?
-20:50 <@dev-zero> dberkholz: sure
-20:50 <@dberkholz> Betelgeuse: what kind of timeframe?
-20:50 <@Betelgeuse> dberkholz: a week should be enough
-20:51 <@dberkholz> ok, sounds great.
-20:51 <@Betelgeuse> dberkholz: I have exams coming the week after that so won't do it then
-20:51 <@dberkholz> those 2 things should help a lot, and we can move forward from there.
-20:52 <@dberkholz> now the other topic, 54, i have basically the identical request. just getting all the info in one place for a good comparison. tanderson said he could help lu_zero with that
-20:52 <@dberkholz> sound good?
-20:52 <@lu_zero> I'll be glad to have his help
-20:53 <@dberkholz> lu_zero, tanderson -- can you have something similar to antarus's thing by this time next week?
-20:53 <+tanderson> dberkholz: hopefully
-20:53 <@lu_zero> it's basically reformat and extend the latest email
-20:53 <+tanderson> dberkholz: I have exams until monday but spring break after that
-20:53 <@Cardoe> I would say let's shoot for that for next week then
-20:53 <@dberkholz> tanderson: if you can't say yes, what timeframe can you say yes to? =)
-20:53 <+tanderson> dberkholz: ok, yes :-)
-20:53 <@lu_zero> tanderson I hope it won't take much
-20:53 <@dberkholz> alright, good.
-20:54 <@lu_zero> I'd like to do a poll like we had for glep-55
-20:54 <@lu_zero> once we have the summary ready
-20:54 <+tanderson> polls are really useless unless we're going for what's the most popular
-20:55 <@lu_zero> at least to get a wider feeling of our developers and users
-20:55 <@Betelgeuse> well it wasn't really wide thise time
-20:55 <@dberkholz> the last point i want to make is what ferringb brought up about pms and gentoo-hosted repos. please read that bit and chip in if you have anything to say.
-20:55 <@dev-zero> lu_zero: then make -dev mandatory again
-20:55 <+tanderson> dev-zero: a lot of people won't like that
-20:55 <+tanderson> dev-zero: if they aren't subscribed they don't care
-20:55 <@dberkholz> i can put a poll on my blog, just give me the question and answers, and point people there.
-20:56 <@lu_zero> dberkholz ok
-20:56 <@dberkholz> i don't think we need to talk about that anymore now
-20:56 <@leio> in for example gnome overlay we negate gentoo-x86 package.masks on purpose to make it a lot easier for the users of the overlay. We'd like to continue doing so, and have it working as portage acts like now.
-20:56 <@dberkholz> leio: ok, i can't remember whether you said that on the list but could you if you haven't?
-20:56 -!- grobian [n=grobian@gentoo/developer/grobian] has joined #gentoo-council
-20:56 <+tanderson> I don't think that'll be a good idea especially when we get to proper repository support
-20:56 <@dev-zero> leio: well, I get ugly warnings all the time since it's against pms
-20:56 <@leio> I will, yes. EvaSDK said something along those lines already
-20:57 <@dberkholz> that's everything besides the glep 55 discussion i wanted to cover
-20:57 <@leio> most of the overlays work on top of gentoo-x86, and it makes logical sense for that to work like it does right now with portage
-20:58 <@lu_zero> dberkholz before I forget for the next council could we get an update about the cvs-> git status?
-20:58 <@leio> I'd hate to lose that just because it doesn't conform to some PMS document, that is supposed to document how portage works
-20:58 <@lu_zero> leio we should make a difference between overlays and alternate repos
-20:58 <@dev-zero> dberkholz: and is there a writeup for Google SoC 2008 ?
-20:58 <@leio> sure, just don't make it impossible to do what we do now :)
-20:58 <@dberkholz> exactly the same blocker as 2 weeks ago -- see http://archives.gentoo.org/gentoo-scm/msg_df7c98ec7d2e313856bec31769df407f.xml
-20:58 <@lu_zero> since those thing overlaps but aren't the same
-20:58 <+tanderson> I have to leave soon, I'll get to the summary in a bit
-20:58 <@dberkholz> dev-zero: no, but i've been blogging and posting about it like crazy
-20:59 <@dberkholz> so can we close up the meeting, unmoderate, and get back to that?
-20:59 <@leio> maybe voice ferringb as the requestor for this discussion?
-20:59 -!- mode/#gentoo-council [+v ferringb] by dev-zero
-20:59 <+ferringb> thank you
-21:00 <@leio> so perhaps a concrete proposal on how to support both in a formalized way from someone?
-21:00 <+ferringb> essentially, if you want overlay x to be able to override repo x's masks, formalize it then; the current state requires basically collapsing it all down into a single stack which is very unfriendly to implementations designed for multiple stacks
-21:00 <+ferringb> further, it goes beyond adjustments of masks- pms specifies profile chunks as files
-21:00 <@leio> some file that says a name for a stack or something. Or declaring a parent repository, or..
-21:01 <@lu_zero> ferringb so also that part should be updated as well?
-21:01 <+ferringb> portage extended it's user profile support (directory or file) to *all* profiles- now the only spec non-portages can follow is pms, but it blows up in our face on overlays following portages looser standards
-21:01 <+ferringb> lu_zero: no, it can't be
-21:01 <+ferringb> lu_zero: it would break older portage installations via allowing that in gentoo-x86
-21:01 <@dberkholz> i've got other meetings i have to attend for the next couple hours. dev-zero, could you please take care of trying to push this topic to the list, then unmoderating and returning to discussion in the next 5 min or so?
-21:02 <@dev-zero> dberkholz: sure
-21:02 <+ferringb> the problem here is that we have unversioned changes occuring.  version the sucker, if portage has it's own overlay repository format that isn't pms (which *is* the case now), it needs to be marked so paludis/pkgcore aren't getting screwed, or forced to loosen our pms compliance for all repos
-21:03 <+ferringb> wordy, but does that make sense?  the real issue here is that these repos we have to assume are pms compliant, there is no marking to rely on to tell us otherwise- because portage is dominant and allows more then pms specifies, we're forced to either have things blow up
-21:03 <+ferringb> or to disregard pms and follow what portage does.
-21:03 <@leio> I'll bring my stuff on the list to get the discussion continued, but I'm not sure I manage before I leave in the morning and be completely without Internet access for a few days.
-21:03 <@dev-zero> ferringb, leio: why not bring in the needed stuff in a proposal for the next eapi?
-21:04 <+ferringb> dev-zero: profiles aren't versioned by eapi
-21:04 <@leio> this isn't really an ebuild thing. How does EAPI apply?
-21:04 <+ferringb> no repository metadata is.  only ebuilds are versioned by eapi
-21:04 <+ferringb> leio: it doesn't apply
-21:04 <@dev-zero> ferringb: we have profile EAPIs now
-21:05 <+ferringb> dev-zero: not for repository level masks.
-21:05 <@lu_zero> then I guess we are set about that to do in this regard
-21:05 <@dev-zero> ferringb: yes, we do
-21:05 -!- mode/#gentoo-council [+v jmbsvicetto] by leio
-21:06 <@dev-zero> but anyway, we're over time already
-21:06 <@dev-zero> ferringb, leio: please bring that topic up on -dev again and we'll talk there about it
-21:06 <@leio> yeah, I'll try hard to bring up my stuff to the list in a new thread name before I get asleep
-21:06  * ferringb sighs, can, but people ignore it
-21:06 <+jmbsvicetto> one concern I have for KDE is that we frequently need to mask some versions in Portage, but to unmask them in the kde-testing overlay (where we're conducting the bulk of our work)
-21:06 <+ferringb> as does upstream portage.  basically leaves the option of loosening to portages spec and disregarding pms
-21:06 <@leio> pretty much exactly the same use case in gnome overlay
-21:07 <@leio> we could probably do package.unmask entries, but that doesn't really work in a profile iirc
-21:07 <@leio> (e.g, not even supported such a list of unmasks)
-21:07 <+jmbsvicetto> profile EAPIs would help, but as ferringb stated, that doesn't help with files directly under /profiles
-21:07 <+ferringb> leio: package.unmask was one of the additions portage leveled iirc.
-21:07 <@dev-zero> well, I'm going to open the channel for discussions again
-21:08 -!- mode/#gentoo-council [+tnc] by dev-zero
-21:08 <@lu_zero> jmbsvicetto as current workaround won't be possible provide unmask file to add in /etc/portage ?
-21:08 <+ferringb> even if you did profile eapis, you'd have to create an eapi w/ the changes portage has forced, then bump every involved profile (repo included) to it where it's used
-21:08 <+jmbsvicetto> lu_zero: yes, but that affects the way users work with the overlay
-21:08 <+ferringb> which is an upgrade without reason.  repository level format marker handles this far cleaner
-21:09 <+jmbsvicetto> lu_zero: by putting the file in the overlay profiles dir, users don't need to "think about it"
-21:09 <@leio> the whole point of doing the mask negation in the overlay is to avoid users having to put stuff in /etc/portage
-21:09 <@leio> we update it for them, they can't forget removing those package.unmask entries from /etc, etc
-21:09 <@lu_zero> jmbsvicetto giving a notice and explanations would be understood or you are afraid it would cause an outrage?
-21:09 <+jmbsvicetto> lu_zero: I'm sure it would cause an outrage
-21:10 -!- mode/#gentoo-council [-m] by dev-zero
-21:10 <@lu_zero> leio ln the file in $overlay/scripts won't be the same?
-21:10 < ciaranm> leio: having global behaviour changing merely because you add a repo is horrid
-21:10 <+jmbsvicetto> lu_zero: users would start complaining why we were making their life harder
-21:10 <@lu_zero> jmbsvicetto I see
-21:10 < ciaranm> a better solution is to get sets standardised, and not how portage does them now...
-21:10 <+ferringb> having users yelling at me unable to use pkgcore because y'all follow portages standards is horrid also
-21:10 <@leio> ciaranm: that is your opinion, and most users disagree with it.
-21:10 <@leio> (about it being horrid)
-21:10 <+jmbsvicetto> ciaranm: I would love to get your feedback about sets
-21:10 <+ferringb> encode it in a format
-21:10 <@leio> it is the logical approach we are doing
-21:10 < ciaranm> leio: most users haven't had access to an easier alternative
-21:10 <+ferringb> it solves everyones complaints and gives us a way to deal with this
-21:10 <+jmbsvicetto> ciaranm: We should really be trying to define a format that all 3 PMs support
-21:11 < ciaranm> leio: you're doing what portage lets you get away with, not what's best
-21:11 < ciaranm> jmbsvicetto: indeed
-21:11 < ciaranm> jmbsvicetto: the paludis format is rather clean... and documented...
-21:11 <@dev-zero> tanderson: I think the meeting can be concidered over
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090312-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090312-summary.txt
deleted file mode 100644
index a32fede82c..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090312-summary.txt
+++ /dev/null
@@ -1,113 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: here
-Cardoe: here
-dberkholz: here
-dertobi123: here
-dev-zero: here
-leio: here
-lu_zero: To Be Determined, 37 minutes late
-tanderson(secretary): here
-
-Topics:
-===========
-
-EAPI-3 Proposals:
-
-    Note: The following two proposals were discussed before it was realized
-    that there was not sufficient time to discuss all of them. At that point a
-    call for objections to any of the proposals found at [1] was asked for,
-    and none were made. A full list of proposals for EAPI 3 follow.
-
-    - New phase: pkg_pretend
-        This phase is most useful for displaying conflicting USE flags at
-        dependency resolution time(pretend), though it has various other uses
-        so that errors about installing the package can be displayed before
-        installation of packages begin.
-
-        Conclusion:
-            Approved for the draft.
-
-    - [flag(+/-)] USE dependencies
-        This may be needed when one wishes to depend on a package with a
-        certain USE flag but if the USE flag is not present in that package
-        assume it is on or off(+ and - respectively).
-
-        Conclusion:
-            Approved for the draft.
-
-    - Multislot Dependency Specifications
-        This allows ebuils to tell the package manager that runtime
-        dependencies are not swappable(:1 installed at runtime can't be
-        removed even though :2 'satisfies' the dependency).
-
-    - PROPERTIES mandatory in cache
-        Some information provided by this variable is useful at --pretend
-        time(interactive packages). 
-
-    - DEFINED_PHASES mandatory in cache
-        Same reasons as for PROPERTIES, but is also useful for determining
-        the phases a package provides with just the cache.
-
-    - Provide a default src_install prototype.
-        Get rid of the need for the src_install functions with just `emake
-        install` in them. Some discussion is needed to clear up issues with a
-        DOCS variable for extra documentation and a list of docs to
-        automatically get installed.
-
-    - Provide a `docompress` function.
-        This function serves as a replacement for prepalldocs. `docompress`
-        can optionally compress files in /usr/share/doc according to a set of
-        inclusion and exclusion lists.
-
-    - Provide a '-r' option to `dodoc`
-        Providing a way to put `dodoc` in recursive mode is widely accepted.
-
-    - Make `doins` preserve symlinks
-        This obsoletes the `cp -R` constructs frequently seen and is easy to
-        implement.
-
-    - Limit values in $USE to those in $IUSE.
-        Certain USE_EXPAND flags may be in USE even if they aren't
-        specifically set in IUSE. Eliminate this.
-
-    Next Action:
-        The Council agreed to have portage implement as many of these as
-        possible in a month and then make that EAPI 3.
-
-Technical Agenda Items:
-
-    - GLEP 54
-        Thomas(tanderson) sent out a comparison of GLEP 54 and the liveebuild proposals.
-        Among those discussing GLEP 54 there was a general consensus that
-        there was nothing wrong with it as a first step to get correct
-        ordering. Luca(lu_zero) commented that all he was concerned about was
-        that there was not enough 'meat' to the GLEP.
-
-        Next Action:
-            Doug(Cardoe) and Luca(lu_zero) intend to write a
-            GLEP to handle the second part of the problem(making the revision
-            available to ebuilds/package manager/users.
-
-    - GLEP 55
-        Petteri, Zac, and Ciaran were supposed to benchmark the various
-        proposals and report back. Zac did not write the code for portage so
-        Petteri had nothing to report on this issue. Ciaran commented that
-        the solutions other than GLEP 55 had a 50% slowdown in the valid cache
-        situation compared to GLEP55, but did not post the raw numbers or the
-	    patches used.
-
-        Next Action:
-            Zac needs to benchmark the proposals in portage.
-
-Open Floor:
-===========
-
-- Migration of KEYWORDS from ebuilds to profiles:
-  Ned Ludd(solar) brought this up, but it came up in the middle of agenda
-  items so was not talked about much. Some points were made that such a scheme
-  would require a git conversion, but nothing was agreed upon. 
-
-
-References:
-[1]: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090312.txt b/xml/htdocs/proj/en/council/meeting-logs/20090312.txt
deleted file mode 100644
index 51a8824b94..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090312.txt
+++ /dev/null
@@ -1,359 +0,0 @@
-20:01 <@dberkholz> ok, let's get started
-20:01 <@Cardoe> Betelgeuse: yes?
-20:01 <@Betelgeuse> Cardoe: just to find out that you are here
-20:01 -!- ferdy [n=ferdy@exherbo/developer/ferdy] has joined #gentoo-council
-20:01 <@Cardoe> Betelgeuse: I've been here talking for the last hour
-20:01 <@dberkholz> Betelgeuse, Cardoe, dberkholz, dertobi123, leio-dl are here
-20:01 <@Betelgeuse> dev-zero:
-20:01 <@dberkholz> lu_zero, dev-zero -- pong please
-20:02 <@dev-zero> dberkholz: pong
-20:02 -!- arkanoid [n=arkanoid@exherbo/developer/arkanoid] has joined #gentoo-council
-20:02 <@dberkholz> lu_zero: check in again when you're back
-20:02 < fmccor> lu_zero was here 9 minutes ago
-20:02 <@dberkholz> let's start
-20:03 <@dberkholz> anyone mind if we talk briefly about the path to EAPI=3, even though it wasn't on the draft agenda?
-20:03 <@Betelgeuse> There won't be a shortage of ideas the main deciding thing is zac.
-20:03 <@Betelgeuse> Unless someone gets down to coding.
-20:04 <@dberkholz> zmedico: around?
-20:04 <@Betelgeuse> As can be seen with GLEP 55 if we rely on zac we really can't make much plans.
-20:04 <@dev-zero> Betelgeuse: for at least one issue on the task there's already a patch for portage
-20:04 < ciaranm> half the things on the list are five minute bash jobs
-20:04 <@dev-zero> second, some issues are pretty much isolated and don't need much portage knowledge
-20:05 <@Cardoe> We don't necessarily have to rely on Zac. Most of the items are really basic and can be coded by someone with 30 min time.
-20:05 <@Betelgeuse> good
-20:05 < ciaranm> the one that's slightly non-trivial is [use(+)] deps (assuming we like that syntax), and afaik that's considered the driving force behind EAPI 3
-20:05 <@dev-zero> yes
-20:05 <+tanderson> hi, I'm here now
-20:05 <@Betelgeuse> Well repoman support would help a lot too.
-20:05 <@dev-zero> and the multislot dep issue
-20:05 <@Cardoe> ciaranm: was that for handling the missing case?
-20:05 < ciaranm> Cardoe: yeah
-20:06 <@dberkholz> which line is that on the spreadsheet?
-20:06 <@dberkholz> use(+)
-20:06 <@dev-zero> 6
-20:06 <@Cardoe> ciaranm: can you give a quick description of the syntax. The spreadsheet kinda is weak on it and I'd also like to have a description of the syntax for the logs.
-20:06 <@Betelgeuse> dev-zero: please post a link so it gets logged
-20:06 <@leio-dl> [use(+)] has the same portage stock message issue as other USE deps, but that's a topic for ml and possibly separate thing
-20:06 <@Cardoe> http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ is the spreadsheet and #6 is what we're talking about
-20:07 < ciaranm> Cardoe: the syntax exheres-0 uses is foo/bar[flag(+)] and foo/bar[flag(-)]
-20:07 <@dev-zero> here are the eapi-3 feature proposals: http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
-20:07 <+tanderson> I need to catch up :\
-20:07 < ciaranm> where (+) means "pretend it's on if foo/bar doesn't have flag in IUSE"
-20:07 <@Cardoe> dev-zero: they're missing a bunch that ciaranm suggested and I'd like to see merged in.
-20:07 <@Cardoe> ciaranm: thanks
-20:07 <@dev-zero> Cardoe: hmm, which ones?
-20:08 <@Betelgeuse> I don't really see it solving the remove use flags problem unless we always start to use these atoms.
-20:08 <@dev-zero> Betelgeuse: that's true
-20:08 < ciaranm> Betelgeuse: until someone removes the use flag in a newer version, though, you don't know what your dep will want
-20:08 <@Betelgeuse> You should always check reverse stuff any way.
-20:08 < ciaranm> if you're currently foo/bar[baz], and new bar has no baz, you don't know in advance whether it's because baz is always on or has been removed or what
-20:09 <@Betelgeuse> ciaranm: I know but I was referring to the spreadsheet.
-20:09 <@Cardoe> I think it's a good syntax as any unless there are any technical objections.
-20:09 < ciaranm> so if you do foo/bar[baz] until you know, the repoman can flag it down for you once a new foo/bar comes along
-20:09 <@leio-dl> we just need tools to show automatically what depends on an IUSE in any way to deal with it
-20:09  * ciaranm really can't type tonight
-20:10 <@Betelgeuse> dev-zero: One thing to add is doexamples
-20:10 <@Cardoe> ok lemme speed this up.
-20:10 <@leio-dl> but repoman will only tell it if you run it inside the package that has foo/bar[baz] in depends, not when you are running it inside foo/bar after removing baz from IUSE
-20:10 <@dev-zero> Betelgeuse: good point
-20:10 < ciaranm> leio-dl: yup. fortunately, people do global tree scans regularly to catch that sort of thing.
-20:10 <@dberkholz> there's some point where we have so many do* actions that it's harder to remember them all than to do an insinto..
-20:10 <@leio-dl> always after the fact. Lets move on
-20:11 < ciaranm> leio-dl: there's no nice easy solution to dealing with reverse deps, and use deps don't really alter that
-20:11 <@Cardoe> Do we want [use(+)] deps to go into the EAPI-3 draft? dberkholz, leio, dev-zero, Cardoe, Betelgeuse, lu_zero?
-20:11 <@Cardoe> I say yes.
-20:11 <@leio-dl> yes
-20:11 <@dertobi123> yep
-20:11 <@dev-zero> yes
-20:11 <@dberkholz> fine w/ me
-20:11 <@Betelgeuse> dberkholz: well in the long term we should more helper stuff to the tree
-20:11 <@Cardoe> dertobi123: sorry for missing you off
-20:11 <@dertobi123> Cardoe: :P
-20:11 <@Betelgeuse> Cardoe: sure
-20:11 <@Cardoe> dertobi123: too many d's
-20:12 <@dertobi123> heh
-20:12 <@Cardoe> Ok. Next item on the draft.
-20:12 <@Cardoe> pkg_pretend()
-20:12 <@dberkholz> we'll have to vote for higher council nick diversity next time.
-20:12 <+tanderson> bwahaha
-20:12 <@dberkholz> i am totally for pkg_pretend
-20:12 <@Cardoe> I would like to see pkg_pretend() useful for displaying USE conflicts
-20:13 <@Cardoe> http://bugs.gentoo.org/show_bug.cgi?id=75936
-20:13 <@dberkholz> there are so many ways it's useful
-20:13 <@Cardoe> To allow the developer to put a description behind it.
-20:13 <@dev-zero> yes, me too, but we should still try to find a more pm-based solution for USE conflicts
-20:13 <@Cardoe> because the current way Portage displays it sucks
-20:13 <@dberkholz> telling people we're gonna break their system before a merge instead of after
-20:13 <@Cardoe> and users are confused
-20:13 <@dberkholz> gentoo sysadmins have complained to me about that so many times
-20:13 <@Cardoe> pkg_pretend in draft EAPI-3.... dberkholz, leio, dev-zero, Cardoe, Betelgeuse, lu_zero, dertobi123?
-20:13 <@dev-zero> yes
-20:13 <@Cardoe> yes
-20:14 <@dberkholz> 20:12 < dberkholz@> i am totally for pkg_pretend
-20:14 <@Betelgeuse> Cardoe: Do we need to go through one by one?
-20:14 <@dertobi123> yes
-20:14 <@leio-dl> abstain (haven't read and thoguht about it enough)
-20:14 <@Betelgeuse> Is there anything people disagree on?
-20:14 <@Cardoe> Betelgeuse: I'm looking for us to nail down a "draft" list.
-20:14 <@Cardoe> That we can hand over to the PM maintainers to implement
-20:14 <@Cardoe> They come back to us once we've got some code and we'll formally resolve the differences and finalize EAPI-3
-20:15 <@Betelgeuse> Cardoe: What good does that do if we are tied to Portage implementing things?
-20:15 < ciaranm> can always take things out if it turns out portage can't do them quickly
-20:15 <@dberkholz> how about we come up with a list of things on that spreadsheet that any of us disagrees with instead
-20:15 <@Cardoe> Fine
-20:15 <@Betelgeuse> I would propose as to set a time and then see what Portage has then.
-20:15 <@dberkholz> it'll take a while to go through 20-something positively
-20:15 <@Betelgeuse> And use that for EAPI 3.
-20:15 <@dev-zero> I already cancelled some features out (those with prio=99)
-20:16 <@Cardoe> dev-zero: please add a reference to bug #75936 to item #1
-20:16 < Willikins> Cardoe: https://bugs.gentoo.org/75936 "method for handling conflicting USE flags at --pretend time required"; Portage Development, Core - Ebuild Support; NEW; ciaran.mccreesh@googlemail.com:pms-bugs@g.o
-20:16 <@Betelgeuse> I say a month is fine.
-20:16 <@dev-zero> Cardoe: I'm sorry, but that's not the same thing
-20:17 <@Betelgeuse> Any comments?
-20:18 <@dberkholz> so basically request a specific list of features in portage, then take whatever's done in a month and call it 3?
-20:18 <@dertobi123> putting those marked with priority 1 to 3 on a draft and look in month what we have implemented in portage would work for me
-20:18 <@dertobi123> in a month*
-20:18 <@Betelgeuse> dberkholz: it can implement more too
-20:19 <@dberkholz> sorry, didn't understand that
-20:20 <@Betelgeuse> dberkholz: I don't think we need to restrict ourselves to the items on that list of there is more implemented (if this is likely is of course another matter)
-20:20 <@dberkholz> all i'm saying is that we actually provide a list of stuff that we want, instead of having this list of random features that a million people have proposed, which we may or may not end up approving
-20:21 <@Cardoe> Betelgeuse: we're not restricting outselves
-20:21 <@Cardoe> We're providing a list of stuff we'd like to see
-20:21 <@dberkholz> so we pre-approve features before they're implemented
-20:21 <@dev-zero> that's true, but it would be good if we limit ourselves to certain points and see that those get really implemented
-20:21 <@Betelgeuse> dev-zero: The easiest way is to divide the features between council members or others to code
-20:21 -!- keytoast1r [n=tobias@alpha.libexec.de] has quit [Client Quit]
-20:21 <@leio-dl> I don't like pre-approving, if expressed that way
-20:22 <@dev-zero> Betelgeuse: ok, fine by me
-20:22 -!- theinlein [n=tobias@gentoo/developer/keytoaster] has joined #gentoo-council
-20:22 <@dberkholz> leio-dl: what's your problem with it?
-20:22 <@Cardoe> We're sifting through the list of proposed features on all the mailing lists
-20:22 <@Cardoe> rejecting certain ones out right
-20:22 <@Cardoe> and prioritizing some based on the needs and requests
-20:22 <@Cardoe> and giving that list to people to code
-20:22 <@Cardoe> then we'll check back with what's coded in a month
-20:22 <@Cardoe> and go from there
-20:22 <@leio-dl> my problem is that for example we haven't actually been able to test this feature, and before actual approving we could and something turns out. That's an example
-20:22 -!- theinlein is now known as keytoaster
-20:23 <@dberkholz> pre-approving doesn't mean pre-requiring
-20:23 <@dberkholz> it means if things work out well, it's in. it could still fail at the implementation step
-20:23 <@leio-dl> pre-approving worded like that sounds like we can't end up rejecting it
-20:23 <@leio-dl> if it turns out to be a bad idea by then, regardless of the implementation
-20:23 <@Cardoe> if it turns out to be a bad implementation or works out to be poorly thought out after further discussions we drop it
-20:23 < ciaranm> leio-dl: all of these features are easy to turn on or off in the package manager
-20:23 <@dev-zero> that's why you usually have developers at the requirement meeting
-20:24 <@Cardoe> It's a wish list
-20:24 <@Cardoe> dev-zero: unfortunately we can't force the developers of PMs to be on here
-20:24 <@leio-dl> wish list, sure. Just avoid the term pre-approved and I'll be happy
-20:24 <@dev-zero> Cardoe: no, it's a requirement list
-20:24 <@dev-zero> Cardoe: we have at least one developer of a package manager here
-20:25 <@Cardoe> dev-zero: indeed we do and we appreciate it.
-20:25 <@Cardoe> dev-zero: but alas the others did not come.
-20:25 <@dev-zero> Cardoe: and the prio=1 features have been implemented in one package manager, so a proof-of-concept is done
-20:25 <@leio-dl> ciaranm: No, they are not. If the ebuild says an EAPI, it has to support it fully not have something turned off
-20:25 <@Cardoe> leio-dl: he meant as part of development and testing
-20:25 < ciaranm> leio-dl: no, i mean, we can implement features in the package manager, but not have them supported for any EAPI
-20:26 <@leio-dl> sure, you can implement what you want :)
-20:26 <@Cardoe> Honestly folks. This is a rather pointless debate.
-20:26 <@Cardoe> We've got a list with priorities
-20:26 <@dev-zero> yes
-20:26 <@Cardoe> It's done
-20:26 <@Cardoe> Move on
-20:26 <@Cardoe> dberkholz: what's the next agenda item?
-20:27 <@dberkholz> it was overlay masking, but we've already got an action there
-20:27 < ciaranm> leio-dl: have a look at http://git.pioto.org/gitweb/paludis.git?a=tree;f=paludis/repositories/e/eapis;h=18e91e4a6e08e6160f400;hb=master to see what i mean. there's no harm in experimentally or provisionally implementing something in a package manager and then just not using it if it turns out it sucks
-20:27 <@dberkholz> leio-dl just needs to follow up on list, which he's gonna do by saturday
-20:27 <@Cardoe> dberkholz: sounds good.
-20:27 <@Cardoe> dberkholz: next item?
-20:27 <@dberkholz> then we've got the live ebuild stuff
-20:28 <@dberkholz> the existing writeup really doesn't address the things i was hoping it would, along the lines that antarus did for 55
-20:28 <@Cardoe> frankly the more we look at the live stuff. the more I feel its lacking
-20:28 <@dberkholz> i'm wondering whether i need to get involved with that
-20:29 <+tanderson> uh, I was supposed to write a comparison, no?
-20:29 <@Cardoe> tanderson: yep
-20:29 <+tanderson> at least that what everybody agreed on for the summary
-20:29 <@Cardoe> The only thing I'd like to see from GLEP 54 is a defined way of storing the revision information used by the build
-20:29 <+tanderson> so How did what I do not address what was wanted?
-20:30 <+tanderson> Cardoe: Yeah, I hope to work on that soon. Thankfully, classes have eased up a bit
-20:30 < ciaranm> Cardoe: storing revision information is largely an unrelated issue. getting that whole thing right is best addressed as stages two and three of a staggered plan
-20:30 <+tanderson> yeah, All we have to agree on is that it's possible and a good plan to do it with GLEP 54, or not..
-20:31 <+tanderson> er, s/we/you obviously :P
-20:31 <@Cardoe> ciaranm: ok fine.
-20:31 <@Cardoe> ciaranm: then I'd like a documented way for the user to specify a specific revision
-20:31 <@Cardoe> right now we've got ESVN_REVISION and EGIT_REVISION
-20:31 < ciaranm> Cardoe: that's stage two, or possibly stage three if it's split in four
-20:32 -!- kICkar [n=didkoddd@unaffiliated/kickar] has joined #gentoo-council
-20:32 <@dberkholz> they're not really compared at all ... there's a document that has descriptions for both of them, and a problem or 2 picked out with each. there's no tie-in to the actual requirements of what this needs to do.
-20:32 < ciaranm> Cardoe: solving the entire live sources problem is a lot of work, and there're a lot of very non-obvious pitfalls. trying to do it all at once means it'll never get anywhere.
-20:32 <@dberkholz> it's clear to me that my mental picture doesn't match with what i actually requested
-20:32 <@Cardoe> ciaranm: fair enough
-20:33 <@Cardoe> ciaranm: so we're just going to say this addresses the -9999 ebuild
-20:33 <@Cardoe> Is Portage using PROPERTIES=live?
-20:33 < ciaranm> Cardoe: right. the glep *just* addresses the ordering problem, and nothing else.
-20:34 < ciaranm> PROPERTIES=live isn't necessarily bad. it's just not related to what the glep's trying to solve.
-20:34 <@Cardoe> ciaranm: well, we could say that if you make a -scm.. you have to put PROPERTIES=live
-20:35 <@Cardoe> in there
-20:35 < ciaranm> really... PROPERTIES=live is just a lousy way of sort of attempting some of part two or three...
-20:35 <@Cardoe> ciaranm: my idea here is let's get GLEP 54 into EAPI=3 and not make people wait until EAPI=4 to really work with it
-20:35 < dleverton> Is there any case when it would be sensible to have -scm without PROPERTIES=live, or vice versa?
-20:35 < ciaranm> dleverton: the PCI IDs list, arguably
-20:36 <@Cardoe> ok fine
-20:36 <@Cardoe> we'll come back to it
-20:36 <+tanderson> ciaranm: is that checking out a static revision?
-20:36 <@dev-zero> Cardoe: the original motivation behind EAPI=3 was to have it fast
-20:36 <@Cardoe> dev-zero: as is my motivation right now.
-20:36 <@dev-zero> Cardoe: things like G55, G54 and a couple of more issues which can take month are not suited
-20:36 < ciaranm> 54's a lot easier with 55, which puts it into "not fast" territory unfortunately
-20:36 <@Cardoe> Does any council member have a technical issue to GLEP 54?
-20:37 <@lu_zero> Cardoe the glep should be specified better
-20:37 <@lu_zero> but I said that already
-20:37 <@leio-dl> I need more time to be sure personally
-20:37 <@dev-zero> Cardoe: and I want a reference implementation
-20:37 <+tanderson> lu_zero: well, considering it's only addressing part 1, I'm not so sure..
-20:37 <@Cardoe> dev-zero: so do I
-20:37 < ciaranm> kdebuild-1's a reference implementation for both 54 and 55
-20:38 <@lu_zero> tanderson it's addressing the last part of something bigger
-20:38 <@lu_zero> you usually do not start from the roof
-20:38 < ciaranm> -scm is the first part, not the last part, because it's easy and doesn't need the other parts to be useful
-20:38 <+tanderson> lu_zero: well, I think the first part is getting correct ordering
-20:38 <@lu_zero> ciaranm it's uses are debatable at best
-20:38 <@dev-zero> lu_zero: I agree with tanderson
-20:39 < ciaranm> lu_zero: tell that to the people using -9999, -20099999 and so on
-20:39 <@lu_zero> ciaranm 9999 it's a value like others
-20:39 < ciaranm> lu_zero: which is the problem
-20:39 <@dev-zero> ok, I don't see that we get to an end here, do you?
-20:39 <@dertobi123> not really ...
-20:39 <@lu_zero> you can enforce ordering otherwise
-20:40 < ciaranm> i honestly don't see an end until there's a vote, because lu_zero isn't ever going to agree to -scm
-20:40 <@lu_zero> like preventing people using pkg-1234545677
-20:40 <@lu_zero> that said my only concern is getting more people agree on it, so if somebody adds more meat to glep 54 I won't be against it
-20:41 <+tanderson> lu_zero: what kind of meat?
-20:41 <@dev-zero> and I still fail to see what needs to be added
-20:41 <@lu_zero> dev-zero if I propose you to allow utf8 for names and latin numbers for version
-20:42 <@lu_zero> you'd consider me crazy
-20:42 < ciaranm> latin numbers for versions is doable
-20:42 <@dberkholz> back in 5, gotta take care of something.
-20:42 <@lu_zero> ciaranm anything is doable
-20:42 <@lu_zero> even utf8 numbers
-20:43 < ciaranm> lu_zero: actually no. i could list several proposals regarding versioning that are technically unimplementable.
-20:43 <@lu_zero> that alone should make you wonder if is worth it
-20:43 <@lu_zero> if there is an use
-20:43 < ciaranm> the use for -scm is replacing -9999 etc
-20:43 <@lu_zero> the use of utf8 names is to allow crazy names in programs
-20:44 <@lu_zero> that doesn't make it more agreable
-20:44 < ciaranm> lu_zero: how many programs can you think of that use utf-8 names?
-20:44 <@lu_zero> ciaranm I hope none
-20:44 < ciaranm> lu_zero: compare that with the number of packages for which people are shipping -scm ebuilds
-20:44 <@dev-zero> lu_zero: I think you're getting far away from the real problem
-20:44 <@lu_zero> ciaranm I hope none as well
-20:44 <@lu_zero> since means that either upstream or the packager is insane
-20:45 < ciaranm> lu_zero: there're lots of packages using -9999 or equivalent. most are masked, fortunately, but people find them useful.
-20:45 <@lu_zero> ciaranm they are masked since they are unstable by definition
-20:45 <@lu_zero> and they are scarce
-20:45 < ciaranm> lu_zero: yes. and? they're still there, so we should support them well.
-20:45 < ciaranm> lu_zero: look at how many scm-related eclasses there are in the main tree. are you saying they should be removed?
-20:45 <@lu_zero> we should support them within the limit of usefulness/effort ratio
-20:46 <@lu_zero> ciaranm they can be used even w/out requesting for fluid revisions
-20:46 < ciaranm> the only effort for -scm is discussing things with you... it's easy to implement
-20:46 <@lu_zero> see mythtv and their ustream
-20:46 <@lu_zero> upstram
-20:46 <@lu_zero> sigh I cannot spell
-20:47 <@Cardoe> lu_zero: I'm the MythTV guy..
-20:47 <@lu_zero> as a -9999 user I'll be glad to have something simpler
-20:47 <@Cardoe> Based on what GLEP 54 proponents are trying to say is
-20:47 <@Cardoe> let's that be the next step
-20:47 <@Cardoe> let us just get the basics down
-20:47 <@lu_zero> Cardoe IIRC you had to use constant revision sometimes
-20:48 <@Cardoe> yep
-20:48 <@Cardoe> But this GLEP won't address all uses of svn/git/cvs/bzr etc
-20:48 <@Cardoe> just the -9999 usage
-20:48 <@Cardoe> which I don't use
-20:48 <@lu_zero> right
-20:48 <@Cardoe> I'll have to write a new GLEP
-20:49 <@dev-zero> ok, result of this discussion?
-20:49 <@dberkholz> back
-20:50 <@dev-zero> dberkholz: right in time
-20:50 <@Cardoe> lu_zero: I say you and I work on another GLEP on top of this
-20:50 <@lu_zero> Cardoe agreed
-20:50 <@Cardoe> which brings up a point.. why aren't the EAPIs a GLEP?
-20:50 <@Betelgeuse> Cardoe: we tagged PMS last time
-20:51 < ciaranm> Cardoe: because we're lazy, and a PMS branch is easier
-20:51 <@Cardoe> Fair enough
-20:51 <@Cardoe> I like lazy
-20:51 <@lu_zero> thehe
-20:51 <@Cardoe> next item?
-20:51 <@lu_zero> everybody feels
-20:51 < ciaranm> otherwise we'd have to rst them for GLEPs as full proposals, and then work that into PMS as diffs
-20:51 < solar> remove keywords from ebuilds.
-20:51 < solar> ciaranm: can your pkg mgr handle that?
-20:51 < solar> ie. profiles/package.keywords
-20:52 <@dberkholz> ...?
-20:52 < ciaranm> solar: we don't use keywords from profiles at all currently. we could, easily enough, but it won't work for gentoo until gentoo-x86 is a tenth of its current size and using git instead of cvs
-20:52 < solar> it wont work?
-20:52 < ciaranm> it doesn't scale to what arch teams do
-20:53 < solar> it works today in everything else. I just want to make sure i don't cause any segvs
-20:53 -!- togge [n=togge@gentoo/contributor/togge] has quit [Remote closed the connection]
-20:53 < ciaranm> this was investigated three or four years ago... iirc agriffis an / or g2boojum
-20:54 < ciaranm> basically... the cvs tree is so big and slow, you'd never be able to commit anything because of conflicts if everyone's editing a single file all the time
-20:54 < solar> ciaranm: well the scaling thing does not really hold true anymore.
-20:54 < solar> and conflict is not any more of a problem than say ppl editing other package.
-20:54 <+tanderson> ciaranm: wouldn't you get merges rather than conflicts?
-20:54 < ciaranm> solar: honestly, i suggest you bring it up after gentoo's using git and lots of smaller independent repositories
-20:55 -!- togge [n=togge@212.247.117.70] has joined #gentoo-council
-20:55 <@Betelgeuse> Is this really something we need to discuss atm?
-20:55 < ciaranm> tanderson: if you're lucky
-20:55 < solar> files. Anyway. I plan to go down this route with a bunch of other ppl. So
-20:55 <@dberkholz> i've gotta head out in the next 5-10 min, so i'd like to get through the next topic as much as possible
-20:55 <@Betelgeuse> dberkholz: fine by me
-20:55 <@dev-zero> me too
-20:56 <@lu_zero> ok
-20:56 <@dberkholz> basically wrt glep 55, we really need the information from people that we requested at the last meeting and expected to hear back about a week ago
-20:56 <@dberkholz> so what's the deal?
-20:56 <@Betelgeuse> I can't benchmark something that's not there.
-20:56 <@Betelgeuse> Zac promised me two weeks ago to do it
-20:56 <@Betelgeuse> But never did it.
-20:56 <@dberkholz> alright
-20:56 <@Betelgeuse> So it seems I must implement it myself.
-20:56 <@lu_zero> did he tell something about it?
-20:57 <@Betelgeuse> lu_zero: See his mail on gentoo-council
-20:57 <@lu_zero> just that?
-20:58 <@dberkholz> Betelgeuse: ok, can you check back in with zac about that timeframe and drop a post to -council?
-20:58 <@Betelgeuse> lu_zero: yeah haven't heard anything yet since that
-20:58 <@dberkholz> it is still "this week" after all
-20:58 <@lu_zero> right
-20:59 <@Betelgeuse> My opinion is to approve 55 and put a GSoC project by an experienced dev to redesign the tree format that always uses .ebuild
-20:59 <@dberkholz> ciaranm: i was hoping to see some benchmarks from you. could you post them?
-20:59 <@Betelgeuse> Can actually nail down PMS and solve other long standing issues.
-20:59 <@lu_zero> I have to ask him something about multislot as well
-20:59 <@lu_zero> Betelgeuse would be interesting
-21:00 <@Betelgeuse> If this doesn't happen before we have a need for global scope changes we can fall back on 55.
-21:00 <@Betelgeuse> In the mean time.
-21:00 < ciaranm> dberkholz: just under 50% slowdown in metadata access times in the 'valid cache' case
-21:00 <@lu_zero> ciaranm something we could try ourselves?
-21:00 <@dberkholz> ciaranm: i'd really love to see the numbers on times for each case
-21:01 < ciaranm> dberkholz: for invalid cache cases you can't measure it since bash is a thousand times slower than using the cache
-21:02 < ciaranm> lu_zero: why? planning to benchmark it on an ssd just to screw with the results? :P
-21:02 <@lu_zero> ciaranm planning to read the patch and see how works
-21:02 <@dberkholz> ciaranm: hot cache, cold cache? what are the numbers in seconds?
-21:03 <@lu_zero> the more people trying the more shared is the decision upon it
-21:03 < ciaranm> dberkholz: hot vs cold doesn't make much difference to the ratio either, since with hot cache you're doubling the syscall overhead
-21:04 < ciaranm> dberkholz: numbers in seconds are "very small" to "double very small". it's when you multiply that by 10k it gets to be the problem.
-21:04 <@lu_zero> using a default set like xorg + kde + gnome would be a good benchmark
-21:04 <@dberkholz> in which situations will people be multiplying it by 10k?
-21:05 < ciaranm> dberkholz: you do 10k metadata lookups to do a pretend-install world
-21:05 <@lu_zero> even if the minimal set would be a portage or a system set
-21:06 <@dberkholz> we've gotta wrap this up
-21:06 <@dberkholz> next step is trying to get a portage implem & benchmarked
-21:07 <@dberkholz> let's get that and go from there
-21:07 <@dev-zero> but to make it clear: benchmark is not the main issue, it may just be another issue
-21:08 <@dev-zero> s/benchmark/performance
-21:08 <@lu_zero> dev-zero which is the other issue in your opinion?
-21:08 <@leio-dl> I think I was supposed to bring my technical objection to G55 to list?
-21:09 <@lu_zero> my main concern is least surprise/ease of use, then performance
-21:09 < dleverton> The other issue is whether the prosposed solution is insane or not.
-21:09 < ciaranm> the whole "having to open the ebuild" thing isn't even an issue if you stick with the EAPI= assignment restrictions i posted, since if you're ok to assume those restrictions you don't need to open the ebuild to check cache validity
-21:09 <@dberkholz> i really need to go now
-21:09 <@dev-zero> lu_zero: restrictions the various solutions imply
-21:09 <@leio-dl> I'm not even sure what's being talked about here
-21:10 <@dberkholz> should we close the meeting or is there another council member who wants to wrap up?
-21:10 <@dev-zero> let's close the meeting
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090326-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090326-summary.txt
deleted file mode 100644
index df6ec858fe..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090326-summary.txt
+++ /dev/null
@@ -1,63 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: here
-Cardoe: absent
-dberkholz: here
-dertobi123: here
-dev-zero: here
-leio: here
-lu_zero: here 
-tanderson(secretary): here
-
-Topics:
-===========
-    
-GLEP 55:
-    Petteri noted that portage had recently gotten support for both GLEP
-    55 and the parse-eapi proposal. Petteri will have benchmarks done by
-    the next meeting.
-
-EAPI-3 Proposals:
-    A call for objections to/questions about any of the various proposals
-    was asked for. What follows is a list of proposals to which objections were
-    raised or for which there are open questions as well as who raised the
-    points.
-
-    slot operator support:
-        leio, open questions, position pending on answers
-    default_src_install:
-        leio, open questions
-        dberkholz
-        dertobi123
-    doinclude:
-        dberkholz
-        leio
-    dosed:
-        dberkholz
-    unpack failing on unknown types:
-        dberkholz
-    docompress:
-        leio, needs to review proposal and prepalldocs
-        dev-zero, thinks it's useless
-    doexample:
-        dev-zero, thinks it should have -r if we have it at all
-    dohard being deprecated:
-        leio, thinks it should remain and have its bugs fixed.
-    disable-dependency-tracking:
-        lu_zero, possible breakage of configure scripts(mplayer & ffmpeg mentioned)
-    utility commands should die by default:
-        leio, open questions
-    ban || ( foo? ( . ) . ):
-        leio, sees no reason to ban something that might have some valid use cases
-
-    One part of the EAPI-3 discussion is whether to have variables that
-    behind-the-scenes control the default functions. The DOCS variable was
-    created so that a list of documentation to install can be passed to
-    default_src_install. A 4-2 vote approved the DOCS variable for use in
-    src_install. Specific details have not yet been worked out.
-
-Open Floor:
-===========
-
-Ned Ludd(solar) requested that the council discuss a migration of KEYWORDS out
-of ebuilds to be discussed at the next meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090326.txt b/xml/htdocs/proj/en/council/meeting-logs/20090326.txt
deleted file mode 100644
index 5787f16bc2..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090326.txt
+++ /dev/null
@@ -1,399 +0,0 @@
-16:01 <@Betelgeuse> so are we starting
-16:01 <@dberkholz> yep
-16:01 <@leio> where does that assumption come from
-16:01 <@dertobi123> heya
-16:01 <@lu_zero> apparently
-16:01 <@leio> ok, nevermind for now
-16:01 <@dberkholz> i was typing and was interrupted by a salad dish =P
-16:01 <@dev-zero> leio: what assumption?
-16:01 <+tanderson> mmmm, yummy
-16:01 <@dberkholz> council folks, speak up please
-16:01 < ciaranm> leio: if the assumption doesn't hold, you're into "stuff that doesn't work with existing EAPIs anyway" territory, and slot operator deps don't affect it
-16:01 <@leio> that >=foo/bar-2:= means 2, 3 or 4, but not 1
-16:01 <@dev-zero> dberkholz: another desert for me please
-16:02 <@dberkholz> tanderson: can you list anyone on council who hasn't spoken since 2000
-16:02 -!- psychoschlumpf [i=lars@unaffiliated/psychoschlumpf] has joined #gentoo-council
-16:02 <@dev-zero> leio: read what ciaran said completely :)
-16:02 < ciaranm> leio: if it doesn't, you can't use existing deps correctly anyway
-16:02 <@leio> There are two parts in there
-16:02 <@leio> >=foo/bar-2
-16:02 <@leio> and :=
-16:02 <@leio> Some foo/bar-2.0.1 might be SLOT=1
-16:02 <@dev-zero> leio, ciaranm: I guess we should do that discussion later
-16:03 <@leio> exactly, nevermind for now
-16:03 < ciaranm> leio: ...in which case you're in "doesn't work with existing deps anyway, so unrelated to the proposal" territory
-16:03 <+tanderson> dberkholz: Cardoe
-16:03 <+tanderson> I knew I was missing someone...
-16:04 <@leio> Cardoe had asked dang to proxy on #gentoo-desktop the other day
-16:04 <+tanderson> well, dang isn't here either...
-16:04 <@dberkholz> neither of them are on freenode
-16:04 <@lu_zero> hmm
-16:04 <+tanderson> dang it :P
-16:04 <@dberkholz> if anyone's got im handy, please ping
-16:05 <@dev-zero> is there a way we can store that info on a voluntary basis in the ldap?
-16:05 <@dberkholz> we already do
-16:05 <@dev-zero> ah, ok
-16:05 <@dberkholz> gentooIM or so
-16:05 <@dev-zero> then I have to go updating my info there :)
-16:05 <@dberkholz> so let's get rolling
-16:06 <@dberkholz> EAPI=3. i'd like to see people mention any specific features they've got questions for or want to reject entirely
-16:06 <@dberkholz> i think only dev-zero and i have done this on the list
-16:06 <@leio> the SLOT operator stuff is hazy for me. A nice concrete user facing documentation blurb would be appreciated
-16:06 < ciaranm> dberkholz: Betelgeuse did too 15m or so ago
-16:07 <@dberkholz> ah, thanks. been eating dinner and all that.
-16:07  * solar requests that you start at the top of the draft vs the middle of it
-16:08  * dev-zero agrees with solar
-16:08 <@lu_zero> there is a quick link with the up to date list?
-16:08 <@dev-zero> see topic
-16:08 <+tanderson> solar: yep, nice for summaries as well
-16:08 <@dberkholz> ok, sure.
-16:08 <@leio> what, we are going to go through all of them again in a meeting?
-16:09 <+tanderson> dleverton had PMS copies available as well, since my computer is still struggling to compile texlive
-16:09 <@dev-zero> we can group them by priority
-16:09 <@dberkholz> i've got an idea
-16:09 <@Betelgeuse> The only thing I see useful to do here is to assign people to take care of getting them implemented
-16:09 <@Betelgeuse> I can take a couple
-16:09 <@dev-zero> I already started :)
-16:10 <@dberkholz> does anyone who hasn't posted on the list have questions or problems with specific features that they want to say here?
-16:10 <@lu_zero> ...
-16:10 < solar> yes
-16:10 < solar> but towards the end
-16:10 < hwoarang> not right now :)
-16:11 <@dev-zero> ok, pkg_pretend and the USe dep modifiers have already been accepted
-16:11 <@leio> yes, but details on list after meeting would be best, sorry for not doing it before-hand.
-16:11 <@dev-zero> slot operator support as implemented in kdebuild ... leio has a question there
-16:12 <@dertobi123> well, probably yeah ... but i wasn't able to do so on-list before the meetingt
-16:12 <@dertobi123> meeting*
-16:12 <@dberkholz> hmm
-16:12 <@dev-zero> leio: your question is about certain use cases, right?
-16:12 <@dberkholz> can we collect a specific list of features that people have questions/problems with now, and not actually discuss the questions?
-16:12 <@leio> yes, and actual examples and user documentation
-16:12 <@dberkholz> that way we at least know what's blocking
-16:13 <@dev-zero> dberkholz: ok, let's first do that and then discuss the concrete questions right afterwards
-16:13 <@lu_zero> or that there are enough features worth an eapi bump
-16:13 <@dev-zero> lu_zero: do you doubt that?
-16:13 < ciaranm> user documentation for slot operator deps is easy. just tell people that if they build+run dep on something that has multiple slots, they should append either :* or :=.
-16:13 <@leio> regarding dohard deprecation I'm reserved about. It should be handled when possible and the portage bug needs to be fixed anyhow (actual packages are getting lots of copies of the same file because hard links are lost, irrelevant to dohard)
-16:13 <+tanderson> I could do devmanual patches easily for docs
-16:14 <@dberkholz> whoever has a feature they have a question/problem with, just say to me (dberkholz: $feature) what the feature is, so tanderson can collect a list of what feature and who
-16:14 <@lu_zero> dev-zero after discussion we can either wait or go on with what is already accepted
-16:14 <@dev-zero> tanderson: that'd be great because I don't want to touch that thing
-16:14 <@dev-zero> leio: I don't think there's a good way to handle it properly
-16:14 <+tanderson> dberkholz: it's easier to prefix that with tanderson since then I'll just look for highlights :)
-16:15 <@dberkholz> either way. already one false positive
-16:15 <@dberkholz> you've got 5 minutes =P
-16:15 <+tanderson> *cricket* :P
-16:15 < hwoarang> dberkholz: doinclude seems useless to me
-16:15 <@leio> Are we talking about open questions about a feature, or rejections too? ;p
-16:16 <@dev-zero> leio: both
-16:16 <@leio> like I'm clear on some of them but definitely rejecting
-16:16 <@lu_zero> which ones?
-16:16 <@dev-zero> dberkholz: mind posting yours too?
-16:16 <@leio> tanderson: slot operator support (open questions, might be against depending on the answer to those)
-16:17 <@leio> tanderson: default src_install (there are already open questions still there per dev-zero's summary - same thing)
-16:17 <@Betelgeuse> I wonder if the slot operator stuff would better be postponed to go in with labels.
-16:17 <@Betelgeuse> ciaranm: Does that make sense^?
-16:17 < ciaranm> Betelgeuse: labels solve a different problem
-16:17 <@lu_zero> tanderson I'm against disable-dependency-tracking in econf by default
-16:17 <@dberkholz> tanderson: default src_install; doinclude; dosed
-16:18 < ciaranm> Betelgeuse: you *could* co-opt it into labels, but it's messy, because labels work on groups, and operators work on individual things
-16:18 <@dberkholz> tanderson: unpack should fail on unknown types
-16:18 <@dberkholz> i think that's it off dev-zero's list
-16:19 < ciaranm> lu_zero: what's wrong with disable-dependency-tracking? not heard any objections to that before
-16:19 <@leio> tanderson: docompress (I need to review what prepalldocs does and compare it closer to the proposed thing, so not open question, just needing more time to be sure)
-16:19 <@lu_zero> ciaranm there are configure script rejecting it
-16:19 <@dberkholz> remember, we're not discussing yet... hold off till we're done
-16:19 <+tanderson> leio: not sure what to classify that one as then
-16:19 <@lu_zero> (sadly)
-16:19 < ciaranm> lu_zero: which ones, and why?
-16:19 <@lu_zero> hand made ones
-16:19 <@leio> tanderson: ignore I guess unless I bring up on ml
-16:19 <@Betelgeuse> lu_zero: Well just have a way to disable the behaviour
-16:20 <@dev-zero> tanderson: docompress ... I still think it's useless
-16:20 <+tanderson> leio: ok
-16:20 <@dev-zero> tanderson: doexample must have -r if at all
-16:20 <@lu_zero> Betelgeuse ok
-16:20 <@dertobi123> tanderson: default src_install; doexample
-16:21 < dleverton_> Are hand-made configuration scripts going to accept the arguments that econf already passes?
-16:21 <@lu_zero> dleverton_ yes
-16:21 <@leio> tanderson: regarding "Limit values in $USE to the ones in $IUSE" I need to just educate the developers about what LINGUAS is and isn't better.
-16:21 <@dberkholz> not all of them. i've got examples
-16:21 < ciaranm> lu_zero: there're hand-made configure scripts that take everything econf passes but not disable-dependency-tracking? examples please
-16:21 <@lu_zero> ffmpeg ?
-16:21 <@lu_zero> mplayer ?
-16:23 < ciaranm> they take weird stuff we already pass like --host and --localstatedir, but barf on --disable-dependency-tracking?
-16:23 <@dberkholz> anyone still got things to list to me / tanderson ?
-16:23 <@lu_zero> anyway if econf is tailed to work with autotool generated configure
-16:23 <@leio> tanderson: Deprecate "|| ( foo? ( . ) . )" in depend  -- should not need an EAPI rule to ban it completely to avoid mis-use, and I see no reason to start banning various specific DEPEND constructs and be required to parse for all the EAPI rejected stuff and so on, while there might be 1-10% valid use cases
-16:23 <@lu_zero> and is stated
-16:23 <@lu_zero> I'm fine with adding them
-16:23 < ciaranm> econf already passes autotools-specific weirdness
-16:23 <@leio> tanderson: dohard - should remain and bugs fixed instead imho
-16:23 < ciaranm> leio: banning it across EAPIs is a clean way of getting rid of it. and there are no valid use cases.
-16:24 < ciaranm> dohard is probably unfixable
-16:24 <@dev-zero> ciaranm: it is
-16:24 <+tanderson> leio: as far as I'm aware there have been no correct usecases for || ( foo? ( . ) . )
-16:24 <@leio> tanderson: doinclude - mostly unnecessary . Might be interesting for the potential +x removing bit, but build systems should install them properly really
-16:25 <@leio> tanderson: .xz support - never heard of what it is and it doesn't appear to be a mature packing format yet. Does it mean portage will have to rdepend on the unpacking tool of it?
-16:25 <@dev-zero> leio: no, it doesn't mean that
-16:25 <@leio> tanderson: --disable-dependency-tracking and --enable-fast-install -- would be nice, but some scripts don't take them and fail
-16:25 < ciaranm> leio: deps for .xz things are like deps for .rar, which unpack already does
-16:26 <@dev-zero> btw, it has been requested that .xpi gets added to the new extensions unpack supports
-16:26 <@leio> package needs to DEPEND on the unpacker? Fine.
-16:26 <@lu_zero> and xpi is stable and widespread
-16:26 < ciaranm> what unpacks xpi, and how horrid is its interface?
-16:26 <@leio> tanderson: utility commands should die -- documented open questions
-16:26 < psychoschlumpf> isnt --enable-fast-install enabled per default for autoconf configure scripts
-16:26 <@lu_zero> ciaranm zip
-16:26 <@dberkholz> can anyone speak up now if they haven't yet said they have issues with EAPI=3 features?
-16:27 < ciaranm> xpi's easy enough then, so i have no opinion on it
-16:27 <@leio> tanderson: "provide ebuilds a way to differentiate between updates and removals" -- seems to duplicate REPLACING_VERSIONS
-16:27 <@dberkholz> tanderson: you have a list of features now?
-16:27 < ciaranm> leio: uh, that *is* REPLACING_VERSIONS
-16:27 <@dev-zero> jup, my bad, sorry
-16:27 <@lu_zero> then it's a dupe
-16:27 <@leio> sorry, I'm going by dev-zero list
-16:27 <@dev-zero> leio: no problem, my fault
-16:27 <@dberkholz> the description needs changing, i guess
-16:28 <@dev-zero> I'll do that after the discussion to not even confuse people even further ;-)
-16:28 <@leio> lots of the stuff at the end seems to have unclear things
-16:29 <@dev-zero> leio: which ones=
-16:29 <@lu_zero> leio you mean "Non-fast Features"
-16:29 <@dev-zero> ?
-16:29 < ciaranm> leio: go by the pms draft for clear specifics
-16:29 < solar> If you are at the end. Then Non-fast Features -> src_test() listed is a no go.
-16:29 <@leio> nah, I think just one or two of the stuff before non-fast features had mentioned open questions too.
-16:30 <@leio> as for non-fast features
-16:30 <@dev-zero> solar: that's why it's non-fast, not considered for eapi-3 unless someone explicitly asks for it
-16:30 <@dev-zero> (should have chosen a better title though)
-16:30 <@leio> most of them have no description in dev-zero summary
-16:30  * ciaranm asked for it, on the grounds that src_test is useless without it
-16:30 <@leio> regarding
-16:30 <@leio> src_test run unless RESTRICTed or explicitly disabled by the user
-16:30 <@leio> completely against it, in any form
-16:30 <@lu_zero> ciaranm src_test should be triggered by repoman
-16:30 <@Betelgeuse> ciaranm: well I do have arch teams using src_test to catch stuff so it's not useless
-16:31 < solar> well as stated. The core problem there is if $CBUILD != $CHOST
-16:31 <@dberkholz> ok, let's skip non-fast things in the interest of getting this in the tree by the end of april
-16:31 <@Betelgeuse> ciaranm: probably could be more useful of course
-16:31 < ciaranm> lu_zero: yes, because that works *brilliantly* for detecting failures on user systems.
-16:31 < ciaranm> solar: ebuilds don't support cross compiling, so it's not an issue
-16:31 <@dberkholz> sarcasm not necessary...
-16:31 <@lu_zero> ciaranm user system having src_test enable is a failure by itself
-16:31 <@lu_zero> since the time and resources needed by certain testsuites
-16:31 < ciaranm> lu_zero: no, it's a basic sanity feature. for those certain test suites you can override it.
-16:31 <@Betelgeuse> If we were to enable to now, my bet would be that most users would just disable it.
-16:31 <@dev-zero> lu_zero: that's a different issue
-16:31 <@leio> ok, now what?
-16:32 <@lu_zero> ciaranm do you really use src_test on your systems?
-16:32 <@Betelgeuse> Then they won't enable it when it's actually good to enable.
-16:32 < ciaranm> lu_zero: yup
-16:32 <+tanderson> lu_zero: I use it on my system, works fine
-16:32 < ciaranm> lu_zero: as does everyone else running paludis
-16:32 < dleverton_> lu_zero: in the same way that having cmake installed or using live ebuilds is a failure?
-16:32 <@leio> lets not discuss src_test further please. It is not feasible to enable it by default this year
-16:32 <@lu_zero> ciaranm and you do not have failures?
-16:32 < ciaranm> lu_zero: i do. EAPI 3 would fix this.
-16:32 <@lu_zero> dleverton_ ciaranm said there are so...
-16:32 <@dev-zero> hehe, touché :)
-16:33 <@lu_zero> ciaranm I don't see why
-16:33 <@dberkholz> tanderson: i'm still waiting for you to tell us that you have a list of features with people who have questions etc
-16:33 < ciaranm> lu_zero: if it were on for EAPI 3, any src_test failure that made it to the user would be a genuine failure. right now, half of test failures are just caused by lazy developers.
-16:33 < dleverton_> lu_zero: ciaranm said there are what so what?
-16:33 <@lu_zero> make test is used by upstream
-16:33 < solar> ok well the real world includes things like cross compiles. So in the case of $CBUILD != $CHOST src_test() can and should not be run.
-16:33 <@lu_zero> dleverton_ not just me apparently
-16:33 <+tanderson> dberkholz: I can't write that up while the meeting's going on...too many people and too many proposals
-16:33 < dleverton_> lu_zero: I can't understand a word you're saying now.
-16:33 <@dev-zero> tanderson: how much off-time you need?
-16:34 <+tanderson> dev-zero: ~5-10 minutes maybe
-16:34 <@dberkholz> tanderson: now you understand the challenge when i was trying to be secretary too =)
-16:34 < ciaranm> solar: so users who do cross-compiling can turn it off, along with all the other things they need to do to get cross-compiling to sort of work
-16:34 <+tanderson> dberkholz: heh, indeed
-16:34 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-16:34 <+tanderson> dberkholz: for now I can give you a list of things that need discussing so it can be done one at a time though
-16:34 < solar> ciaranm: no reason to break stuff that works now for people
-16:34 <@leio> ciaranm: for cross-compiling to work they just cross-compile, there's nothing else to do beside fix bugs...
-16:35 <@dberkholz> tanderson: ok. all in one line, please, so it doesn't get broken up. then i'll start at the beginning
-16:35 < solar> if people want and have the spare cpu and are the type to fix stuff. They can enable what they want.
-16:35 < ciaranm> solar: it's an easy change for people who've already made large changes for cross-compiling to make one more small change
-16:35 < solar> vs us being broken by default
-16:35 < ciaranm> leio: ebuilds don't support it, though, except by fluke
-16:35 <@leio> FEATURES=test on by default is completely unfeasible
-16:35 < dleverton_> If it would really make people happy, portage could easily disable tests automatically in that case.  PMS already doesn't cover cross compiling, so no need to mention it there.
-16:35 <@leio> and as far as I'm concerned not a thing for an EAPI point
-16:36 <@dertobi123> leio: fully-agreed
-16:36 < ciaranm> leio: explain why please, avoiding any issue that has previously been shown to be false
-16:36 < solar> our users are not an excuse for upstreams often buggy test suites. but that is a diff story.
-16:36 <@dev-zero> ok, can we stop src_test discussion _now_ ?
-16:36 <@leio> if a package manager wants to give users pleasures of uninteresting subtle failures due to bugs in the tests themselves, and increase the compile time from minutes to days for some stuff, that's their business
-16:37 < ciaranm> leio: sorry, already debunked as being utter nonsense. please at least read the discussion we had.
-16:37 <@leio> it's not an EAPI feature what a package manager or profiles considers a default FEATURES
-16:37 < ciaranm> leio: also already debunked
-16:37 < solar> I read it and in no way did you debunk it. you dismissed it
-16:37 <@leio> I'm done with src_test for today.
-16:37 <@Betelgeuse> stop
-16:37 <@Betelgeuse> I don't see this going anywhere useful atm
-16:38 <@dev-zero> me neither
-16:38 <+tanderson> slot operator support(leio questions), default src_install(leio, open questions), disable-dependency-tracking(lu_zero), unpack fail on unknown types(dberkholz), doinclude( dberkholz ), doesed( dberkholz ), docompress(dev-zero+leio), doexample(dev-zero), limit values in $use to $iuse(leio), deprecate || ( foo? ( . ) . )(leio), dohard(leio), doinclude(leio), fast-install(leio)
-16:38 <@Betelgeuse> There's nothing new here.
-16:38 <@dertobi123> Betelgeuse: exactly
-16:38 < ciaranm> it's not going to go anywhere useful until people read the frickin' discussion
-16:38 <@dberkholz> aha, there we go
-16:38 < solar> so drop it from the draft plz then
-16:38 <@dev-zero> solar: will do
-16:38 < ciaranm> solar: it's not in the draft
-16:38 < solar> thanks. have a nice day *
-16:38 <@dertobi123> tanderson: hrm, you missed my comment? ;)
-16:38 <@dberkholz> the first thing on the list is slot ops. leio, you said you'll post to the list about that?
-16:38 < solar> ciaranm: see the end of it. It was.
-16:38 <@Betelgeuse> solar: read pms
-16:38 < ciaranm> solar: no, it's in dev-zero's summary. it's not in the draft.
-16:38 <+tanderson> dertobi123: I skimmed over, probably missed a few people's objections
-16:39 < solar> Betelgeuse: PMS is the final spec. We are talking about a draft here at listed in the topic
-16:39 <@leio> dberkholz: I guess. It would be nice to have explanations from an ebuild developer point of view for things like that point
-16:39 <@dev-zero> list seems small enough to be discussed here, no?
-16:39 < ciaranm> solar: uh. no. we're talking about a pms draft branch.
-16:39 < solar> if you are putting things into before they are approved, then something is really wrong
-16:39 < solar> ok
-16:39 <@dertobi123> tanderson: anyways, my topics are listed
-16:39 <@Betelgeuse> solar: The topic should have been made to point to PMS draft branch
-16:40 <+tanderson> dertobi123: yeah, when we get to those you can just chip in that you also have questions
-16:41 <@dev-zero> leio: from an ebuild developer pov: DEPEND="dev-lang/python" in a python package spans up to 4 slots
-16:42 <@dev-zero> leio: DEPEND="dev-lang/python:=" will tell the pm that a package built using a specific python version needs that specific python version as long as that package is installed
-16:42 <@leio> dev-zero: I think my point is to have such an explanation available to anyone evaluating the features. Your summary page or mailing list or whatever that goes beyond council members :)
-16:42 < ciaranm> leio: *all* the changes will need user-facing documentation
-16:42 <@dev-zero> yes, but creating them before actually having stuff implemented is a lot of work
-16:43 <@leio> yeah, I don't mean all. Just things that are not well understood otherwise. Like this one.
-16:43 <@dberkholz> leio: anythong you want to bring up now on default src_install?
-16:43 <@leio> Ah! I think I found the right place in PMS. the hyperlinks on the bottom to up are going to weird places
-16:44 <@dev-zero> leio: and the result? :)
-16:44 <@leio> as for default src_install, I understand it covers what docs should be installed by default
-16:44 -!- kickar [n=didkoddd@unaffiliated/kickar] has joined #gentoo-council
-16:44 < ciaranm> the default src_install has "TODO: what goes here?"
-16:45 <@leio> I think that this should be done by the maintainer always
-16:45 <@dev-zero> leio: so, no default src_install?
-16:45 <@dberkholz> yeah, there are many cases when the default GNU files are totally useless
-16:45 < ciaranm> because some people think ebuilds shouldn't use DOCS="blah", despite writing lots of code themselves that does exactly that...
-16:45 <@leio> this is in regards to the docs part of it
-16:45 <@dev-zero> dberkholz: but for those a src_install is already written
-16:45 <@leio> dodoc seems to already ignore files listed that are empty
-16:46 <@leio> but in some cases NEWS says
-16:46 <@leio> "See ChangeLog" and nothing else, crap like that doesn't need to get installed
-16:46 <@leio> DOCS sounds good. Many eclasses do it.
-16:46 <@dev-zero> dberkholz: and don't understand the argumentationn, sorry
-16:46 < ciaranm> leio: in some cases, you override it. it's only a default.
-16:47  * dertobi123 likes to see a useful default DOCS
-16:47 <@leio> but I want the default src_install to handle the actual installation
-16:47 <@leio> not decide for me what docs get installed
-16:47 < ciaranm> then if the default's not good enough, don't use it
-16:47 < ciaranm> the idea of defaults is to cover a lot of cases, not all cases
-16:47 <@dertobi123> have a sane default, if you want to decide what docs get installed set DOCS
-16:48 <@dev-zero> yes, you can still override it if you see that the docs installed by default are crap
-16:48 <@leio> yeah, just please with a way that doesn't mean I can't call default in src_install for stuff like getting make install run by the default
-16:49 <@leio> DOCS=""
-16:49 <@leio> src_install() {
-16:49 < ciaranm> leio: that'd need DOCS then, which some people object to
-16:49 <@leio>   some_extra_stuff
-16:49 <@leio>   default
-16:49 <@leio> }
-16:49 <@leio> sounds good
-16:49 <@leio> right, so there's more discussion to do on list :(
-16:49 < ciaranm> unfortunately the objection to DOCS is purely ideological
-16:49 <@dev-zero> no, I don't think so
-16:49 -!- spitf1r3 is now known as spitfire_
-16:49 < ciaranm> which means voting on it and seeing which ideology is in the majority...
-16:50 <@dev-zero> dberkholz: I remember you being the one objection DOCS, right?
-16:50 <@dberkholz> yes
-16:51 <@dberkholz> if you want docs defaults, i'd prefer a function argument instead
-16:51 <@dev-zero> example?
-16:52 <@dberkholz> i haven't thought about the interface
-16:52 <@dberkholz> but you're all familiar with the concept of arguments to functions
-16:52 <+tanderson> why not just vote on it?
-16:53 <@dev-zero> yes, who objects a default src_install which calls "emake DESTDIR=${D} install ... ; dodoc ${DOCS}" ?
-16:53 <@dev-zero> and from those who don't: who objects DOCS having a sane default like README NEWS etc. if not specified otherwise?
-16:53 < solar> will it die if they don't exist?
-16:54 <@dberkholz> i object to the whole philosophy of moving important parts of all ebuild functions (not global metadata) into variables
-16:54 <@Betelgeuse> I want the contrary
-16:54 <@Betelgeuse> In Java ebuilds having as much in variables has showed to be much better
-16:54 <@dberkholz> i don't think it's useful enough with the changes in new EAPIs
-16:54 < solar> and will the ebuild be forced to set DOCS="" ?
-16:54 <@dberkholz> although when i wrote eclasses years ago, it was nice
-16:54 < ulm> solar: some eclasses die if files from DOCS don't exist. so a general default may be problematic
-16:55 < ciaranm> solar: the DOCS-based proposals i've seen only die if you explicitly set docs and stuff doesn't exist
-16:55 < solar> seems sane
-16:55 < ciaranm> solar: they silently ignore any defaults that don't exist
-16:55 <@dev-zero> that seems useful
-16:55 <@dev-zero> vote?
-16:55 <@dberkholz> making people know all these variables associated with ebuild functions adds a whole new dimension to what they have to learn
-16:56 <+tanderson> so people learn a bit more...big deal.
-16:56 <+tanderson> Learning ebuilds isn't terribly difficult
-16:56 < solar> tanderson: it will become harder over time as each eapi will have it's own rules.
-16:56 < hwoarang> imho it's better to learn a couple of new ebuild than writting functions
-16:56 <@dev-zero> nothing more than they have to learn when writing an ebuild using one of 13 or 14 eclasses which already recognise DOCS
-16:56 <@dertobi123> and DOCS shouldn't be that hard to "learn" *cough*
-16:56 < hwoarang> *s/ebuilds/variables
-16:57 <@lu_zero> since is already in use
-16:57 < ciaranm> solar: you only have to learn the EAPIs for things you're writing. which should just mean new EAPIs. older stuff you just look up.
-16:57 <@lu_zero> have it standardized would be good
-16:57 <@dev-zero> solar: there's usually only one eapi to learn, the most recent one
-16:57 < solar> no
-16:58 <@dberkholz> editing an ebuild that's e.g. part of kde or X or whatever is a whole different story from having *all* ebuilds doing something
-16:58 <@dev-zero> dberkholz: not all, only those being EAPI=3 and from those only the ones with no src_install
-16:58 < ciaranm> this isn't going to get decided by anything except a vote
-16:58 <@dberkholz> you can learn levels of complexity in steps instead of needing it all at once for a basic ebuild
-16:58 <@lu_zero> I'd just think if it would make us spare time or not
-16:58 < ciaranm> both sides already know the arguments each way
-16:58 <+tanderson> hint: if a substantial amount of eclasses do something, there might be a point to it
-16:59 <@dev-zero> tanderson: my point
-16:59 <@dev-zero> and I would like to see a vote
-16:59 <@Betelgeuse> DOCS++
-16:59 <@dev-zero> DOCS++
-17:00 <@dberkholz> ----------------------
-17:00 <@dertobi123> DOCS++
-17:00 <@dberkholz> sorry, bad wifi.
-17:00 <@lu_zero> too many - ^^
-17:00 <+tanderson> unfortunately, we could have a tie vote...
-17:00 <+tanderson> lu_zero: is that a DOCS-- for you?
-17:00 <@leio> sorry, I got pre-occupied
-17:00 <+tanderson> ok
-17:01 <@lu_zero> tanderson I'm not so fond of having too many automagic vars
-17:01 <@lu_zero> so I can agree on the idea of dberkholz
-17:02 <@lu_zero> in itself shouldn't change much since common docs aren't that common (sadly)
-17:02 <@Betelgeuse> lu_zero: woot?
-17:02 <@Betelgeuse> lu_zero: I see it in almost every ebuild I write
-17:03 <@lu_zero> Betelgeuse and you touch which kind of ebuilds?
-17:03 <@dev-zero> lu_zero: and you can still set it manually
-17:03 <@Betelgeuse> lu_zero: Java and autotools
-17:03 <@dberkholz> we need to wrap it up
-17:03 < ciaranm> need to finish the vote!
-17:03 <+tanderson> is that a positive vote for DOCS? 3 ++, 2 --
-17:03 <@dberkholz> looks like we're waiting on another vote from leio, and we'll catch cardoe later
-17:04 <@dberkholz> if necessary
-17:04 <@dberkholz> then we'll close up
-17:04 <@leio> sorry, was on phone with landlord, gimme a minute please
-17:05 <@lu_zero> Betelgeuse do they have a common intersection that is bigger than 2?
-17:05 <@Betelgeuse> betelgeuse@pena /usr/portage $ find -name "*.ebuild" | xargs grep -l dodoc | wc -l
-17:05 <@Betelgeuse> 12457
-17:05 <@Betelgeuse> betelgeuse@pena /usr/portage $ find -name "*.ebuild" | xargs grep -vl dodoc | wc -l
-17:05 <@Betelgeuse> 26204
-17:05 <@Betelgeuse> and then there's the DOCS using stuff etc
-17:05 <@dberkholz> leio: from 20:53 on will catch you up on this, if you aren't yet
-17:06 <@leio> yeah, got markerline, reading
-17:06 <@lu_zero> Betelgeuse so you are positive that would make us spare time
-17:06 < solar> it sounds like you don't have to vote right now as cardoe is not here anyway
-17:06 <@Betelgeuse> solar: if leio votes yes we have a majority any way
-17:06 < ciaranm> doesn't really matter if leio votes in favour
-17:06 <@dberkholz> you could do a grep for exactly how dodoc is called
-17:06 <@dberkholz> indeed
-17:07 <@leio> DOCS++
-17:07 <@Betelgeuse> lu_zero: We used to have lots of stuff in functions in Java ebuidls. I migrated to using variables and it has been a lot better.
-17:07 <@Betelgeuse> lu_zero: At least for me personally
-17:07 <+tanderson> fine, DOCS is in
-17:07 <@dberkholz> k, that's it for tonight
-17:07 < solar> guys done?
-17:07 <@dev-zero> yes
-17:07 <@Betelgeuse> I will note that zac told me that GLEP 55 support is in Portage.
-17:07 <@Betelgeuse> So I can finally do the numbers.
-17:07 <@lu_zero> its 10.12 for me
-17:08 <@dberkholz> meeting's over, tanderson please be sure to post the nice list of features with people blocking them
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090409-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090409-summary.txt
deleted file mode 100644
index 02fe83af21..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090409-summary.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: here
-Cardoe: here
-dberkholz: here
-dertobi123: here
-dev-zero: here
-leio: here
-lu_zero: here 
-tanderson(secretary): absent
-
-Topics:
-===========
-    - Migration of KEYWORDS out of ebuilds
-        There was initial discussion on this idea. The council requested that
-        Ned Ludd(solar) post a draft proposal of his idea to one of the lists
-        for discussion, since the idea interested the council and they wish to
-        get an idea of its pros and cons.
-
-    - EAPI 3 features block
-        To make sure that there is enough discussion on all EAPI 3 features a
-        block on new features for consideration into EAPI 3 was considered. A 
-        vote was taken to
-            A) block features to those already discussed
-            B) 'A' with mtime preservation
-            C) no block for features
-        Choice 'A' won with 4 votes.
-        This block doesn't affect discussion of the implementation of the
-        features, only new features.
-
-    - EAPI 3 updates
-        Zac Medico(zmedico) commented that while he hadn't worked on
-        [use(+/-)] yet it shouldn't take more than a week or two to complete.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090409.txt b/xml/htdocs/proj/en/council/meeting-logs/20090409.txt
deleted file mode 100644
index 0d9a7d80df..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090409.txt
+++ /dev/null
@@ -1,276 +0,0 @@
-20:00  * dertobi123 yawns
-20:00 <@dberkholz> yep, bout that time.
-20:00 <@dberkholz> council & secretary, please speak up
-20:01 <@lu_zero> '/
-20:01 < mama> tanderson said he's not gonna be here.
-20:01 <@leio_> the secretary told to be away
-20:01 <@leio_> apr   09 17:24:24 <tanderson>	I will not be making it to today's meeting :(. My mom needs to pick up my brother for good friday break and the pickup time is 2000 :(
-20:01 <@leio_> apr   09 17:24:57 <tanderson>	I'll still have my irc client on to make up a summary though, so no worries there
-20:01 <@lu_zero> pity
-20:01 <@dberkholz> alrighty
-20:01 <@dev-zero> I'm here
-20:02 -!- filko [i=filko@unaffiliated/filko] has joined #gentoo-council
-20:02 <@dberkholz> Betelgeuse, Cardoe: ping
-20:03 <@dberkholz> ok, let's start
-20:04 <@dberkholz> i put this idea of solar's at the top of the agenda because i think we can manage to avoid going into long extended arguments about it
-20:04 <@dberkholz> the basic idea is to move keywording to a package.keywords file or something along those lines
-20:05 <@dberkholz> reduce rsync overhead, constant redigesting of whole packages for a change to keywording, etc
-20:05 <@dberkholz> downsides is that you can get conflicts
-20:05 <@dberkholz> anyone got thoughts about this?
-20:05 <@dev-zero> conflicts?
-20:05 <@dberkholz> if keywords for all packages are in the same file, it will change very frequently
-20:06 <@dertobi123> i don't get what to discuss on this topic for now, there isn't even some kind of proposal
-20:06 < solar> back.
-20:06 <@dertobi123> if solar needs an "ok" to draft some proposal ... here's my "ok"
-20:06 <@leio_> I think it should be actually written down by someone. Abstract, problems that it solves, plan of implementation
-20:06 <@dberkholz> so you might get people changing an outdated file and committing it. overwriting someone else's changes or producing a cvs conflict
-20:07 < solar> dertobi123: there is no proposal. You guys are the council. I'm asking you to also put some thought into it
-20:07 <@dev-zero> well, I dislike the idea for various reasons
-20:07 <@leio_> make it nice, don't just try to do it with current mechanisms available if better methods could be implemented, etc
-20:07 <@dberkholz> i tend to think we should keep package-level metadata as close to the package as possible, even if it's not in the ebuild itself
-20:07 <@leio_> Get each arch their own file perhaps, etc
-20:07 < solar> being that we have not even discussed it. I'm not sure how you can dislike it.
-20:08 <@dberkholz> i'd rather get rid of the centralized files than create more of them
-20:08 <@leio_> and after there is such a plan, it might have a chance of being better than the status quo
-20:08 <@dev-zero> solar: moving the keywords into one file <-- that's what I don't like
-20:08 < solar> but to explain. Yes we want to reduce the overall resources needed in keywording. keywords can be broken out on a per cat basis also.
-20:08 < solar> it's not a single file.
-20:08  * solar digs up his example script to show ya
-20:09 <@dev-zero> still, I don't see a benefit
-20:09 < solar> really?
-20:09 <@dev-zero> really
-20:09 <@lu_zero> dev-zero it is nicer for minor arches or experimental branches
-20:09 < solar> it's nicer from an overall pov.
-20:09 <@dev-zero> solar: then show me
-20:10 <@lu_zero> solar if you have many devs it doesn't change much
-20:10 <@leio_> I don't need to cvs diff my packages when vapier keywords stuff without updating ChangeLog yet again ;p
-20:10 < solar> right now every single dev both risks breaking the tree. Wastes tons of resources cvs up/diff/push of the entire ebuild dir.
-20:10 <@dev-zero> lu_zero: that doesn't apply to most of our ebuilds in the tree
-20:10 <@lu_zero> if you have too many devs the bare implementation would hit cvs limits
-20:10 <@lu_zero> so right now I think the idea isn't that bad
-20:10 < solar> look at it from a space savings also. There are just so many reason it makes sense
-20:11 <@dberkholz> heh
-20:11 <@dev-zero> and space saving isn't one of them
-20:11  * ciaranm is curious as to how it would save space
-20:11 <@dertobi123> space savings? maybe if we make it a single file
-20:11 <@dertobi123> but having ~12.000 keyword files for each package wouldn't save space
-20:11 <@leio_> there are no space savings to speak of
-20:12 < solar> yes there is
-20:12 <@leio_> there is quite some rsync wins probably however
-20:12 < solar> not much but you save atleast 9 bytes per ebuild
-20:12 <@dev-zero> doesn't matter
-20:12 < solar> then you take into consideration that you can begin marking ranges
-20:12 < solar> dev-zero: what do you mean?
-20:12 <@leio_> I don't see how it saves anything
-20:12 < solar> there are many rsync wins.
-20:12 <@dev-zero> space: you saved 90MB, so what?
-20:13 <@lu_zero> solar it would be something like generalizing .keywords file?
-20:13 <@leio_> removing 20 bytes from each ebuild will make maybe 1% of them take one page less disk space
-20:13 < solar> sec let me find my script. I really don't think you guys are getting it at all
-20:13 <@Betelgeuse> hmm
-20:13 <@Betelgeuse> Sorry
-20:13 <@lu_zero> hi Betelgeuse
-20:13 <@Cardoe> I'm here now
-20:14 <@Betelgeuse> For the keywording it would be nice to be able to group keywords together for stuff.
-20:14 <@dberkholz> alright, 2-3 more minutes and we need to wrap this bit up
-20:14 <@Betelgeuse> There are plenty of things that go stable in sets.
-20:14 <@dberkholz> just want to make sure the idea is clear to everyone
-20:14 <@Betelgeuse> Like KDE, ant etc
-20:15 < darkside_> the concept works, fwiw. we do it in prefix. asume all arches, mask when it breaks.
-20:15 <@dev-zero> Betelgeuse: thanks, that was the first useful use case
-20:15 <@Cardoe> We're arguing abstracts.
-20:15 <@lu_zero> for common usage is the change user transparent?
-20:15 <@Cardoe> solar: what exact setup did you have in mind?
-20:16 <@dertobi123> Betelgeuse: which would require to have per category keyword files or a single global keyword file
-20:16 <@Cardoe> solar: i.e. what would be the file and the syntax?
-20:16 <@leio_> I'd hope solar can find some time to at least draft up a post to mailing list about it. Most people haven't read the beginning of the discussion covering the problems it solves, etc. And many discussions that happened on IRC on top of that kind of assumed prior knowledge and didn't specify many things over again iirc
-20:16 <@lu_zero> developer wise will it be harder or simpler to do the common tasks?
-20:16 < bonsaikitten> should end up simpler
-20:16 < solar> I can't seem to find my example code at the moment.
-20:16 <@dberkholz> ok
-20:16 <@dberkholz> the idea is out there. we need to get it clarified and written down somewhere
-20:17 <@dberkholz> is anyone willing to do that?
-20:17 < solar> but it's quite simle. Assuming we all understand package.keywords/x11-wm/keywords
-20:18 < ciaranm> i don't understand how you're going to keep it in sync or how you're going to avoid having to have a line for every single package... can't even keep package.mask clean currently.
-20:18 <@leio_> I doubt package.keywords is unfamiliar to anyone here. It needs writing down what problems it solves, what benefits it has, and so on to properly be able to evaluate it and discuss about it
-20:18 < solar> ugg
-20:18 <@dertobi123> dberkholz: i'd expect solar to do so
-20:18 <@dev-zero> solar: I think you can't avoid writing at least a draft
-20:18 <@dberkholz> ciaranm: he's proposing a directory containing keywords files, kinda like /etc/portage/package.keywords/ or something
-20:18 <@lu_zero> (or provide an implementation for us to play ^^)
-20:18 < ciaranm> dberkholz: it's the "or something" bit
-20:18 <@Betelgeuse> I could just go with being able to refer to an external file in KEYWORDS
-20:19 <@dberkholz> actually the directory approach makes a bit more sense than the huge single file, although i'm still unsure about the overall approach.
-20:19 < solar> You don't generally have 15 people editing at the same time.
-20:19 <@dberkholz> but to return to my original question, who will pick this up and run with it?
-20:19 < ciaranm> so you'd have zillions of =foo/bar-1.23 =foo/bar-1.23-r1 =foo/bar-1.23-r2 lines, and would have to ensure that they were all kept in sync with what's in the tree?
-20:20 <@dev-zero> dberkholz: I also expect solar doing it
-20:20 < solar> dev-zero: what do you expect?
-20:20 <@dev-zero> solar: that you finally write at least a draft of it instead of just dumping your ideas here and expect us doing the work
-20:20 < solar> I hope you all realize this functionality exists today
-20:21 < solar> and the only thing that prevents us from using it is nothing
-20:21 <@dberkholz> alright.
-20:22 < solar> dev-zero: I never said i expected you to work. I asked the council to start thinking about it
-20:22 <@Betelgeuse> The functionalilty to do lots of stupid things to the tree is available but I wouldn't want to see people doing them either.
-20:22 < solar> if I have to spell out everything and hand it to you on a golden platter. Then umm.
-20:22 <@dberkholz> to sum up, we've got a basic idea of the proposal, and we'd really like to have a stronger understanding of exactly what your idea is and its pros & cons
-20:22 <@Betelgeuse> ^Doesn't necessarily mean this is stupid.
-20:22 < solar> dberkholz: sure.
-20:23 <@dberkholz> or just post the idea to the mailing list and ask other people to come up with the pros/cons bit
-20:23 <@dberkholz> we need to move on to the next topic now
-20:23 <@dberkholz> i would like to propose that we block any new features being added to the EAPI=3 set and postpone them to 4 (which can come at any point, it doesn't need to take forever)
-20:24 <@lu_zero> ok
-20:24 <@dberkholz> the goal being that we get something done now instead of continually adding features forever
-20:24 <@dev-zero> I would like to set the deadline to Thursday, 16th
-20:24 <@dev-zero> that's true, but a deadline needs to be announced beforehand which didn't happen so far
-20:24 <@Betelgeuse> I would just set a deadline for Portage having implemented what's in EAPI 3.
-20:24 <@dberkholz> because that's basically what's been happening over the past month or longer already, and this is supposedly "lightning"
-20:25 <@dev-zero> that as well, yes
-20:25 < ciaranm> so far as i'm aware, the things holding up EAPI 3 are the 'key' features, not the little bits
-20:26 <@dberkholz> dev-zero: why does a deadline need to be announced? we can immediately start work on 4.
-20:26 <@Betelgeuse> The idea behind deadline is to get people to work
-20:26 <@dberkholz> just pick what's ready and do that as 3, things that are ongoing can be 4, things that are ongoing then can be 5, etc.
-20:27 <@Betelgeuse> I do stuff best if I have a deadline to meet. Grated people might just not crre.
-20:27 <@Cardoe> dberkholz: Why don't we just set rolling releases for EAPIs
-20:27 <@Cardoe> whatever is ready every X days is a new EAPI
-20:27 <@lu_zero> works for me
-20:27 < darkside_> agile EAPI
-20:27 <@dberkholz> i kinda like that, actually.
-20:27 <@dev-zero> there is nothing agile in that
-20:27 <@Betelgeuse> Cardoe: if there's something substancial there then sure
-20:28 <@dev-zero> yeah, but bumping the eapi just for minor foo things is just nonsense
-20:28 <@dev-zero> why not do it like the kernel development cycle
-20:28 < ciaranm> the problem with that is that difficult things will just get postponed indefinitely
-20:28 <@lu_zero> why?
-20:29 <@lu_zero> you start working on it with a target
-20:29 <@lu_zero> that isn't the next release window
-20:29 < ciaranm> because as soon as a feature starts hitting the "needs detailed discussion" target, it just gets postponed over and over and no-one ever makes a decision
-20:29 <@lu_zero> once it's done you can get it released
-20:29 <@dberkholz> dev-zero: why? if the feature's there, somebody is clearly expecting to benefit from it. making them wait another X months because there's no "important enough features" sucks
-20:29 <@dev-zero> dberkholz: oh, that's not what I meant
-20:30 <@dev-zero> dberkholz: what I meant was: having defined "open for ideas/requests", "implementation", "deployment" phases
-20:30 < ciaranm> "once it's done" is only good for things that will get done without a degree of coordinated work. it'll be fine for most things, but it's not a complete solution.
-20:30 <@Betelgeuse> ciaranm: With new EAPIs I don't think making decisions has been the problem.
-20:30 < mpagano_>  /win 20
-20:30 <@Betelgeuse> The problem is getting Portage to implement things.
-20:30 <@Cardoe> Do we have any targets to get anything done today?
-20:30 < ciaranm> Betelgeuse: with EAPIs 1, 2 and 3 all being "what's available" stuff, we've not been able to put in "what's necessary" yet
-20:30 <@Cardoe> Cause I've unfortunately seen only 30 minutes of unproductive arguing
-20:31 <@dev-zero> Cardoe: and you keep adding to that
-20:31  * solar never got a chance to speek. So the first 10 was wasted.
-20:31 <@dev-zero> dberkholz: let's vote on whether or not we have feature freeze for eapi-3 now
-20:31 <@dberkholz> sounds good.
-20:31 <@lu_zero> ok
-20:31 <@dev-zero> dberkholz: and discuss a standard way for developing future eapis on the ml
-20:31 <@leio_> what defines what features are frozen there?
-20:32 <@dev-zero> since we can't fully control what features get implemented in time in portage
-20:32 <@dberkholz> leio_: i suggested what was already discussed at the last meeting is the maximal set, and things can be cut from there
-20:32 < ciaranm> leio_: just say "no to anything that's not already in the draft, and maybe to anything that is"?
-20:32 <@dev-zero> the feature freeze is more a: that's what we like to have, things can be dropped if not implementable in time
-20:32 <@lu_zero> btw freezing the spec or the implementation?
-20:32 <@dberkholz> spec
-20:32 < ciaranm> lu_zero: the spec isn't ready to be frozen
-20:32 <@dev-zero> there is no implementation
-20:33 <@dberkholz> well, the features in the spec, anyway.
-20:33 < ciaranm> lu_zero: the list of... what dberkholz said
-20:33 <@lu_zero> ok
-20:33 < ciaranm> some of those features still have things like "TODO: we need to work out exactly what this does"
-20:33 <@dberkholz> so, let's vote on blocking new feature addition to EAPI 3 and postponing them to 4.
-20:33 <@dev-zero> dberkholz: what about the other meeting topics, do they fall into the category of eapi-4 or later?
-20:34 <@dberkholz> dev-zero: from agenda, "This [the block] specifically applies to anything not already discussed as of last meeting, including the 2 below items."
-20:34 <@leio_> I'm cool with mtime preservation when it's just setting in writing what portage already does
-20:34 <@leio_> (and having that guarantee for the future since EAPI-3), but if there's controversy, postponing might be good.
-20:34 <@dberkholz> not really a big deal if you want to change that, though.
-20:35 < ciaranm> mtime preservation as "what portage already does" has issues. it's not something that should be going in without discussion.
-20:35 <@leio_> lets say then - if the discussion ends up with concluding something that portage already implements, we can add it to EAPI-3 if it's not already finalized and shipped
-20:35 <@dev-zero> leio_: no
-20:35 <@dberkholz> ok, 3 choices. A -- block as of already-discussed features. B -- include mtime preservation. C -- no block yet.
-20:35 <@dberkholz> take your pick
-20:36 <@Betelgeuse> C
-20:36 <@dberkholz> A
-20:36 <@dev-zero> C
-20:36 <@leio_> hum
-20:36 <@Cardoe> What do we gain exactly from A and B?
-20:36 <@dberkholz> getting an implementation sometime this year, one hopes.
-20:37 <@dertobi123> and when's the block/deadline for C?
-20:37 <@Cardoe> Arbitrarily picking a list won't guarantee anyone will code it in Portage?
-20:37 <@Betelgeuse> indeed
-20:38 <@lu_zero> keeping the list small raises the chances
-20:38 <@leio_> B, but that doesn't mean already in the list things can't get dropped out if they don't get implemented on time (what time?) or there are open questions without concensus
-20:38 <@dberkholz> if people want the 'no block yet', we'll have to figure out where to go from there, when to have a deadline, etc.
-20:38 <@dev-zero> s/C/A
-20:38 <@Cardoe> ciaranm has a point that several of the items on there vague.
-20:38 <@lu_zero> A
-20:38 < ciaranm> once we know which features are candidates, fixing the vagueness isn't too tricky
-20:38 <@dberkholz> 3 A's, 1 C, 1 B.
-20:38 <@dertobi123> so well, A then to at least have a chance of making it a "quick" eapi-3
-20:38 <@Cardoe> ok fair enough
-20:38 <@Cardoe> then A
-20:39  * ciaranm was planning to do a mass pms fixup over the weekend anyway so fauli's cheatsheet stuff can go in
-20:39 <@dertobi123> ciaranm: nice
-20:39 <@Cardoe> ciaranm: you'll generate the cheat sheet as a page at the end?
-20:39 < ulm> i'd really urge to council to act on the mtime issue
-20:39 < ciaranm> Cardoe: see the pms mailing list. not quite.
-20:39 < ulm> should be very easy to implement
-20:39 < ciaranm> Cardoe: we have plans for a document reformatting and a two pdf thing. probably too off-topic for here.
-20:39 < darkside_> and the prefix variables. 3 lines in ebuild.sh and it is done. (already done actually)
-20:40 <@dev-zero> ulm: as far as I've seen it has some pitfalls
-20:40 < ulm> dev-zero: everything is better than leaving it unspecified
-20:41 <@dberkholz> ok, four A's it is. feature block as of already-discussed features.
-20:41 < solar> w15
-20:42 <@dberkholz> those of you with a pet feature, feel free to respond to the summary on -dev if you have some compelling reason why it's super easy to get in and can't be pushed back. keep in mind there's no reason we need to take forever for EAPI 4, either
-20:42  * ciaranm cries at dberkholz's last remark
-20:43 <@dev-zero> dberkholz: we did a feature freeze
-20:43 <@dev-zero> dberkholz: nothing comes in anymore
-20:43 <@lu_zero> we could take the 4 to experiment with release methods
-20:43 < grobian> dberkholz: does that mean you won't discuss the topics of your agenda anymore?
-20:43 <@dev-zero> we can discuss it as part of eapi-4
-20:44 <@dev-zero> or defer the discussion and discuss eapi-independent topics
-20:44 < ulm> this so sucks :(
-20:44 <@dberkholz> ciaranm: people are going to do it anyway. =) if we attempt to "forbid" them somehow, it just erodes our authority.
-20:44 < ciaranm> dberkholz: should've just insisted upon it being in 4!
-20:45 < ciaranm> also, if anyone wants me to rewrite pms history to get their feature in in such a way that it looks like it was before the deadline, send me a hundred quid in nonsequential used ten pound notes
-20:45  * ciaranm giggles
-20:45 <@dberkholz> we should start discussing the features regardless, because the whole point is that EAPIs shouldn't take forever
-20:46 <@dberkholz> i'm fine if we approve 4 a month after 3.
-20:46 < ciaranm> sure. but for 4, rather than "4 unless you can come up with a convincing argument for it being in 3"
-20:46 < ciaranm> because everyone thinks their arguments are convincing
-20:46 <@dev-zero> dberkholz: after having 3 implemented, please
-20:46 <@Betelgeuse> Instead of discussion let's all just implement things.
-20:46 <@dertobi123> zmedico: can we set a deadline on when eapi3 stuff is implemented in portage? i.e. when we can compile a final list of eapi-3 features?
-20:48 <@dev-zero> what about 42 days from now?
-20:49 < zmedico> dertobi123: sure, I guess so.
-20:49 < ciaranm> zmedico: did you have [use(+)] done? that was the critical feature for 3
-20:50 <@dertobi123> zmedico: so what about an estimate? ;)
-20:50 < zmedico> ciaranm: I haven't done anything yet but none of it seems particularly difficult
-20:51 <@dberkholz> grobian: looks like we're about to run out of time today, but i'm happy to discuss those prefix features in general at any point ... i've already put it on the next agenda -- http://dev.gentoo.org/~dberkholz/20090423-agenda.txt
-20:51 < grobian> dberkholz: great
-20:52 < zmedico> dertobi123: if I've got a firm list of things that are definitely going in then I can probably have it done in a week or two
-20:52 <@dberkholz> let's go with next meeting, then
-20:52 <@dberkholz> april 23
-20:52 <@dertobi123> sounds good
-20:52 <@Betelgeuse> Just to note if someone needs something from me I will be in Spain next week.
-20:52 <@dev-zero> ok
-20:52 <@dertobi123> bleh, everyone's out for holidays :(
-20:53 < ciaranm> i can have pms ready (with features being easily removable) by monday, assuming i've got at least some kind of mobile phone coverage over the weekend...
-20:53 <@leio_> So anyone from Spain can find you and get what they want?
-20:53 <@Betelgeuse> leio_: If someone wants to come to visit my hotel for a review, sure
-20:54 <@leio_> I should send armin76 to you or something. Any updates on that benchmarking stuff, or what's the next topic again?
-20:54 <@dberkholz> so, we've got about 5 minutes.
-20:55 <@dberkholz> i've already started the agenda for next meeting to try helping everyone get better prepared
-20:55 <@dev-zero> dberkholz: I assume you're putting the other topics we didn't discuss today on that list as well?
-20:55 <@dberkholz> yeah, i put them there. prefix, mtime, and the changing ebuild features thing.
-20:56 <@dberkholz> we'll have to sort things out a bit as the time approaches
-20:56 <@dberkholz> hopefully some of that can become clearer on the lists over the next 2 weeks
-20:56 <@Betelgeuse> leio_: Yeah slacker.
-20:56 <@Betelgeuse> Forgot mainly.
-20:56 <@dev-zero> yeah, and let's try to start discussing things 10 days before the next meeting instead of 1 day before
-20:57 <@dberkholz> sorry about that for my lack of participation, i've been really busy w/ work. that'll be done a week from now.
-20:57 <@Betelgeuse> dberkholz: well you still do more than I have lately
-20:58 <@dev-zero> I have to admit that I wasn't so active last week but the OpenExpo took some time as well...
-20:58 <@dertobi123> dev-zero: heh
-20:58 <@dev-zero> dertobi123: didn't even have time to upload the picture of you and maekke ;-)
-20:58 <@dberkholz> ok, today's meeting is over. as usual, i strongly encourage everyone to take topics to the lists that we didn't get to today, so we can get some action without waiting 2 weeks.
-20:58 <@dertobi123> dev-zero: oh! ;)
-20:59 <@dberkholz> and council members in particular, please do what you can to actively participate on those topics in particular
-21:00 <@dev-zero> or do help zmedico with the implementation of eapi-3 features :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090423-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090423-summary.txt
deleted file mode 100644
index 317723ce91..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090423-summary.txt
+++ /dev/null
@@ -1,82 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: here
-Cardoe: absent
-dberkholz: here
-dertobi123: here
-dev-zero: here
-leio: here
-lu_zero: here 
-tanderson(secretary): here
-
-Topics:
-===========
-
-Technical Issues:
-
-    - Portage changing behaviour without EAPI bumps:
-        David Leverton(dleverton) requested that the council mandate that portage
-        is not allowed to change behaviour that is specified in PMS, as has
-        occurred a few times in the past.
-
-        Conclusion:
-            The council decided that if PMS-conflicting changes occur in
-            package managers then the council can mandate that versions that
-            conflict will be masked. The council may take into account
-	    extenuating circumstances.
-
-    - EAPI 3:
-        EAPI 3's features have been finalized and its final approval is
-        pending portage support for the most important features. Some less
-	critical features may be removed if they cannot be accomplished in
-	a reasonable timeframe and are holding up the introduction of the
-	critical features. This summary of features lists only those features
-	discussed on the April 23 meeting of the Gentoo Council.
-
-        - New utility functions: 'Doexample'/'Doinclude'
-            Some council members believed that adding these utility functions
-            would complicate things for new ebuild authors while not providing
-            any especially needed features.
-
-            Conclusion:
-                Voted to not be included in EAPI 3.
-
-        - Ban || ( use? ( ... ) ... )
-            Mart Raudsepp(leio) argued that banning such constructs is
-            strictly a QA issue and shouldn't be covered by PMS, while others
-            argued that there are no valid use cases for the construct and
-            that you need appropriate rules to parse RDEPEND/DEPEND.
-
-            Conclusion:
-                It was decided that a repoman warning would be most
-                appropriate for this case and that the topic of banning it in
-                an EAPI can be revisited for EAPI 4.
-
-        - Ban 'dohard'
-            Currently dohard cannot be guaranteed to work across filesystems
-            and few packages use it.
-
-            Conclusion:
-                Voted to be banned in EAPI 3.
-
-        - New econf options,
-          '--disable-dependency-tracking'/'--enable-fast-install'
-            The addition of '--enable-fast-install' was opposed because it is
-            already a libtool default and as such is useless. No arguments
-            were made against '--disable-dependency-tracking'.
-
-            Conclusion:
-                '--disable-dependency-tracking' was voted in, while
-                '--enable-fast-install' was voted out.
-
-        - Add --if-compressed option to unpack().
-            
-            Conclusion:
-                Voted to be not included in EAPI 3.
-
-        - Slot Operator Dependencies(:= and :*)
-            
-            Conclusion:
-                 Voted to be included in EAPI 3. Mart Raudsepp has remaining
-                 queries about the final syntax.
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090423.txt b/xml/htdocs/proj/en/council/meeting-logs/20090423.txt
deleted file mode 100644
index 1935ff82ca..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090423.txt
+++ /dev/null
@@ -1,707 +0,0 @@
-20:00 <@dberkholz> ok, let's get started
-20:00 <@dberkholz> who's here
-20:00 <@dertobi123> <-
-20:00 <@dev-zero> here
-20:00 <@leio-dl> here
-20:01  * lu_zero is here
-20:02 <@dberkholz> Betelgeuse, Cardoe: check in post-2000 please
-20:02 <@Betelgeuse> \o/
-20:02 <@dberkholz> tanderson: here?
-20:03 <+tanderson> yeup
-20:03 <@dberkholz> ok, that's everyone but cardoe
-20:03 -!- ferringb [n=ferringb@67.164.75.74] has joined #gentoo-council
-20:04 <@dberkholz> seems people really want to cover the "Portage changing behavior in ebuild-visible ways
-20:04 <@dberkholz> "
-20:04 <@dberkholz> topic, and we heard positively back from zmedico, so my feeling is that we can do something worthwhile with it quickly
-20:04 <@dberkholz> the proposal is that we vote that this isn't allowed to happen in the future and will be reverted if so
-20:05 <@dberkholz> are people ready to vote on that?
-20:05 <@dev-zero> yes
-20:05 <@dertobi123> yes and yes
-20:05 <@lu_zero> yes^2
-20:05 <@dev-zero> and yes for the vote
-20:05 <@leio-dl> what is really "this" is the vague thing here imho. Pretty subjective matter at times
-20:06 <@Betelgeuse> zmedico: has changed things on ways that are on no way subjective
-20:06 <@Betelgeuse> like changing order of phaes
-20:06 <@Betelgeuse> phases
-20:06 <@leio-dl> sure, those should get communication
-20:06 <@Betelgeuse> they should not be done at all
-20:06 < ciaranm> uhm. not "communication". "reverted".
-20:06 <@Betelgeuse> that's why we have EAPI
-20:07 <@dev-zero> it's not a one-man show anymore
-20:07 <@leio-dl> but lets make sure we aren't going to end up having to discuss everything done or have everything done be an EAPI feature, you see where I'm going maybe. Otherwise, yes
-20:07 < jmbsvicetto> Are you guys ready to "forbid" portage to have new features?
-20:07 <@leio-dl> No
-20:07 <@dberkholz> as far as i can tell, ebuild-visible features is pretty much the definition of an EAPI
-20:07 < ciaranm> jmbsvicetto: uh, no-one said anything about that
-20:08 <@Betelgeuse> Portage should not change behaviour in EAPI 0.
-20:08 < jmbsvicetto> ciaranm: well, restrict the above sentence to "if those features happen to have ebuild-visible effect"
-20:08 <@leio-dl> for example phase order default isn't really ebuild-visilbe
-20:08 <@dberkholz> not counting optionally handled stuff etc.
-20:08 < ferringb> hate to point out the obvious, but why not just have it such that the next time this occurs it's brought to the council, instead of trying to forbid portage from doing a vaguely defined thing
-20:08 <@Betelgeuse> leio-dl: what?
-20:08 < ciaranm> jmbsvicetto: read dleverton's proposal.
-20:09 < jmbsvicetto> ciaranm: was it sent today?
-20:09 <@Betelgeuse> leio-dl: ebuilds wont' break if src_install comes before src_compile?
-20:09 < ferringb> changing the mtime preservation (which is ebuild visible but not eapi mandated) is a good example of why this vagueness will be problematic
-20:09 < ciaranm> jmbsvicetto: no. long before that.
-20:09 <@leio-dl> Betelgeuse: nevermind, I was thinking completely different thing
-20:09 <@leio-dl> phase order change is ebuild visible. What was the change exactly btw?
-20:09 < Ford_Prefect> ++ on what ferringb said. Rather than stifle changes we don't even know yet, let's talk about them when they actually (need to) happen.
-20:09 <@Betelgeuse> leio-dl: he changed the order while updating
-20:09 <@dberkholz> the wording might be a touch off.
-20:10 < ciaranm> ferringb: we're looking to get assurances that when it happens, we can get it reverted quickly, rather than having to wait months for a decision by which point there's an even bigger mess to fix
-20:10 <@dberkholz> we could clarify it to ebuild-visible things that are specified by an EAPI or conflict with something specified by an EAPI
-20:10 < jmbsvicetto> ciaranm: I understand the concern about package.mask.d changes and agree about that, but I'm worried this might end up in preventing portage development
-20:10 < ferringb> ciaranm: I've been there for each of those scenarios; going to the council (which has a two week cycle roughly) is fast enough
-20:10 -!- codejunky [i=jan@nerdig.org] has left #gentoo-council []
-20:10 < ciaranm> jmbsvicetto: and if it ends up doing so in such a way that's causing problems, we can revisit it for those issues. but given that we have EAPIs, there's very likely not a problem.
-20:11 < ciaranm> ferringb: that hasn't worked.
-20:11 <@leio-dl> I think the important bit is to simply not have that unwarranted change end up in a stable version portage upgrade
-20:11 <@leio-dl> more or less
-20:11 < ferringb> ciaranm: if it fails next time around, fine, going for the heavy handed ruleset.  this is keeping in mind I agree with your point, but not your solution here.
-20:11 <@lu_zero> ciaranm your concern is just for stable portage and api or every portage released?
-20:11 < ciaranm> lu_zero: my concern is when portage makes arbitrary, ebuild-visible, PMS-contradicting changes because zmedico thinks it's a good idea
-20:11 <@dberkholz> ok, here's an idea that might satisfy people
-20:11 < darkside_> man, give zac a break. he didn't brick everyone's gentoo system. i didn't even notice this change that is causing so much concern
-20:11 <@dberkholz> the change has to be reverted until the next council meeting
-20:11 < ciaranm> such as, say, phase order changes.
-20:12 < ciaranm> darkside_: you didn't have to go around tidying up after him
-20:12 < ferringb> that change was also near a year back
-20:12 <+tanderson> darkside_: yeah, I'd agree. but it still shouldn't have happened and things like that have the possibility to brick things
-20:12 < Ford_Prefect> Why does it need to wait for a council meeting for a decision? Can the discussion and decision not be made on-list?
-20:13 <@Betelgeuse> darkside_: We shouldn't gamble with users systems.
-20:13 < ferringb> dberkholz: s:reverted:unreleased:
-20:13 < jmbsvicetto> ciaranm: I think the real problem is for portage to introduce new features that cause issues for established EAPIs and that people start relying on
-20:13 < ferringb> dberkholz: and that I personally could live with, suspect zac also.
-20:13 < jmbsvicetto> ciaranm: The problem isn't the feature in itself but that people start relying in it
-20:13 <@dberkholz> ferringb: i guess reverted from the user perspective. you can't unrelease things, but you can release a bump that reverts the change.
-20:14 < ciaranm> what we need is a "this won't happen, and if it does it will get reverted quickly, and if something really needs to break that rule then it'll do so after careful discussion and planning", not "well the council might eventually step in, but not if by that point the mess has already happened, in which case everyone else has to catch up"
-20:14 <@dberkholz> can someone propose a single wording that we can just vote on?
-20:14 <@dberkholz> this is turning into a long discussion
-20:14 < solar> don't be afraid to talk
-20:15 <@Betelgeuse> solar: if there was something to talk about
-20:15 < ciaranm> "If ebuild-visible, PMS-conflicting changes occur in Portage, the Council will make sure they get reverted quickly. If special circumstances come along, they will be dealt with specially."
-20:15 < ferringb> dberkholz: you can pull it from the tree actually; also note that people are watching the changes occuring in svn, so it may not even hit the point of a release.
-20:15 <@Betelgeuse> or does some council feel that he doesn't understand the issue?
-20:15 <@Betelgeuse> +member
-20:15 < solar> there is clearly if people are talking about it and don't see eye to eye
-20:15 < ferringb> ciaranm: drop ebuild visible
-20:15 <@lu_zero> I'd specify portage version
-20:16 < ciaranm> "If PMS-conflicting changes occur in Portage, the Council will make sure they get reverted quickly. If special circumstances come along, they will be dealt with specially."
-20:16 < Ford_Prefect> ciaranm's wording sounds reasonable. The second sentence seems redundant, really, since that is implicitly the council's job.
-20:16 < ferringb> mostly suffices, even if I think this seriously heavy handed for issues mostly gone these days.
-20:16 < tove> s/Portage/PM/
-20:16 -!- mroconnor [n=MarcO@unaffiliated/mroconnor] has joined #gentoo-council
-20:16 < ferringb> tove: ++
-20:17 <@Betelgeuse> council has no control over other PMs
-20:17 < ciaranm> for issues that're already gone we've already tidied up the mess
-20:17 < ferringb> Betelgeuse: council implicitly does via punting the versions out of gentoo-x86
-20:17 < ciaranm> things like phase order changes are a lost cause now
-20:17 <@leio-dl> we could have control of what version and stuff is in gentoo-x86
-20:17 < ferringb> Betelgeuse: that's the same control the council has over portage realistically
-20:17 < ferringb> nail *all* PM's with that rule and I'll be very happy
-20:17 <@leio-dl> you break it in pkgcore new version, we p.mask it
-20:17 < ferringb> exactly
-20:17 <@Betelgeuse> ferringb: well we control who has access to Portage svn etc
-20:17 <@Betelgeuse> ferringb: or Gentoo does in general
-20:18 <@lu_zero> so we can control what's in portage
-20:18 < jmbsvicetto> Betelgeuse: And we don't control gentoo-x86?
-20:18 <@dertobi123> yep
-20:18 < ferringb> Betelgeuse: all that truly matters here is if it gets released and used- meaning gentoo-x86.
-20:19 <@dertobi123> so, make it "in any Package Manager"Ã? can we agree on that?
-20:20 <@Betelgeuse> fine to me if ferringb and ciaranm don't oppose
-20:20 <@dev-zero> ++
-20:20 < ciaranm> wfm
-20:21 <@leio-dl> "If PMS-conflicting changes occur in a package manager, the council will make sure the affected versions will be package.masked in gentoo-x86 at the very least". Something like that?
-20:21 < ciaranm> although i think it's silly. the whole problem is only there because portage's influence means if portage changes everyone else has to.
-20:21 <@dberkholz> so how's this "If PMS-conflicting changes occur in a package manager, the council will ensure that conflicting versions are not generally available in Gentoo, excepting extenuating circumstances."
-20:21 < ferringb> dberkholz: masked please, although preferably not even in gentoo-x86
-20:21 < jmbsvicetto> ciaranm: If someone were to rely on changes done on another PM in the tree, we would get the same issue
-20:21 < ferringb> dberkholz: extenuating is fine also.  frankly sorting it out when it occurs works for me also
-20:22 < ciaranm> jmbsvicetto: yeah, but that's never happened and realistically won't happen
-20:22 < jmbsvicetto> Cardoe: The problem is people relying on "incompatible changes"
-20:22 < ferringb> it's happened w/ paludis
-20:22 < ferringb> version comparison differences come to mind
-20:22 < jmbsvicetto> Cardoe: sorry
-20:22 < ferringb> pretty sure I've triggered it at least once unintentionally in the past for pkgcore also
-20:22 < jmbsvicetto> ciaranm: ^^
-20:22 < jmbsvicetto> The -r0 stuff, right?
-20:23 <@dberkholz> happy with this, then? "If PMS-conflicting changes occur in a package manager, the council will ensure that conflicting versions are masked, excepting extenuating circumstances."
-20:23 < ferringb> no, actual version comparison, how '0' was dealt with
-20:23 < ciaranm> -r0 was a pkgcore bug, and paludis behaved exactly as pms specified
-20:23 < Ford_Prefect> dberkholz, ++
-20:23 < ciaranm> the '0' thing varied between portage releases at that point
-20:23 < ciaranm> dberkholz: fine by me
-20:23 <@dertobi123> dberkholz: happy with that
-20:23 <@dev-zero> dberkholz: ++
-20:23 <@dberkholz> other council members?
-20:23 <@lu_zero> I'm fine
-20:23 <@leio-dl> zmedico: how do you feel about that?
-20:24 < ferringb> dberkholz: wfm.
-20:24 <@Betelgeuse> sure
-20:24 < zmedico> leio-dl: sounds reasonable
-20:24 <@dberkholz> i'm good with that.
-20:24 <@leio-dl> then fine by me
-20:24 <@dberkholz> ok, let's get on with it
-20:24 <@dberkholz> EAPI=3 proposal
-20:24 <@dberkholz> you saw all the features with "no" votes
-20:25 -!- EvaSDK [n=eva@gentoo/developer/evasdk] has joined #gentoo-council
-20:25 <@dev-zero> you can change my "no" for docompress to a "whatever"
-20:25 <@dberkholz> i propose that any features with a "no" get dropped, unless people voting no are willing to change their votes
-20:25 < ciaranm> dberkholz: some features are considered both "no" and "critical"
-20:25 <@dberkholz> yeah, i'm looking forward to that one.
-20:26 <@dberkholz> ciaranm: some meaning more than just the compression one?
-20:26 <@dberkholz> because that's now a whatever
-20:26 < ciaranm> mm, the rest are mostly one no with a bunch of yesses
-20:27 < ciaranm> dropping all of those would be rather crippling
-20:27 <@Betelgeuse> I don't see why one no should get a feature dropped.
-20:27 < Arfrever> You could vote separately for every feature.
-20:27 <@dberkholz> the others i see are ANY-USE, DOEXAMPLE/DOINCLUDE, BANNED-COMMANDS (dohard/dosed), UNPACK-IF-COMPRESSED
-20:27 < ciaranm> for most of the features there's a clear majority
-20:27 <+tanderson> Betelgeuse++
-20:28 <@leio-dl> I explained why that majority is not that meaningful in my e-mail
-20:28 <@dberkholz> Betelgeuse: yeah, i guess my real intention is to make sure everyone knows *why* someone is voting no
-20:28 <@leio-dl> many of the features with no's are not features but banning, tolo
-20:28 <@leio-dl> too*
-20:28 <@dberkholz> if they take that into account and still choose to vote for it, that's fine
-20:28 < ciaranm> dropping anything with a single "no" is going to cripple EAPI 3, and postponing's a really bad idea
-20:29 < bonsaikitten> so let's drop eapi3 and wait until people can agree.
-20:29 <@dberkholz> a la src_install DOCS, i explained my opinion and most people just didn't agree
-20:29 < bonsaikitten> I like that idea
-20:29 <@dev-zero> I agree there, and I could have argued the same way as leio for controllable-compress, but seeing that people really seem to want it led me decide to accept it
-20:29 < ciaranm> bonsaikitten: please troll somewhere else, we're trying to get this settled
-20:30 < ciaranm> the two 'controversial' ones seem to be doexample and doinclude
-20:30 < bonsaikitten> ciaranm: so am I. Stop throwing mud.
-20:30 < ciaranm> which fortunately no-one really seems to care overly much about
-20:30 < Ford_Prefect> dberkholz, why not assign 5 minutes per feature for discussion. If there is consensus at the end, go ahead, else drop for further discussion.
-20:30 <@dberkholz> so, let's run through the "no's" quick now that everyone is definitely listening
-20:30 < peper> 5x24 - gl with that ;]
-20:30 <@leio-dl> maybe we all can find some dozen more minutes for the meeting if necessary
-20:30 < peper> 25 even
-20:31 <@Betelgeuse> peper: just nos
-20:31 <@leio-dl> the ones with any 'no's is considerably smaller
-20:31 <@dberkholz> let's start with doexample/doinclude
-20:31 <@Betelgeuse> we use doexample quite often with java
-20:31 <@dberkholz> my feeling is that these don't do anything interesting that insinto+doins can't do easily
-20:32 < ciaranm> i get the impression that opinions on doexample and doinclude are either "sure, why not, there'd be a use for that" or "meh, i think it's pointless"
-20:32 <@dberkholz> same permissions as any other arbitrary normal file
-20:32 <@leio-dl> my feeling is the same, especially for doinclude
-20:32 < Arfrever> dberkholz++
-20:32 <@leio-dl> (on top of that with doinclude you really shouldn't need to use it but have the build system fixed imho)
-20:32 <@Betelgeuse> dberkholz: insinto+doins can do that but it's much easier for newbies to write a single call
-20:32 <@dberkholz> it's more material to learn that doesn't really simplify anything complex
-20:32 <@dertobi123> indeed
-20:33 <@Betelgeuse> dberkholz: you need a subshell if you don't want insinto sticking to exampels dir
-20:33 <@leio-dl> dberkholz++
-20:33 < ferringb> random suggestion.... why not set aside a meeting for *just* eapi3 if y'all are low on time.  dislike the notion it needs to go through now, and nothing can be dropped.
-20:33 < ciaranm> unless anyone has an opinion other than "mildly useful" or "mildly pointless", how about just having a vote right now and going on majority?
-20:33 <@dev-zero> ferringb: please, there isn't much left we have to discuss
-20:33 <@Betelgeuse> How about doinstall <dir> <stuff> ?
-20:33  * leio-dl has time for 2-3 more hours :)
-20:34 <@dberkholz> if i thought it was mildly pointless, i would've said whatever instead of no
-20:34 <@Betelgeuse> well food for later eapis
-20:34 < ferringb> Betelgeuse: exactly.
-20:34 <@dberkholz> other council members got a useful, new opinion on doexample/doinclude?
-20:35 <@dberkholz> otherwise let's take a vote and go with majority, since the idea is that we've spoken our minds
-20:35 <@Betelgeuse> I vote yes
-20:35 <@dev-zero> yes
-20:35 <@dberkholz> no
-20:35 <@leio-dl> maybe they should be taken separately
-20:35 <@leio-dl> I vote no
-20:35 <@leio-dl> for both
-20:35 <@dertobi123> no for both
-20:35 <@dberkholz> sure, if anyone has a split vote, feel free to say so.
-20:35 <@lu_zero> I'd no both since Betelgeuse suggested something that could replace them
-20:36 <@dberkholz> that's all 6 of us who are around, 2 yes 4 no
-20:36 <@dberkholz> so it's in
-20:36 <@dberkholz> let's move on to ANY-USE
-20:36 <@leio-dl> I think you mean it's out?
-20:36 <@dberkholz> errr, yes.
-20:37 <@dertobi123> heh
-20:37 <@leio-dl> ANY-USE I think is me
-20:37 < ciaranm> both out? lemme update the spreadsheet
-20:37 <@dberkholz> leio-dl: your reason for voting "no" once more, please?
-20:37 <@dberkholz> tanderson: just to be perfectly clear when you're making the summary, doexample/doinclude will not be in EAPI=3.
-20:37 <@leio-dl> I strongly believe this is not something that an EAPI should be dictating. It's a QA issue if used for the purpose as described, not something that must be completely forbidden hard with an EAPI rule
-20:38 <@Betelgeuse> ciaranm: is || ( foo? ( a ) b ) valid btw?
-20:38 < ciaranm> Betelgeuse: currently yes, but it shouldn't be, and won't be with ANY-USE
-20:38 <@leio-dl> Make a repoman check, what is the reason to have this an EAPI item
-20:38 <+tanderson> dberkholz: k
-20:38 < ciaranm> leio-dl: the reason is that it's already special-cased in PMS, and we want to remove that special case
-20:39 <@dev-zero> since there is no use case you could solve with it
-20:39 <@dev-zero> but you generate problems by using it
-20:39 <@leio-dl> how are you sure about that?
-20:39 <@leio-dl> that there is no use case. Why should it be said in PMS
-20:39 <@leio-dl> there is no use case for other constructs as well conceptually
-20:39 <@Betelgeuse> leio-dl: because Portage supports it in EAPI 0
-20:39 <@dberkholz> maybe to rephrase, nobody has thought of a use case for it and devs do create real problems when trying to use it
-20:39 < ciaranm> other constructs aren't special-cased in PMS currently
-20:39 <@Betelgeuse> leio-dl: so if you are making a diff against EAPI 0 you must ban it
-20:39 <@leio-dl> so it should be a repoman warning or error
-20:40 < ciaranm> dberkholz: it's not just that there's no use case thought of. it's that there's no way you can use it correctly.
-20:40 <@leio-dl> why should we set a precendence that EAPI's can say what kind of RDEPEND combinations are valid or not
-20:40 < ciaranm> leio-dl: it's already something mandated by PMS
-20:40 <@leio-dl> if you give me a bit, I can come up with many more nonsensical constructs there
-20:40 < ciaranm> leio-dl: you can't cope up with any nonsensical constructs that have special wording in PMS to deal with them
-20:40 <@Betelgeuse> You need rules to be able to parse RDEPEND.
-20:41 <@dberkholz> does that mean we should be changing the meaning of || instead of banning a syntax?
-20:41 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Nick collision from services.]
-20:41  * ferringb strongly suspects that via appropriate checks in the ebuild it is possible to use it properly.  not saying people do that however.
-20:41 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council
-20:41 < ciaranm> dberkholz: all we're doing, in effect, is moving part of ||'s meaning from being a convoluted mess to just making some of it explicitly illegal
-20:41 <@leio-dl> exactly, there can be cases where it _could_ be used fine
-20:41 < ferringb> hence error/warning being my preference, and banning if it proves to be a non issue by the time of the next eapi.
-20:42 < ciaranm> leio-dl: no there aren't
-20:42 <@lu_zero> anybody checked how widely it is used?
-20:42 <@leio-dl> I believe zmedico agrees with ferringb?
-20:42 <@Betelgeuse> ciaranm: Is there a valid syntax for use? inside || ( ) ?
-20:42 < ciaranm> lu_zero: three or four places in the tree last time i looked, all wrong, and one example in the docs, which is wrong
-20:42 <@dberkholz> my understanding is that because of the difference between || preferring first-installed and use flags preferring what USE is, you can never deterministically pull in the right deps
-20:42 < zmedico> leio-dl: yeah, I'd prefer warning
-20:42 < ciaranm> Betelgeuse: as a direct child, it's syntactically legal at present but can't be used correctly
-20:43 < darkside_> bug 168179
-20:43 < Willikins> darkside_: https://bugs.gentoo.org/168179 "Packages misusing || ( use? ( ) ) constructs"; Gentoo Linux, Applications; NEW; ciaran.mccreesh@googlemail.com:qa@g.o
-20:43 < ferringb> dberkholz: has_version... like I said, via appropriate ebuild voodoo...
-20:43 <@dberkholz> ferringb: how can you use has_version in DEPEND?
-20:43 < ciaranm> you can't even has_version it correctly because there can be multiple matches
-20:43 <@leio-dl> yes, you prefer one of them
-20:43 < ferringb> dberkholz: has_version checking w/in the ebuild as to which actually was used.  for hard linkages (gcc and friends) he's right
-20:43 < ferringb> dberkholz: for dynamic imports, it's a different story imo
-20:43 <@leio-dl> you can do that in python
-20:44 <@dberkholz> by the time you know which was used, you've already pulled in an irrelevant package in DEPEND that you had a USE flag for but didn't get used in the ||
-20:44 <@leio-dl> they actually use code
-20:44 <@leio-dl> try:
-20:44 < ferringb> or at least a muddier story that makes this grey
-20:44 <@leio-dl>   import foo
-20:44 <@leio-dl> except:
-20:44 <@leio-dl>   import bar
-20:44 < darkside_> looks like 6 ebuilds are still in violation? really a reason to be arguing about this?
-20:44 < ferringb> elementtree/celementtree/python:2.6 is an example
-20:44 < ciaranm> darkside_: we want to remove a whole load of messy special-casing, so yes
-20:44 < ferringb> pkgcore would have such a dep if it weren't for the fact we bundle a fallback ;)
-20:44 <@leio-dl> that special casing isn't going to go anywhere
-20:44 <@dberkholz> any council members still unclear on the implications of this?
-20:45 <@dberkholz> if not, we might as well vote
-20:45 <@dev-zero> leio-dl: wrong, in general an ebuild should remove the option which hasn't been selected, even if changeable at runtime
-20:45 <@leio-dl> so to reiterate, there are valid use cases for this
-20:45 <@Betelgeuse> Well could someone tell me why flatten use and then do || ( ) norma doesn't work if there are multiple children
-20:45 <@Betelgeuse> I was only thinking with a single use? children
-20:45 < ciaranm> Betelgeuse: did you see the example i posted to the list when this first came up?
-20:46 <@Betelgeuse> ciaranm: that's probably some time ago and I have already forgotten
-20:46 <@Betelgeuse> ciaranm: do you have an archive link?
-20:46 < ciaranm> Betelgeuse: http://archives.gentoo.org/gentoo-dev/msg_4b2d8e11cb80aba847b8ab687ab5af47.xml
-20:46 <@leio-dl> you have a dynamic language. You allow something to be preferred by a USE flag (possibly an extra dep). The package itself can work dynamically with either anyway. Hence that syntax is exactly what is proper to express all of that
-20:47 <@dev-zero> leio-dl: no, it's not. example: blueman
-20:47 < ciaranm> leio-dl: no, it's not.
-20:47 <@leio-dl> blueman?
-20:47 < ciaranm> leio-dl: either you use a simple || ( ) dep, or you use a set of use? deps so you know which you're getting
-20:47 <@leio-dl> you don't need to know that
-20:48 <@leio-dl> it is irrelevant
-20:48 <@dev-zero> leio-dl: check the ebuild, reason why even for dynamic languages such switching may be harmful
-20:48 <@leio-dl> it works with both
-20:48 < ciaranm> leio-dl: if you don't need to know it, you use || ( ) on its own
-20:48 < ciaranm> leio-dl: if you do need to know, you use the use construct expanded to what you really mean
-20:48 <@dev-zero> vote please?
-20:48 <@leio-dl> dev-zero: what category is that?
-20:48 <@dev-zero> leio-dl: net-wireless
-20:49 <@dev-zero> leio-dl: but that doesn't really belong in this meeting
-20:49  * ferringb notes again, pkgcore's xml usage is a valid counter example to this
-20:49 < Arfrever> There's only: network? ( || ( net-dns/dnsmasq =net-misc/dhcp-3* ) )
-20:49 < ciaranm> ferringb: || ( ) with no use? is the correct way of doing that
-20:50 < ciaranm> ferringb: if you add in the use?, all you do is break up-front repeatability
-20:50 < ferringb> ciaranm: obviously folk disagree on the 'correct' there.
-20:50 <@Betelgeuse> I vote no and make this go to repoman then.
-20:50 < ciaranm> ferringb: those people are missing the implications of lack of up-front repeatability
-20:50 < Arfrever> dev-zero: What is exactly wrong in blueman?
-20:51 <@Cardoe> tanderson: mark me as basically missing it.
-20:51 < ferringb> ciaranm: up front repeatability isn't there to begin with unless the vdb is in the exact same state, resolver algo hasn't changed, etc.
-20:51 <@dev-zero> Arfrever: not now
-20:51 <@leio-dl> the settings are stored in different place depending on which
-20:51 <@Betelgeuse> But I am not strongly opionated either way.
-20:51 < ciaranm> ferringb: if a user has USE=-foo, but has libfoo installed, does pkgcore still use libfoo if it's available?
-20:51 -!- mroconnor [n=MarcO@unaffiliated/mroconnor] has quit [Connection timed out]
-20:52 < ciaranm> ferringb: assuming libfoo is the first choice, of course
-20:52 < ferringb> ciaranm: in cases of this sort, ||() constructs basically become ordered preference
-20:52 <+tanderson> Cardoe: yep, you were more than 15 minutes late anyway I /think/
-20:52 < ciaranm> ferringb: simple question. simple answer please?
-20:53 <@Cardoe> tanderson: I was.
-20:53 <+tanderson> goodie, my clock's not off then
-20:53 <@leio-dl> the USE is in there something that allows the user to opt out or in of a provider. An ordered preferences, yes
-20:53 < ferringb> ciaranm: the underlying code is still going to do an ordered set of imports till it finds one that works- via ||() w/ conditionals it's specifying the preference.  yes, because of ||() behaviour it's possible for it to choose something other then leftmost- that's more a resolver choice however
-20:54 <@dberkholz> i've gotta step away for a few, anyone feel free to bring it to a vote
-20:54 < ciaranm> so basically if we're using this construct for dynamic things as leio-dl and ferringb have suggested, the user specifying USE=-foo but having foo installed may result in foo being used anyway, and the package manager thinking it's not used. so, again, no right way of using it.
-20:54 < loki_val> Please ban this feature. It makes my head hurt trying to figure it out.
-20:54 < ferringb> loki_val: heh
-20:54 <@leio-dl> it doesn't matter
-20:54 <@leio-dl> if the package manager thinks its used or not
-20:55 < ferringb> ciaranm: if you'd really like the import list to be pruned down to exactly what the ||() was at the time of merging, it can be done.  reason it isn't is because that's generally pointless to do
-20:55 <@leio-dl> the package itself works with either one, as long as one of them is available, which is what a ||() construct is about
-20:55 <+tanderson> loki_val: hehe, :)
-20:55 < ciaranm> leio-dl: uh, i don't think you've thought that through
-20:55 < ferringb> warn/error it, presuming no real world screaming after an eapi cycle, punt it.
-20:55 < ferringb> for eapi deprecation of most stuff I kind of prefer that approach anyways
-20:55 < ferringb> (where viable of course)
-20:56 < ciaranm> leio-dl: you're saying, in effect, that it's fine for packages to list utterly incorrect dependencies, when listing them correctly instead is even easier
-20:56 <@leio-dl> ciaranm: except they are not incorrect
-20:56 <@Betelgeuse> add a warning now and let's drop it in EAPI 4 if not valid usage comes up
-20:56 < ciaranm> leio-dl: read what i just said. they are.
-20:56 <@leio-dl> read what I said, they are not? This goes nowhere like that.
-20:57 < ciaranm> leio-dl: your "try to import foo, then bar" example is expressed as || ( foo bar ), not || ( foo? ( foo ) bar? ( bar ) )
-20:57 <@leio-dl> My vote is that we make it a repoman warning instead, and see for EAPI-4
-20:57 < ferringb> ciaranm: you're pointing at all fault w/ ||() in general btw, consider multiple satisfiers available...
-20:57 < ciaranm> ferringb: || ( ) in general is at least well defined
-20:57 < ferringb> Eh.
-20:57 <@leio-dl> the USE check adds a preference
-20:57 < ferringb> weak counterarg, that one.
-20:57 < ciaranm> if a package does "try to import foo, then bar", that maps exactly onto what || ( foo bar ) does
-20:57 <@leio-dl> it can be useful in certain embedded scenarios, for example
-20:58 < ferringb> either way
-20:58 <@dertobi123> ok, dito for repoman warning now and let's take another look for eapi-4
-20:58 < ciaranm> leio-dl: er, the preference is ignored, though
-20:58 <@leio-dl> but foo is something that needs a python library that has a global USE flag for it
-20:58 < ferringb> ciaranm: suspect you've made your point, know I've made my point.  might as well leave it to them to decide.
-20:58 <@lu_zero> I agree with leio-dl first have a repoman check then bring it back to eapi-4
-20:59 <@dev-zero> well, I'd vote for ban in eapi-3, but since that doesn't get a majority I'm fine with first repoman check and then ban (to get at least something)
-20:59 <+tanderson> I gotta run to a college seminar(trying to steal my money.) I'll work(hopefully get out) on the summary tomorrow
-20:59 <@dev-zero> tanderson: ok, thanks
-21:00 <@leio-dl> ok, so I think we have leio, lu_zero, dertobi123 and Betelgeuse for repoman warning and revisit EAPI enforcement in EAPI-4
-21:00 <@dertobi123> right
-21:00  * ciaranm marks that on the spreadsheet
-21:00 <@Betelgeuse> I would like to see us finishing the list today so let's continue?
-21:00 <+tanderson> dev-zero: np
-21:00 <@dev-zero> Betelgeuse: jup
-21:01 <@dev-zero> next: banned-commands?
-21:01 <@leio-dl> Betelgeuse: too late, the day just changed for me ;p
-21:01 <+tanderson> hah
-21:01 <@Betelgeuse> leio-dl: same here
-21:01 <@leio-dl> ok, so we have 24 hours.
-21:01 <@dertobi123> Betelgeuse: uhrm, i need to get up again in a few hours ...
-21:02 <@dberkholz> alright
-21:02 <@Betelgeuse> Well if there's 4 of use around we can vote on what's left :)
-21:02 <@leio-dl> for banned commands the only "no" is for dohard specifically I believe
-21:02 <@dberkholz> i'm back now
-21:02 <@Cardoe> leio: you can add me to the list for enforcement for EAPI=4
-21:02 <@dberkholz> next question is part ofBANNED-COMMANDS dohard
-21:02 < jmbsvicetto> Cardoe: You may want to direct that to tanderson
-21:03 <@dberkholz> quick on the trigger there. leio objected to dropping dohard, people didn't seem to care about dosed one way or the other.
-21:03 <@leio-dl> dohard is useful, it just doesn't guarantee a hard link if they are across partitions. Portage is now fixed to deal with the situation when it is temporarily in different partitions like PORTAGE_TMPDIR or $D
-21:03 <@leio-dl> which was a bug that simply needed fixing, for other reasons mainly
-21:03 <@Cardoe> jmbsvicetto: he already left
-21:04 <@leio-dl> so dohard should now behave quite good, with probably a guarantee to work fine if it's a link to the same directory. Don't see why we should ban a useful function that has no alternative
-21:05 <@leio-dl> (other than calling ln directly, but the PM can deal better with any portability concerns)
-21:05 <@Betelgeuse> leio-dl: in a single dir use ln directly
-21:05 < ciaranm> there's no guarantee it'll work even for the same directory. not all filesystems do hardlinks at all.
-21:05 <@lu_zero> in that case it fallsback to symlink?
-21:05 < ferringb> ick
-21:05 < jmbsvicetto> Isn't a "best effort" better than nothing at all?
-21:05 < ferringb> usual fallback for hardlink is a seperate copy
-21:05 <@Cardoe> not all filesystems support symlinks as well
-21:05 < ciaranm> lu_zero: no, there's a fallback to a copy
-21:05 <@leio-dl> yes, the documentation implying that there is a guarantee should be changed then
-21:06 < ciaranm> Cardoe: if there's no symlink support you can't install gentoo onto it
-21:06 <@Betelgeuse> Do we support file systems with no hardlinks on system partitions?
-21:06 <@Cardoe> ciaranm: I'll make Gentoo on vfat a reality someday ;)
-21:06 < ciaranm> Betelgeuse: yes
-21:06 <@lu_zero> which ones?
-21:07 <@leio-dl> if it's not technically possible, it'll make a copy. But if a hard link is useful instead of a copy when it's possible to have on the partitions involved...
-21:07 <@Betelgeuse> I wonder how much upstream software relies on hardl inks.
-21:08 <@leio-dl> well, probably not much that would fall over if it's a copy instead
-21:08 <@lu_zero> is dohard used widely?
-21:08 <@leio-dl> but a copy takes space
-21:08 <@dev-zero> lu_zero: no
-21:08 < ciaranm> dohard's not used widely and mostly used incorrectly
-21:08 < ferringb> hardlinks have other issues anyways... they're not really represented in the vdb at all
-21:09 < ferringb> treated as a seperate copy there (chksums and all)
-21:09 <@dberkholz> dohard is used by 6 packages
-21:10 <@dberkholz> streamixer, nbsmtp, w3mimgfb, mailwrapper, pipes, cdecl
-21:10 <@dev-zero> and one of them does a hardlink across directories
-21:10 <@leio-dl> that's orthogonal - proper hard link support is necessary either way. Some packages standard install scripts can do hard links (see dev-util/git)
-21:10 <@dberkholz> all of them stay within /usr/{bin,lib,sbin}
-21:11 < ciaranm> proper hard link support can't be guaranteed. having a dohard's just encouraging people to use something that might not work.
-21:11 <@leio-dl> so in a common scenario of that being mounted on / or /usr, the hard link is technically working
-21:11 <@leio-dl> (not guaranteed)
-21:11 <@dev-zero> dberkholz: nope, nbsmtp doesn't
-21:12 <@Betelgeuse> well dohard would become fatal in EAPI 3 so if there's no hard link support it would not succeed
-21:12 < ciaranm> there was one filesystem a while back (coda? i forget) that only allowed hardlinks that were in the same directory, regardless of cross-fs
-21:12 <@lu_zero> hmm
-21:12 <@Betelgeuse> so you would not end up in an unwanted state
-21:12 <@dberkholz> dev-zero: what does nbsmtp do outside of /usr/bin, /usr/lib, and /usr/sbin? is my grep broken?
-21:12 <@leio-dl> I don't think it should become fatal. So I guess we need some changes anyway in what it does
-21:13 < ferringb> unionfs likely allows for inter-directory hardlink failure btw
-21:13 <@lu_zero> I'd keep it for now and try to overhaul it a bit
-21:13 <@Betelgeuse> Is it useful enough to keep a complicated spec?
-21:13 <@Betelgeuse> Just use ln || die for current usage?
-21:13 <@dev-zero> dberkholz: it links from /usr/bin to /usr/lib and with split-debug info in /usr/lib some user might get the idea to put that one on a separate volume
-21:14 <@dev-zero> dberkholz: probability is low, the case probably doesn't exist, but...
-21:14 <@dberkholz> i think that is a good point from Betelgeuse. we should focus on the core things that get done often as ebuild-specific features, and let people do rare things by hand
-21:14 < ferringb> Betelgeuse: || die doesn't do jack though since when it would fail is during merge
-21:14 <@Betelgeuse> If people want to shape it up, it can come back later.
-21:15 <@Betelgeuse> ferringb: true
-21:15 < ciaranm> ln can fail at build time
-21:15 < ciaranm> the || die is still useful
-21:16 < ferringb> eh, only in build
-21:16 < ferringb> binpkg is completely exempted there, so it's not a good gurantee
-21:16 < ferringb> can only check in preinst, which would suck
-21:16 <@Betelgeuse> ferringb: but dohard suffers the same thing any way
-21:16 <@Betelgeuse> so ot
-21:17 < ciaranm> just tell people to use symlinks. far easier.
-21:17 <@leio-dl> dohard - Create a hardlink to the first argument from the second argument, when possible on the system. Otherwise copies first argument to second argument.
-21:17 <@leio-dl> is what I would propose as an alternative then
-21:17 < ciaranm> leio-dl: bleh. that's not what it does.
-21:17 < ferringb> that's what it should do however
-21:17 < ciaranm> leio-dl: dohard can't even know whether it'll work later on
-21:17 <@leio-dl> that's what I propose it to do in EAPI-3 instead of banning. We need to change something as the stuff would die by default otherwise
-21:18 < ferringb> ciaranm: dohard is enough of a hook that the pm can track that request and try to honor it at merge time
-21:18 < ciaranm> ferringb: but it can't provide that information up-front, which is what leio-dl's saying it has to do
-21:18 <@leio-dl> it doesn't need to provide anything up front
-21:19 <@leio-dl> with that alternative description the package manager at merge time does what it can
-21:19 < ferringb> ciaranm: different reading there.  I interpret most of that as merge time rather then just build.
-21:19 <@dberkholz> we're running over and i need to get going.
-21:19 < ciaranm> leio-dl: the way you have it worded, ebuilds are allowed to dohard, then check whether it did a copy or a link, and do something different depending upon the two as a result
-21:19 < ferringb> ciaranm: my standpoint, once it goes into ${D}, the ebuild shouldn't be screwing with it.
-21:19 <@dberkholz> do you want to continue the discussion about this and --if-compressed?
-21:19 < ciaranm> and the econf options stuff, that has a no
-21:19 <@dberkholz> oh yeah, missed that one.
-21:19 < ferringb> although yes that can make perms slightly tricky (did the hardlink succeed?  if not, I need to chmod it... etc).
-21:20 -!- maekke [n=maekke@gentoo/developer/maekke] has quit [Client Quit]
-21:20 <@dertobi123> can we make it another meeting then, next week or so?
-21:20  * ciaranm cries
-21:20 < ciaranm> can we just go with the majority for the sake of finally getting this done?
-21:20 <@dev-zero> jup
-21:20 <@dertobi123> if we're not going to discuss everything for another 30 minutes each?
-21:20 <@leio-dl> I need to go afk for 3 minutes
-21:20 < ferringb> next meeting.  I dislike rushing stuff that folks don't fully agree on...
-21:20 -!- spitfire__ [n=none@abja91.neoplus.adsl.tpnet.pl] has joined #gentoo-council
-21:21 <@dev-zero> ahem, we had a couple of weeks time to think it through, there was the list request
-21:21 <@dev-zero> no running anymore, please
-21:21 <@dberkholz> and yet people continue to have things to discuss, as evidenced by this meeting
-21:22 < ciaranm> this should have been over weeks ago. unfortunately some people want to be council members for one hour a week.
-21:22 < ferringb> dev-zero: mean it nicely, but there are two options there- 1) folks don't give a damn, 2) consensus ain't there.  if it's #1, hey, force it through.  #2 however...
-21:22 < ferringb> dev-zero: so find out who truly gives a damn ;)
-21:22 < bonsaikitten> grumble.
-21:22 < NeddySeagoon> reconviene another day, it need not be next meeting
-21:23 <@Betelgeuse> Let's just put the yesses here: 1. yes
-21:23 <@dev-zero> yes, yes from me
-21:23 <@dertobi123> and yes from me
-21:23 <@Betelgeuse> one more and we are done
-21:24 <@dberkholz> what are we even voting on here, dohard or everything left on the list
-21:24 <@leio-dl> I just hope everyone understands the implications here.
-21:24 <@Betelgeuse> dberkholz: banning dohard/dosed
-21:24 <@dev-zero> both of it
-21:24 <@Betelgeuse> I don't see the complexity being worth it
-21:24 <@leio-dl> dohard was discussed by me long ago. No-one ever replied to me
-21:25 <@dberkholz> i don't care about dohard
-21:25 <@Betelgeuse> leio-dl: you mean a couple packages just use symlinks?
-21:25 <@dberkholz> i am fine with removing it. not like EAPI=2 is going to disappear tomorrow
-21:25 <@Betelgeuse> leio-dl: they don't even have to migrate to EAPI 3
-21:25 <@leio-dl> until you need to use both dohard and a EAPI=3 feature
-21:26 <@Betelgeuse> leio-dl: there's nothing in the tree that needs dohard
-21:26  * lu_zero doesn't care about dohard that much as well
-21:26 <@leio-dl> maybe that's because portage hard link handling was quite broken until January this year
-21:26 <@dertobi123> so we have 4,5 yes for now, right?
-21:27 <@dberkholz> doesn't that just prove it wasn't needed?
-21:27 <@dertobi123> can we move on then, please?
-21:27 <@leio-dl> I don't care about dohard very hard(sic) either, but I am making myself care as one of the representatives of the electorate. Lets put it that way.
-21:27 <@Betelgeuse> I see dosym as better than falling back on copies
-21:27 <@leio-dl> fine, lets ban it and move on.
-21:27 <@leio-dl> there are technical reasons to use hard links instead of symlinks
-21:27 -!- nirbheek [n=nirbheek@gentoo/developer/nirbheek] has joined #gentoo-council
-21:27 <@leio-dl> where a copy is better than a symlink
-21:28 <@Betelgeuse> sure but doesn't see a big need for stuff ebuidls manually install
-21:28 < ciaranm> econf options!
-21:28 < ciaranm> four yes, one no from leio-dl
-21:28 <@dberkholz> ok, we've pretty much finished up with removing dohard.
-21:28 <@leio-dl> I am fine with --disable-dependency-tracking
-21:28 <@leio-dl> --enable-fast-install is just irrelevant. There is even no reasoning of why that should be passed
-21:29 <@leio-dl> The bug just had the bug subject changed to include --enable-fast-install with not even a mention in comments of why the change of title
-21:29 <@leio-dl> --enable-fast-install is a libtool specific option, which is already the default
-21:30 <@Betelgeuse> so no harm in including it?
-21:30 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)]
-21:30 <@leio-dl> there is the same harm as --disable-dependency-tracking, instead in this case there is no gain either
-21:30 <@leio-dl> hand-made configure scripts might very well implement all the other options, because they are standard in autoconf
-21:30 <@dberkholz> ebuilds would be a lot longer if we respecified every default configure option
-21:31 <@leio-dl> but no-one will want to implement all these libtool configure arguments when they aren't even using libtool
-21:31 <@Betelgeuse> I foudn ciaranm's argument about ignoring unknown options valid
-21:31 <@leio-dl> and those that do use libtool, already have --enable-fast-install as the default unless the upstream package maintainer has specifically requested it to not be (which I have never seen
-21:31 < ciaranm> the hand-made thing is a straw man
-21:31 <@Betelgeuse> libtool might change default
-21:32 <@dberkholz> so might everything else, and yet we don't specify every single option
-21:32 < ciaranm> we still haven't found a hand-made configure script that works with all the mess we already pass but not with the two new ones
-21:32 <@Betelgeuse> vote:
-21:32 <@Betelgeuse> 1.yes
-21:32 <@dberkholz> i'm for dep tracking, against fast-install
-21:32 <@leio-dl> also, there is not even any word from the one who has "requested" it
-21:32 <@leio-dl> not sure why this is even considered as part of EAPI-3 (--enable-fast-install)
-21:33 <@leio-dl> a bug title was changed with no explanation. That's it.
-21:33 < ferringb> ciaranm: about the only one I'd expect is mplayer, due to them mangling the crap out of their script.  still would be rather unlikely to be affected...
-21:33 <@lu_zero> I'm for dep tracking, not fast install
-21:33 <@dev-zero> I'm for both
-21:33 <@leio-dl> bug 211529 is the one in question
-21:33 < Willikins> leio-dl: https://bugs.gentoo.org/211529 "[Future EAPI] have econf run ./configure with --disable-dependency-tracking and --enable-fast-install"; Gentoo Hosted Projects, PMS/EAPI; NEW; nyhm@g.o:pms-bugs@g.o
-21:33 <@leio-dl> you will note that the title was changed with no comment, and there is no mention of fast-install anywhere in the content.
-21:33 <@dertobi123> i'm with lu_zero and dberkholz on that
-21:33 <@lu_zero> ferringb mplayer and ffmpeg are better left w/out econf
-21:34 <@leio-dl> I'm against --enable-fast-install, whatever with --disable-dependency-tracking
-21:34 <@leio-dl> so we have 4 no's
-21:34 <@dberkholz> ok, that's enough folks
-21:34  * ciaranm updates
-21:34 <@dberkholz> plus on --disable-dependency-tracking, minus on --enable-fast-install
-21:34 < ferringb> lu_zero: tend to agree.  either way, only potential I could think of
-21:35 <@leio-dl> when libtool changes default, we can reconsider
-21:35 <@dberkholz> last topic is unpack --if-compressed only allowing known suffixes
-21:35 < ciaranm> unpack --if-compressed. two yes, one no from dberkholz, one query from leio-dl which i think was just about messed up wording in pms
-21:35 -!- spitfire_ [n=none@abjg217.neoplus.adsl.tpnet.pl] has quit [Read error: 110 (Connection timed out)]
-21:36 <@dberkholz> i think it's annoying to need --if-compressed for all unknown formats even though they may not be compressed at all
-21:37 <@leio-dl> no, it was uncertainty of the same thing dberkholz is against
-21:37 < ciaranm> what it means is that unpack foo.txt will now die, unless you do unpack --if-compressed foo.txt
-21:37 <@dev-zero> I think it's easy for people to specify --if-compressed in case they have an A mixed of compressed and uncompressed stuff
-21:37 <@leio-dl> why have to pass it at all
-21:38 < ciaranm> well, we could just make unpack foo.txt utterly fatal, but there are times it's convenient when foo.txt is part of something else
-21:38 <@leio-dl> PM already has a list of extensions it needs to unpack. We make things hard for ebuild developers because we think they don't know if the extension they write in SRC_URI is not a common pack format?
-21:39 <@dberkholz> perhaps adding a few of the most common uncompressed suffixes would help
-21:39 < ciaranm> it's not making things for ebuild developers at all. it's making it easier for them.
-21:39 < ferringb> seems like a rather zealous safety feature more annoying then useful
-21:39 <@dberkholz> my main annoyances are .txt files and scripts
-21:39 <@dberkholz> .sh, .py, .pl
-21:40 <@leio-dl> how is it easier if they have to now pass --if-compressed to places when there is no reason right now and it works fine that way
-21:40 < ciaranm> dberkholz: and how often do you pass those to unpack?
-21:40 <@dberkholz> every time i don't define a custom src_unpack...
-21:40 < ferringb> ciaranm: how does it make it easier?  For the vast majority they won't even need it- for those that do, unpack just doing a cp if it's an unknown format seems way simpler
-21:40 < ciaranm> dberkholz: uh, no. check the default src_unpack in eapi 3
-21:40 <@dev-zero> c
-21:41 < ferringb> it's not like this is an error that'll silently slip by also ;)
-21:41 <@dev-zero> dberkholz: meaning that default src_unpack is passing --if-compressed
-21:41 < ciaranm> ferringb: it's highly unobvious when people do unpack foo.xz and foo.xz silently gets passed through ununpacked
-21:41 <@dertobi123> i'm merely "whatever" on that, but we do specify a list of extensions to unpack - therefore it implicitly is defined how to act on extensions not-specified-for-compression. no need to define that again.
-21:41 < ferringb> ciaranm: not really.  the build blows the hell up shortly there after
-21:42 < ciaranm> ferringb: and people wonder why, especially with some extensions being eapi dependent
-21:42 < ferringb> personally, I consider it a daft feature- it'd be less annoying if it was inverted (--all-compressed)
-21:42 < ciaranm> experience has shown that you very rarely have to specify it
-21:43 <@dberkholz> so, if it's in the default to ignore them, then how is it even a useful thing to add?
-21:43 < ferringb> raising the question of it's usefulness in light of the build blowing up if they screw up anyways
-21:43 < ciaranm> dberkholz: stick 'unpack foo.xz' in an ebuild right now. it will silently do nothing.
-21:44 <@dertobi123> as expected
-21:44 <@dberkholz> same as would happen if i stuck foo.cx in SRC_URI and didn't have src_unpack
-21:44 <@leio-dl> adding --if-compressed also means all eclasses that export src_unpack need to make yet another EAPI conditional in there (unless they call default too)
-21:44 < ciaranm> try 'gunzip foo.txt'
-21:44 <@dberkholz> now, i'll get different behavior in those two scenarios because default_src_unpack is passing extra nondefault options
-21:44 < ciaranm> dberkholz: no you wouldn't, because you'd just call 'default'
-21:45 < ciaranm> the *only* thing this alters is where people explicitly call 'unpack'
-21:45 < ferringb> eclasses...
-21:46 < ciaranm> eclasses are already conditionaling that lot because of src_prepare, and usually don't need to mess with src_unpack at all in EAPI 2+
-21:47 < ciaranm> there really aren't that many unix apps that silently do nothing if you give them a file parameter that they don't support
-21:47 <@leio-dl> they do
-21:47 <@leio-dl> a common src_unpack in an eclass is
-21:48 <@leio-dl> eclass_src_unpack() {
-21:48 <@leio-dl>         unpack ${A}
-21:48 <@leio-dl>         cd "${S}"
-21:48 <@leio-dl>         has ${EAPI:-0} 0 1 && gnome2_src_prepare
-21:48 <@leio-dl> }
-21:48 <@leio-dl> I guess maybe it shouldn't export src_unpack with EAPI-2+ then
-21:48 < ciaranm> that should be rewritten the clean way
-21:48 <@leio-dl> but we must do that export
-21:49 <@leio-dl> and we can't call default unless there is an additional check in there. unpack ${A} cd "${S}" if EAPI<2, otherwise default
-21:49 <@dberkholz> ciaranm: so in what cases would people be calling unpack in EAPI=3?
-21:49 < ciaranm> dberkholz: in fancy cases like having to unpack one tarball in one place, then cd to a subdirectory and unpack a second tarball
-21:50 <@dberkholz> this seems like a lot of special casing for unlikely scenarios
-21:51 < ciaranm> by that argument, you could say that giving people explicit access to 'unpack' is unlikely
-21:51 <@dberkholz> yep, you could.
-21:51 < ciaranm> it still happens often enough that unpack is useful, and that it should behave sanely on error
-21:51  * ferringb still says invert the bugger... preserves the common case without detriment while covering the potential ciaran is worried about
-21:52 < ferringb> or nuke the proposal. ;)
-21:52 < ciaranm> if you invert it no-one will remember to use it. also, i can't think of any unix apps that work that way around.
-21:53 < ciaranm> silently ignoring failures is highly weird
-21:53 < ferringb> I'd rather it just cp it over if it's not a supported extension
-21:53 <@dberkholz> i feel like parameters should get added in the special cases, not by default
-21:53 < ciaranm> that'd change existing behaviour
-21:54 < ferringb> re: unixy, if we were talking about -stupid-mplayer-options vs --stupid-mplayer-options, sure, applicable; this is core logic of our own defined func, so... unix traditions apply only so far.
-21:54 < ciaranm> dberkholz: the special case *is* "i want this argument i'm explicitly specifying to be ignored"
-21:54 < ferringb> dberkholz: you nailed my view.
-21:55 <@dberkholz> except that special case happens every time you do SRC_URI="foo.tgz bar.txt" and don't define src_unpack
-21:55 < ciaranm> but then you're not dealing with unpack yourself, so it's irrelevant
-21:56 -!- nirbheek [n=nirbheek@gentoo/developer/nirbheek] has quit [Read error: 60 (Operation timed out)]
-21:56 <@dberkholz> i don't think i'll ever be calling unpack again either way, so i'm not really going to spend any more time on this
-21:57 <@dberkholz> any other council members want to say something, or ready to vote?
-21:57 <@dev-zero> I vote yes
-21:57 <@dertobi123> ready to vote and no
-21:57 <@lu_zero> no as well
-21:58 < ciaranm> Cardoe and Betelgeuse were yes before the meeting, dunno about now
-21:58 <@leio-dl> some points were brought up that when thinking more about I _might_ change my mind, but a no right now
-21:59 <@Cardoe> ciaranm: hmm?
-21:59 <@dberkholz> Cardoe: on --if-compressed
-22:00 <@Cardoe> oh
-22:00 <@Cardoe> Did we extend the meeting length?
-22:01 -!- Netsplit hubbard.freenode.net <-> irc.freenode.net quits: kallamej, GrantN05, dleverton, wrona
-22:01 <@dberkholz> felt like actually getting through EAPI=3 today
-22:01 <@dertobi123> Cardoe: obviously yes :P
-22:01 -!- billie80 [n=billie@dslb-094-218-009-031.pools.arcor-ip.net] has joined #gentoo-council
-22:01 <@dberkholz> and this is the last bit
-22:01 <@Cardoe> wish that had gone out in the e-mail
-22:01 <@leio-dl> there was also SLOT-OPERATOR-DEPS
-22:02 <@dberkholz> well, it didn't get extended till we were about out of time and decided we wanted to extend
-22:02 <@dberkholz> it's not an advance notice thing
-22:02 -!- Netsplit over, joins: dleverton, wrona, kallamej, GrantN05
-22:02  * ferringb still wants mtime (in one form or another) yayed nayed, although unlikely considering folks ignoring it :P
-22:02 <@dberkholz> i can finish this, then i'm done
-22:02 <@dertobi123> so can we finish --if-compressed, please?
-22:02 <@dberkholz> i cannot take any more time out of work
-22:02 <@Cardoe> sure
-22:02 <@Cardoe> I was a yes on it
-22:03 <@leio-dl> the point was to understand the no-sayers view and then perhaps that changes
-22:03 <@leio-dl> but I think we have 4 no's anyway, don't we?
-22:03 < ciaranm> leio-dl: only if you're voting no
-22:03 <@dberkholz> i haven't changed my opinion
-22:04 < ciaranm> dberkholz, dertobi123 and lu_zero said no, Cardoe and dev-zero said yes, Betelgeuse isn't here but said yes in his email
-22:04 <@Betelgeuse> People oppose --if-compressed by default in src_unpack I presume? It will still be added to unpack as an option?
-22:04 < ciaranm> Betelgeuse: no, they're opposing it entirely
-22:04 <@leio-dl> it's about the option I believe.
-22:04 < ciaranm> the option and the src_unpack pretty much have to go together
-22:04 <@leio-dl> If the option is voted to happen, most will want that option passed in default_src_unpack I bet
-22:04 <@dberkholz> if it's on by default so often, it's not really a useful validation
-22:05 <@Betelgeuse> leio-dl: eclass authors can still decided on way or the other
-22:05 <@dev-zero> leio-dl: that's already the case in eapi-3
-22:05 < ciaranm> --if-compressed without the default src_unpack is a very bad idea and if anyone calls for that i'll yell lots and lots
-22:05 <@leio-dl> yes, the change of src_unpack seems to be the same item in the consideration list.
-22:06 <@leio-dl> I vote no
-22:06 < ciaranm> lame!
-22:06 <@Betelgeuse> do we still have something left?
-22:06 <@leio-dl> I would vote yes for a --all-compressed option
-22:06 < ciaranm> looks like it's out :(
-22:06 <@dertobi123> it is
-22:06 <@leio-dl> I have reservations about :* syntax that I didn't manage to think through today
-22:07 <@dberkholz> i need to leave now
-22:07 < ciaranm> slot-operator-deps is down as two critical, three yes and a query from leio-dl
-22:07 <@leio-dl> I am not opposed to the feature by concept. A query means something is missing from making a yes or no decision I think.
-22:08 <@Cardoe> ciaranm: so are you saying you're opposed to --if-compressed? Wasn't it your proposal?
-22:08 <@dberkholz> leio-dl: can you post your query by monday so we can nail that down by next thursday?
-22:08 < ciaranm> Cardoe: no, i'm saying i want --if-compressed, and i think you all suck for not going for it
-22:08 <@dberkholz> other than that, EAPI=3 is good to go
-22:08 <@leio-dl> I have a visitor till Monday
-22:08 < ferringb> heh
-22:08 <@Cardoe> ciaranm: oh. I agree
-22:08 <@leio-dl> so I'm not sure I can do Monday. I can promise Tuesday
-22:09 <@Betelgeuse> dberkholz was talking about Thursday
-22:09 <@leio-dl> I think the implementation can start for portage
-22:09 <@dberkholz> ok, we've made a decision, and this is the part where you guys support the council even though you disagreed with it, because you got to speak up =)
-22:09 < ciaranm> quick! four people vote yes to slot-operator-deps so we can just approve the frickin' thing right now
-22:09 <@Cardoe> Can someone ensure the FULL log is posted somewhere so I can read it on my next plane flight?
-22:09 <@Cardoe> ciaranm: didn't I already say yes?
-22:09 <@dberkholz> Cardoe: you were on irc the whole time, don't you log?
-22:09 < ciaranm> Cardoe: yes, but you need to say so now for it to count as not being deferred
-22:09 <@Cardoe> ciaranm: well then yes
-22:09 <@Cardoe> dberkholz: not on this client
-22:10 <@dev-zero> ahem, what's the point of waiting for slot-op-deps if most people aren't going to change their minds?
-22:10 <@leio-dl> please by all means start implementing slot-op-deps
-22:10 <@dev-zero> and why did we extend the meeting time to bring through the issues when we wait again?
-22:10 <@leio-dl> I do not want to see it not be part of EAPI-3
-22:11 <@dev-zero> so, then lets vote
-22:11 < ciaranm> we're deferring because leio-dl has unspecified objections to slot-operator-deps that he hasn't brought to the list yet
-22:11 <@Betelgeuse> yes
-22:11 <@Cardoe> if you guys marked me as deferred on any items I already commented on in my e-mail then you can simply change my vote to what I put in my e-mail
-22:11 <@dev-zero> and nail that thing done for once
-22:11 <@Cardoe> leio-dl: ok so change to yes
-22:11 < ciaranm> that's yes from dev-zero, Betelgeuse and Cardoe. please one more. make my life easier!
-22:11 <@dertobi123> yes and good night
-22:12 < ciaranm> \o/
-22:12  * dertobi123 gotta go to bed
-22:12 <@dev-zero> yes from me
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090514-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090514-summary.txt
deleted file mode 100644
index 52138a4bb5..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090514-summary.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: here
-Cardoe: absent, receives slacker mark
-dberkholz: proxied by ssuominen
-dertobi123: proxied by ulm
-dev-zero: here
-leio: here
-lu_zero: here 
-tanderson(secretary): physically late, irc client logged everything
-
-Topics:
-===========
-
-    - Approve wording of PMS for EAPI 3
-        This call for approval comes from the perspective that package manager
-        developers currently do not know the specifics of what to code for
-        EAPI 3. With this approved package manager developers can write code
-        and testcases for each feature and know that the specifics of each
-        feature is final(some features may be removed however).
-
-        Conclusion:
-            Approved, EAPI 3 specifications have been merged to the main PMS
-            repository. EAPI 3 will be tagged when developers are able to use
-            it.
-
-    - Vote on GLEP 54
-        This vote was called for by dertobi123. The vote was on whether to
-        approve GLEP 54 conditional on whether GLEP 55 is passed. The reason
-        for this is that GLEP 54 is unimplementable without the problems
-        mentioned in GLEP 55 being solved.
-
-        Conclusion:
-            Conditionally approved on whether GLEP 55 is approved.
-
-    - Vote on GLEP 55
-        A vote was required on this GLEP since GLEP 54 was already passed
-        conditional on this vote. 
-
-        Conclusion:
-            After quite a bit of confusion in the voting(people changing their
-            votes), a tie(3-3) vote was reached. Therefore, no decision was
-            reached. This vote will be brought up again next meeting so that
-            the tie can be broken(hopefully with everyone present).
-
-    - Discussion of dropping static libraries automatically.
-        Peter Alfredsen(loki_val) asked the council to discuss the ability to
-	    automatically drop static libraries from installs and the best way to
-	    do so.
-
-	    Conclusion:
-		    The council unanimously voted that developers, at their
-            discretion, can drop static libraries but it will not be the
-            default. The council also expressed support for an EAPI 4 proposal 
-            to automatically disable static libraries via configure options.
-
-    - Council Election Update
-        The election team decided to hold nominations for the Gentoo Council
-        from June 1st to June 14th with the voting period running from June
-        16th to June 30th. Results will likely be announced on July 2nd. The
-        election officials for this election are NeddySeagoon, rane, and
-        jmbsvicetto with fox2mike as the infrastructed liaison.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090514.txt b/xml/htdocs/proj/en/council/meeting-logs/20090514.txt
deleted file mode 100644
index b9a5f65f58..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090514.txt
+++ /dev/null
@@ -1,566 +0,0 @@
-20:01 -!- dev-zero changed the topic of #gentoo-council to: Meeting started || Meeting agenda here: http://dev.gentoo.org/~dev-zero/council/meeting-agenda-20090514.txt
-20:01 <@dev-zero> roll-call please?
-20:01 <@leio> here
-20:01 <@lu_zero> here
-20:02 < ulm> here (proxying dertobi123)
-20:02 < ssuominen> here (proxying dberkholz)
-20:03 <@dev-zero> Cardoe: ping?
-20:03 <@dev-zero> tanderson: ping?
-20:03 <@dev-zero> zmedico: ping?
-20:04 <@dev-zero> well, then let's start with the first topic and hope the others get here as soon as possible
-20:04 <@dev-zero> zmedico promised an updated on the progress of the implementation
-20:05 <@dev-zero> anyone knows something about it?
-20:05 -!- darkside_ [n=darkside@gentoo/developer/darkside] has joined #gentoo-council
-20:06 <@Betelgeuse> I can take a look at svn log to see if there's anything
-20:06 <@dev-zero> Betelgeuse: yes, please :)
-20:08 <@Betelgeuse> I don't immediately see anything
-20:09 <@dev-zero> good, ok, state didn't change then, two smaller features are implemented then
-20:09 <@dev-zero> Betelgeuse: thanks
-20:09 <@Betelgeuse> Add dummy dosed and dohard functions for EAPI 3, so that a trace can be
-20:09 <@Betelgeuse> something but not much
-20:09 <@dev-zero> and 'dodoc -r'
-20:09 <@dev-zero> which was also one of the easiest features
-20:10 <@dev-zero> I'd say let's move to the next task if nobody objects
-20:10 <@dev-zero> EAPI 3: PMS approval
-20:10 <@dev-zero> the idea is to approve the wording of the EAPI 3 part of the PMS formally
-20:11 <@lu_zero> I'd like to have a clean diff
-20:11 <@Betelgeuse> What's the need before Portage is even half way there?
-20:11 < ssuominen> Did EAPI 3 contain a suitable replacement for "prepalldocs" and "ecompress" which are both used in tree now, and for a reasons that can't be worken out
-20:11 <@lu_zero> ciaranm there is a tag to use or I should dig the log?
-20:11 <@dev-zero> ssuominen: yes, docompress
-20:11 < ciaranm> lu_zero: just diff the heads on the official version and the eapi 3 branch
-20:11 <@leio> I don't feel comfortable with giving things an official stamp when there is no implementation in the official package manager. However I do want to signal that the feature list is final when while doing the official implementation nothing appears to need changes, and I believe I did that with my vote about EAPI-3 last time
-20:12 <@lu_zero> ciaranm ok
-20:12 < ciaranm> leio: we want approval on the wording now, not the feature list
-20:12 <@leio> I see no reason to need such an approval now
-20:12 <@dev-zero> Betelgeuse: well, the most complicated features to implement are probably the slot-operators and the use-specifiers
-20:13 < ciaranm> lu_zero: you could've asked me two weeks ago when the item was first sent out...
-20:13 < ssuominen> dev-zero: but say one does, mansuffix="$(ecompress --suffix)" and then dosym /usr/share/man/man1/foo.1${mansuffix} usr/share/man/man1/bar.1${mansuffix}
-20:13 < ssuominen> dev-zero: how would docompress work on such case?
-20:13 <@dev-zero> Betelgeuse: the rest is basically bash stuff which could be done by everyone
-20:13 < ciaranm> ssuominen: ecompress isn't in any EAPI
-20:14 < ulm> ssuominen: docompress has no substitute for that
-20:14 < ssuominen> i'm fine with the eapi3 as is, but this is the part that's been buggering me..
-20:14 <@leio> ulm: can you comment on that approval need as a PMS representative of gentoo?
-20:14 < ssuominen> no way to symlink manpages in src_inst..
-20:14 < ciaranm> in any case, the wording's not changed for two weeks, and you've had two weeks asking to send any questions...
-20:14 < ciaranm> ssuominen: uh, yes there is
-20:15 < ciaranm> ssuominen: pms is quite clear about that
-20:15 < ulm> leio: seems to me that the eapi 3 features were already approved at last meeting?
-20:15 < dleverton> ssuominen: IIRC the portage compression handles symlinks transparently already, so if you symlink to foo.1, it'll rewrite it to foo.1.bz2 or whatever.
-20:15 <@leio> ulm: what kind of approval is ciaranm wanting here that is necessary?
-20:16 <@dev-zero> lu_zero: about the diff, you can use the app-doc/pms ebuild with USE=eapi3-draft which colors the differences
-20:16 <@lu_zero> dev-zero thank you
-20:16 < ssuominen> dleverton: oh.. lemme try that, but this would only work in src_, not in pkg_postinst? there's the legacy update-alternatives.eclass
-20:16 < ulm> leio: from my point of view we could postpone that until after an implementation is ready
-20:17 < ssuominen> dleverton: e.g. xloadimage is using the symlinking in postinst, that's after the install func has processed the compression
-20:17 < dleverton> ssuominen: yeah, only src_install as far as I know.  Is that eclass still used?
-20:17 < ciaranm> ulm: thanks for consulting with the rest of the pms team about that back when we first asked for approval
-20:17 < ssuominen> dleverton: see xli or xloadimage's ~ ebuilds for example
-20:17 < dleverton> Hmm
-20:18 < dleverton> You could probably check the contents of ${D} in pkg_preinst
-20:18 <@leio> no reason has been provided why an approval of the final text is necessary
-20:18 < ssuominen> dleverton: i'm not saying i want to keep it around, i'm entirely fine with the concensus "if ecompress is no longer allowed, we need to kill update-alternatives.eclass"
-20:18 <@leio> so actually having portage implementations first makes sense
-20:18 < ciaranm> leio: so we can go ahead and implement it without having to worry that the wording will be changed
-20:18 < ulm> ciaranm: imho the text is good for approval, but why the haste?
-20:19 < ciaranm> ulm: because without approval, we can't get implementations ready
-20:19 <@leio> ciaranm: who is worrying about that?
-20:19 -!- igli [n=igli@fu/coder/igli] has joined #gentoo-council
-20:19 <@dev-zero> ulm: we have to approve it at some point
-20:19 < ciaranm> leio: everyone who wants to implement it without having to worry that someone will come along and change, say, the src_install wording
-20:20 <@leio> the features are already approved
-20:20 < ciaranm> the features, not the details
-20:20 <@lu_zero> ciaranm I'd rather have incremental drafts of both
-20:20 < ciaranm> what we have is approval of the features, in general. what we need now is approval of the wording of the details, subject to the usual "we fix it if it goes wrong"
-20:21 <@dev-zero> ciaranm: thanks :)
-20:21 < ciaranm> the council has said "there will be a default src_install". it has not approved what that is, so anyone writing implementations or test cases is wasting their time.
-20:21 < ssuominen> docompress should have "exclude" flags as dohtml has..
-20:21 <@leio> I wasn't aware that we didn't consider all the details while voting last time
-20:21 < ssuominen> (it might already have?)
-20:21 < ulm> ssuominen: what do you mean by exclude flags
-20:21 <@dev-zero> leio: we discussed the stuff which people didn't agree up on
-20:21 -!- yngwin [n=yngwin@gentoo/developer/yngwin] has joined #gentoo-council
-20:21 < ulm> ssuominen: there's docompress -x
-20:22 < ciaranm> ssuominen: thanks for doing your homework and reading the pms draft and raising your questions before the meeting
-20:22 <@dev-zero> leio: so I think we were clear about the features
-20:22 <@dev-zero> leio: and we surely don't have the time to nitpick about every single detail, that's the reason why stuff got posted on the ml
-20:22 < ssuominen> ulm: lets's say econf --docdir=/usr/share/doc/${PF} installs the docs into the directory, but one of them is a .pdf file used directly runtime from the program, or a manual.txt that's invoked from the application
-20:22 <@leio> ssuominen seems to mean file exclusion as opposed to directory exclusion
-20:23 < ciaranm> ssuominen: what part of the things that are in pms to handle that case are no good for you?
-20:23 < ulm> ssuominen: then you can call docompress -x .../manual.txt
-20:24 < igli> what's wrong with: emake install prefix=/usr sysconfdir=/etc docdir=/usr/share/doc mandir=/usr/share/man # or the equiv (specced by someone who knows autotools a bit better than I do obviously;)
-20:24 < ssuominen> ciaranm, ulm: awesome. missed that part, i've had only few hours to get myself familiar with it. sorry.
-20:24 < ssuominen> that works for me.
-20:25 -!- tomaw [i=tom@freenode/staff/tomaw] has quit ["Quit"]
-20:25 <@dev-zero> ok, are there any objections to the wording of certain parts?
-20:25 <@leio> src_install was quite much nitpicked and details hammered down. Even dodoc already doing an empty file check and src_install doing it too was brought up (and concluded the extra doesn't hurt in case dodoc changes in some way or something). Anyway, I have already voted on the features in detail, so you can just take my last vote if wanting it like that again
-20:25 -!- tomaw [i=tom@freenode/staff/tomaw] has joined #gentoo-council
-20:26 <@leio> so, no objections, unless something has been changed in the wordings of the features that were voted in, as I did not know to review all the text in detail of the latest branch version
-20:26 <@dev-zero> leio: on the ml, yes
-20:27 <@leio> src_install was discussed in the meeting, I'm quite sure, but whatever :)
-20:27 < ciaranm> i didn't ever get a definitive answer to a whole bunch of wording questions, so i arbitrarily picked things. i assume that anyone who has a problem with any of those choices would have raised their queries in the past two weeks.
-20:27 < igli> assumptions: mother of all fsck-ups.
-20:28 <@dev-zero> good
-20:28 < ciaranm> so really, approving a merge of the eapi 3 branch to the gentoo-hosted master shouldn't be a big deal, should it?
-20:28 <@Betelgeuse> ciaranm: If that's what you need approval I have no problem with that
-20:29 <@lu_zero> same here
-20:29 <@leio> I must have missed some e-mails then, and my -dev folder is with an unusually small unread count
-20:29 <@Betelgeuse> ciaranm: The council approved tagging should imho wait until Portage gets up to speed
-20:29 < ulm> ok with me too
-20:29 <@dev-zero> so, do we need to vote or can we say that all people here agree that the wording of eapi-3 as it has been presented is ok?
-20:29 <@leio> I approve merging to master without tagging
-20:29  * lu_zero seconds leio
-20:29 <@Betelgeuse> There's four so it passes
-20:29 < ciaranm> tagging's the sign for "stick stuff in the tree using it", which we probably shouldn't do just yet...
-20:29 < ciaranm> ok, merged. ta.
-20:30  * ulm seconds it too
-20:30 <@dev-zero> fine
-20:30 <@dev-zero> next topic then
-20:30 <@dev-zero> GLEP 54
-20:30 < solar> again?
-20:30 <@dev-zero> jup
-20:30 < solar> kill it. Nobody wants it
-20:31 <@dev-zero> solar: are you proxying someone?
-20:31 <@Betelgeuse> solar: please contribute something useful or shut up
-20:31 < solar> I'm a dev. I think I have a right to speak
-20:31 -!- nirbheek [n=nirbheek@gentoo/developer/nirbheek] has quit [Read error: 110 (Connection timed out)]
-20:31 <@Betelgeuse> Indeed. We don't have to listen though.
-20:31 <@lu_zero> solar I think somebody could disagree with you
-20:31 < igli> it's much better done as a prefix
-20:31 < ssuominen> If live ebuilds would be marken with something special, like suffix or a PROPERTIES="" in the ebuilds it would be easier to package manager to identify them
-20:32 < igli> or indeed a property yeah
-20:32 <@Betelgeuse> Wasn't PROPERTIES="live" already approved?
-20:32 < ciaranm> PROPERTIES=live is unrelated to version ordering
-20:32 <@Betelgeuse> ciaranm: sure just said to ssuominen
-20:32 < igli> is -scm a binary indicator or not?
-20:32 < igli> leaving aside repo
-20:33 < ciaranm> -scm's an ordering thing
-20:33 <@dev-zero> lu_zero: you once said you'd update your counter glep, is there anything new there?
-20:33 < igli> i know its implications, but in data terms it's a binary value
-20:33 <@lu_zero> dev-zero in the devspace there is the updated one
-20:33 <@dev-zero> lu_zero: what has been changed since last time we discussed it?
-20:34 <@leio> was there really nothing in GLEP54 to updated after all the discussions? If the discussions explain things in more detail, those things ought to get into the GLEP text as well
-20:34 < igli> LIVE="foo" # (or SOME_LONG_VAR_THAT_MEANS_LIVE) if you want more flexibility
-20:34 < ssuominen> As for GLEP 54's part "Motivation", if there is/will be PROPERTIES for them it pretty much covers the motivation already
-20:34 < ssuominen> Can't just see any other benefits
-20:35 < ciaranm> the other benefit is ordering
-20:35 <@lu_zero> dev-zero I think it is more or less the same
-20:35 <@dev-zero> lu_zero: ok, thanks
-20:35 < igli> which the pkg-mangler knows about when considering the ordering in resolution, one would hope.
-20:35 <@lu_zero> the glep54 didn't see any update since the inception I guess
-20:35 <@dev-zero> lu_zero: that's correct
-20:35 <@Betelgeuse> ssuominen: You can more easily make scm version for branches etc
-20:36 <@lu_zero> Betelgeuse not branches
-20:36 <@lu_zero> one kind of version branches
-20:36 < ciaranm> topic branches aren't versions and shouldn't be treated as such
-20:36 < ulm> lu_zero: your counterproposal is the one in http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst ?
-20:36 <@lu_zero> ciaranm target branches are version branches...
-20:36 <@lu_zero> ulm yup
-20:36 < igli> if it has to be in filename, that can be done with prefix as well. but I remain unconvinced it needs to be exposed in the filename
-20:36 < ciaranm> lu_zero: scm works for target branches
-20:37 <@leio> I'd hope to see a complete proposal that actually solves more things. The ordering works fine even with 9999, so right now all that -scm is is pretty much giving a name to that ugly 9999 construct and not solving anything else
-20:37 < ciaranm> lu_zero's counterproposal is unimplementable, in any case. -scm has a reference implementation in paludis.
-20:37 <@lu_zero> ciaranm unimplementable as in you cannot make it?
-20:37 <@dev-zero> lu_zero, ciaranm: stop that right now
-20:37 < ciaranm> lu_zero: no, unimplementable as in it's impossible to implement
-20:37 < igli> oh it's in paludis, it has to go in. I forgot.
-20:37 < bonsaikitten> igli: silence!
-20:38  * igli stfu
-20:38 <@dev-zero> lu_zero: does it still stand that your proposal could be implemented on top of G54? (since it's described as an expansion)
-20:38 < igli> what if it's cleaner implemented another way tho?
-20:39 <@lu_zero> dev-zero it diverged enough
-20:39 < scarabeus> i like lu_zeros glep more, and it would be greatly utilized by mesa/drm for example (take look on live ebuilds in overlay how i allow the branching now)
-20:39 < ssuominen> Betelgeuse: You mean grabbing the branch from the version into ebuild, instead of defining the branch in a variable inside the ebuild?
-20:39 <@dev-zero> I guess we have to vote about G54 to get it off the table, is that correct?
-20:39 <@lu_zero> it aims to solve glep54 pointed issue and some more that cropped up
-20:40 <@Betelgeuse> ssuominen: I mean if you want both 2.2 official release and then a live ebuild for 2.2 branch
-20:40 < ciaranm> with lu_zero's glep you can't set use flags just for live packages using package.use without breaking emerge -N. how can people like that?
-20:40 <@leio> I like many of the things lu_zero's glep would allow to do, and would like to see that explored more
-20:41 <@Betelgeuse> I don't want 54 in without 55 so I would rather do that first.
-20:41 < ssuominen> Betelgeuse: 2.2 < 2.2-scm
-20:41 <@Betelgeuse> ssuominen: yes
-20:42 < igli> I'm sure portage team can fix emerge, if the need arises. but that proposal still does it as yaf suffix when that space is already quite crowded with patch data.
-20:42 < ssuominen> Betelgeuse: 2.2 < 2.2.9999.. but I don't mind, if we change to more pretty and constant -scm.
-20:42 < igli> better to shove it in same place as debian put their epochs imo.
-20:42 < ssuominen> So I'm for the glep.
-20:42 <@dev-zero> lu_zero: do you think you could provide a reference implementation of your proposal?
-20:43 <@lu_zero> dev-zero no
-20:43 <@lu_zero> first I wanted to see if there were enough interest
-20:43 <@dev-zero> lu_zero: there is surely interest, otherwise G54 would have voted in a long time ago
-20:43 <@Betelgeuse> dev-zero: We have never really voted in it
-20:43 <@Betelgeuse> dev-zero: Just post poned it
-20:43 <@lu_zero> dev-zero see solar reply before
-20:44 <@Betelgeuse> At least as far as I remember
-20:44 <@dev-zero> Betelgeuse: that's true, but we postponed it since we thought other solutions would show up, better explanations given, etc.
-20:44 <@lu_zero> and it got postponed since the glep wasn't detailed enough
-20:44 <@Betelgeuse> dev-zero: No. Mainly because it's controversial so it's easier to push later based on those arguments.
-20:45 < ciaranm> last time it got postponed was because lu_zero said he had an alternative
-20:45 <@dev-zero> Betelgeuse: also true
-20:45 <@dev-zero> well, then I think we should put it to a vote to get it off the table at last
-20:45 <@lu_zero> and seems people like the possibility to have both _plive and _prelive ...
-20:45 <@Betelgeuse> I propose the following. This is stuff that belongs to PMS. If GLEP 55 is approved, this can be put to list for EAPI 4.
-20:45 <@leio> I do not see any relevance to EAPI's here
-20:46 <@dev-zero> Betelgeuse: the relevance to EAPIs may be true
-20:46 < ssuominen> What about _r as in revision to reuse it in the ebuild
-20:46 <@dev-zero> Betelgeuse: but not the one to G55
-20:46 <@Betelgeuse> dev-zero: You can't do 54 without breakage unless you do 55 too
-20:46 <@dev-zero> Betelgeuse: if G55 gets accepted the people can start using it faster
-20:46 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Read error: 110 (Connection timed out)]
-20:46 < ssuominen> _r should be > _p
-20:46 <@dev-zero> Betelgeuse: otherwise they have to wait at least 6 months
-20:46 <@leio> Betelgeuse: you can
-20:46 <@Betelgeuse> I hate the wait way when we have a better way these days.
-20:47 <@leio> why would it have to wait 6 months?
-20:47 <@dev-zero> Betelgeuse: that's true and can be prevented
-20:47 -!- reavertm [n=reavertm@gentoo/contributor/reavertm] has quit [Read error: 104 (Connection reset by peer)]
-20:47 -!- reavertm [n=reavertm@ary193.neoplus.adsl.tpnet.pl] has joined #gentoo-council
-20:47 <@dev-zero> leio: because of portage moaning about unknown version tags
-20:47 <@Betelgeuse> Can we just vote on the following: Approve GLEP 54 on the condition that 55 is approved and move it to PMS instead for next EAPI instead of being a separate GLEP.
-20:47 <@leio> because it has a reason to moan
-20:47 <@Betelgeuse> I want to see this stuff being centralised.
-20:48 <@Betelgeuse> I obviosly vote yes.
-20:48 <@leio> the user hasn't bothered to upgrade portage despite strong suggestions in the form of messages after syncing AND the moaning about invalid version tags
-20:48 < ciaranm> there's already wording for scm stuff in pms if you enable the kdebuild bits, if anyone's worried about whether it'll fit in that way
-20:48 < ciaranm> so what Betelgeuse makes sense from a pms perspective
-20:48 < bonsaikitten> le sigh!
-20:49 <@dev-zero> Betelgeuse: and what happens if G55 is not approved?
-20:49 <@leio> the warnings I see as a good thing. Developers also will notice it and not regenerate manifests with a portage that doesn't know this versioning
-20:49 <@Betelgeuse> Please vote so we can see where you stand.
-20:49 < solar> vote of no confidence?
-20:49 <@Betelgeuse> solar: not on the agenda
-20:49 <+tanderson> wait, I thought the meeting was at 5:00 EST?
-20:49 <@Betelgeuse> tanderson: 20UTC like always
-20:50 <@dev-zero> I vote yes, in case G55 is accepted do it like Betelgeuse said, in case G55 is not accepted keep it as GLEP and implement it
-20:50 <@Betelgeuse> dev-zero: A new vote on what do to instead.
-20:50 <+tanderson> Betelgeuse: oops, sorry
-20:50 <@lu_zero> I'd like to know how many would like to have the live templates implemented
-20:50 <@leio> I do not see how we can vote on it like that, it seems weird
-20:50 <@leio> lu_zero: I would like to see an implementation and further investigation of this
-20:51 <@Betelgeuse> leio: If my proposal is approved then we can just move on. If not then we need to talk what else.
-20:51 < ulm> i vote yes (as specifically instructed by dertobi123, not my personal opinion though)
-20:51 <@dev-zero> I vote yes
-20:51 <@lu_zero> I vote no
-20:51 <@leio> ok, so what are we voting here?
-20:51 <@Betelgeuse> 20:47 <@Betelgeuse> Can we just vote on the following: Approve GLEP 54 on the condition that 55 is approved and move it to PMS instead for next EAPI instead of being a separate GLEP.
-20:52 < solar> thanks lu_zero
-20:52 <@Betelgeuse> ssuominen: your vote please
-20:52 <@leio> I vote no. It is a) not fleshed out, no updates at all after discussions, I can not vote with an approval on this; b) it is not an EAPI or PMS thing
-20:53 < ciaranm> of course it's an EAPI / PMS thing
-20:53 <@Betelgeuse> indeed
-20:53 < igli> it's just a pig, is all.
-20:53 < ssuominen> sec
-20:53 <@leio> sorry, I meant just EAPI.
-20:53 <@Betelgeuse> leio: the versioning rules are EAPI 0
-20:53 <@Betelgeuse> leio: This is an extension to those
-20:53 < ssuominen> vote is yes
-20:54 <@Betelgeuse> Ok vote passed.
-20:54 <@leio> So we are going to modify EAPI 0?
-20:54 <@Betelgeuse> leio: no
-20:54 <@Betelgeuse> leio: My proposal puts it to next EAPI and it passed
-20:54 < ssuominen> yes, with the condition Betelgeuse said
-20:54 <@leio> how can that work, versioning rules are across the board. Would all revisions of a package have to be upgraded to that new EAPI first?
-20:54 < ulm> Betelgeuse: how can version ordering be part of an eapi?
-20:55 < ciaranm> ulm: quite easily
-20:55 <@lu_zero> leio the vote was about having 54 approved if 55 passes
-20:55 < ulm> but you may compare ebuild with different eapis
-20:55 < igli> just like it can be non-bash (yay)
-20:55 <@Betelgeuse> ulm: You don't want PMs to handle it the same way
-20:55 <@Betelgeuse> ?
-20:55 < ciaranm> you define version comparisons in terms of a super-version-format of which every other eapi is a subset
-20:55 -!- darkside_ [n=darkside@gentoo/developer/darkside] has left #gentoo-council []
-20:56 < igli> even the eapi's you don't know about which can't cope with EAPI='foo'
-20:56 <@Betelgeuse> igli: If you don't know about EAPI 4 you don't see scm ebuilds at all
-20:56 < igli> scheme?
-20:56 < igli> I love scheme
-20:56 < igli> i think you mean VCS
-20:56 < ciaranm> sorry, gentoo standardised on 'scm' by order of seemant about five years ago
-20:57 < ssuominen> can we move on?
-20:57 <@dev-zero> jup
-20:57 <@Betelgeuse> I have exams tomorrow morning so I would rather stop at this one hour mark because I need study.
-20:57 < ulm> igli: the scheme team has already announced that there will be a dev-scheme/scm-scm if glep 54 is approved :p
-20:57 < igli> sure; diktat from on-high seems order of the day.
-20:57 -!- igli [n=igli@fu/coder/igli] has left #gentoo-council ["Have a good one ;-)"]
-20:57 < solar> yeah enough fucking up for one day
-20:57 <@dev-zero> Betelgeuse: do you think we could stretch it for the next item?
-20:57 <@Betelgeuse> I expect a lengthy discussion coming unless we just vote.
-20:57 <@dev-zero> Betelgeuse: then let's do just that
-20:58 < bonsaikitten> what the ... why are we discussing eapi4 and later when eapi3 isn't even out
-20:58 <@dev-zero> because the discussion could be going on forever
-20:58 <@dev-zero> bonsaikitten: please, you can flame away in 5-10 minutes
-20:58 <@dev-zero> ok, next topic and the last one for today: GLEP 55
-20:58 <@Betelgeuse> For GLEP 55 I propose: Approve it and I will start a project to redesign the tree where it will be moved back inside .ebuild
-20:58 <@Betelgeuse> There's plenty of stuff we want to solve with a redesign
-20:59 < ulm> dev-zero: tobias wanted to see the benchmarks (promised long time ago) for glep 55
-20:59 <@Betelgeuse> can't promise anyhting delivered any time soon
-20:59 <@dev-zero> ulm: I know, he told me, I don't think there are any (at least not published)
-20:59 <@leio> There is no need for GLEP55
-20:59 <@Betelgeuse> But in the time it takes for the extensions to blow out of proportion we should have something
-20:59 <@leio> It doesn't solve anything
-20:59 < ciaranm> glep 55 is needed to get the recently approved glep 54 usable in EAPI 4 timeframes
-20:59 <@Betelgeuse> leio: Then we will never have the need to use a new extension
-20:59 <@lu_zero> ciaranm glep 54 isn't approved
-20:59 <@lu_zero> it has been linked to glep 55
-20:59 < NeddySeagoon> Betelgeuse, so why approve G55 then - just fix stuff properly ?
-21:00 < ulm> ciaranm: glep 54 was only conditionally approved
-21:00 <@leio> Betelgeuse: we don't have that need now either.
-21:00 < jmbsvicetto> ciaranm: That argument doesn't hold - GLEP54 was approved *pending* GLEP55 being approved
-21:00 <@Betelgeuse> NeddySeagoon: http://rafb.net/p/09PDiO25.html
-21:00 < jmbsvicetto> ciaranm: So you can't say GLEP55 need to be approved because GLEP54 was approved
-21:00 <@Betelgeuse> NeddySeagoon: It just seemed easier to just rethink
-21:00 <@Betelgeuse> NeddySeagoon: Easier to avoid breakage
-21:00 < bonsaikitten> sigh. why don't you stop for a minute and decide where you want to go before starting to run ...
-21:01 < NeddySeagoon> Betelgeuse, that does not answer my question ... how is that related to G55 ?
-21:01 <@leio> Instead of GLEP55 we simply need to say EAPI=<value> comes as the first non-comment within a certain set of lines. Done. G55 serves no purpose
-21:01 <@Betelgeuse> NeddySeagoon: Some people don't want to see us having ten different EAPI file extensions in use
-21:01 <@Betelgeuse> NeddySeagoon: My proposal would mean we would not use GLEP 55 for more than a couple
-21:01 <@leio> and when the next step plan is to have *.ebuild again, what's the point of changing that then
-21:01 <@Betelgeuse> NeddySeagoon: if any
-21:01 < jmbsvicetto> Betelgeuse: I don't see how most (any?) of those is related to GLEP55
-21:01 <@Betelgeuse> jmbsvicetto: Please ready what I said
-21:01 < NeddySeagoon> Betelgeuse, Yep. me too - its bad system design.  So kill G55
-21:02 <@Betelgeuse> s/ready/read/
-21:02 <@dev-zero> ok, council members, please state your votes
-21:02 < NeddySeagoon> Betelgeuse, there is nothing so permanent as a temprory fix
-21:02 <@dev-zero> otherwise it will never end, sorry
-21:02 < jmbsvicetto> Betelgeuse: So you want it for a "transition" phase?
-21:02 <@Betelgeuse> I vote yes (with the final extension format to be decided later)
-21:02 <@leio> We are not in a hurry
-21:02 <@dev-zero> I vote yes
-21:03 <@Betelgeuse> .eb vs .ebuild-<eapi>  I think
-21:03 < ssuominen> Don't see any harm in it, so I vote yes as well.
-21:03 <@leio> why are we bringing this up again within one meeting timeframe and try to get votes out of council members who need to review it more. Have you all even been able to read the last e-mail about it, especially bonsaikitten ones?
-21:03 <@Betelgeuse> GLEP 55 will never be utilised without a new EAPI any way
-21:03 <@Betelgeuse> which we need to vote on
-21:03 < NeddySeagoon> Betelgeuse no hurry for G55 at all then
-21:04 <@Betelgeuse> leio: Finally voting it even if controversial will allow people to put their energy to something more useful
-21:04 <@Betelgeuse> Which is a good reason for voting in itself
-21:04 <@lu_zero> I vote no
-21:04 < ulm> i vote no
-21:04 <@leio> Betelgeuse: and we end up with something bad voted in because people were uninformed. Sounds very useful
-21:04 < NeddySeagoon> Betelgeuse, This vote looks like UK MPs voting their expenses
-21:04 <@Betelgeuse> leio: Some of us don't htink it's bad.
-21:04 < ciaranm> don't worry, there's nothing informative in bonsaikitten's recent email
-21:05 < bonsaikitten> ciaranm: I don't think you're qualified to say that
-21:05 < bonsaikitten> you didn't even understand it ...
-21:05 < ahf> bonsaikitten: go rant somewhere else
-21:05 < solar> he is a dev. He is allowed to voice his concerns here
-21:05 < NeddySeagoon> bonsaikitten, hes qualified, just not impartial as he has a vested interest
-21:05 <@leio> The first two e-mails of bonsaikitten were very informative
-21:05 < jmbsvicetto> Can we please leave the "pleasentries" for somewhere else? Thanks
-21:06 < ciaranm> leio: no, they were very wrong
-21:06 < yngwin> so far i counted 2 yes and 2 no votes
-21:06 < jmbsvicetto> yngwin: 3 yes and 2 no
-21:06 <@Betelgeuse> yngwin: 3 times yes
-21:06 <@Betelgeuse> Nothing from leio I think
-21:06 < scarabeus> 3 yes 2 noes by mine counting
-21:06 < yngwin> ok
-21:06 <@Betelgeuse> leio: So what do you vote?
-21:07 <@leio> I do not see voting being the correct action here, for the record
-21:07 <@leio> I vote no
-21:07 <@dev-zero> and Cardoe wrote in his mail that he's against it
-21:07 <+tanderson> nice, a tie
-21:07 <+tanderson> oh, not a tie
-21:07 <@Betelgeuse> Will have to wait until next time then.
-21:07 < solar> nope
-21:08 < NeddySeagoon> its voted down
-21:08 < ulm> Betelgeuse: 3 yes 4 no?
-21:08 < ssuominen> Please clarify which we are really voting for, for me it seems very vague..
-21:08 < ciaranm> Cardoe hasn't voted
-21:08 < ssuominen> or me
-21:08 < jmbsvicetto> Betelgeuse: iirc, the rules are that any vote without a majority is a no vote
-21:08 <+tanderson> ssuominen: GLEP 55 I think
-21:08 < ulm> ciaranm: <dev-zero> and Cardoe wrote in his mail that he's against it
-21:08 <@leio> the e-mail was private
-21:08 < ciaranm> ulm: that's not a vote
-21:08 <@Betelgeuse> I don't see us counting private mails like that.
-21:08 <@dev-zero> no
-21:08 < ulm> ciaranm: you're right i guess
-21:09 <@dev-zero> so we'll see it next time again
-21:09 < jmbsvicetto> ulm: it doesn't matter. What counts are the votes here - a miniumum of 4 votes is required for a motion to pass
-21:09 <@Betelgeuse> "Council decisions are by majority vote of those who show up (or their proxies)."
-21:09 <@leio> lets say we know cardoe's opinion of it, but it's not a vote
-21:09 < NeddySeagoon> Its still an overall no, as there was no majority
-21:09 <@Betelgeuse> There's no majority either way.
-21:09 <@dev-zero> leio: exactly
-21:09 <@Betelgeuse> So there's no decision either.
-21:09 < ssuominen> I vote no for GLEP 55 as it is put now.
-21:09 < solar> that is some BS. You call for a vote. Don't like the results. And then declare there is no decision?
-21:09 <@Betelgeuse> ssuominen: s/vote/change your vote/?
-21:09 < ssuominen> As for the other ideas -part it leaves too many options open to give a vote on it.
-21:10 < solar> you are serious? really?
-21:10 <@Betelgeuse> solar: it was a tie
-21:10 <@Betelgeuse> solar: Where does it say a tie means no decision?
-21:10 < yngwin> so it is rejected
-21:10 <@Betelgeuse> Now it's rejected as ssuominen changed votes.
-21:10 < ssuominen> I voted yes for 54 if 55 gets approved, and no for 55 since it's not specific enough, specially the parts suggesting se different subdirectories for different EAPIs, i.e. cat/pkg/eapiX/
-21:10 < ssuominen> It needs to be more clear
-21:10 < ciaranm> ssuominen: uh, 55 isn't proposing that
-21:11 <@Betelgeuse> ssuominen: That's just a bad alternative
-21:11 <+tanderson> ssuominen: 55 is saying that that's not a good idea
-21:11 < NeddySeagoon> So when does the vote end ?
-21:11 <@lu_zero> are we going to have petitioning about glep55 till next morning?
-21:11 <+tanderson> NeddySeagoon: when I say that I'm Cardoe's proxy? (I'm not) :P
-21:12 < ssuominen> well the other ideas is confusing, but if that's not really going in [in] anyway, then yes
-21:12 < ssuominen> "other ideas" in the glep
-21:12 <@Betelgeuse> ssuominen: Yes that's just to list other ideas proposed and why they are bad
-21:12 <@lu_zero> ssuominen what donnie said in the email?
-21:12 <@Betelgeuse> lu_zero: To use his judgement
-21:12 < NeddySeagoon> ssuominen, how can you vote in favour of somethiing you clearly don't understand
-21:13 <@dev-zero> NeddySeagoon: and how can he vote against?
-21:13 < ssuominen> NeddySeagoon: I do understand, The GLEP imho is not clear enough.
-21:13 <@Betelgeuse> Any way we need to vote again next time as there was no decision this time.
-21:13 <@Betelgeuse> Next item
-21:13 < bonsaikitten> LOL
-21:13 < ssuominen> NeddySeagoon: The GLEP expects you to have read a mile long thread.
-21:13 < NeddySeagoon> ssuominen, IF you understood it, you would not be changing your vote
-21:13 <@lu_zero> ssuominen the problem is that glep shouldn't require that
-21:14 <@lu_zero> (one of the problems)
-21:14 <@dev-zero> Betelgeuse: since there was a tie at the beginning and now it changed to something else I'd say we retake the vote
-21:14 <@leio> therefore the GLEP needs to be edited to make it so that a mile long thread doesn't need to be read before it can be considered to be approved
-21:14 <@dev-zero> Betelgeuse: do you think we can continue or should we stop here?
-21:14 <@lu_zero> and that was requested the first time it was proposed.
-21:14 < ssuominen> a glep should be a full spec. of the proposed change, not some random quoting tablet.
-21:14 <@Betelgeuse> dev-zero: I consider vote 3-3 and in GLEP 39 terms it means there's no decision either way
-21:14 < ssuominen> tech. doc
-21:15 <@dev-zero> Betelgeuse: good, also my point
-21:15 <@lu_zero> ssuominen that's what I requested many times.
-21:15 <@Betelgeuse> dev-zero: So I would put to agenda next time with hopefully 7 here
-21:15 <@Betelgeuse> There's time to flame in between
-21:15 <@dev-zero> Betelgeuse: good, will do that
-21:15 <@dev-zero> ok, topic is closed
-21:15 <@lu_zero> could we quickly stamp static libs?
-21:15 < reavertm> according to GLEP1, this voted glep status could be changed to "Deferred" as no progress has been made on that glep (if not "Rejected") - I mean, if there's no resolution after so long time, maybe it should be reedited, as some people already raised points, that it's not well specified.
-21:16 <@dev-zero> reavertm: topic closed, please post on ml, sorry
-21:16 <@Betelgeuse> reavertm: There's no resolution because this was the first time the council actually voted on it
-21:16 < ssuominen> i'd say normal default should be static libs disabled, but add USE="static-libs" to those ebuilds where they are needed
-21:17 <@dev-zero> ssuominen: no ebuild "needs" to disable static libs
-21:17 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)]
-21:17 <@leio> or unconditionally enable where they are needed, such as those mythical system things that are told to break things if their .a gets filtered out with INSTALL_MASK
-21:17 < jmbsvicetto> Betelgeuse / dev-zero: I disagree with your reading of GLEP39. The "Council decisions are by majority vote of those who show up (or their proxies)" in my reading means any motion that doesn't have a majority is by definition turned down
-21:17 < ssuominen> dev-zero: only wrt installing performance, many ebuilds in tree does this already
-21:17 <@leio> We explicitly disable static libraries with no USE flag option in most GNOME packages for good maintainer decided reasons
-21:18 <@Betelgeuse> jmbsvicetto: Well turned down or not, we can always put it to vote next time if we want to
-21:18 < fmccor|home> jmbsvicetto, No, that says "no decision"
-21:18 < fmccor|home> jmbsvicetto, Because a vote to turn down is a decision, too.
-21:18 <@leio> However we are about to add IUSE=static-libs to a few where users reasonably might have a potential use for static libraries, this iis basically C++ and glib (for prefix=/ usages)
-21:19 < fmccor|home> jmbsvicetto, So you would need a majority "no"
-21:19 < yngwin> there is a majority no
-21:19 <@leio> I have never understood where this "ebuild must always install static libraries when available" "rule" comes from. Have seen it nowhere written down or explained
-21:19 < ciaranm> leio: it comes from solar
-21:19 <@lu_zero> solar really?
-21:19 < ssuominen> leio: Me either, not needed for running, longer building time
-21:20 < ssuominen> Should be "Only install shared libs, unless there is a real reason to add USE="static-libs" to control it."
-21:20 <@leio> e.g, if you enable static libs in gtk+ and use them, you are just crazy and don't know what you are doing
-21:21 < jmbsvicetto> leio: Qt/KDE would also be fun
-21:21 <@dev-zero> so, should we put it like that "install shared libs only per default unless there is a reason and let users request USE=static-libs to control it" ?
-21:21 <@dev-zero> ... if needed
-21:22 < ssuominen> dev-zero: exactly
-21:22 <@lu_zero> sounds ok
-21:22 <@leio> yup. Could use some wording touch-up though
-21:22 < ciaranm> you're wanting every ebuild to start doing econf --disable-static?
-21:22 < ssuominen> ciaranm: yes, unless $(use_enable static-libs static) is requested.
-21:23 <@leio> I see the supposed policy of always having to install static libraries as the problem
-21:23 < ssuominen> or plain needed.
-21:23 < ciaranm> my point was more "every ebuild", for some value of "every", tends to smell like a "shove it in the next EAPI" thing rather than forcing everyone to write their own src_configure
-21:23 <@leio> I think maintainers can decide on that fully well themselves
-21:23 < ulm> dev-zero: "install shared libs ..."? s/shared/static/?
-21:23 <@leio> if they decide to keep it, I can live with that and work as a user and developer in convincing with technical arguments
-21:23 < ciaranm> make EAPI 4 do src_configure() { if hasq "static-libs" $IUSE ; then econf $(use_enable static-libs static ) ; else econf ; fi }
-21:24 <@Betelgeuse> I would see it cleaner to allow dropping statis libs now and wait for EAPI 4 having --disable-static by default
-21:24 <@dev-zero> ulm: no :) bad wording: "install only shared libs per default"
-21:24 < ssuominen> leio: Indeed, no doubt about that. I bet both Gnome and Xfce4 can all do --disable-static and we'll hear no complaints.
-21:24 < ulm> dev-zero: o.k. ;)
-21:24 <@leio> we've only had reasonable technical complaints
-21:24 <@leio> a) C++ bindings, users fear that libstdc++ will break ABI again, so they want that part statically linked
-21:24 < reavertm> why not just make it some eclass feature? why involve eapi here?
-21:25 <@leio> b) glib, because some things in prefix=/ (as opposed to /usr) might want to use it
-21:25 < ciaranm> reavertm: because otherwise no-one can use the default src_configure
-21:25 < ciaranm> reavertm: also because otherwise there's no obvious way which ebuilds have been updated
-21:25 < ciaranm> ...to tell which...
-21:25 < jmbsvicetto> About removing the static libs, does the prefix project have any objections to it?
-21:26 <@Betelgeuse> So let's vote on: It's now possible to drop static libs (with possible USE static-libs) and make it the default in EAPI 4.
-21:26 <@Betelgeuse> ^yes
-21:26 <@dev-zero> Betelgeuse: thanks :)
-21:26 <@dev-zero> yes
-21:26 <@leio> not like that
-21:26 < ulm> yes
-21:26 <@leio> lets vote on jsut dropping the requirement to ship static libraries or some such
-21:26 <@leio> and we vote on EAPI-4 stuff when we are actually dealing with EAPI-4
-21:26 < ciaranm> eh, eapi 3's merged. i can keep track of eapi 4 now.
-21:26 < ssuominen> i second that.. why pull the eapi4 into this?
-21:27 <@dev-zero> leio: uhm, that's what Betelgeuse proposed
-21:27 <@leio> he proposed to vote on making it the default in EAPI 4
-21:27 <@leio> it's not the time to vote on EAPI-4 items
-21:27 < ssuominen> Why does it need to be EAPI=4 bound?
-21:27 <@Betelgeuse> Well if I wasn't clear let's say put it as an item for EAPI 4.
-21:27 <@Betelgeuse> ssuominen: I don't really fancy mandating every putting --disable-static
-21:28 <@Betelgeuse> If people want to then sure
-21:28 < reavertm> btw, why add autotools specific configuration to eapi? there are other buildsystems as well, hence I see no valid reason to make exception for it
-21:28 <@leio> someone will make sure to propose it for EAPI-4. If no-one does, they don't find that useful
-21:28 < ciaranm> reavertm: uhm... it's already in there.
-21:28 <@Betelgeuse> reavertm: There's lots of autotootls specific stuff in default ./configure args
-21:28 < ciaranm> reavertm: econf and src_configure are already both highly autoconf-centric
-21:28 <@lu_zero> and that was stated again while discussing eapi3
-21:28 <+tanderson> emake also assumes DESTDIR=$D for eapi 3
-21:29 <@lu_zero> DESTDIR is more standard ^^
-21:29 <@dev-zero> can we have your votes please?
-21:29 <@leio> ok, so what are we voting on?
-21:30 < ssuominen> if this gets passed, can we start using it right now in tree?
-21:30 <@leio> I see it's appropriate to vote on either dropping the requirement to ship static libraries (if such exists)
-21:30 <@leio> s/either//
-21:30 <@Betelgeuse> Developers can drop static libs if they want to but it won't be the default now.
-21:30 < ssuominen> or do we have to wait for eapi4 for some magical reason
-21:30 < reavertm> if so, I guess it's wrong approach - PM should be buildsystem independent - that's what eclasses are for imho
-21:30 <@Betelgeuse> ssuominen: you can do it now if you want to
-21:30 <@leio> Betelgeuse: with that wording I'm prepared to vote, and the vote is obviously yes :)
-21:30 <@Betelgeuse> reavertm: No. The defaults should cater to most cases.
-21:30 <+tanderson> reavertm: So econf should be in an eclass? That's silly
-21:30 < ulm> reavertm: the default is reasonable since it covers the vast majority of cases
-21:30 < ciaranm> reavertm: that idea was dropped years ago
-21:31 <@dev-zero> ok, I vote yes
-21:31 <@Betelgeuse> I vote yes
-21:31 < ssuominen> I vote yes (but it should become the default to disable the static libs)
-21:31 < ulm> I vote yes
-21:31 -!- Zorry [n=zorry@fu/coder/zorry] has quit [Read error: 104 (Connection reset by peer)]
-21:32 <@leio> we have a majority
-21:32 <@dev-zero> good
-21:32 -!- Zorry [n=zorry@ip1-67.bon.riksnet.se] has joined #gentoo-council
-21:32  * lu_zero votes yes as well
-21:32 <@dev-zero> ok, developers are allowed to drop static libs if the they want to but it won't be the default now
-21:33 < ssuominen> dev-zero: right, it can be decided/voted later on will it become the default or not
-21:33 <@leio> I suggest we suggest the development community to standardize on an USE=static-libs when they want to make installation of static libraries to be optional when they see a reason that someone might want them, and then it is eventually made a global USE flag per usual ways of having more than some 8 packages using it and proposing it on gentoo-dev as usual
-21:33 <@dev-zero> leio: sounds reasonable
-21:33 < jmbsvicetto> leio: 5 is the "magic" number
-21:34 <@dev-zero> ok, I'd say we put the rest of the topics on the agenda for the next meeting
-21:34 < ssuominen> so next topic removing old eclasses?
-21:34 <@dev-zero> yes, in two weeks
-21:34 < jmbsvicetto> leio: Should USE="static-libs" be a choice by the dev or should we mandate it for any ebuild that starts disabling them?
-21:35 <@dev-zero> ssuominen: sorry, but the suggested timeframe for such meetings is 1 hour and some of us have either job, studies or bed calling
-21:35 <@leio> jmbsvicetto: no, I meant it only for cases where it is reasonable to provide such an option. Not mandatory
-21:35 < ssuominen> dev-zero: right
-21:35 < jmbsvicetto> leio: If it is an option, users might start complaining about not being able to build packages with static-libs
-21:36 <@dev-zero> ok, has somebody to say something which should get in the log, statemement etc?
-21:36 < jmbsvicetto> leio: I was trying to clear what you said. I think some people (in particular users) might start "demanding" it becomes mandatory
-21:36 < jmbsvicetto> Yes
-21:36 < ssuominen> jmbsvicetto: for pkgs e.g. gst-engines-something just always --disable, i can see only few core libraries really needing the flag
-21:36 < dleverton> Presumably EXTRA_ECONF could still override it (although a USE flag is still nice in cases where it's most likely to be useful)
-21:36 <@dev-zero> jmbsvicetto: ok, what is it? :)
-21:36 <@leio> jmbsvicetto: hmm... I guess it might be useful to define when it would make sense to have it. I personally see it making sense for some C++ things and in lower-level things that are of interest to the embedded community
-21:36 <+tanderson> Why not just use EXTRA_ECONF in the places is useful(livecds I've heard)
-21:36 < jmbsvicetto> The election team decided to hold the council elections from June 1st to 14th for nominations and 16th to 30th for voting. The results will likely be announced on July 2nd
-21:37 < solar> <ciaranm> leio: it comes from solar <-- not me. Perhaps somebody else.
-21:37 <@leio> solar: vapier
-21:37 < ssuominen> EXTRA_ECONF is not an option, there's other build systems as well...
-21:37 < jmbsvicetto> leio: I'm not a fan of static-libs, but I antecipate users will complain about not having a choice
-21:37 <@dev-zero> jmbsvicetto: ok, thank you already for organizing the elections
-21:37 <@leio> solar: I think. At least he's the only one that has been saying there is such a rule, and the only actual written down statement as such is a short e-mail from him stating such a rule exists
-21:37 <@dev-zero> tanderson: ^^ please put that in the summary
-21:38 <+tanderson> the elections stuff? I miss nothing :P
-21:38 <@dev-zero> someone else?
-21:38 <@Betelgeuse> Well usually devs cater to users that want a choice.
-21:38 <@Betelgeuse> IF it makes sense.
-21:38 <@leio> solar: and Halcy0n saying there is such a thing because vapier said so :)
-21:38 <@dev-zero> tanderson: yes, just add it as a separate point please
-21:38 <+tanderson> yup
-21:38 <@dev-zero> ok, then the meeting is over
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090528-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090528-summary.txt
deleted file mode 100644
index 5a972d231b..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090528-summary.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: here
-Cardoe: here
-dertobi123: here 
-dev-zero: here
-leio: here
-lu_zero: here
-tanderson(secretary): here
-ulm: here
-
-Topics:
-===========
-
-    - Filling the empty council seat.
-        Donnie Berkholz resigned from the council so there is an empty spot
-        that needs to be filled. ssuominen and ulm were tied for the next
-        spot, but ssuominen relinquished his seat to ulm. To fill the spot,
-        ulm needed to be unanimusly voted in by the current members.
-
-        Conclusion:
-            Unanimously voted to fill the seat. Ulrich Müller will fill Donnie
-            Berkholz's seat for the rest of the current term.
-
-    - EAPI 3 status report from Zac Medico.
-        No progress yet. Zac said he'd have a recent recruit of his work with
-        him on it.
-
-        Conclusion:
-            Zac will work on EAPI 3 features with the help of his recruit. He
-            will also blog about what features need to be done so the general
-            community can pitch in.
-
-    - Removal of Old Eclasses.
-        Jorge(jmbsvicetto) requested that the council discuss removing
-        eclasses from the tree that are no longer needed. The problem with
-        this is that old(<2.1.4) portage versions used the eclasses from the
-        tree to run uninstall phases. Thus, the removal of eclasses would
-        break users who have a portage older than 2.1.4.
-
-        Conclusion:
-            The council voted that to remove eclasses devs should take the
-            following steps:
-                1) Deprecate eclasses.
-                2) Removal of all functionality relating to installing.
-                3) After two years the eclass may be removed.
-            Thomas Anderson(tanderson) will write up patches for devmanual so
-            that this policy is documented.
-
-    - Handling EAPI Versioning in a forwards-compatible way.
-        Various developers have raised concerns that GLEP 55 only describes a
-        solution and doesn't clearly show the problems being solved(if any).
-        Luca(lu_zero) mentioned a few things in the "Problem" section that he
-        thought could be clarified, listed below:
-
-            1) For "Change the behaviour of inherit in any way", it would be
-            useful to include references to bugs where requested inherit
-            changes would require GLEP 55.
-
-            2) For "Add new global scope functions in any way", defining
-            'Sane'.
-
-            3) For "Extend versioning rules in an EAPI", removal of all
-            mentions of GLEP 54 would remove circularity. In addition,
-            mentioning other version format changes would be useful.
-
-            4) For "Use newer bash features", listing useful(including
-            in-tree) bash features not available in the bash version mandated
-            by PMS would be useful.
-
-        Conclusion:
-            The council voted on whether they recognized the problem that GLEP
-            55 is attempting to solve is real. The vote was affirmative in
-            recognition of the problem with two abstentions(leio and ulm). '
-            Cardoe was no longer at the meeting for this vote and will post 
-            his voteon-list.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090528.txt b/xml/htdocs/proj/en/council/meeting-logs/20090528.txt
deleted file mode 100644
index e77c576553..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090528.txt
+++ /dev/null
@@ -1,401 +0,0 @@
-16:00 <@dev-zero> ok, let's start the roll-call
-16:00  * dertobi123 his here and grabs another beer
-16:00  * lu_zero is present
-16:00  * Naib joins Sput. 
-16:00 <@dertobi123> is*
-16:00 < Naib> I has beer Sput
-16:00  * lu_zero takes some water
-16:01 < zmedico> dev-zero: yeah
-16:01 <@dev-zero> zmedico: cool :)
-16:01  * ulm is here
-16:01 <@leio> here
-16:01 <@dertobi123> so, we're waiting for Cardoe and Betelgeuse, right?
-16:02 <@dev-zero> yes
-16:02 <@dev-zero> Cardoe: ping?
-16:02 <@dev-zero> Betelgeuse: ping?
-16:02 <@Cardoe> pong
-16:02 <@dertobi123> heya Cardoe
-16:03 <@dev-zero> just updated the agenda again to match the one I posted
-16:03 <@dev-zero> Betelgeuse: please call in asap
-16:03 <@dev-zero> let's get started
-16:03 -!- Ron_157 [n=Matt@DSL01.212.114.237.250.ip-pool.NEFkom.net] has joined #gentoo-council
-16:03 <@dev-zero> Donnie decided to resign
-16:04 <@Cardoe> dertobi123: hey
-16:04 <@Betelgeuse> dev-zero: \o/
-16:04 <@dev-zero> the next person on the list are: ssuominen and ulm
-16:04 <@dev-zero> Betelgeuse: heya :)
-16:04 <@dev-zero> ssuominen decided to leave the spot to ulm
-16:05 <@dev-zero> so, unanonymous vote please
-16:05 <@Cardoe> ulm: are you present?
-16:05 <@dertobi123> he is
-16:05 < ulm> Cardoe: yep
-16:05 <@lu_zero> ulm =)
-16:05 <@Cardoe> yes for ulm
-16:05 <@dev-zero> yes for ulm
-16:05 <@dertobi123> welcome ulm ;)
-16:05 <@lu_zero> ulm welcome =)
-16:06 < ulm> thanks :)
-16:06 <@leio> yes for ulm
-16:06 <@Betelgeuse> yes
-16:06 -!- mode/#gentoo-council [+o ulm] by dev-zero
-16:06 <@dev-zero> good, that was quick :)
-16:07 <@dev-zero> can we move to the next topic?
-16:07 <@dertobi123> yes
-16:07 <@dev-zero> zmedico: what's the progress on eapi-3 implementation in portage?
-16:08 <+tanderson> I'm here
-16:08 < zmedico> dev-zero: almost nothing so far. only stuff is what you've given me patches for. however, I hope to make time to get it all done pretty soon.
-16:08 <+tanderson> dev-zero: yeah, I've been logging the whole thing
-16:09 -!- aknm [n=aknm@5acabe73.bb.sky.com] has joined #gentoo-council
-16:09 -!- spatz [n=spatz@unaffiliated/spatz] has joined #gentoo-council
-16:09 <@dev-zero> zmedico: ok, thanks
-16:10 <@dev-zero> I guess there's nothing more we could do besides start coding to speed up the process, is there?
-16:10 <@Betelgeuse> zmedico: Jugding from past experience that's anything from days to a year :)
-16:10 <@Betelgeuse> dev-zero: Writing code is recommended for everyone.
-16:10 < zmedico> Betelgeuse: yeah, but I don't expect the eapi3 stuff to be much work. just need to make time for it
-16:11 <@dev-zero> Betelgeuse: maybe we should point out that many features are not that hard to implement, just need a bit of bash and/or python knowledge
-16:11 <@lu_zero> basically patches welcome?
-16:11 <@Betelgeuse> dev-zero: Indeed.
-16:11 <@leio> lets rewrite portage in C, then I can help *g
-16:11 <@Betelgeuse> dev-zero: The barrier of entry for some of them shouldn't be that high and maybe it would encourage further contributions.
-16:11 -!- xake [n=xake@liten.csbnet.se] has joined #gentoo-council
-16:11 <@lu_zero> leio ok =P
-16:11 <+tanderson> I could take a look at making some patch for the bash things
-16:11 <+tanderson> *patches
-16:11 < Calchan> zmedico, how about asking your recruit to help you ?
-16:12 -!- marens [n=marens@unaffiliated/marens] has joined #gentoo-council
-16:12 < zmedico> Calchan: good idea, will do
-16:12 <+tanderson> zmedico: I never did get around to rewriting ebuild.sh to be more eapi-friendly,did I :/
-16:13 < zmedico> well, it works fine as is
-16:13 <+tanderson> zmedico: yeah, but it's a tad messy
-16:13 -!- spaceinvader [n=desktop@unaffiliated/spaceinvader] has joined #gentoo-council
-16:13 < zmedico> yeah, could use some cleanup
-16:14 <@lu_zero> zmedico you may try to point some tasks you'd like to see patches in your blog
-16:14 <@Betelgeuse> dev-zero: Next topic time?
-16:14 <@dev-zero> Betelgeuse: I think so
-16:14 <@dev-zero> zmedico: jup, that would be great :)
-16:14 < zmedico> lu_zero: good idea, will do
-16:14 <@dev-zero> zmedico: thanks for reporting :)
-16:14 <@dev-zero> ok, next topic
-16:15 < zmedico> you're welcome
-16:15 <@dev-zero> removing old eclasses
-16:16 <@dev-zero> as Betelgeuse pointed out it would only be a problem for packages where the vdb entry has been generated with a very old portage version
-16:16 <@dev-zero> or when using a portage version older than 2.1.4
-16:16 <@dev-zero> is that correct?
-16:16 <@leio> do I get it right that if user has packages using eclasses that have been removed, all he has to do is upgrade portage before upgrading or removing other stuff to get the environment.bz2 used that has been saved for lots more than since a year?
-16:16 <@ulm> zmedico: when exactly was Portage 2.1.4 stabilised?
-16:16 <@dev-zero> leio: I did understand it that way as well, yes
-16:17  * dertobi123 too
-16:18 <@dev-zero> it seems something around a year ago
-16:18 < peper> and how horribly <2.1.4 fails at uninstallation? i.e. is it just a case of upgrading and trying again or something is screwed up in the process?
-16:18 < zmedico> ulm: around march, 2008
-16:20 <@dertobi123> it was mid-february last year according to the changelog
-16:20 <@leio> I think it would be fine to remove eclasses once we map out which ones are used by portage and its deps and limit any compatibility breaking impact there
-16:20 <@ulm> dertobi123: 2008-02-18 according to bug 210031
-16:20 < Willikins> ulm: https://bugs.gentoo.org/210031 "sys-apps/portage-2.1.4.4 stable request"; Portage Development, Conceptual/Abstract Ideas; RESO, FIXE; zmedico@g.o:dev-portage@g.o
-16:20 <@Cardoe> The packages that don't know what repo they were generated with are generated with which Portage?
-16:20 -!- lavajoe [n=joe@mail.boulder.swri.edu] has joined #gentoo-council
-16:20 <@Cardoe> the ones that say "[?=>0]"
-16:21 <@dertobi123> ulm: yep, that was the one i found, too
-16:21 <@Cardoe> cause if that's 2.1.4, then I still have packages that were recently upgraded with that version
-16:21 <@dev-zero> zmedico: ^^ ?
-16:21 -!- marens [n=marens@unaffiliated/marens] has left #gentoo-council []
-16:22 <@Betelgeuse> Yeah many people never run emerge -e world
-16:23 <@Betelgeuse> I don't really see what's the big benefit of being able to rm a couple files?
-16:23 <@dertobi123> i don't, too
-16:23 <@dertobi123> mark them as deprecated and we're done
-16:24 < zmedico> Cardoe: repo labels in /var/db/pkg are in >=portage-2.1.5 iirc
-16:24 <@dev-zero> maybe make anything not needed for uninstall unusable? (by using die in src_install/src_compile/etc)
-16:24 <@Cardoe> zmedico: and what file is that stored in?
-16:24 <+tanderson> dertobi123: you could even put a die in pkg_setup or something 
-16:24 <@Betelgeuse> dev-zero: That's been the practise
-16:24 <@dev-zero> Betelgeuse: ah, ok
-16:24 <@Betelgeuse> dev-zero: see debug.eclass
-16:25 < zmedico> Cardoe: /var/db/pkg/*/*/repository
-16:25 <@dertobi123> tanderson: exactly ...
-16:26 <@dev-zero> well, we already drop enough bugs on our users, I don't like risking even more
-16:26 <@dertobi123> agreed
-16:26 <@Cardoe> so we can see what directories are missing /var/db/pkg/*/*/repository
-16:26 <@dev-zero> Cardoe: but that isn't related to environment.bz2, is it?
-16:27 <@Cardoe> and that'll give you a guess at seeing that that some packages are made with an old portage
-16:27 <@Cardoe> dev-zero: I thought we were talking about when eclasses were included in environment.bz2
-16:27 <@leio> by my understanding that's a lot before 2.1.4
-16:28 <@dev-zero> Cardoe: yes, but repository is included with portage >=2.1.5 and environment.bz2 got generated by even older portage but not used
-16:28 <@dev-zero> ok, can we come to a conclusion here?
-16:28 <@dertobi123> guess we can quickly vote on that
-16:28 <@Cardoe> dev-zero: right so my check tells you what vdb's were created with 2.1.4 and older
-16:28 <@dev-zero> leio, lu_zero, ulm, Cardoe: what's your opinion on this?
-16:28 <@leio> repeating from before: I think it would be fine to remove eclasses once we map out which ones are used by portage and its deps and limit any compatibility breaking impact there
-16:29 <@ulm> if it's only a little more that a year ago, then IMO it's too risky to allow removing
-16:29 <@lu_zero> as a general rule I'd keep 6 month of deprecation, make sure an upgrade path is available as leio said
-16:29 <@ulm> after all, the benefit is very small
-16:29 <@lu_zero> and do the cleanup if is deemed useful
-16:29 <@Cardoe> I'm with ulm on this one
-16:30 <@dev-zero> that leaves us with "wait a bit longer to remove eclasses"?
-16:30 <@leio> does that have to be mean about all eclasses?
-16:31 <@dev-zero> well, graph theory is non-trivial, so I don't consider myself smart enough to ensure that a given eclass doesn't show up in a dep-tree when updating portage
-16:31 <@leio> there's a difference between eclasses that portage and its deps depend on and eclasses that only a limited set of packages used, and all those revisions of such packages were removed two years ago
-16:31 <@dertobi123> leio: eclasses which were introduced after portage-2.1.4 went stable might be an exception (though the number of those eclasses isn't that large, i guess)
-16:32 <@ulm> dertobi123: that makes sense
-16:32 <@leio> maybe the community can bring example of which eclasses they'd like to remove
-16:33 <@dev-zero> kde has been mentioned
-16:33 <@Betelgeuse> GLEP 55 allows us to use a new eclass approach etc
-16:33 <@Betelgeuse> so the old ones can just be left to rot
-16:33 <@dertobi123> unused eclasses are marked as deprecated and it's functionality except uninstall-related stuff removed, and that for a minimum of 2 years before final removal
-16:34 <@dertobi123> what about that? (and the exception i stated above)
-16:34 <@ulm> dertobi123: +1
-16:34 <@dev-zero> dertobi123: sounds good
-16:34 <@lu_zero> dertobi123 fine
-16:34 <@dertobi123> so we have 4 yes on that :)
-16:34 <@dertobi123> any "no"s?
-16:35 <@Betelgeuse> I don't really see a need for a time limit like that
-16:35 <@leio> I take it as something that can be relaxed once more time has passed
-16:35 <@dev-zero> where do we write that down?
-16:35 <@Betelgeuse> I would just leave the empty ones there
-16:35 <@dertobi123> dev-zero: meeting agenda, dev-manual, anywhere else?
-16:35 <@dev-zero> dev-manual mainly I think
-16:36 <@Betelgeuse> Otherwise if we keep the flat namespace someone might accidentally resurrect an eclass with different behavior
-16:36 <@dev-zero> tanderson: can you do the update perhaps?
-16:36 <@Cardoe> dev-zero: dev-manual for sure
-16:36 <@Cardoe> dev-zero: I'd file a ticket for that
-16:37 <@Cardoe> alright let's get moving on the agenda items
-16:37 <@Cardoe> got about 20 min left
-16:37 <@dertobi123> yeah
-16:38 <@dev-zero> good
-16:38 <@leio> instead of keeping empty ones, there could be a cvs or git hook to disallow resurrection
-16:39 <+tanderson> dev-zero: for eapi 3?
-16:39 <@leio> however initially I thought the intention of keeping empty ones around idea was to keep the inherit calls from old package revisions being uninstalled to not error out on missing eclasses
-16:39 <+tanderson> dev-zero: or deprecating unused eclasses?
-16:39 -!- codejunky [i=jan@nerdig.org] has joined #gentoo-council
-16:39 <@dev-zero> tanderson: deprecating unused eclasses
-16:39 <+tanderson> right.
-16:40 <+tanderson> can do. Probably after my summary is finished though :)
-16:40 -!- codejunky [i=jan@nerdig.org] has left #gentoo-council []
-16:40 <+tanderson> leio dislikes waiting :p
-16:40 <@dev-zero> tanderson: otherwise please open a bug for it
-16:40 <+tanderson> ok
-16:40 <@dev-zero> leio: can we discuss it on-list or later on?
-16:40 <@leio> sure.
-16:40 <@dev-zero> ok
-16:40 <@leio> (I'll be gone till Monday after meeting though, fyi)
-16:41 <@dev-zero> let's move on: Handling EAPI versioning in a forwards-compatible way
-16:41 <+tanderson> If I don't get it done this weekend I'll file a bug. Usually I just poke halcy0n with patches
-16:41 <@dev-zero> ok, Ferris proposed a good way to maybe shed some light on that issue
-16:42 <@dev-zero> are we all clear what the problems are GLEP55 tries to solve?
-16:42 <@leio> Not completely.
-16:42 <@lu_zero> dev-zero some are still disputing them
-16:42 -!- windzor [i=windzor@goatse.baconsvin.dk] has quit [SendQ exceeded]
-16:43 <+tanderson> mmm
-16:43 <+tanderson> what specifically is not understood about the purpose?
-16:43 <@leio> some things it tries to solve seem like things that are not a problem that needs solving
-16:43 <@ulm> dev-zero: the glep in its current wording doesn't make clear what the problem is
-16:44 < ciaranm> what's unclear about the four bullet points describing the problems?
-16:44 <+tanderson> leio: -scm?
-16:44 <@lu_zero> tanderson from what I see from a cursory read the items listed as "problems" aren't believed to be problems at all
-16:44 < NeddySeagoon> GLEP 55 could use some editorial work.  There is more useful info in emails than in the glep
-16:44 <@leio> -scm does not need an extension change.
-16:44 <@dertobi123> ulm: right
-16:44 < ciaranm> please point out which of the four bullet points listing the problem needs clarifying
-16:44 <@leio> this discussion will go downhill from this point.
-16:44 <@dertobi123> as usual
-16:44  * dertobi123 sighs
-16:45 <+tanderson> leio: we do not want per-package eclasses at all? I do certainly
-16:45 < ciaranm> if someone could say which of the bullet points they think isn't clear enough, i'm sure the glep could be updated to address that
-16:45 < bonsaikitten> ciaranm: they do not list the problem but a potential solution
-16:45 <@leio> tanderson: good for you. There are other ways to achieve that.
-16:45 <@Betelgeuse> Who wants to us VAR+="addition" in global scope?
-16:45 <@Betelgeuse> s/us/use/
-16:45 -!- alip [i=alip@unaffiliated/alip] has joined #gentoo-council
-16:46 < ciaranm> bonsaikitten: the four bullet points under the Problem title, please
-16:46 <@dev-zero> bonsaikitten: no, they don't. Please read "current behaviour" in the glep
-16:46 < bonsaikitten> which version are we talking about btw?
-16:46 <@Betelgeuse> http://www.gentoo.org/proj/en/glep/glep-0055.html
-16:47 < bonsaikitten> Betelgeuse: that's not the current version
-16:47 <@lu_zero> ciaranm I'd say
-16:47 <@lu_zero> all.
-16:47 <@lu_zero> either by their vague definition
-16:47 <@lu_zero> or their circularity
-16:47 < ciaranm> lu_zero: ok, let's start with "Change the behaviour of inherit in any way (for example, to extend or change eclass functionality)". what's the problem with that one?
-16:47 <@lu_zero> ciaranm case 1: vague definition
-16:47 < NeddySeagoon> lets not waste the meetings time - lets just fix the glep
-16:47 < ciaranm> lu_zero: what specifically is vague, that you don't understand?
-16:48 <@Betelgeuse> NeddySeagoon: Do you have a patch in mind?
-16:48 < ciaranm> NeddySeagoon: that's what we're doing. we're finally getting someone to say specifically what they think needs fixing.
-16:48 <@Betelgeuse> NeddySeagoon: Feel free to submit one.
-16:48 < ciaranm> NeddySeagoon: if lu_zero could explain exactly what he thinks is wrong with the four bullet points, we can fix them
-16:48 <@dev-zero> jup, that's the point of it
-16:48 <@lu_zero> ciaranm "in any way" doesn't explain which way
-16:49 <@lu_zero> and could be merged with the point 2
-16:49 <@Cardoe> This is a constant struggle.
-16:49 < NeddySeagoon> Betelgeuse,  as I suggested on on -ml it needs a rewrite to include much of the missing information, that is available in the emails
-16:49 <@lu_zero> and there "sane" isn't defined
-16:49 <@Cardoe> People are confused about some wording
-16:49 < fmccor> bonsaikitten, It's dated 17 May 2009.  You have something more recent?
-16:49 <@Cardoe> and they just want clarification
-16:49 < ciaranm> lu_zero: so if we add in links to the pms "future eapi request" bugs that give examples of ways that people want inherit to be changed, you'd be happy with that?
-16:49 <@Cardoe> there's no need to be defensive and get in a fight
-16:49 < bonsaikitten> fmccor: it shows ver. 1.4, cvs has a 1.5
-16:49 <@Cardoe> explain it to the person
-16:49 <@Cardoe> if more then 1 person is confused.
-16:49 < ciaranm> Cardoe: i'm trying to establish exactly what people don't understand or want changed
-16:50 < ssuominen> ulm: to old msg, good :)
-16:50 <@lu_zero> ciaranm if that manages to get less people going berserk when you proposed that in ml probably.
-16:50 <@Betelgeuse> Let's go this way. Who thinks being able to use VAR+="addition" in global scope is useless?
-16:50 < ciaranm> lu_zero: ok, second bullet point. "Add new global scope functions in any sane way.". what is your problem with that statement?
-16:50 < NeddySeagoon> ciaranm, references to other docs are only useful if the reference docs will not change
-16:50 <@ulm> Betelgeuse: nobody needs this
-16:50 <@leio> "Easily fetchable EAPI inside the ebuild" sounds like a good way to start with solving the thing that is the agenda topic - "Handling EAPI versioning in a forwards-compatible way"
-16:50 < bonsaikitten> Betelgeuse: nicely loaded question
-16:50 < peper> bonsaikitten: it's the current version. probably some cvs/web-sync screw-up
-16:50 <@leio> because it merely makes it a rule something that already is a QA policy
-16:51 <@lu_zero> ciaranm define "Sane"
-16:51 < ciaranm> lu_zero: would it help if we add in links to bugs where people are requesting new global scope functions?
-16:51 < bonsaikitten> peper: oh fun ... so which version is authorative?
-16:51 <@Betelgeuse> ulm: why?
-16:51 <@lu_zero> inherit is a global scope function or not btw?
-16:51 < peper> bonsaikitten: it's the same version
-16:51 < ciaranm> lu_zero: inherit's an existing global scope funtion, not a new one
-16:51 < drantin> it's outside a stage, so it's global
-16:51 <@ulm> Betelgeuse: because you can do it in a different way?
-16:51 <@lu_zero> ciaranm inherit2 would be
-16:51 < ciaranm> lu_zero: and inherit has its own special problems unrelated to adding new functions
-16:52 <@lu_zero> or inherit with optional parameters
-16:52 <@lu_zero> anyway it's digressing
-16:52 <@dev-zero> NeddySeagoon: would it be sufficient to add examples for stuff where "in any way" is written?
-16:52 <@Betelgeuse> ulm: We should write longer code on purpose when we could get away with new syntax? I don't see any benefit to sticking with old bash syntax.
-16:52 < ciaranm> lu_zero: bullet point 4. what don't you understand about "use newer bash features."?
-16:52 < ciaranm> lu_zero: would you like a list of newer bash features that we could use?
-16:52 <@lu_zero> ciaranm I think it would help a lot
-16:53 < ciaranm> lu_zero: ok, easily done. and bullet point three: "Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely.". what's wrong with that?
-16:53 <@ulm> Betelgeuse: it's no so much longer, probably on the few percent level
-16:53 <@lu_zero> it's circular.
-16:53 < ciaranm> lu_zero: how is it circular?
-16:53 < NeddySeagoon> dev-zero, that will help.  I understand the reason for the glep and support it aims.
-16:53 <@lu_zero> glep54 isn't accepted
-16:53 < ciaranm> lu_zero: glep 54 is merely an example
-16:53 <@dev-zero> NeddySeagoon: good, will happen then
-16:54 < ciaranm> lu_zero: it also lists other examples of things we might want to do
-16:54 < bonsaikitten> ciaranm: we might want to keep the status quo
-16:54 <@ulm> ciaranm: who is "we"?
-16:54 <@Betelgeuse> ulm: Well bash syntax evolves constantly and there's other things too. But as said a couple lines up there will be a list.
-16:54 <@dev-zero> lu_zero: even your .live extension depends on it
-16:54 < ciaranm> ulm: people who submit feature requests for future eapis
-16:54 < NeddySeagoon> dev-zero, I can volunteer some editorial time, if that helps.
-16:54 <@lu_zero> dev-zero I know
-16:54 < ciaranm> lu_zero: would you like us to remove the specific examples from the third bullet point whilst we're adding them in to the other three?
-16:55 <@lu_zero> ciaranm as I said 3 are vague, one is circular
-16:55 < ciaranm> lu_zero: please explain the circular thing
-16:55 < ciaranm> lu_zero: glep 54 is merely one example of a thing we'd like to do
-16:55 < Sput> isn't the real problem g55 should be solving "how to figure out EAPI prior to sourcing", and shouldn't the discussion center around how to achieve that best?
-16:55 <@dev-zero> lu_zero: ... and your glep is another example
-16:55 <@Betelgeuse> I guess he means that go hand in hand but I don't see how it makes GLEP 55 worse.
-16:56 <@lu_zero> dev-zero none of them are accepted
-16:56 < ciaranm> lu_zero: if that bullet point instead said "Extend versioning rules in an EAPI, for example to allow version formats like 1-rc1, 1-alpha etc. to match upstream more closely", would you be happy?
-16:56 < NeddySeagoon> ciaranm, do you already have glep 54 and 55 implemented in paludis ?
-16:56 < ciaranm> lu_zero: they can't be accepted until glep 55 is
-16:56 <@dev-zero> NeddySeagoon: yes
-16:56 < ciaranm> NeddySeagoon: 54, yes. 55, more or less, although not for the specific suffixes we're asking for (it's used by exheres and kdebuild)
-16:56 <@lu_zero> so you don't need glep 55 if people agree live ebuild or scm version rules are useful
-16:57 -!- alip [i=alip@unaffiliated/alip] has left #gentoo-council []
-16:57 <@Betelgeuse> how do you do -scm without 55?
-16:57 < ciaranm> lu_zero: you need glep 55 if you want any of the bullet points, or if you want -rc support or so on
-16:57 <@Betelgeuse> And no user visible breakage.
-16:57 < lack> Betelgeuse: Easy -> Wait a year
-16:57 <@Betelgeuse> or year wait
-16:57 < NeddySeagoon> ciaranm, maybe that explains why glep55 needs to be read from the bottom up.  You are too close to the problem and perceived solution to document it well
-16:57 <@leio> there is no need to wait for a year
-16:58 <@leio> to introduce -scm or -live
-16:58 <@dev-zero> leio: can you explain that please?
-16:58 <@Betelgeuse> dev-zero: I propose having a vote on if the council thinks the problems as worthy.
-16:58 < ciaranm> NeddySeagoon: stop thinking of the abstract and title as part of the main body
-16:58 < peper> NeddySeagoon: just fyi, I wrote the glep :) as can be easily seen by english quality probably :)
-16:58 <@dev-zero> Betelgeuse: and then update them according to what we discussed today?
-16:58 < ciaranm> lu_zero: so if we update those four bullet points the ways we discussed, you'll be happy?
-16:59 <@Betelgeuse> dev-zero: I only see clarifications coming out of this.
-16:59 < NeddySeagoon> ciaranm I'm not. The body is very thin too
-16:59 -!- xake [n=xake@liten.csbnet.se] has quit [Client Quit]
-16:59 < ciaranm> NeddySeagoon: please point out specific areas where you'd like it fattened up
-16:59 <@lu_zero> ciaranm I see people complaining about that so I hope that will make the thing more acceptable to that point
-16:59 <@lu_zero> then there is the rest
-16:59 <@leio> dev-zero: you simply have portage warn about an unrecognized atom for people with old portage. One line warning per package seen that has a -scm revision, nagging them even further to finally upgrade their package manager for doing, duh, package management. Nothing catastrophic to my knowledge.
-16:59 <@Betelgeuse> dev-zero: And if you understand the problem domain you don't need any concrete wording for voting
-16:59 < ciaranm> leio: did you see the mess last time that happened?
-17:00 <@leio> No.
-17:00 <@lu_zero> I don't see benchmarks yet I have most of the alternate proposals ruled as resource heavy
-17:00 <@dev-zero> Betelgeuse: ok, agreed for the voting
-17:00 <@dev-zero> ok, people
-17:00 < NeddySeagoon> ciaranm, I would like objective, quantitive measurements of the main potential solutions included in the GLEP.  Some have been posted to the -ml, so they are probebly available
-17:00 <+tanderson> This is a vote on the 'problem' not the solution, right?
-17:00 < Calchan> what the glep really needs is summarizing what was said on the list, and I know that ciaranm is going to say that very little to none of it is valuable but many will disagree with that
-17:00 <@ulm> leio: do you remember if there were any serious problems when multiple _pre, _rc, etc. were allowed?
-17:00 <@dertobi123> NeddySeagoon, Calchan: agreed
-17:01 <@lu_zero> and possibly reproducible by third party easily
-17:01 <@dev-zero> tanderson: yes
-17:01 <@leio> ulm: I don't remember, but that's a reason why I don't see it reasonable to change versioning rules to track upstream better.
-17:01 <+tanderson> Calchan: I could clarify some points of the problem part. I just need concrete emails on which parts are confusing and why they are confusing
-17:01 < NeddySeagoon> lu_zero, auditable anyway
-17:01 <@dev-zero> ok, can we please get votes for whether the problems mentioned in the glep are worth to get solved?
-17:01 <@ulm> leio: I also see no need for things like "-rc" instead of "_rc"
-17:01 <@Betelgeuse> I vote yes.
-17:02 < Calchan> tanderson, that's the hard part, digging the interesting stuff from all these useless flamewars
-17:02 <@dertobi123> in general, yes
-17:02 <@dev-zero> I vote yes.
-17:02 <@lu_zero> I asked them to be clarified so count me as a yes with reserve
-17:02 <+tanderson> Calchan: indeed. I'm actually considering asking for _private_ emails so I don't have all the back-and-forth
-17:02 <@dev-zero> good, that makes 4
-17:03 <@lu_zero> dev-zero that makes me a no if they aren't clarified
-17:03 <@dev-zero> so, glep authors: please update the glep as discussed here
-17:03 <@dev-zero> lu_zero: yes, I understand that
-17:03  * ulm doesn't see a basis to vote about the glep in its current wording
-17:03 <@Betelgeuse> ulm: We are not voting about the GLEP at all
-17:03 <@dev-zero> ulm: it's not about the glep, only about the problems mentioned
-17:03 <@leio> I agree there are things to solve for bullet points 1, 2 and 4, but do not agree with glep55 being the best way to do that.
-17:03 <@dertobi123> ulm: we're not voting about the glep, but the problems described
-17:03 <@dertobi123> i'd like to vote the next meeting on whether to approve on of the mentioned solutions
-17:03 <@dertobi123> and only to vote.
-17:03 <@dev-zero> leio: ok, that's the only thing we wanted to know :)
-17:04 <@dertobi123> otherwise this will become a neverending story ...
-17:04 <@dev-zero> dertobi123: but this discussion was probably one of the most productive ones we had about it
-17:04 <@leio> I am heavily against voting on stuff that is not clear only to "get it under the carpet"
-17:04 < Calchan> I'd like everybody to note that there seemed to have been an informal consensus on the third solution in the list of three that peper proposed in http://archives.gentoo.org/gentoo-dev/msg_959451961983a52129e3f41cd87eac0e.xml
-17:04 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council
-17:05 <@dertobi123> leio: there are again 14 days to get those things sorted
-17:05 < NeddySeagoon> ciaranm, if the council pick an in ebuild solution, how much work do you have to redo ?
-17:05 <@ulm> Calchan: that would be "Easily fetchable EAPI inside the ebuild"?
-17:05 < ciaranm> NeddySeagoon: we can implement anything we want in paludis. it's not portage, you know :P
-17:06 <@dertobi123> ulm: plus extention change, "easily fetchable eapi inside the ebuild" wasn't mentioned in peper's mail
-17:06 < NeddySeagoon> dev-zero, thats good design, break the problem into small pieces and address each piece.  Recursively as needed
-17:06 < Calchan> ulm, yes with for example a .eb extension and eapi in she-bang
-17:06 <@dertobi123> and that's another thing i dislike
-17:06 <@dertobi123> extension* even
-17:06 <@dev-zero> ok, I think that topic is over for today
-17:06 < NeddySeagoon> ciaranm, I was thinking wasted effort
-17:06 < peper> dertobi123: hmm?
-17:06 < ciaranm> NeddySeagoon: eh, exherbo's using it anyway
-17:06 <@dev-zero> reserve solutions to the problems for the next 14 days and the next meeting, please :)
-17:07 < peper> dertobi123: it wasn't cause I hate it. you are free to like it :)
-17:07 < NeddySeagoon> ciaranm, I think you went with eapi in filename ?
-17:07 <@Betelgeuse> coding and changin wording is nothing compared to what people seem to be using for mailing on lists
-17:07 <@dev-zero> is someone on the run or can we peek into the next topic?
-17:07 <@dertobi123> peper: if the glep mentiones 4 solutions i'd expect to put all of them up for discussion on the ml and not to hide a solution you personally dislike.
-17:07 < ciaranm> NeddySeagoon: oh, you mean, you want someone to code in-ebuild-eapi support? can do that, if the council decides it doesn't want to take the best solution
-17:07 < peper> dertobi123: err, the list was labeled: "Just FYI, my order of preference of solutions is:"
-17:07  * dertobi123 needs to go to bed somewhat soonish
-17:08 < fmccor> dertobi123, It's in GLEP55 (alternative 3 or idea 4, depending on where you start counting)
-17:08 < peper> i listed 2. and 3. just to show I can live with them
-17:08 <@dertobi123> fmccor: sure
-17:08 < NeddySeagoon> ciaranm, the objective evidence for 'best solution' is still missing
-17:08 <@dev-zero> ok, the next topic:
-17:08 <@Betelgeuse> dev-zero: I need to finish a task for tomorrow.
-17:08 <@Betelgeuse> dev-zero: I will glance every once in a while
-17:08 <@dev-zero> Betelgeuse: fine by me
-17:09 <@Cardoe> dev-zero: we're over time.. have we decided to extend?
-17:09 <@dev-zero> ok, next topic (just to get an idea).
-17:09 < ciaranm> NeddySeagoon: objectively, you have to either not change version format rules ever, or force the package manager to open() every ebuild rather than no ebuilds before it can find the best version of something
-17:09 < peper> NeddySeagoon: re: your editorial time, I would appreciate it and welcome patches
-17:09 <@dev-zero> Cardoe: I asked, see above
-17:09 <@dertobi123> we did agree on a one-hour meeting and i don't think the next topic is that important to extend the meeting
-17:09 <@leio> ciaranm: incorrect, but this is not the place to discuss right now indeed.
-17:09 < NeddySeagoon> peper, I can't start until Wednesday ... but ok
-17:09  * antarus chuckles
-17:09 <@dev-zero> dertobi123: then please say just "no" the next time I ask :)
-17:10 <@dev-zero> ok then, meeting is over
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090611-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090611-summary.txt
deleted file mode 100644
index 3263fab1f6..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090611-summary.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: here
-Cardoe: here
-dertobi123: here 
-dev-zero: here
-leio: here
-lu_zero: here
-tanderson(secretary): here
-ulm: here
-
-Topics:
-===========
-
-     - Short discussion of EAPI 3 progress.
-        Zac Medico(zmedico) commented that while no progress had been made, a
-        tracker bug had been made[1] for those interested in providing patches
-        for and tracking the progress of the EAPI 3 implementation. Ciaran
-        McCreesh noted that paludis is ready for EAPI 3 whenever the portage
-        implementation is finished.
-
-    - Default contents of ACCEPT_LICENSE(license filtering).
-        GLEP23[2] provided a method for users to select what licenses they are
-        willing to accept based on a ACCEPT_LICENSE configuration variable. In
-        addition it provided for 'license groups' so users could accept or
-        decline to use software of a certain license type. What GLEP 23 did not
-        specify was the default value of ACCEPT_LICENSE.
-
-        Conclusion:
-            The council unanimously voted to have the default ACCEPT_LICENSE
-            value as ACCEPT_LICENSE="* -@EULA".
-
-    - BASH 4 in EAPI 3.
-        There were three parts to this topic:
-            1) Unlocking of feature requests for EAPI 3.
-            2) Allowing BASH 4 features in EAPI 3 ebuilds.
-            3) Allowing BASH 4 features in all ebuilds with EAPIs >= 3 after a 
-               fixed amount of time in gentoo-x86(Overlays could begin use
-               immediately).
-
-        Conclusion:
-            By a 4-3 decision the council voted not to open the feature list for
-            EAPI 3.
-
-    - The banning of igli(Steve Long) from #gentoo-council.
-        Tiziano Muller(dev-zero) banned igli from #-council for what he called
-        repeated trolling after private warnings. The ban was later reversed by
-        Doug Goldstein(Cardoe) because it had not been put to a council vote as
-        all bans in #-council are.
-
-        Conclusion:
-            No decision yet, the council decided to discuss this issue privately
-            on the council@ alias so that precious meeting time is not spent.
-
-    - Define EAPI development/deployment cycles.
-        Various Council members expressed support for Ciaran McCreesh's EAPI
-        development guidelines as outlined in [3]. However, the discussion
-        reached no conclusion and quickly spiraled into a discussion of the
-        removal of Ciaran McCreesh's bugzilla privileges.
-
-    - Removal of Ciaran McCreesh's(ciaranm) bugzilla permissions.
-        At some point in the last year ciaranm's bugzilla permissions were
-        removed. He filed a bug about the issue(#273759) and was talking about
-        moving PMS off of Gentoo Infrastructure, a move that some council
-        members were strongly opposed to. When asked about the permissions,
-        Ciaran had no objections to waiting a few days for the infra to complete
-        an investigation into who removed the access and for what reason.
-
-        Conclusion:
-            The council voted to reinstate Ciaran's editbugs privileges. Ned
-            Ludd (solar) noted that infra will investigate who removed the privileges
-            in the first place, and asked for not changing bugzilla privileges before
-            this is completed.
-
-[1]: https://bugs.gentoo.org/show_bug.cgi?id=273620
-[2]: http://www.gentoo.org/proj/en/glep/glep-0023.html
-[3]: http://archives.gentoo.org/gentoo-dev/msg_d3a4758c455fded00608e891f525d3cc.xml
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090611.txt b/xml/htdocs/proj/en/council/meeting-logs/20090611.txt
deleted file mode 100644
index 9946cd8715..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090611.txt
+++ /dev/null
@@ -1,860 +0,0 @@
---- Log opened Thu Jun 11 00:00:30 2009
-01:47 -!- mode/#gentoo-council [+b %igli!*@*] by dev-zero
-01:48 <@dev-zero> I'm definetely fed up with his repeated trolling
-02:04 <@dev-zero> ... and since I told him to control his temper I think it's justified
-03:31 -!- ulm [n=ulm@gentoo/developer/ulm] has joined #gentoo-council
-03:31 -!- mode/#gentoo-council [+o ulm] by ChanServ
-04:11 -!- alexxy [n=alexxy@gentoo/developer/alexxy] has quit [Read error: 104 (Connection reset by peer)]
-04:12 -!- alexxy [n=alexxy@gentoo/developer/alexxy] has joined #gentoo-council
-04:45 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has joined #gentoo-council
-07:13 -!- touparx [n=toupar@125.220.139.49] has joined #gentoo-council
-07:21 < Polynomial-C> I need more popcorn for all those barren discussion held in here... (*sigh*)
-07:22 < Naib> Polynomial-C: iirc Sput has some shares in a big popcorn company, he should be asking for higher yield soon
-07:23 < Sput> meh, I already lease most of Iowa, don't tell me I need to invest in Kansas too :/
-07:23 < Polynomial-C> Sput, any plans to expand to Europe? :)
-07:24 < Sput> meh, we don't grow that much corn :)
-08:10 -!- jlec [n=abraxxas@ibi199.ibi.kfa-juelich.de] has joined #gentoo-council
-08:46 -!- yngwin [n=yngwin@gentoo/developer/yngwin] has joined #gentoo-council
-08:47 -!- yngwin__ [n=yngwin@gentoo/developer/yngwin] has quit [Read error: 60 (Operation timed out)]
-09:03 -!- The_Paya [n=the_paya@gentoo/developer/thepaya] has quit [Client Quit]
-09:12 -!- touparx [n=toupar@125.220.139.49] has quit [Client Quit]
-09:13 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council
-09:14 -!- The_Paya [n=the_paya@201-212-72-125.cab.prima.net.ar] has joined #gentoo-council
-09:18 -!- touparx [n=toupar@125.220.139.49] has joined #gentoo-council
-09:21 -!- Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #gentoo-council
-09:21 -!- mode/#gentoo-council [+o Cardoe] by ChanServ
-09:26 -!- The_Paya [n=the_paya@gentoo/developer/thepaya] has quit [Client Quit]
-09:26 -!- The_Paya [n=the_paya@190.51.250.242] has joined #gentoo-council
-09:32 < fmccor> tanderson, ping when you have a moment.
-09:41 <+tanderson> fmccor: I sort of do now
-09:41 <+tanderson> Sort of in and out
-09:45 < fmccor> tanderson, may I query?
-09:45 <+tanderson> yes
-09:50 -!- spatz [n=spatz@unaffiliated/spatz] has joined #gentoo-council
---- Log closed Thu Jun 11 10:24:21 2009
---- Log opened Thu Jun 11 10:27:36 2009
-10:27 -!- gentoofan23_ [n=gentoofa@gentoo/developer/gentoofan23] has joined #gentoo-council
-10:27 -!- Irssi: #gentoo-council: Total of 66 nicks [8 ops, 0 halfops, 1 voices, 57 normal]
-10:27 -!- mode/#gentoo-council [+v gentoofan23_] by ChanServ
-10:28 -!- tanderson [n=gentoofa@gentoo/developer/gentoofan23] has quit [Nick collision from services.]
-10:28 -!- You're now known as tanderson
-10:30 -!- Irssi: Join to #gentoo-council was synced in 182 secs
-10:47 -!- jlec [n=abraxxas@ibi199.ibi.kfa-juelich.de] has left #gentoo-council []
-11:38 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Read error: 113 (No route to host)]
-11:46 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council
-11:46 -!- You're now known as nop
-11:47 -!- You're now known as tanderson
-11:53 -!- togge|laptop [n=togge@212.247.117.70] has joined #gentoo-council
-12:02 -!- togge [n=togge@gentoo/contributor/togge] has quit [Read error: 113 (No route to host)]
-12:05 -!- musikc [n=musikc@gentoo/developer/musikc] has joined #gentoo-council
-12:05 < trelane> Cardoe: identify why they're quitting and solve that problem.
-12:06 < trelane> tanderson: regarding your note on quoting the council, I will ensure that I quote from the actual council logs in the future.  Please note there was no intent to deceive there, or reword a council vote, merely I chose to use the summary rather than an extensive log, only part of which was essential to my point.
-12:07 < musikc> ping dev-zero
-12:07 <@Cardoe> trelane: too much time spent babysitting and being forced to read everyone's opinion of every damn thing even though there really should only be a select few that have a say
-12:07 <@Cardoe> they present it
-12:07 <@Cardoe> filter what's worth hearing
-12:07 <@Cardoe> and be done
-12:08 < trelane> Cardoe: well, lets fix that problem then.
-12:08 < trelane> fixing that sort of, and I cannot overstate how massive it is based on my own experience would do much to make this council, and the next council's life easier
-12:09  * trelane figures the word problem should have been included up there someplace (insert it as you see fit)
-12:09 <@Cardoe> unfortunately some people don't want to fix it
-12:09 < trelane> Cardoe: I'm having the same experience from a Funtoo perspective. The problem persons for me (and probably for you as well) are not even gentoo developers.
-12:09 <@Cardoe> and as such the rest of us are punished
-12:09 < bonsaikitten> so fix them. with two bricks.
-12:10 <@Cardoe> so I will not be running and instead will write code instead of babysit
-12:10 < trelane> I understand your frustration, however I have heard nearly the same complaint verbatim from one of the original council members as to the reason why he quit.
-12:10 <@Cardoe> trelane: bonsaikitten: feel free to say ciaranm is the problem. however, you guys are probably a bit biased and I will gladly say ciaranm is not the problem.
-12:11 -!- jlec [n=jlec@ip-62-143-31-170.unitymediagroup.de] has joined #gentoo-council
-12:12 < trelane> It's not just Ciaran.  When I sent my thoughts on the paludis problem to -dev, I mentioned that there were quite a few problems, but that it seemed they centered around Paludis and Exherbo personalities
-12:12 < trelane> I absolutely think Ciaran needs to go, and nothing above should be read otherwise.
-12:12 <@Cardoe> While he doesn't help the problem and does tend to fan the flames (i.e. a thread goes from 10 posts to 60 posts cause every starts arguing)
-12:12 <@Cardoe> But there's other people that are the problem
-12:12 < trelane> the problem is the arguments have become religious
-12:12 <@Cardoe> The people unqualified to put their two cents in
-12:13 < trelane> I agree, but I have to note that Ciaran is a magnet for such things.
-12:14 < trelane> the eventual solution is to remove one side of the argument, and the board has already in part done this
-12:14 <+tanderson> trelane: I know, just making sure you understand that the summaries are *quite* simplified
-12:15 <+tanderson> I didn't view you as twisting the summary ;)
-12:15 < trelane> tanderson: thanks, I will absolutely bear that in mind in the future and make sure I cite any specific clarifying statements from the council :)
-12:15 < trelane> tanderson: I didn't think you did, but as we're in a text medium I wanted to make sure that you were aware that no malice was intended.
-12:15 <+tanderson> yup
-12:15 -!- mode/#gentoo-council [-b %igli!*@*] by Cardoe
-12:16 <@Cardoe> dev-zero: we've in the past decided that any bans need to be brought up to the other council members and e-mailed out the the council@gentoo.org alias
-12:16 <@Cardoe> dev-zero: since you didn't do so, I am removing the ban until you discuss it with the rest of us
-12:18 <@dev-zero> Cardoe: hey, you don't really think that going through all meeting summaries is a way to document things, do you?
-12:19 <@dev-zero> musikc: pong?
-12:19 <+tanderson> Cardoe: does it look like you'll be here for the meeting?
-12:19 < musikc> dev-zero, i apologize, i need to get something completed at RL work. i shall return in a bit
-12:19 <@dev-zero> musikc: no problem
-12:22  * tanderson -> softball, back before the council meeting hopefully
-12:24 -!- You're now known as tanderson|na
-12:25 <@Cardoe> dev-zero: ?
-12:26 <@dev-zero> Cardoe: sorry, I didn't find any reference to such a rule
-12:27 <@Cardoe> dev-zero: it's how it's always been done.
-12:27 <@Cardoe> dev-zero: since we decide everything as a group
-12:27 <@Cardoe> dev-zero: never has there been a decision on anything council "owned" by just one council member
-12:27 < Philantrop> Cardoe: Was that done when I was banned from here?
-12:28 <@Cardoe> Philantrop: yes it was
-12:28 < Philantrop> Cardoe: Ah, ok, thanks.
-12:28 <@Cardoe> Philantrop: I believe the vote was 4-3
-12:28 <@Cardoe> Philantrop: I can look it up if you'd like
-12:28 < Philantrop> Cardoe: Doesn't really matter but thanks.
-12:29 <@dev-zero> Cardoe: is it documented in a meeting summary?
-12:29 < mama> that's about that supposedly nazi response to a nazi blogpost ban?
-12:30 -!- touparx [n=toupar@125.220.139.49] has quit [Client Quit]
-12:30 <@Cardoe> dev-zero: It's documented in the council rules
-12:30 <@Cardoe> The ones that say we decide by a vote
-12:30 < Philantrop> mama: No.
-12:31 <@dev-zero> Cardoe: ah, ok
-12:31 < mama> I still haven't seen that one discussed and voted.
-12:31 <@dev-zero> Cardoe: another issue, btw, did you read my comment to your meeting organization proposal?
-12:33 <@Cardoe> dev-zero: on the ML or where?
-12:33 <@Cardoe> dev-zero: wrt to igli. bring it to vote and we can make it happen.
-12:34 <@Cardoe> dev-zero: however, I think if we +m, it'll be a non-issue
-12:36  * Calchan agrees
-12:38 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Remote closed the connection]
-12:44 -!- hwoarang_ [n=eternity@adsl136-183.kln.forthnet.gr] has joined #gentoo-council
-12:52 < dleverton> trelane: what you're suggesting is a lot like trying to get rid of racism by banishing all the non-white people
-12:54 -!- zmedico [n=zmedico@gentoo/developer/zmedico] has quit [Remote closed the connection]
-12:57 -!- hwoarang [n=eternity@gentoo/developer/hwoarang] has quit [Read error: 110 (Connection timed out)]
-12:57 -!- spatz [n=spatz@unaffiliated/spatz] has quit [Remote closed the connection]
-12:58 <@dev-zero> Cardoe: well, that's fine by me
-12:58 <@dev-zero> Cardoe: yes, on the ml
-12:59 -!- hwoarang_ is now known as hwoarang
-13:04 -!- spatz [n=spatz@unaffiliated/spatz] has joined #gentoo-council
-13:26 -!- Thargor [n=quassel@unaffiliated/thargor] has joined #gentoo-council
-13:57 -!- zmedico [n=zmedico@gentoo/developer/zmedico] has joined #gentoo-council
-14:17 < yngwin> dleverton: no, it's about improving the signal-to-noise ratio by removing the greatest source of noise
-14:17 < ciaranm> greatest source of noise? bonsaikitten?
-14:18 < yngwin> no, you
-14:18 < ciaranm> yes, because i produce noise. pms. devmanual. eselect. just noise.
-14:19 < scarabeus> please not here
-14:20 <@dev-zero> jup
-14:20 < ciaranm> i'm sorry, i find yngwin's implications extremely offensive
-14:20  * yngwin is already finished feeding the trolls :)
-14:21 <@dev-zero> ciaranm: agreed, yes
-14:21 < ciaranm> i don't give a crap whether you like me... but suggesting that nothing useful comes from either me or the people certain trolls like to think is my cabal is going a bit far...
-14:21 <@dev-zero> yngwin: the problem is that many problems in eapi seem to be easy at first glance but they aren't
-14:22 < yngwin> i didnt say that
-14:23 <@dev-zero> trelane: the problem of being a council member is that no matter what you do, some people will hate you afterwards
-14:24 < dleverton> yngwin: trelane agreed with Cardoe when he said "But there's other people that are the problem", and still claimed that Ciaran should be punished for it
-14:24 <@dev-zero> trelane: it's not a general problem of the council that is, but being some kind of lead of something in general
-14:31 -!- graaff [n=graaff@gentoo/developer/graaff] has joined #gentoo-council
-14:31 <@dev-zero> trelane: but since Gentoo is for nearly everyone a fun project and there are only less masochists around, well, then people leave
-14:43 <@Cardoe> what'd I do?
-14:56 -!- reavertm [n=reavertm@gentoo/contributor/reavertm] has joined #gentoo-council
-14:56 <@lu_zero> hi
-15:14 -!- bearsh [n=quassel@80-219-1-239.dclient.hispeed.ch] has joined #gentoo-council
-15:18 <@dev-zero> Cardoe: was that for me? :)
-15:18 <@Cardoe> no
-15:21 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-15:23 -!- alexxy [n=alexxy@gentoo/developer/alexxy] has quit [Remote closed the connection]
-15:26 -!- alexxy [n=alexxy@gentoo/developer/alexxy] has joined #gentoo-council
-15:36  * NeddySeagoon puts his copy of glep 55 on a chair at the back and goes to the shop for beer
-15:38  * fmccor wonders if NeddySeagoon is treating everyone.
-15:39 <@dev-zero> zmedico: around?
-15:39 < zmedico> yeah
-15:39 <@dev-zero> zmedico: did you have time to work on eapi-3 features?
-15:40 < zmedico> not yet, but I've got thistracker bug to track progress: https://bugs.gentoo.org/show_bug.cgi?id=273620
-15:41 < zmedico> hopefully I'll get to working on it pretty quickly
-15:41 < zmedico> I
-15:41 < zmedico> I'd like to :)
-15:43 <@dev-zero> zmedico: ah, neat, thanks
-15:43 -!- Thargor [n=quassel@unaffiliated/thargor] has quit [Read error: 113 (No route to host)]
-15:43 < zmedico> you're welcome
-15:43 <@lu_zero> ^^
-15:55 <@Cardoe> zmedico: how's it coming?
-15:55 < NeddySeagoon> fmccor, I can't carry that much beer and I'm walking
-15:56 < zmedico> Cardoe: haven't really started yet but it shouldn't be long once I get rolling
-15:57 < zmedico> having that tracker bug, maybe some people will pitch in and help :)
-15:58 <@lu_zero> fine
-15:58 < zmedico> that guy who filed those bugs has been really helpful
-15:58 <@Cardoe> zmedico: cool
-15:59 < fmccor> :(
-16:00 <@lu_zero> fmccor ?
-16:00 <@dertobi123> heya
-16:00 <@lu_zero> hi dertobi123
-16:00 < fmccor> lu_zero, In response to NeddySeagoon
-16:00 <@dertobi123> hi luca :)
-16:00 <@Betelgeuse> here
-16:00 <+tanderson|na> Cardoe: you're going to be here?
-16:01 <@dev-zero> ready?
-16:01 <+tanderson|na> I'm here
-16:02 -!- ABCD [n=ABCD@wikipedia/ABCD] has joined #gentoo-council
-16:02 <@dev-zero> good
-16:02 -!- Irssi: Topic: -: Next Meeting: June 11 20:00 UTC
-16:02 -!- Irssi: Topic: +: Meeting started
-16:02 -!- dev-zero changed the topic of #gentoo-council to: Meeting started || Agenda is here: http://dev.gentoo.org/~dev-zero/council/meeting-agenda-20090611.txt
-16:02 <@dertobi123> ulm: around?
-16:02 <@ulm> yep
-16:02 <@dertobi123> aye
-16:02 <@dev-zero> roll call please
-16:02 <@dev-zero> here
-16:02  * lu_zero is here as well
-16:02 <@leio> here
-16:02 <@ulm> still here :)
-16:02 <@dertobi123> <-
-16:02 <@Cardoe> tanderson|na: yeah I'm here.
-16:02 -!- mode/#gentoo-council [+m] by Cardoe
-16:03 <+tanderson|na> Cardoe: k, now I can just idly watch what's going on :P
-16:03 -!- You're now known as tanderson
-16:03 <@Cardoe> We're all here.
-16:03 <@dev-zero> and I assume Betelgeuse is still here
-16:03 <@Cardoe> dev-zero: you made the agenda.. call the first item.
-16:03 <@dev-zero> good, let's start
-16:04 <@dev-zero> EAPI-3 progress
-16:04 <@Betelgeuse> \o/
-16:04 <@dev-zero> there's no progress so far
-16:04 -!- mode/#gentoo-council [+v zmedico] by Cardoe
-16:04 -!- mode/#gentoo-council [+v ciaranm] by Cardoe
-16:04 <@dev-zero> but Zac provided a tracker bug
-16:04 <@dev-zero> https://bugs.gentoo.org/show_bug.cgi?id=273620
-16:04 <@Cardoe> any pkgcore people send me a query
-16:04 <@dev-zero> progress in portage, that is
-16:05 -!- milobit [n=milobit@barbossa.ns-linux.org] has joined #gentoo-council
-16:05 <@dev-zero> Cardoe: I don't think we agreed on moderation, but it's ok
-16:05 <+ciaranm> paludis is good to go whenever
-16:05 <@dev-zero> ciaranm: so, next release will contain eapi-3 support?
-16:06 <@dev-zero> ciaranm: or are you waiting on portage's implementation of certain things to be compatible?
-16:06 <+ciaranm> dev-zero: i'm not putting a release out with eapi 3 stuff enabled until portage is done
-16:06 <@Betelgeuse> well you can't claim eapi-3 support before it's approved
-16:06 <+tanderson> Weren't we going to wait until portage was done to see if portage would get everything?
-16:06 <@Betelgeuse> doubtful we will do that without Portage support but could of course
-16:06 <+tanderson> "pending portage support in time" was the phrase iirc
-16:07 <+ciaranm> we have eapi 3 support enabled but we've marked the eapi config file for 3 as noinst, so it'll be used for test cases etc but not actually be installed
-16:07 <@Cardoe> dev-zero: we had 3 in favor and 2 against. 2 people never commented
-16:07 <@Cardoe> dev-zero: oops. sorry 3 vs 3
-16:08 <@Cardoe> 1 person never commented
-16:08 <@Cardoe> leio
-16:08 -!- maekke [n=maekke@gentoo/developer/maekke] has joined #gentoo-council
-16:08 <@leio> Maybe it should have been discussed in gentoo-council to keep up during my temporary busier times. I am from the camp to moderate when necessary only
-16:09 <@Cardoe> leio: it was discussed on gentoo-council, gentoo-dev and I e-mailed it to the council members individually
-16:09 -!- mode/#gentoo-council [-m] by Cardoe
-16:09 <@dertobi123> zmedico: so we can expect some progress within the next 2 weeks (for next meeting)? how's your recruit doing?
-16:09 <@Cardoe> Well then.. moderation loses.. 4 to 3
-16:09 <@Cardoe> Ok. Well we've covered EAPI-3..
-16:10 <@Cardoe> Default ACCEPT_LICENSE is the next item on the list.
-16:10 <@dev-zero> Cardoe: just a second, please
-16:10 <@dev-zero> Cardoe: there's a minor issue concerning implementation of eapi-3
-16:10 <@Betelgeuse> Cardoe: I don't remember seeing any individual mails?
-16:10 <@dev-zero> which needs coordination of the pm devs
-16:11 <@Cardoe> Betelgeuse: it was sent to the council@gentoo.org alias which e-mails each of you guys individually.
-16:11 <@leio> for me council alias is much better than individual, ftr
-16:11 <@dev-zero> namely the vdb entry for the slot-dep-operators
-16:11 <+ciaranm> zmedico: since you're around... what dev-zero is talking about is the implementation of := deps. did you see the stuff about how to implement that for saving to vdb?
-16:11 <+zmedico> dertobi123: yeah, I expect to get started on it myself and make some significant progress before the next meeting. not sure about recruits but we'll see.
-16:11 <+ciaranm> zmedico: rewriting foo/bar:= to foo/bar:=1 at install time, that is
-16:11 <@dertobi123> zmedico: great :)
-16:12 <@Cardoe> dev-zero: you said it yourself. Its something for the pm devs to discuss
-16:12 <@Cardoe> Not the council
-16:12 <@Cardoe> moving on folks
-16:12 <@dev-zero> Cardoe: it's something we have to coordinate
-16:12 <@Cardoe> dev-zero: We're technical people. Not baby sitters to watch people talk.
-16:12 <@dev-zero> Cardoe: make them aware of it is sufficient, yes
-16:13 <@Cardoe> They're aware. And they're talking.
-16:13 <@Cardoe> Moving on
-16:13 <@dev-zero> good, next point
-16:13 <+zmedico> ciaranm: I had just assumed that it would collapse to a normal slot dep bug the :=slot seems good
-16:13 -!- igli [n=igli@fu/coder/igli] has joined #gentoo-council
-16:13 <@dev-zero> ACCEPT_LICENSE
-16:13 <@Cardoe> dev-zero: please include the proposed the default in the chat log
-16:14 <@dev-zero> then I need a sec to dig it out
-16:14 <@leio> * -@EULA
-16:14 <@dev-zero> jup
-16:14 <@dev-zero> that was it
-16:14 -!- graaff [n=graaff@gentoo/developer/graaff] has quit ["Leaving"]
-16:15 <@dev-zero> does someone not want that to be the default?
-16:15 <@leio> zmedico: that will work as far as portage is concerned, right?
-16:15 -!- WilliamH [n=william@gentoo/developer/williamh] has joined #gentoo-council
-16:15 <@ulm> dev-zero: i'm a bit sceptical about the -EULA part
-16:15 <+zmedico> leio: yeah, it's a new EAPI and so we can change syntax as necessary
-16:15 <@lu_zero> ulm why?
-16:15 -!- The_Paya [n=the_paya@gentoo/developer/thepaya] has quit [Read error: 110 (Connection timed out)]
-16:16 <@leio> zmedico: it's what?...
-16:16 -!- Arfrever [n=Arfrever@gentoo/developer/arfrever] has joined #gentoo-council
-16:16 <+zmedico> leio: oh, * -@EULA
-16:16 <+zmedico> that seems fine
-16:16 <@ulm> lu_zero: eulas are not legally binding in most countries, so it's sort of pointless to exclude these packages
-16:16 <@ulm> but IANAL
-16:16 <+zmedico> leio: just have to make sure the @EULA group is populated
-16:17 <@dev-zero> ulm: true, but I'd rather be on the safe side
-16:17 <@leio> ok, then I have nothing against it, as long as users can have ACCEPT_LICENSES="*" in their make.conf and have everything accepted
-16:17 <@Betelgeuse> ulm: Better to be aware that it's bad upstream stuff.
-16:17 <+zmedico> leio: yeah, seems good
-16:17 <@lu_zero> we could leave a commented line with * -@EULA
-16:17 <@dev-zero> ulm: and as pointed out by some it's questionable how that end-user in EULA should work in the *nix world anyway
-16:17 -!- candybar [n=foo@unaffiliated/candybar] has joined #gentoo-council
-16:18 <@ulm> dev-zero: i don't have a very strong opinion on it
-16:18 <@dev-zero> lu_zero: I'd not do that, it's then rather taken as an example
-16:19 <@lu_zero> both should fit for me
-16:19 <@dev-zero> ok then
-16:20 <@dev-zero> decision is then: have ACCEPT_LICENSES="* -@EULA"
-16:20 <@dev-zero> is that correct?
-16:20 <@leio> yes
-16:20 <@lu_zero> yup
-16:20 <@dertobi123> yep
-16:20 <@dev-zero> yes
-16:20 <@ulm> yes
-16:20 <@dev-zero> ok, next item
-16:20 <@dev-zero> Bash-4 in EAPI-3
-16:21 <@dev-zero> some already commented it
-16:21 <@dertobi123> simply put no for the reasons stated by several people on -dev
-16:21 <@dev-zero> I'd second that
-16:21  * lu_zero is against that as well
-16:21 <+tanderson> dertobi123: would you state them here for completeness? :)
-16:22 <@dertobi123> "I'm against re-opening the feature list for EAPI-3, let's get EAPI-3
-16:22 <@dertobi123> finally implemented and put this on the agenda for EAPI-4. I don't see
-16:22 <@dertobi123> the pressure to allow bash-4.0 stuff now."
-16:22 <@Cardoe> I was already in favor of ACCEPT_LICENSES="* -@EULA" for the record.
-16:22 <+tanderson> dertobi123: thanks
-16:22 <@Cardoe> I'm against bash-4 in EAPI-3 as well
-16:22 <@dev-zero> tanderson: for me it's basically the same reason
-16:22 <@Betelgeuse> I am against bash-4.
-16:22 <@leio> I'm in favour or re-opening feature list, I'm against bash-4 in EAPI-3
-16:23 <@ulm> ^^ same for me
-16:23 <@ulm> re-open for zero-cost features
-16:23 <@dev-zero> good, since the question was about bash-4 in eapi-3 and re-opening the feature list a requirement I think we have decision
-16:24 <@Betelgeuse> Re-open only for features with PMS text and Portage patches submitted.
-16:24 <+ciaranm> and this is where decisions go to die
-16:24 <@Betelgeuse> But I still don't see the much reason to do that. There's no reason that EAPI 4 will have to take ages.
-16:24 <@ulm> Betelgeuse: or already implemented in portage ;)
-16:25  * dertobi123 sighs ... not once again, please
-16:25 <@dev-zero> ok, next item
-16:25 <@leio> anyway, the official request from the council to put on agenda list back in june 1st was
-16:25 <@leio> Please vote on:
-16:25 <@leio> * Temporary unlocking of list of features of EAPI="3"
-16:25 <@leio> * Allowing bash-4.0 features in EAPI="3" ebuilds
-16:25 <@leio> * Temporary disallowing of adding bash-4.0 features to ebuilds in
-16:25 <@leio>   gentoo-x86 repository until ${TIME:-1 month} has passed since
-16:25 <@leio>   stabilization of =app-shells/bash-4.0* on all architectures.
-16:26 <@ulm> leio: these are three separate points?
-16:26 <@Betelgeuse> I unloacking, no IN EAPI 3, no bash-4.0 in tree at all before council approval.
-16:26 <@Betelgeuse> s/I/No/
-16:26 <@Cardoe> I'm opened to re-opening EAPI-3 as long as all requests for additions contain documentation patches and Portage patches. Otherwise, no.
-16:26 < Arfrever> Maybe minimal supported version of bash shouldn't at all be specified in PMS?
-16:26 <@lu_zero> I second Betelgeuse
-16:27 <@dev-zero> I'm against reopening and therefore no bash-4 in eapi-3 and therefore no bash-4 in the tree
-16:27 <@Betelgeuse> Arfrever: PMS specifies what ebuilds can expect from the env.
-16:27 < Arfrever> There are many ebuilds using += ...
-16:27 <@ulm> yes for unlocking, no for bash-4 features in EAPI 3
-16:27 <@dertobi123> i second Betelgeuse, too
-16:29 <@leio> Cardoe, ulm and leio are in favour of re-opening EAPI-3 (some with conditionals); Betelgeuse, lu_zero, dev-zero and dertobi123 are against re-opening EAPI-3.
-16:29 <@ulm> Arfrever: open a bug so they can get fixed
-16:29 <@leio> 4 to 3, lets move on
-16:29 <@Cardoe> 4 to 3.. done. move on
-16:29 <@dev-zero> good
-16:29 < Arfrever> Betelgeuse: Anyway, patches for Portage should be sufficient. Only small amount of people understand file format used by PMS sources.
-16:30 < Arfrever> ulm: I would rather open a bug for PMS being out-of-date...
-16:30 <@lu_zero> Arfrever could work
-16:31 <+ciaranm> pms accurately reflects the official decision made concerning bash-3...
-16:31 <@Betelgeuse> Should have a progmmatically usable bash parser for repoman.
-16:32 <@leio> Arfrever: bash-3.2 and such could be more controversial. bash-4 is pretty clear - it isn't even stable yet, people are saying it only recently still had bugs blocking stabilization and maybe still do, etc
-16:32 < Arfrever> leio: bash-4 works very stably (it only lacks stable keywords).
-16:33 <@lu_zero> Arfrever does it solve something that makes it a necessity?
-16:33 <@leio> I don't particularly agree with this being tied to EAPI's, but EAPI-3 was voted to be still feature-locked, lets move on. Maybe a different discussion approach (untied to EAPI-3) could lead to some interesting discussion
-16:33 <@leio> (on the mailing list)
-16:33 <@dev-zero> jup, agreed
-16:33 < Polynomial-C> The anount of bugs reported to the bash-ml decreased significantly in the last couple of weeks
-16:33 <@leio> meanwhile I suggest people interested to push bash-4 stable
-16:34 <@Betelgeuse> And they can work on GLEP 55 too.
-16:34 < Arfrever> lu_zero: ${variable^^} and associative arrays would allow to solve some problems in some ebuilds maintained by me.
-16:34 < igli> ydiw
-16:34 <@lu_zero> Arfrever good to know please document it and let's start a discussion in ml =)
-16:34 <@ulm> leio: yes, i wouldn't even think about allowing it in the tree before bash-4 is stable on all major archs
-16:34 <@leio> Next topic: Define EAPI development/deployment cycles
-16:35 <@Betelgeuse> For EAPI there's only one bottleneck atm and it's getting Portage to have code.
-16:35 < Arfrever> lu_zero: So I should copy a part of bash-4's ChangeLog/NEWS file?
-16:35 <@Betelgeuse> Otherwise it seems to work fine.
-16:35 <@dev-zero> Arfrever: no, how it can be used in ebuilds
-16:35 <@lu_zero> Arfrever a link probably could fit =)
-16:36 <@dertobi123> leio: that's a non-topic for now from my pov. i'd like to see some discussion on-list before we can discuss something in our meeting.
-16:36 <@dev-zero> Arfrever: or how you'd use it in your ebuilds
-16:37 <@leio> dertobi123: pretty much the same here, just trying to speed things up in the spirit of Cardoe and you getting to sleep and me getting back to doing useful project proposal and code writing :)
-16:37 < Arfrever> dev-zero: ${variable^^} and ${variable,,} allow to avoid using  'tr [[:lower:]] [[:upper:]]' / 'tr [[:upper:]] [[:lower:]]'
-16:37 <@dev-zero> Arfrever: on ml please
-16:37 <@dev-zero> ok, next item
-16:37 <@dev-zero> it's not on the agenda, I'm afraid
-16:38 <@Cardoe> Here it goes then
-16:38 <@Cardoe> igli was banned in this channel by a council member.
-16:38 <@Cardoe> user-rel has asked us to review it
-16:38 <@lu_zero> why he was banned?
-16:38 < Arfrever> dev-zero: So if I provide (in mailing list) examples about using bash-4 features in ebuilds, there will be a chance for repeating voting on this proposition?
-16:38 <@Cardoe> so if anyone has any comments on whether he should be banned or not.
-16:39 < trelane> (assuming this is based on rules of order I'd like to request a few minutes of the coucil's time if permissible on this issue)
-16:39 <@Cardoe> Arfrever: yes.
-16:39 <@Betelgeuse> Cardoe: do you have logs?
-16:39 <@Cardoe> Betelgeuse: I don't
-16:39 <+tanderson> I do.
-16:39 <@dev-zero> and I have excerpts
-16:39 <@lu_zero> provide them please ^^
-16:39 <@dertobi123> ack ...
-16:39 <+tanderson> h/o
-16:39 <@Cardoe> Also council members should consider +q vs +b
-16:40 <@Cardoe> While we wait for the logs...
-16:40 <@dev-zero> http://dev.gentoo.org/~dev-zero/council/igli.txt
-16:40 <@lu_zero> I'd also consider having #-council +m while not used
-16:41 < igli> hmm
-16:41 <@leio> I'd like the channel to stay as a place to freely interact with your elected council members while not in use for other purposes
-16:41 <@dev-zero> jup, me too
-16:41 <+tanderson> http://dev.gentoo.org/~gentoofan23/%23gentoo-council.06-10.log
-16:41 <@Betelgeuse> dev-zero: I don't see the actual ban there.
-16:41 <@Cardoe> I'd be against +m while its not used
-16:41 <@dertobi123> leio: agreed ...
-16:41 <+tanderson> leio: ++
-16:41 <@Betelgeuse> tanderson: permissions
-16:41 <@dertobi123> Betelgeuse: /me too
-16:42 <+tanderson> Betelgeuse: gah
-16:42 <@lu_zero> I saw it squatted lots of times
-16:42 <@lu_zero> but I didn't care much
-16:42 <@leio> The ban happened while igli was not in the channel
-16:42 <@lu_zero> tanderson please make it accessible ^^
-16:42 < igli> yeah 8 hours later.
-16:42 <+tanderson> Betelgeuse: fixed
-16:42 <@dev-zero> Betelgeuse: ok, added
-16:42 <+tanderson> lu_zero: yeah, irssi likes saving it -rw------- apparently
-16:42 <@dertobi123> leio: quite useless ban, then ...
-16:43 <@dev-zero> not really, maybe I can explain
-16:43 <@dertobi123> you should
-16:43 <@dev-zero> good
-16:43 < igli> I said an awful lot more than that very partial excerpt
-16:43 <@dev-zero> the point is that while discussing stuff he repeatedly insults people (whether willingly or not)
-16:43 <@dev-zero> igli: that's true
-16:43 <@dev-zero> igli: this is why there's the log from tanderson and the excerpts from me
-16:44 <+tanderson> igli: the full log is probably a better indication of what went on :)
-16:44 < igli> and others were far more off-topic afaik, tho i have several on /ignore ofc
-16:44 < igli> indeed
-16:44 < igli> and having this sprung on me doesn't exactly make me feel like there's an impartial process going on, for the record.
-16:44 <@dev-zero> the problem is not being off-topic, the problem is that you insult people repeatedly
-16:45 <@Cardoe> I'd say this channel should be opened while not used by council meetings. When used by council meetings, anyone that proves themselves distruptful can find themselves on the +q list. I'm against banning the very people we're suppose to work with and decide on issues.
-16:45 < igli> I insult a lot less than some others. and only when I am being insulted repeatedly
-16:45 <@Betelgeuse> I don't see the council having to be impartial.
-16:45 <@dev-zero> and the reason why I banned him while not being around is because he keeps showing on and doing it again and again
-16:45 <@Betelgeuse> We are not judges.
-16:45 <@dev-zero> Cardoe: fully agree
-16:45 <@Betelgeuse> Cardoe: seems fine
-16:45 < igli> are you not judging my behaviour atm?
-16:45 <@Betelgeuse> dev-zero: As there wasn't anything pressing it would have been prudent to consult with others first.
-16:46 <@Betelgeuse> So we don't have to use council meeting time on these types of things.
-16:46 <@dev-zero> Betelgeuse: true
-16:46 <@dertobi123> Cardoe: agreed
-16:46 <@Cardoe> trelane wishes to say something on igli's behalf. So hopefully, he can say his piece and this won't spiral out of control.
-16:46 <@dev-zero> Betelgeuse: and I'm sorry for that
-16:46 < igli> please note that trelane does not represent me
-16:46 <@Cardoe> You know what. Betelgeuse is right.
-16:46 <@ulm> Cardoe: i agree too
-16:46 <@Cardoe> let's take this to e-mail.
-16:46 <@Cardoe> and be done with it.
-16:46 <@lu_zero> ok
-16:47 <@Cardoe> next item
-16:47 < igli> I thought it had been dealt with in #-user-rel <end>
-16:47 < trelane> Cardoe: I'm fine with that.  Would you mind submitting my comments as my comments to the -council list then?
-16:47 <@Cardoe> trelane: you can e-mail council@gentoo.org if you think it's relevant.
-16:47 <@Betelgeuse> Let's just ack that this wasn't handled in the best way and hopefully the parties involved can get the matter solved.
-16:47 <@dev-zero> igli: it's still in-progress
-16:47 < igli> fine dev-zero, i refer you to what i said in there then.
-16:48 <@Betelgeuse> If there's actually something to vote on then we can get back to the issue.
-16:49 <@Cardoe> ok. any other topics?
-16:49 <@dev-zero> well, next issue would be the EAPI development/deployment cicle
-16:49 <@dev-zero> Cardoe: you said you don't want to have it discussed here
-16:49 <@dev-zero> dertobi123: you made some good comments already
-16:49 <@dev-zero> do we want to discuss it here or not?
-16:49 <@dertobi123> 22:36 <@dertobi123> leio: that's a non-topic for now from my pov. i'd like to see some discussion on-list before we can discuss something in our meeting.
-16:50 <@dertobi123> it would be useful to discuss this on-list to get it rolling
-16:50 <@Betelgeuse> I already said my opinion about EAPI development.
-16:50 <@Betelgeuse> As discussing process won't get code to Portage any faster.
-16:50 <@leio> Maybe we should select someone to make sure the discussion is actually happening
-16:50 <@Betelgeuse> Time better spent coding the actual features.
-16:50 <@dertobi123> as for development ciaranm described a quite useful process it seems which we could try for eapi-4
-16:50 <@dev-zero> leio: agreed
-16:50 <@leio> if there is any to be had
-16:50 -!- igli [n=igli@fu/coder/igli] has left #gentoo-council ["it's not the code it's the borked process. *disgusted at the blatant politicking*"]
-16:51 <@dev-zero> ^^ no comments
-16:51 <+ciaranm> actually... one thing...
-16:51 <@leio> eapi-3 process seemed fine to me with two exceptions - implementation time and too many different places things got recorded
-16:51 < trelane> dev-zero: I've handled firearms for a long time, I can correctly identify when someone has shot themselves in the foot.
-16:51 <@dev-zero> leio: jup, noted
-16:51 <@Cardoe> We can give ciaranm's suggestion a go for eapi-4. But otherwise that all depends on the list.
-16:51 <+ciaranm> i think we might have to move pms off gentoo infrastructure... so what i said, but github instead of bugzilla?
-16:52 <@Cardoe> We keep trying to discuss HOW to do EAPI development.. the issue is writing code.
-16:52 <@dertobi123> ciaranm: for what reason?
-16:52 <+ciaranm> i suspect most people have accounts on github already, and they do bug tracking now...
-16:52 <@Cardoe> discussing and debating everything won't implement code
-16:52 <@ulm> ciaranm: why?
-16:52 <@leio> ciaranm: What has GIT and github to do with anything of that?
-16:52 <+ciaranm> the short story, bug 273759
-16:52 -!- The_Paya [n=the_paya@190.189.19.103] has joined #gentoo-council
-16:52 < Willikins> ciaranm: https://bugs.gentoo.org/273759 "I should be able to edit PMS bugs"; Gentoo Infrastructure, Other; RESO, NEED; ciaran.mccreesh@googlemail.com:infra-bugs@g.o
-16:53 <+ciaranm> the longer version: when we moved to gentoo infra, i was given various assurances by robbat2
-16:53 <@ulm> i'm strictly against this, PMS is central to Gentoo and should be hosted on our infrastructure
-16:53 <+ciaranm> among those being that i wouldn't have to worry about infra dicking around with permissions, privs etc
-16:53 <@dev-zero> ulm: but then all people working on it should have appropriate access
-16:53 <+ciaranm> it looks like infra's no longer prepared to stick to that, so rather than get into an argument with them i think it'd be easier if we just moved elsewhere
-16:53 <@dertobi123> ulm++ and dev-zero++, too
-16:53 <@ulm> dev-zero: that's not a reason to move it away from our infra
-16:53 <+tanderson> ciaranm: just wait a bit for infra to sort things out
-16:54 <+ciaranm> infra have decided that, contrary to what was promised when we moved to gentoo hardware, they're going to screw us around. i don't have time to deal with that.
-16:54 <@leio> I'm not sure ciaranm should have the access that gives him the ability to decide if bugs and PMS requests are valid or not
-16:54 <@Betelgeuse> I can switch bugzilla prives if we vote here.
-16:54 <@dev-zero> ulm: well, we've always been a project with non-developer contributors, moving the project to a neutral platform would guarantee access for everyone
-16:55 <+ciaranm> Betelgeuse: they've already been switched once for that, and they got removed with no-one telling me
-16:55 <+ciaranm> Betelgeuse: oi
-16:55 <+ciaranm> gah
-16:55 <@dev-zero> ulm: but in general I agree with you that PMS is a central project for Gentoo and should be hosted on our infra
-16:55 <+ciaranm> Betelgeuse: i'm sceptical about keeping things on gentoo infrastructure if it's just going to lead to this kind of mess again
-16:55 <@ulm> dev-zero: the access problems can be sorted out
-16:55 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)]
-16:55 <@dertobi123> ulm: exactly.
-16:55 <@Betelgeuse> ciaranm: Well if an infra member defies a council decision without having a security etc reason then they need a devrel bug filed.
-16:55 <@dev-zero> ulm: sure, we should just avoid the bureaucracy needed now
-16:55 < reavertm> dev-zero: everyone can clone and send patches already btw
-16:56 <@dev-zero> reavertm: yes, I know
-16:56 <@lu_zero> still I'm not sure what makes one repo different to another
-16:56 <+ciaranm> leio: i already have push access to the pms repo... what's the big deal with bugzilla? not like there's not a reopen button, and the council already came up with a process for what to do if we can't reach agreement on a bug
-16:56 < solar> FYI robbat2 is researching how any perms might of changed. KingTaco said at one point there were perms granted but also noted that any bad behaviors or abuse would lead to perm removal. Nobody in infra so far says there have been any removals.
-16:57 <+ciaranm> solar: well, at one point i could close pms bugs, and now i can't
-16:57 < solar> I don't care about that
-16:57 <@ulm> ciaranm: but you still have commit access to the repo, or did this also vanish?
-16:57 <@leio> ciaranm: sounds good too if gentoo developers are monitoring pms-bugs@ I guess
-16:57 < reavertm> ciaranm: maybe you need to send ebuild quiz :)
-16:57 <+ciaranm> ulm: i did a week ago
-16:57 <@Cardoe> reavertm: unnecessary
-16:57 <+ciaranm> leio: i hope they are...
-16:57 < solar> point is you have not shown where perms were granted. And any user claiming I should have more perms than I have now.. Is treated the same way
-16:57 <@ulm> Cardoe: and any evidence that you don't anymore?
-16:57 <@ulm> sorry
-16:58 <@ulm> ciaranm: ^^
-16:58 < solar> so why don't you either work with us as requested. Or wait till it's sorted out
-16:58 <+ciaranm> ulm: i'm assuming i still have git repo access. it's bugzilla that's the problem.
-16:58 <@Betelgeuse> Wasn't this already discussed at some point and someone was supposed to be watching the access for possible misuse?
-16:58 <+ciaranm> Betelgeuse: yup
-16:58 <+ciaranm> Betelgeuse: and considering the number of people watching the pms alias...
-16:59 <+ciaranm> solar: the only question is why permissions that i had mysteriously vanished
-16:59 <@Cardoe> ok. this looks like silly politics with someone screwing with ciaranm's access and a non-council issue really. Just fix it and lets move on.
-16:59 <@dertobi123> Cardoe++
-16:59 <+ciaranm> Cardoe: the "fix it" bug's been closed off without it being fixed
-16:59 <@ulm> Cardoe: +1
-16:59 < solar> I don't care about that question. that is not what the bug was filed for.
-16:59 <@dev-zero> Cardoe: fully agree
-16:59 <@Betelgeuse> Ok let's vote on turning on editbugs back on. This means ciaranmn can edit bugs in all products.
-16:59 <@Betelgeuse> It will be revoked if misused like usual.
-16:59 <@dev-zero> jup
-16:59 <@lu_zero> ok
-16:59 <@dev-zero> I vote yes
-16:59 <@Betelgeuse> We already give editbugs to potential new bug wranglers etc.
-16:59 < solar> if they are lost. Then how did that happen
-16:59 <@Betelgeuse> I vote yes.
-17:00 <@dertobi123> yes too
-17:00 <@ulm> yes
-17:00 <@Cardoe> Just give him the access.
-17:00 < solar> no. You are not going to bypass infra procedures
-17:00 <@leio> who's following that mail alias with bugzilla means?
-17:00 <@lu_zero> solar which is the procedure?
-17:00 <@Betelgeuse> solar: I already have the power to do that as far as I know.
-17:00 <@leio> (err, not alias, mail address)
-17:00 < solar> what did I say at first? robbat2 is researching it
-17:00 <@dev-zero> Betelgeuse: just do it
-17:00 < solar> no
-17:00 <@Betelgeuse> solar: The standing policy has been to give users who do a lot of bugzilla useage powers.
-17:00 <+ciaranm> i had editbugs way before i became a dev, btw
-17:00 <+ciaranm> on everything, not just pms stuff
-17:02 <@Betelgeuse> solar: If you have some written policy somewhere please post a link.
-17:02 <@Betelgeuse> For now editbugs are back. Infra is free to do research on PMS restricted powers of course.
-17:02 <+ciaranm> thanks
-17:02 <@leio> it seems ciaranm just needs to point infra people to some supposedly already happened decision by council that he should have such access, to solve that bug. Of course another option is to give a new access if desired
-17:02 < solar> Betelgeuse: you just abused your perms
-17:03 < solar> and you should not of done that. That is not why you had bugzilla perms
-17:03 <@Cardoe> Do we have any real topics to discuss anymore?
-17:03 <@leio> apparently not, that were on agenda, anyway
-17:03 <@dertobi123> as for the eapi-development stuff can we agree on the process described by ciaranm on -dev list?
-17:03 <@dev-zero> I'd say so, yes
-17:04 <@Betelgeuse> solar: I have been giving possible recruits editbugs for ages with infra blessing.
-17:04 <@dertobi123> for eapi-deployment i'll try to keep the discussion going on
-17:04 < Arfrever> solar: In which bug did he abuse his permissions?
-17:04 <@dev-zero> dertobi123: cool, thanks
-17:04 <@Betelgeuse> solar: some issue.
-17:04 <@Betelgeuse> s/some/same/
-17:04 < solar> Betelgeuse: you oversteped the bounds.
-17:04 <@Betelgeuse> solar: If you think so feel free to vote inside infra.
-17:04 <+ciaranm> i wasn't aware there were bounds on a council vote
-17:04 <@dev-zero> jup, me neither
-17:04 <@Betelgeuse> solar: And present a new policy to replace GLEP 39 for developers.
-17:05 <@Betelgeuse> Or recruiting.
-17:05 < solar> This is not a normal case in any such way
-17:05 <@dev-zero> it would be nice to know who removed those perms in the first place without announcement anyway
-17:05 <@lu_zero> or why
-17:06 <@Betelgeuse> I will find in the logs when this was first discussed.
-17:06 <@dev-zero> ok then
-17:07 <@Betelgeuse> If I can figure out proper grep terms.
-17:07 <@dev-zero> meetings is over
-17:07 <@leio> I think solar's point is something along the lines of the latest proven evidence related to this having been the council or devrel decision to revoke ciaranm developer privileges and force-resign
-17:08 <+ciaranm> leio: i was given those privs way after that
-17:08 <+ciaranm> leio: as you can see by looking at those pms bugs i closed last year
-17:08 <@lu_zero> ciaranm and then when they got removed?
-17:08 < spatz> solar just wants you to prove that and be done with it
-17:08 <@leio> do you remember by whose decision were they given back? Is there a record of it?
-17:09 <+ciaranm> lu_zero: sometime after that. i didn't notice for a while since we don't generally close pms things often until new EAPIs come along
-17:09 <@leio> I'm not sure I care either way as long as you are being monitored as told, but these things would seem to speed things up, which you seem to wish
-17:09 < solar> I wanted to allow Robbat2 to do his research. Now that you went and messed with perms. Timestamps in bugzilla has changed.
-17:09 < solar> now I gotta have a BS meeting about if Betelgeuse should be allowed to retain any extra perms in bugzilla
-17:09 <@lu_zero> sigh...
-17:10 <@leio> ok, then I thought wrong above
-17:10 <+ciaranm> leio: unfortunately a lot of it's in private emails, including the part where i was promised that people wouldn't mess around with permissions like this
-17:10 <@lu_zero> ciaranm looks like you were expecting that
-17:11 <+ciaranm> lu_zero: when we moved, yes, i was expecting certain people in infra to dick around. i was given promises that they wouldn't. unfortunately, i can't provide those emails since they're private.
-17:11 <@lu_zero> ciaranm bad =\
-17:11 < NeddySeagoon> ciaranm, there was discussion here before PMS moved
-17:11 <@dev-zero> anyway, the decision to give ciaranm back the permissions where backed by the councils decision
-17:11 < solar> One thing is for sure. Nobody in infra is going to just randomly remove perms
-17:12 <@lu_zero> dev-zero you have the link to the council log about that?
-17:12 <@lu_zero> (just for reference)
-17:12 <@dev-zero> lu_zero: we just did, above?
-17:12 <@dev-zero> lu_zero: I was referring to that
-17:12 <@lu_zero> I mean before
-17:12 <@Betelgeuse> this is what I found so far bug nothing better yet: <04.05.2009 14:23> < ciaranm> could someone please either tidy up the pms bug list or find out why i'm mysteriously unable to do so yet again?
-17:12 <@dev-zero> lu_zero: no, sorry
-17:13 < solar> that was not in the agenda, there was an open bug in which a team was doing research.
-17:13 -!- The_Paya [n=the_paya@gentoo/developer/thepaya] has quit [Read error: 60 (Operation timed out)]
-17:13 < solar> so sorry but you are mostly all in the wrong here
-17:13 <@lu_zero> and looks like the time is up ...
-17:13 <@dev-zero> jup, I already announced the meeting to be over :)
-17:13 < solar> and I hope that our devs vote properly for a better council next time around
-17:13 <+ciaranm> *shrug* i don't really mind either way. but if infra decides it's going to ignore the council, i have no objections to moving to github if that'd work for everyone else.
-17:13 <@lu_zero> Betelgeuse you used to be less rushy =P
-17:14 <@dev-zero> solar: thanks for the flowers then
-17:14 < NeddySeagoon> ciaranm, when did you notice your permissions had changed ?
-17:15 <@Betelgeuse> Now let's see if I can search bugzilla for bugs marked as resolved by ciaranm but not reported by him
-17:15 <@dev-zero> ok, time's definetely up
-17:15 <+ciaranm> NeddySeagoon: few months back
-17:15 <@leio> it seems some topic popped up suddenly without it being on the agenda, and it even went as far as to an uninformed quick vote
-17:16 <@dev-zero> leio: jup, it did during the eapi devel/deploy topic
-17:16 < NeddySeagoon> ciaranm, so another day or so while -infra search logs is nethier here nor there.
-17:16 <@leio> so why did we vote on this uninformed exactly? Something to keep in mind while trying to reform things then
-17:17 -!- Irssi: Topic: -: Meeting started | Agenda is here: http://dev.gentoo.org/~dev-zero/council/meeting-agenda-20090611.txt
-17:17 -!- Irssi: Topic: +: Meeting of June 11 is over | Next Meeting: Thursday June 25 20:00 UTC
-17:17 -!- dev-zero changed the topic of #gentoo-council to: Meeting of June 11 is over || Next Meeting: Thursday June 25 20:00 UTC
-17:17 <+ciaranm> NeddySeagoon: the issue's about whether i have to get involved with the gentoo infra power-play or not. i only agreed to move to gentoo infra because i was assured that i wouldn't have to worry about any of that mess.
-17:17 <@Betelgeuse> https://bugs.gentoo.org/show_activity.cgi?id=217492
-17:17 <@Betelgeuse> This shows ciaranm having them at least a year ago
-17:17 <@dev-zero> leio: because there were some people agreeing on that and wanted something to happen so people can continue to work
-17:17 < NeddySeagoon> ciaranm, you don't. but they should be given time to look at logs to see who did what and when
-17:18 <@leio> dev-zero: all at the same time as information was trying to be given, yes
-17:18 <@dev-zero> leio: it got fast a little, yes
-17:18 <+ciaranm> NeddySeagoon: the council already voted to give me editbugs, and infra are blocking it. this is exactly the kind of mess i was assured wouldn't happen.
-17:18 <@leio> when did that voting happen, except today?
-17:19 < NeddySeagoon> ciaranm, As solar said, infra are looking into why the perms changed.
-17:20 -!- WilliamH [n=william@gentoo/developer/williamh] has left #gentoo-council []
-17:21 <+ciaranm> NeddySeagoon: sure. and in the mean time, the council voted to give me editbugs, Betelgeuse gave me editbugs and i don't appear to have editbugs.
-17:21 -!- maekke [n=maekke@gentoo/developer/maekke] has quit [Client Quit]
-17:21 <@Betelgeuse> heh clicked the wrong place
-17:21 <@lu_zero> uff
-17:21 <@Betelgeuse> stupid me
-17:22 <+ciaranm> ah, ok, thanks
-17:22 < trelane> Betelgeuse: remind me to never give you a pistol to shoot :/
-17:22 <@lu_zero> ciaranm could you wait a day or two?
-17:22 <@Betelgeuse> trelane: I have used a lot of weapons.
-17:22 <@Betelgeuse> trelane: Mandatory conscription and all.
-17:22 < trelane> Betelgeuse: and the mouse is the only point-and-click interface you have problems with? :)
-17:22 < trelane> aah :)
-17:23 <+ciaranm> lu_zero: sure
-17:23 <@Betelgeuse> Well you can do civil service too but any way.
-17:23 -!- The_Paya [n=the_paya@190.189.19.103] has joined #gentoo-council
-17:23 <@Betelgeuse> ciaranm: ok let's wait a couple of days then
-17:23 <@lu_zero> so you wouldn't mind if they spend some time sorting out what happened
-17:23 <+ciaranm> lu_zero: if they're going to, that's fine. if they're just going to leave it with solar's resolution, then no.
-17:24 <@dev-zero> tanderson: still around?
-17:24 <@Betelgeuse> trelane: I am in a flu so I just misread the edit* privs.
-17:24 < NeddySeagoon> ciaranm, Solar said it was under investigation ... thats not resolved
-17:24 <@Betelgeuse> NeddySeagoon: Then the bug should be open.
-17:24 <+ciaranm> NeddySeagoon: solar's closed off the bug too though
-17:24 <@leio> Betelgeuse: so the timestamps weren't touched or something?
-17:24 < Calchan> ciaranm, you should seriously consider that sometimes shit happens and that not everything is a conspiracy against you
-17:24 <@Betelgeuse> leio: Dunno how it works bug I did change other lines.
-17:25 <@dev-zero> Calchan: he didn't assume that
-17:25 <+ciaranm> Calchan: are we aware of other people's bugzilla privs vanishing?
-17:25 <@Betelgeuse> leio: And it's by now changed probably.
-17:25 < Calchan> ciaranm, invalid point
-17:26 <+ciaranm> Calchan: well, i had privs, and then i didn't, and infra tried to close the bug off without fixing it
-17:26 < trelane> Betelgeuse: swine flu? (suddenly wishing linux had anti-virus...)
-17:26 -!- ssuominen [n=ssuomine@gentoo/developer/ssuominen] has quit [Remote closed the connection]
-17:26 < Calchan> ciaranm, see above
-17:26 <+ciaranm> Calchan: i don't really mind either way if that's what infra wants to do, but if they do, i need to find a new home for pms that's acceptable for everyone
-17:26 <@dev-zero> Calchan: see the bug
-17:26 <@dev-zero> Calchan: the bug got "resolved"
-17:27 < Calchan> dev-zero, so what ?
-17:27 < NeddySeagoon> ciaranm, so gibe infra a wee while to find out what happened
-17:27 < Calchan> let's cool down
-17:27 < NeddySeagoon> give*
-17:27 <+ciaranm> NeddySeagoon: infra were trying to close it off without fixing it until the council intervened
-17:27 < solar> No
-17:27 < spatz> so have an entire council meeting about bugzilla permissions
-17:27 <@dev-zero> Calchan: well, the message in the bug was "ciaran provide info why you had that perms anyway" and not "sorry, we're investigating it"
-17:27 <@lu_zero> spatz the leftovers
-17:28 < solar> anybody that is on #infra should see the chat we were already in the process of having
-17:28 <@Betelgeuse> I need to go sleep to get better.
-17:28 < NeddySeagoon> ciaranm, Wait for -infra to find out what happened and why
-17:28 <@lu_zero> Betelgeuse take care and rest well
-17:28 < Calchan> dev-zero, it's a legitimate request from somebody who obviously didn't know the whole story, does that make it a conspiracy ?
-17:28 < Polynomial-C> spatz, the meeting finished already.
-17:29 <@dev-zero> Calchan: huh?
-17:29 <@dev-zero> Calchan: what request?
-17:29 <@leio> dev-zero: maybe that information should be provided then as asked? When I ask users something I often mark the bug NEEDINFO while waiting for an answer (or an answer telling they can't give one)
-17:29 < hwoarang> get well soon Betelgeuse
-17:29 < spatz> i know that, i was referring to how the meeting was suddenly off the agenda
-17:29 < Calchan> dev-zero, request for providing info
-17:29 <+tanderson> dev-zero: sorta
-17:29 <@dev-zero> Calchan: when the user says "I had foo but then foo vanished"?
-17:30 <@dev-zero> Calchan: did you work in support once?
-17:30 < NeddySeagoon> dev-zero, we see that on the forums :)
-17:30 < Calchan> dev-zero, ah, btw yes
-17:30 <@dev-zero> Calchan: you don't ask "why did you have foo in the first place"
-17:30 <+ciaranm> hey! it was "I had foo, as you can see from this clear evidence, and now I don't, as I can see from not being able to do blah"
-17:30 < yngwin> false analogy
-17:30 < solar> You ask such things when somebody was kicked out of gentoo. dunno what 2.5 times
-17:31 <@dev-zero> tanderson: you might have to proxy for me next time
-17:31 <@dev-zero> solar: it doesn't matter
-17:31 < solar> yes it does
-17:31 <+tanderson> dev-zero: might have to work that out with Cardoe to see if he's going to be missing
-17:31 < solar> it's our job to make sure that we do the right thing.
-17:31 < Calchan> dev-zero, cool down, I was just saying that we should give this thing more importance than it deserves, and just work to solve the matter
-17:31 < NeddySeagoon> ciaranm, yep but the reasoning is missing. Thats what infra are looking at.  Then you may get your foo back
-17:31 < Calchan> s?should/shouldn't/
-17:32 <+ciaranm> NeddySeagoon: only infra have access to that reasoning, afaik
-17:32 <@dev-zero> Calchan: I agree, but closing that bug with a pretty arrogant statement is not how things should work
-17:32 <+ciaranm> NeddySeagoon: from what i've seen of bugzilla on other sites, there's a log of permission changes but it's only accessible to people with superpowers
-17:32 < Calchan> dev-zero, a bitchy dev doesn't a conspiracy make ;o)
-17:32 < solar> and bypassing a team which was doing research is somehow the right thing?
-17:32 < NeddySeagoon> ciaranm, Probably.  Are you suggesting there will not be an honest report ?
-17:32 <@dev-zero> Calchan: I don't talk about conspiracy
-17:33 <+tanderson> just calm down guys, I doubt there's a conspiracy and ciaran will get to do his pms stuff in a day or two
-17:33 <+tanderson> It's really not a big deal at all
-17:33 < Calchan> dev-zero, you're right, I did, but I guess you know what I meant
-17:33  * reavertm agrees
-17:33 <+ciaranm> NeddySeagoon: all i really care about is whether i'm going to have to go through this mess all over again in another few months if i don't find a new home for pms
-17:33 < solar> tanderson: and you can see from the infra chat that there may be a few ways it could of happened. Including user error
-17:33 <+ciaranm> NeddySeagoon: i'd really rather not have to get involved in yet another council / infra power struggle
-17:33 <@dev-zero> Calchan: I talk about infra providing a service and guessing from the comments some let their personal feelings come in their usually nearly perfect way of maintaining stuff
-17:34 < NeddySeagoon> ciaranm, how many times have you lost perms since PMS moved to gentoo hardware ?
-17:34 <+tanderson> solar: true, thanks. I don't think he's done email addr changes in a while however
-17:35 <+ciaranm> NeddySeagoon: once since, and i've also had permissions revoked by infra despite an explicit council order for them not to before we moved pms there, which is why i asked for guarantees before moving pms
-17:35 <@dev-zero> Calchan: and we wouldn't have this whole discussion if people would have handled that request with respect
-17:35 < Calchan> ciaranm, remember that access to gentoo infra is a privilege, so ask nicely and behave adequately and there's no reason you don't get all the access you require to work on pms
-17:35 <+ciaranm> Calchan: i had that access, and it vanished, and infra tried to refuse to give it back
-17:36 <+tanderson> bye guys, my garden needs work. But remember, it'll all get sorted out in the end and it'll likely not happen again
-17:36 -!- You're now known as tanderson|na
-17:36 <+ciaranm> Calchan: which, again, is entirely up to infra, and i'm quite happy to move pms somewhere else that's acceptable to everyone involved if infra decide to do that
-17:36 < NeddySeagoon> ciaranm, so wait for the investigation.  Its no big deal long term.  Nobody is immune for finger trouble, your 'guarantees' won't cover that
-17:37 <+ciaranm> NeddySeagoon: now that the investigation is happening, i'm happy. until the council got involved, though, there wasn't an investigation and it was being brushed under the carpet.
-17:37 <@leio> oh, btw, apparently PMS is not a draft standard of EAPI-0 or something
-17:37 -!- ssuominen [n=ssuomine@i062213.gprs.dnafinland.fi] has joined #gentoo-council
-17:37 < Calchan> ciaranm, and you explained your problem and you got you edit privs back (although it's not there technically you got a positive council vote), no reason to make more fuss about it
-17:37 < reavertm>  please all stop this soap opera, let infra do their investigation
-17:38 <+ciaranm> leio: "or something"? details please?
-17:38 < solar> ciaranm: that is not true at all
-17:38 <@leio> I believe the requirements listed at http://www.gentoo.org/proj/en/council/meeting-logs/20080911-summary.txt have not been met
-17:38 < NeddySeagoon> ciaranm So, let it cool a little.  The only thing I would like to see is a target date for the investigation to complete
-17:38 <+ciaranm> leio: er, all of those were met a long time ago
-17:39 <+ciaranm> NeddySeagoon: like i said, i'm happy
-17:39 <@leio> good, where's the documentation?
-17:39 <+ciaranm> in the pms intro
-17:39 < NeddySeagoon> ciaranm, I've never heard you say that before :)
-17:39 <+ciaranm> NeddySeagoon: you weren't around in the good old days when i would sing "happy happy joy joy" all the time?
-17:40 < NeddySeagoon> ciaranm, Nope, you had left just before I became a staffer
-17:41 <@leio> ok, sounds good. I suggest for the PMS editors to document some of that in the project page as well, or point to the intro for these things
-17:41 <+ciaranm> leio: you'll need to find out who has permission to edit the pms page this week for that part
-17:41 <+ciaranm> NeddySeagoon: all was sunny and shiny, gentoo made progress, developers got along and bugs got fixed
-17:42 <@ulm> ciaranm: every dev can edit it i think
-17:42 <@leio> where's the conflict resolution process documented?
-17:42 <+ciaranm> leio: credits.tex in pms iirc
-17:42 < reavertm> ciaranm: so what happened that it all changed? :)
-17:42 < NeddySeagoon> ciaranm, pretty mucah as happens now but Gentoo has got a lot more complex meanwhile
-17:42 <+ciaranm> reavertm: love-sources
-17:42 <+ciaranm> reavertm: and then gentoo-alt
-17:43 <@leio> no references to "conflict" in pms.html
-17:43 < reavertm> you suggested to keep them off-tree or sth?
-17:43 <@dev-zero> ciaranm: what had love-sources to do with it?
-17:43 < reavertm> probably personal conflicts with maintainers?
-17:43 <+ciaranm> leio: there should be a "Reporting Issues" section
-17:44 <+ciaranm> dev-zero: seemant decided that we couldn't tell users in #gentoo who were using love-sources to change kernels before moaning that they experienced filesystem corruption etc
-17:44 < yngwin> bug 57300
-17:44 < Willikins> yngwin: https://bugs.gentoo.org/57300 "Ciaranm: the antagonism continues"; Developer Relations, Default; RESO, FIXE; seemant@g.o:devrel@g.o
-17:44 <@leio> ciaranm: ok, thanks. I'll add to my TODO to read through the whole document from top to bottom one day even though not implementing a PM
-17:44 -!- jlec [n=jlec@ip-62-143-31-170.unitymediagroup.de] has left #gentoo-council []
-17:45 <+ciaranm> leio: oh good. we could use some people doing that.
-17:45 <+ciaranm> yngwin: before then even
-17:45 <@leio> the TODO list is too long.
-17:45 < yngwin> yeah, but thats where its documented
-17:45 <+ciaranm> the whole "#gentoo losing all its active ops" thing happened quite a bit before that mess
-17:46 <+ciaranm> then there was that whole year-long freeze on recruiting developers thanks to drobbins' lawyer trying to make everyone sign a bit of paper agreeing to turn over their computer to the foundation upon request
-17:47 < hwoarang> :/
-17:47 < NeddySeagoon> ciaranm, do you still have a copy of that ?
-17:47 <+tanderson|na> dev-zero: I'll talk to cardoe and ask if he is expecting to have problems next meeting. If not, I'll be your proxy
-17:47 <+ciaranm> NeddySeagoon: i could probably find one if i could remember where stuff is in gentoo cvs
-17:48 <+ciaranm> NeddySeagoon: proj/en/devrel/copyright-assignment.xml iirc
-17:48 <+ciaranm> ...or, for that matter, if i could remember how to use cvs
-17:48 < NeddySeagoon> ciaranm, thanks.
-17:49 <+ciaranm> http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/copyright-assignment.xml?hideattic=0&rev=1.17&view=log
-17:49 <@dev-zero> does the proxy have to be a gentoo-dev anyway?
-17:49  * dev-zero is going to read tha ru!3z
-17:49 <+ciaranm> dev-zero: no
-17:50 <+ciaranm> NeddySeagoon: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/assignment.txt?hideattic=0&rev=1.2&view=markup is the exact wording
-17:50 <+tanderson|na> dev-zero: I'll just make an alterego and we're good :P
-17:50 <+ciaranm> NeddySeagoon: search for 'media' for the nasty part
-17:50 <@dev-zero> tanderson|na: hehe :)
-17:50 <+ciaranm> hrm, no
-17:50 <+ciaranm> that's not the lawyer version
-17:50 <@dev-zero> tanderson|na: or someone who responded quiet fast got a job
-17:53 -!- ssuominen [n=ssuomine@i062213.gprs.dnafinland.fi] has quit [Remote closed the connection]
-17:54 -!- ssuominen [n=ssuomine@i062213.gprs.dnafinland.fi] has joined #gentoo-council
-17:57 < NeddySeagoon> ciaranm, I can't believe that was written by a lawyer. It confuses copyright and IP
-17:58 <+ciaranm> NeddySeagoon: i'm not even sure if that's the lawyer's version
-17:58 <+ciaranm> NeddySeagoon: i seem to recall there being a version at one point that specifically said you have to hand over your computer if they ask for it
-17:58 < NeddySeagoon> ciaranm, Its quite possible to assign copyright and retain IP
-17:59 < NeddySeagoon> also, it takes no account in the variations in copyright law aound the world
-17:59 <+ciaranm> NeddySeagoon: one of the objections was that anyone in germany(?) couldn't legally sign the original agreement, or that they couldn't agree to hand over certain rights that it demanded
-18:00 <@dev-zero> ciaranm: same problem with Switzerland I think
-18:00 < NeddySeagoon> ciaranm, yep. In the UK employers often own copyright and IP to everything you do, even in your own time
-18:00 <+ciaranm> NeddySeagoon: fortunately the only thing i've ever had to care about on this was a one day course explaining all of it from some very highly paid lawyers for a very large software company, who only did that and got us to take a silly test so they could cover their asses regarding us understanding our rights
-18:01 < NeddySeagoon> heh
-18:01 -!- The_Paya [n=the_paya@gentoo/developer/thepaya] has quit [Read error: 110 (Connection timed out)]
-18:02 <+ciaranm> i do recall them very specifically saying that they didn't own anything we did in our own time on our own hardware, but that we should write down anything we did do and tell management everything we did in spare time so they could be clear there what they did and did not own
-18:03 < Calchan> ciaranm, that's the US way and it's contagious, I spent my whole morning with lawyers today instead of doing useful work
-18:03 < NeddySeagoon> ciaranm, read the fine print in your contract of employment
-18:04 <+ciaranm> NeddySeagoon: oh, my current contract's fine on that
-18:04 < NeddySeagoon> ciaranm, I'm glad to hear that
-18:05 <+ciaranm> although for some weird reason i'm not allowed to contribute code to projects using GPL-1. i have nfc why.
-18:05 -!- spatz [n=spatz@unaffiliated/spatz] has left #gentoo-council ["Bye"]
-18:05 < NeddySeagoon> ciaranm, It sounds like you went into it before you signed on the dotted line
-18:23 -!- candybar [n=foo@unaffiliated/candybar] has left #gentoo-council ["Leaving"]
-18:29 -!- You're now known as tanderson
-18:35 -!- musikc [n=musikc@gentoo/developer/musikc] has quit ["Leaving"]
-18:44 -!- Cardoe [n=Cardoe@gentoo/developer/Cardoe] has quit ["Leaving"]
-18:47 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has quit [Client Quit]
-18:49 -!- milobit [n=milobit@barbossa.ns-linux.org] has left #gentoo-council ["Leaving"]
-19:14 -!- miknix [n=miknix@gentoo/developer/miknix] has joined #gentoo-council
-19:41 -!- ABCD [n=ABCD@wikipedia/ABCD] has left #gentoo-council ["http://quassel-irc.org - Chat comfortably. Anywhere."]
-19:48 -!- Arfrever [n=Arfrever@gentoo/developer/arfrever] has quit [Read error: 110 (Connection timed out)]
-19:58 -!- miknix [n=miknix@gentoo/developer/miknix] has quit [Read error: 110 (Connection timed out)]
-19:58 -!- miknix [n=miknix@gentoo/developer/miknix] has joined #gentoo-council
-20:11 -!- madpinger [n=mad@fu/coder/madpinger] has joined #gentoo-council
-20:15 -!- madpinger [n=mad@fu/coder/madpinger] has left #gentoo-council ["Ex-Chat"]
-20:22 -!- ulm [n=ulm@gentoo/developer/ulm] has quit ["ERC Version 5.3 (IRC client for Emacs)"]
-20:40 < trelane> well, due to the silence based on what I had to say, either I'm WAY out in left field, or I'm pretty much right on it.
-20:40  * trelane just hopes he got it right
-20:42 <@leio> trelane: most of council members are in such a timezone to go to sleep right after meeting, I believe. I was dealing with something related though
-20:42 < trelane> cool :)
-20:42 <@leio> and now it's way past my bed time too, which in my timezone is really right after the meeting
-20:42 < trelane> darn, I've always thought a well written argument wakes up the soul
-20:43 < trelane> I'll write it better next time :)
-20:43 <@leio> give it some time, people are indeed really sleeping or tired
-20:44 < trelane> next time I'll send caffeine pills along with my argument then
-20:44 <@leio> I think the mail was well worded and I have it marked as important in IMAP to follow-up
-20:44 < trelane> thanks
-21:03 -!- The_Paya [n=the_paya@190.189.19.103] has joined #gentoo-council
-22:07 -!- zxy_64 [n=zxy_64@unaffiliated/zxy64/x-762372] has left #gentoo-council []
-22:39 -!- miknix [n=miknix@gentoo/developer/miknix] has quit ["Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC."]
-22:50 -!- reavertm_ [n=reavertm@azs80.neoplus.adsl.tpnet.pl] has joined #gentoo-council
-23:03 -!- reavertm [n=reavertm@gentoo/contributor/reavertm] has quit [Read error: 110 (Connection timed out)]
-23:19 -!- reavertm_ is now known as reavertm
-23:22 -!- Poly-C [n=Poly-C@gentoo/developer/Polynomial-C] has joined #gentoo-council
-23:23 -!- Polynomial-C [n=Poly-C@gentoo/developer/Polynomial-C] has quit [Read error: 60 (Operation timed out)]
---- Log closed Fri Jun 12 00:00:30 2009
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090625-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090625-summary.txt
deleted file mode 100644
index f37a717999..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090625-summary.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: here
-Cardoe: here
-dertobi123: here
-dev-zero: absent(see below)
-leio: here
-lu_zero: not present
-tanderson(secretary): here
-ulm: here
-
-Absence of Tiziano(dev-zero)
-=============================
-
-Tiziano Muller(dev-zero) appointed Ciaran McCreesh(ciaranm) as his proxy on the
-council@g.o alias. However, four out of the seven council members agreed
-that proxies must be gentoo developers(which ciaranm is not) just as council
-members must be. Thus, because Tiziano did not attend the meeting he is
-considered absent.
-
-Topics:
-===========
-
-    - Define EAPI development/deployment cycles
-        No vote was taken on this, though many members were not supportive of
-        the 'codename for features' part.
-
-    - EAPI 3 progress
-        Zac Medico(zmedico) reported that he'd been pretty active with portage
-        development the past week and that EAPI 3's implementation should be
-        done within a month.
-
-    - Discussing the past year
-        Petteri(Betelgeuse) mentioned having a web application to handle agenda
-        creation and approval by council members to streamline the policy set
-        towards the end of the term to 'ACK' agendas before the meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090625.txt b/xml/htdocs/proj/en/council/meeting-logs/20090625.txt
deleted file mode 100644
index 01b23e2215..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090625.txt
+++ /dev/null
@@ -1,222 +0,0 @@
-16:01 <@dertobi123> so
-16:01 <@dertobi123> heya
-16:01 <+tanderson> hi folks, I'm present
-16:01 <+ciaranm> evenin'
-16:01 <+ciaranm> <-- dev-zero's proxy, unless he finds internet
-16:02 <@leio-dl> sorry, but no
-16:03 <@dertobi123> so, first of all: roll-call - who's here?
-16:03 <@ulm> here
-16:03 <@leio-dl> here
-16:03 <+tanderson> dertobi123: are you chairing the meeting?
-16:03 < spatz> can you please change the topic?
-16:03 <@dertobi123> tanderson: if you'd like to, go ahead
-16:03 -!- dertobi123 changed the topic of #gentoo-council to: Next Meeting: now.
-16:04 <@Cardoe> now as in right now!
-16:04 -!- lavajoe [n=joe@...] has joined #gentoo-council
-16:04 -!- dertobi123 changed the topic of #gentoo-council to: Next Meeting: now. Agenda: http://archives.gentoo.org/gentoo-dev/msg_3de4654630dd6805259714833442c4f2.xml
-16:04 <+tanderson> ok, we have enough
-16:04 -!- mescalinum [n=mescalin@gentoo/developer/mescalinum] has joined #gentoo-council
-16:04 -!- ABCD [n=ABCD@wikipedia/ABCD] has joined #gentoo-council
-16:04 <+tanderson> first topic, EAPI development/deployment cycles
-16:05 <@dertobi123> stop
-16:05 -!- drantin [n=drantin@pdpc/supporter/active/Drantin] has joined #gentoo-council
-16:05 <@Cardoe> dertobi123: hammer time?
-16:05 <@dertobi123> Cardoe: just for the record ...
-16:06 <@dertobi123> for the record: dev-zero appointed ciaranm as his proxy. 4 out of 7 council members agreed that proxies must be gentoo developer, just like regular council members. therefore ciaranm isn't accepted as dev-zero's proxy for today.
-16:06 <+ciaranm> could you point to where that rule is documented please?
-16:06 <+ciaranm> glep 39 imposes only one restriction on proxies, which is that you can't have one person with multiple votes
-16:06 <@dertobi123> council members must be gentoo developers. proxies therefore need to be, too.
-16:06 <+tanderson> dertobi123: ok
-16:06 <+ciaranm> dertobi123: where is that documented?
-16:06 -!- Pesa [n=Pesa@...] has joined #gentoo-council
-16:07 <@dertobi123> that's what 4 out 7 council members did agree on and this is not going to be discussed now.
-16:07 <+ciaranm> dertobi123: glep 39 does not impose requirements upon council members
-16:07 <@ulm> ciaranm: custom and practice
-16:07 <@ulm> and common sense
-16:07 <@Cardoe> Anyway, 4 out of 7 voted and it takes a majority vote to make something a reality
-16:07 <@Cardoe> so that's all the justification necessary
-16:07 <@dertobi123> exactly.
-16:07 <@Cardoe> on to EAPI development/deployment cycles
-16:07 <@dertobi123> end of discussion, first topic pklease
-16:07 <@dertobi123> Cardoe: *5*
-16:08 <+ciaranm> the council's ignoring glep 39 then?
-16:08 <+ciaranm> you're going against the direct request of an elected council member here
-16:09 <@Cardoe> So who had items to discuss wrt to the EAPI development cycles?
-16:09 -!- zhick [n=henning@...] has joined #gentoo-council
-16:09 <@Cardoe> cause if no one has anything to discuss...
-16:09 <@Betelgeuse> \o/
-16:09 <@dertobi123> this topic is split up into development and deployment
-16:09 <+tanderson> Cardoe: well, my agenda points to a process that quite a few people acknowledged was a step in the right direction
-16:10 <@dertobi123> as for the deployment part ciaranm described a possible way which i'd like to try for eapi-4 development
-16:10 <+tanderson> Cardoe: we were sidetracked last meeting unfortunately..
-16:10 <+tanderson> for development, we just NeedCode(TM)
-16:11 <@dertobi123> tanderson: for implementation, not for eapi-development
-16:11 <@Cardoe> tanderson: yep. which points to agenda item 2... talking to zmedico
-16:11 <+tanderson> dertobi123: right
-16:11 <+tanderson> Cardoe: I can pretty much guarantee that there's been no progress
-16:12 < zmedico> well, we got KV taken care of :)
-16:12 <+ciaranm> http://bugs.gentoo.org/show_bug.cgi?id=273620
-16:12 <@Betelgeuse> For the record I don't think proxies need to be Gentoo developers. But in the end it shouldn't matter today as I don't plan on us having a vote on anything major.
-16:12 <+tanderson> zmedico: oops, my apologies ;-)
-16:13 <@dertobi123> http://archives.gentoo.org/gentoo-dev/msg_d3a4758c455fded00608e891f525d3cc.xml <- anyone having something to discuss on the development part described there?
-16:13 <+tanderson> zmedico: nothing on the substantial things though, right?
-16:13 <@dertobi123> tanderson: can we please discuss #1?
-16:13 <@dertobi123> +first
-16:13 <+ciaranm> i just consulted with the person who wrote the proxy rules. he says that there's deliberately no restriction other than the one vote per person thing.
-16:13 <+tanderson> dertobi123: yeah...
-16:14 < zmedico> tanderson: no, not really. I've been pretty active working on portage the last week though (unlike the previous month), and I plan to stay pretty active and I should get eapi 3 done after not too long.
-16:14 <+tanderson> dertobi123: other than that I in general agree, no
-16:15 <@dertobi123> other opinions?
-16:15 <+ciaranm> afaik the only disagreement on the eapi stuff was over the codenames
-16:15 <@ulm> dertobi123: generally agree too, except that we should use reasonable and descriptive names for features
-16:15 <+tanderson> codenames isn't really crucial. It can go away if need be.
-16:15 <@leio-dl> ulm++
-16:15 <@dertobi123> ulm++, yeah
-16:16 <+tanderson> *aren't
-16:16 <+ciaranm> the problem with not using codenames is that certain people didn't bother to read pms and just started commenting based upon what they thought something was, not what it was
-16:16 <@Cardoe> this is such a nit picky argument that isn't meaningful or technical. it's just personal attacks.
-16:17 <@dertobi123> agreed
-16:17 <@dertobi123> the codenames should describe what it's about and that's it
-16:17 <+ciaranm> it's the best solution i've found to a problem we encountered for EAPI 3
-16:17 <@leio-dl> I believe he might have something in mind I might have talked about in the council channel while working through the features outside a meeting
-16:17 <+ciaranm> if you've got a better way of ensuring that people read the material they're discussing, please present it
-16:17 -!- darkside_ [n=darkside@gentoo/developer/darkside] has left #gentoo-council []
-16:17 <@Cardoe> again, completely non-technical in nature
-16:18 <+ciaranm> we're discussing process here. half of it's non-technical.
-16:18 <+ciaranm> whether or not we use a wiki or google docs is non-technical.
-16:18 <@leio-dl> if something was not clear at meeting time, then due to rushing this to the very next meeting, when the material to work through is immense
-16:19 <@dertobi123> besides this being a personal thing between leio-dl and ciaranm I don't see any argument why should've nonsense codenames
-16:19 <@dertobi123> +we
-16:19 <+ciaranm> dertobi123: please present a better solution for ensuring that material has been read before being discussed
-16:19 <@leio-dl> the take-away point here is that maybe the meeting 1-2 weeks after EAPI-3 draft shouldn't have it in the agenda yet, but give some time to actually work through things
-16:20 <@Cardoe> ok this is just a circular and pointless argument
-16:20 <@dertobi123> ciaranm: there is none and we don't need one.
-16:20 <@dertobi123> Cardoe: indeed
-16:20 <@leio-dl> err, after an EAPI draft is ready
-16:20 <+ciaranm> dertobi123: it was a considerable problem during the EAPI 3 process
-16:20 <+ciaranm> leio-dl: i don't want to waste time writing draft-quality material for features that definitely won't be accepted
-16:21 <@leio-dl> then what kind of a material should be worked through
-16:21 <+ciaranm> i want features written in a couple of paragraphs of semi-spec-quality material, then a rough vote on whether to proceed to draft quality material for those
-16:21 <+ciaranm> and then a final vote on the draft quality material
-16:22 -!- psychoschlumpf [i=lars@unaffiliated/psychoschlumpf] has joined #gentoo-council
-16:22 <+ciaranm> but the voting needs to be on those couple of paragraphs and then the real draft material, not just the name
-16:22 <@dertobi123> sure
-16:23 <@dertobi123> but in the end it's everyone's (council member) responsability to be informed and to know what to vote on
-16:23 <@ulm> ciaranm: so there will be a bug # for every feature?
-16:23 <@dertobi123> so, if someone screws up by voting just on some random names ...
-16:23 <+ciaranm> ulm: roughly, yeah, although we might end up with a shared bug if features are closely related but independently votable (doexample, doinclude for example)
-16:24 <@ulm> ciaranm: so use the bug number as your codename if you want, but don't introduce any additional nonsense names
-16:24 <+ciaranm> could do that. although then people might just read the bug summary...
-16:24 <@ulm> ciaranm: you can't control what people will read anyway
-16:25 <+ciaranm> ulm: no, but we can modify the process based upon past experience to reduce the likelihood of problems cropping up
-16:25 <@dertobi123> serious, this is not kindergarten. you can't control who will read what and vote based on what he had red before.
-16:26 <+ciaranm> you can modify the process to decrease the possibility of abuse
-16:26 <@ulm> anyone has new arguments on this point? if not, i suggest that we proceed
-16:26 <@dertobi123> ulm: yeah ...
-16:26 <@leio-dl> So, simply to make sure everything is worked through (not just mindlessly read through), make sure there is enough time between material to be worked through presented and a vote
-16:27 <+ciaranm> leio-dl: there was plenty of time last time around. and people didn't even say "i haven't read it yet", they said "i have objections and questions"
-16:27 <@leio-dl> The only past experience perceived bad comes from there. I wasn't just reading through. I was thinking every single point  through and might not have gotten to one fourth of them by the time voting had to happen.
-16:27 <@dertobi123> leio-dl: we introduced that requirment lately with requiring an agenda sent out a week before the meeting (though it ended being just a couple of days, but we're making progress on that!)
-16:28 <@leio-dl> didn't help when it situated at a time I had no time for gentoo for one week. Anyways, I don't remember all the timeline and I don't care to
-16:28 <@leio-dl> lets move on
-16:28 <@dertobi123> leio-dl: in that case you should've appointed a proxy *cough*
-16:28 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-16:28 <@dertobi123> i think we reached a consensus on that and can move on
-16:29 <@dertobi123> right?
-16:29 <@leio-dl> because I was unable to work on gentoo stuff during the time in the middle of two meetings?
-16:29 <@ulm> dertobi123: yes
-16:29 <+ciaranm> leio-dl: you aren't just a council member for one hour every two weeks
-16:29 <+tanderson> This is pretty unproductive
-16:29 <@dertobi123> somewhat, but we're making kind of progress
-16:29 <@dertobi123> *cough*
-16:29 < bonsaikitten> ciaranm: people may have jobs and other things that take up time ...
-16:30 <+ciaranm> bonsaikitten: and they are more than welcome to appoint a proxy
-16:30 < bonsaikitten> how does that help?
-16:30 <@dertobi123> so, next part of the development/deployment discussion is the deployment part
-16:30 <@dertobi123> guess that's a topic for the next council and we can move on again.
-16:30 <@dertobi123> other input on that?
-16:30 <@leio-dl> yes, and I was responsible enough to actually work deeply through all of the points I managed by the time that meeting came on by the time some voting had to happen. It takes time. Hours and hours.
-16:31 <@Betelgeuse> In general getting EAPIs specified is a minor concern compared to getting the code into Portage.
-16:31 <+ciaranm> leio-dl: no, you were irresponsible enough to raise queries and say "i object to this" rather than "i haven't read this yet"
-16:31 <@leio-dl> nope, we just need more portage developers
-16:32 <@dertobi123> guys, can we please just follow our agenda???
-16:32 <@leio-dl> ciaranm: I'm done with this. Apparently I need to waste my time on re-reading thousands of lines of council channel log to deal with these claims.
-16:32 <@ulm> silence please ;)
-16:32 <@dertobi123> there's space left for some metadiscussions on #3
-16:33 <@dertobi123> so any other comments on the deployment part?
-16:35 <@dertobi123> can we at least get a quick overview if the council thinks that describing a deployment process for new eapis is important?
-16:35 <@dertobi123> i for one do think we do need such a process.
-16:36 <+ciaranm> i think we need one, but the one we've been using seems to work
-16:36 <+ciaranm> i'd really rather not see portage to stable without having had main-tree testing of new EAPIs
-16:37 <@ulm> but we have no writeup of the current process, right?
-16:37 <+tanderson> isn't ciaran's mail a pretty good summary of the current process?
-16:37 <+ciaranm> nothing documented in stone that i'm aware of
-16:38 <@dertobi123> i don't think the process used for now is perfect. we have the problems i described in my mail and other problems as well. the process i described some weeks ago isn't perfect as well, that's for sure. but in the end i think this is an important topic, but sadly noone seems to be really interested in that.
-16:38 <+ciaranm> i don't think we're going to get a perfect process
-16:39 <@dertobi123> not if we're not going to improve what we do
-16:39 <+ciaranm> i think we'd do best by paying more attention to where things go wrong with EAPI 3 and then addressing those next time
-16:39 -!- musikc_mobile [n=musikc@...] has joined #gentoo-council
-16:40 <@dertobi123> well, i described problems i've seen going wrong with eapi-2 i'd like to see improved for eapi-3 deployment
-16:40 <+ciaranm> with EAPI 2 the big one i saw was portage releasing something that didn't conform to the spec we'd agreed upon and that clearly hadn't undergone any kind of testing
-16:42 <@dertobi123> and what i've seen is that people immediately started using eapi-2 features (which isn't bad at all), but in the end packages needed to be backported to older eapis for security bugs
-16:42 <@dertobi123> anyway, 20 minutes left. we have to move on.
-16:42 <+ciaranm> the unfortunate reality is that for security, occasionally extra work has to be done
-16:43 <@dertobi123> ciaranm: security's one example, but that whole topic needs to be discussed on the dev-ml first of all
-16:44 <@dertobi123> so, eapi-3 progress
-16:44 <@dertobi123> zmedico: please :)
-16:44 <+ciaranm> http://bugs.gentoo.org/show_bug.cgi?id=273620 <-- portage's eapi 3 progress
-16:45 < zmedico> dertobi123: I estimate it will be done within about a month
-16:45 <@leio-dl> ciaranm: Maybe you could help with some of that, btw?
-16:46 <+ciaranm> leio-dl: afaik the only code that's realistically shareable between portage and paludis is on the amazingly easy shell stuff that's not worth copying
-16:46 <@leio-dl> I didn't have code sharing in mind, I had portage contributing in mind :)
-16:46 <@dertobi123> zmedico: ok
-16:46 <+ciaranm> leio-dl: there's a reason i gave up on fixing portage a long time ago...
-16:46 <@leio-dl> ok, lets leave it at that.
-16:47 <@dertobi123> zmedico: seen that arfrever is helping out, you mentioned a recruit 2 weeks ago (iirc?) - how's that process going?
-16:48 <@ulm> zmedico: any features where you see particular difficulties?
-16:49 < zmedico> dertobi123: I've been getting lots of help from the fellow who filed bug 273620 . that's going very well
-16:49 < Willikins> zmedico: https://bugs.gentoo.org/273620 "[TRACKER] sys-apps/portage EAPI 3 implementation"; Portage Development, Core; NEW; s.mingramm@...:dev-portage@g.o
-16:49 <@dertobi123> zmedico: cool!
-16:50 < zmedico> ulm: not really, seems like it should go pretty smoothly
-16:50 <+ciaranm> i was hoping we'd eliminated the "this'll be a pain for portage to implement" stuff early on in the process
-16:51 < zmedico> if anything comes up I'll let you know :)
-16:52 <@Betelgeuse> Who can be bride to get the features done?
-16:52 <@Cardoe> Betelgeuse: stop trying to marry developers ;)
-16:53 <@Betelgeuse> Cardoe: Ah yes. Oh well I stopped my night out drinking for this.
-16:54 <@dertobi123> ok, thanks for the update zac :)
-16:54 <@dertobi123> so we have a couple of minutes left to discuss the past year
-16:55 < bonsaikitten> bonus points for trying to streamline and optimize the meeting process
-16:55  * NeddySeagoon realises that this is the last meeting of this council and thanks the members for serving 
-16:56 <+tanderson> seconded. I want to thank you guys for allowing me to work with you
-16:56 <+tanderson> It's been great.
-16:56 < Philantrop> tanderson: Slimebag! ;-)
-16:57 <@dertobi123> bonsaikitten: well, we made a start with that. having a secretary makes life much easier. making it a requirement to post (and ack!) an agenda some days (preferrably a week) in advance is another improvement, too
-16:57 < bonsaikitten> hope to see y'all next year ;)
-16:57 <+tanderson> I hope to be able to work with you next year as a member or as a continuing secretary(if so requested)
-16:58 <@dertobi123> tanderson: thanks for being our wonderful secretary :) everyone thanks for being on the council as well (and we had lots of members this year *cough*)
-16:58 <@Cardoe> You guys will all miss me
-16:58 <@Cardoe> I know
-16:58 <@dertobi123> one thing i like the next council to improve is to announce a host for the meeting in advance
-16:59 <@dertobi123> chairing the meetings quite effective is thing all of us did fail for mostly the whole year.
-16:59 <@dertobi123> +a
-16:59 <@Betelgeuse> If I find the time I will take a shot at writing a web app for handling agenda etc.
-16:59 < bonsaikitten> good point
-16:59 <@dertobi123> Cardoe: oh yeah, we will do so :)
-16:59 <@Betelgeuse> But likely I will slack.
-16:59 <@dertobi123> Betelgeuse: keep it simple. just do it. if a webapp then can make things easier, ok ...
-16:59 <+tanderson> dertobi123: np,it's been a great ride
-17:00 <+tanderson> why a webapp for what can be done in vim?
-17:00 <@Betelgeuse> dertobi123: It should help tacking acks and prioritizin.
-17:00 <@Betelgeuse> s/tack/track/
-17:00 <@Betelgeuse> tanderson: A single person can handle it but when you need to get input from man.
-17:00 <@Betelgeuse> tanderson: y
-17:00 <@Betelgeuse> tanderson: Reminders etc would be helpful and can be automated.
-17:00 <+tanderson> ok
-17:01 <@dertobi123> Betelgeuse: there are some steps between. first get the basics done, then make it bright and shiny
-17:02 <@Cardoe> Or you can follow the Windows development model
-17:02 <@Cardoe> make it bright and shiny... then when you get some time... make it work
-17:02 <@dertobi123> Cardoe: i personally do prefer the other way 'round ;)
-17:03 <@dertobi123> so, if there's nothing left we would like to write down for our next council we're done.
-17:03 <@dertobi123> thanks again for that somewhat interesting experience during the past year, hopefully we see us again in 14 days.
-17:03 <+ciaranm> dev-zero would like you to write down the rules you're following, since they're clearly not glep 39
-17:03 <@dertobi123> thanks guys!
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090720-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090720-summary.txt
deleted file mode 100644
index c6b348c66e..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090720-summary.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-1. Intro 
-
-  1.2. Roll call.
-> Missing: lu_zero.
-
-  1.3. Any volunteers to chair this meeting?
-> solar volunteered.
-
-2. Meeting format
-
-  2.1. Should the channel be moderated during council meetings?
-  > Yes: solar, calchan, dertobi123, ulm, leio, betelgeuse.
-  > No: none.
-
-    2.1.1. If yes, moderate the channel now.
-    > solar moderated the channel at 1816UTC.
-
-    2.1.2. If yes, should council members watch another channel in order to
-    paste ideas/propositions from the latter to the council channel?
-    > No: solar, calchan, betelgeuse, dertobi123, ulm.
-    > Yes: leio.
-
-  2.2. Do we need a secretary?
-  > Yes: calchan, betelgeuse, dertobi123, ulm, solar, leio.
-  > No: none.
-  > The secretary's role will be limited to providing logs and summaries of
-  > the meetings.
-
-    2.2.1. If yes, does the secretary need to be a council member?
-    > No: ulm, solar, dertobi123, leio, betelgeuse, calchan.
-    > Yes: none.
-
-      2.2.1.2. If no, do we confirm gentoofan23?
-      > Yes: solar, calchan, leio, dertobi123, ulm, betelgeuse (?).
-      > No: none.
-
-    2.2.2. Do we need a backup?
-    > No: dertobi123, leio, calchan.
-    > Yes: none.
-    > Did not vote: betelgeuse, solar, ulm.
-
-  > Betelgeuse requested a vote on whether drafts had to be reviewed on the
-  > private alias instead of on the public mailing-list.
-  > Public: betelgeuse, calchan, leio.
-  > Private: solar, dertobi123, ulm.
-  > The decision was made to wait for lu_zero's vote by email.
-
-    2.2.3. gentoofan23 is away for this week, so if yes to 2.2.1.2 we need to
-    look for a secretary for this meeting. Volunteers?
-    > Question not asked.
-
-      2.2.3.1. If no make it an action that we look for one (who, by when?).
-      > Not done.
-
-3. GLEP 39
-
-  3.1. Can the council decide on the process of voting amendments to GLEP 39
-  without an all-developers vote?
-  > No: betelgeuse, dertobi123, solar, ulm.
-  > Yes: calchan, leio.
-
-  3.3. If no to 3.1 make it an action to see with the elections project that
-  all developers vote on 3.2 (who, by when?).
-  > Not done.
-
-4. Meeting schedule
-
-  4.1. Periodicity.
-  > Monthly: solar, calchan, dertobi123, ulm, betelgeuse, leio.
-  > Every two weeks: none.
-
-  4.2. Depending on 4.1 and your availability what week would you like to meet?
-  > Third monday of the month.
-
-  4.3. Do we keep using a Doodle poll to decide when in the week we meet?
-  > Only in case of personal schedule issues, assuming a warning long enough
-  > in advance.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090720.txt b/xml/htdocs/proj/en/council/meeting-logs/20090720.txt
deleted file mode 100644
index a78f6f9e9f..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090720.txt
+++ /dev/null
@@ -1,376 +0,0 @@
-19:59 <@solar> I'm seeing most of the other council people are idle for long periods of time.
-20:00 <@Betelgeuse> solar: of course we are!
-20:00 <@Betelgeuse> I said in my manifesto that I am slacking but got voted in regardless \o/
-20:01 <@solar> you just broke your 4h8m of idle time :p
-20:01 <@Calchan> I'm ready
-20:01  * dertobi123 waves
-20:01 <@Betelgeuse> At some point I thought this was 20UTC like before but luckily it was temporary.
-20:01  * jmbsvicetto takes a seat in the backrow
-20:02 <@Betelgeuse> Calchan: could you link the agenda to the topic
-20:02  * ulm is here too
-20:02 <@Calchan> anybody logging? I am, but would apprecaite a backup in case of splits
-20:02 <@Betelgeuse> Calchan: I always log everything
-20:02 <@Calchan> Betelgeuse, ok
-20:02 -!- Topic for #gentoo-council: Next meeting Monday July 20th 1800UTC.
-20:02 -!- Topic set by Calchan [i=calchan@gentoo/developer/calchan] [Thu Jul 16 23:16:52 2009]
-20:02 <@solar> so only lu_zero is missing?
-20:03  * fmccor|home also always logs everything if needed.
-20:03 -!- Calchan changed the topic of #gentoo-council to: Next meeting Monday July 20th 1800UTC. Agenda: http://archives.gentoo.org/gentoo-council/msg_14756d9207e877f124a36b54f6e43f65.xml
-20:03 <@Calchan> solar, and leio who should be back any time
-20:03 <@Calchan> we can wait a bit for those 2
-20:04 <@leio> here now
-20:04 -!- ssuominen [n=ssuomine@gentoo/developer/ssuominen] has joined #gentoo-council
-20:04 <@Calchan> good, let's give lu_zero a last chance
-20:05 <@Calchan> so, any volunteers to chair?
-20:06 <@solar> sure let get this party started.
-20:06 <@solar> 1. Intro (10 minutes inlcuding late arrivals)
-20:06 <@Calchan> If you agree I would like us to focus on voting today, and keep the discussions and comments to what's required and stick to the agenda
-20:07 <@solar> This is the first council meeting of the 5th council. It's clear we want to take a slighly different path that has been done in the past.
-20:07 -!- tampakrap [n=tuxicity@gentoo/developer/tampakrap] has joined #gentoo-council
-20:07 <@solar> 1.1) fmccor/Betelgeuse and others are logging.
-20:07 <@Calchan> we have plenty of time to discuss on the list, I encourage everbody to do that, dev or not
-20:08 <@solar> 1.2) Everybody is present minus lu_zero so far.
-20:08 -!- spatz [n=spatz@unaffiliated/spatz] has quit [Remote closed the connection]
-20:08 <@solar> 1.3) I'm happy to do it this time.
-20:08 <@Calchan> thanks
-20:09 <@solar> 2) Meeting format.
-20:09 <@solar> 2.1. Should the channel be moderated during council meetings?
-20:09 <@solar> I'll vote: yes
-20:09 <@Calchan> I vote yes too
-20:09 <@dertobi123> yes
-20:09 <@ulm> yes
-20:10 <@solar> that is a majority rule of 4 votes.
-20:10 <@leio> yes
-20:10 <@Calchan> we should still let Betelgeuse vote though
-20:10 <@Betelgeuse> Calchan: I wouldn't mind using it just when needed but find by moderating too.
-20:10 <@Betelgeuse> s/find/fine/
-20:11 <@Calchan> What we can also do is leave the channel open and the first one of us who's uncomfortable with how things go can moderate it without asking us
-20:11 <@Betelgeuse> Calchan: yeah that's what I was saying
-20:11 -!- mrpouet [n=mrpouet@gentoo/developer/mrpouet] has joined #gentoo-council
-20:11 <@solar> 2.1.2. If yes, should council members watch another channel in order to
-20:11 <@solar>     paste ideas/propositions from the latter to the council channel?
-20:11 <@leio> yes
-20:12 <@solar> I would vote No on that. People wanting a voice often would request it via /msg council-guy please +v me so I can talk about item.
-20:12 <@Calchan> I say no, devs and users have plenty of time to express ideas, request discussion topics etc.. on the list
-20:12 <@Betelgeuse> yeah and can use priv / #gentoo-dev
-20:12 <@dertobi123> no, too
-20:13 <@leio> under my vote I have discussional agenda items in mind
-20:13 <@ulm> i vote no, any discussion can take place on the -dev ml beforehand
-20:13 <@Calchan> ulm, I'd prefer gentoo-council@
-20:13 <@solar> note that -dev ml is no longer a requirement
-20:13 <@Betelgeuse> Calchan: I don't like gentoo-council existing at all.
-20:13 <@ulm> Calchan: also fine, I don't mind if it's -dev or -council
-20:13 <@Betelgeuse> gentoo-project and gentoo-dev cover what's there currently
-20:14 <@Calchan> Betelgeuse, true, let's make a note to put discuss that asap after this meeting
-20:14 <@Calchan> /put/d
-20:14 <@leio> and I don't like gentoo-project existing at all, but yeah, lets not go there now :)
-20:15 <@Calchan> look slike we definitely need to discuss this :o)
-20:15 <@dertobi123> looks like, yes ;)
-20:15 <@solar> so +m is the vote with 2.1.2* not being a requirement?
-20:16 <@dertobi123> yeah
-20:16 <@ulm> yes
-20:16 -!- mode/#gentoo-council [+m] by solar
-20:16 <@solar> 2.2) Do we need a secretary?
-20:17 <@Calchan> yes
-20:17 <@Betelgeuse> yes
-20:17 <@dertobi123> we do, yeah
-20:17 <@ulm> i think it worked well, so yes
-20:17 <@solar> I'm in favor of it.
-20:17 <@Calchan> lerio?
-20:17 <@Calchan> leio?
-20:18 <@leio> Define secretaries tasks/responsibilities?
-20:18 <@Calchan> good point
-20:18 <@leio> If the same as before, I'll go with yes
-20:18 <@Calchan> we should still define it now
-20:18 <@Calchan> can we say agendas, logs and summaries?
-20:19 <@Betelgeuse> fine by me
-20:19 <@ulm> sounds good
-20:19 <@dertobi123> Calchan: as before, yeah
-20:20 <@solar> agendas? I don't recall those being part of the role directly.
-20:20 <@Calchan> solar, I seem to remember tanderson slacking on those, so he must have
-20:20 <@Betelgeuse> they weren't I think
-20:20 <@Calchan> oh ok
-20:21 <@leio> I remember dev-zero doing agendas often
-20:21 <@Betelgeuse> and dberkholz at the beginning
-20:21 <@leio> Calchan seems to be good at it now as a replacement *grin*
-20:21 <@Betelgeuse> small toilet break
-20:21 <@Calchan> leio, thanks for volunteering me ;o)
-20:22 <@leio> but that's a separate topic I guess. I agree with logs and summaries being secretary tasks
-20:22 <@leio> and we can maybe sometimes convince the secretary to sometimes volunteer to do something more
-20:22 <@Calchan> btw, we could add agendas to the mix in case we end up deciding the secretary needs to be a council memebr
-20:23 <@solar> I would say yes on the logs and summary. But think mostly it should be council people defining the agenda items based on what we feel the devs/others are calling for.
-20:23 <@solar> 2.2.1. If yes, does the secretary need to be a council member?
-20:23 <@ulm> no
-20:23 <@solar> My input would be 'no'
-20:24 <@Calchan> let's give Betelgeuse a chance to not wet himself before we go forward :o)
-20:24 <@leio> igli made a good comment on the topic of logs and summaries
-20:24 <@dertobi123> dito, no
-20:24 <@leio> "logs and summaries to appointed officer seems good to me; good precedence for trustees (ie officer doesn't decide policy.)"
-20:24 <@leio> which I agree with from the neutrality view
-20:26 -!- Zorry [n=zorry@fu/coder/zorry] has quit [Client Quit]
-20:26 <@Betelgeuse> back
-20:26 <@Betelgeuse> and the secretary doesn't need to be a council member
-20:26 <@Calchan> leio, true, but on the other hand as summaries can't hardly be biased there is a responsibility issue
-20:26 <@Calchan> Betelgeuse, we weren't there yet ;o)
-20:26 <@leio> I guess it's a bigger point in regards to agendas
-20:27 <@Calchan> oh we were, sorry, I had lost my screen for a while
-20:27 <@solar> in the past it was my understanding that the role would mail the council with drafts of the summary. it would then be approved/rejected by the council before being sent to any mailing lists
-20:27 <@leio> anyhow, I think we can easily "outsource" logs and summaries, and we might as well call the person who's supposed to do that the secretary
-20:28  * dertobi123 nods
-20:28 <@ulm> solar: yes, the summary needs approval by the council
-20:28 <@leio> and yes, we read first before it being official
-20:28 <@Calchan> looks like everybody agrees then
-20:28 <@leio> up to now it has been a preliminary summary to gentoo-council ml, we comment (often in IRC), and then it gets posted to -dev after fixes
-20:29 <@solar> you did not vote that I saw Calchan
-20:29 <@Calchan> count it as a no to "does the secretary need to be a council member"
-20:29 <@solar> ok so that moves us to.
-20:29 <@solar> 2.2.1.2. If no, do we confirm tanderson?
-20:29 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-20:29 <@Calchan> only if he agrees to wear shorter skirts
-20:30 <@solar> I think it's pretty much a given that he wants the role again.
-20:30 <@Calchan> agreed, and I vote yes
-20:30 <@leio> yes
-20:30  * dertobi123 too, yes
-20:30 <@ulm> yes
-20:30 <@solar> igli is asking that the summary be posted to -project for open comments
-20:31 <@Betelgeuse> fine by me (it has been posted to -council before though)
-20:31 <@Betelgeuse> as long as we have -council it's best there
-20:31 <@ulm> solar: before it's approved by the council?
-20:31 <@solar> I would hope not.
-20:31 <@Calchan> solar, he can comment on -council it's open, at least until we decide what we do with it
-20:31 <@solar> he just /msg me saying after.
-20:32 <@Calchan> solar, and I'd agree with you there
-20:32 <@solar> personaly I would only happen to see -council as being a requirement to where it's sent.
-20:32 <@leio> I find -dev more appropriate for that, as it has been before iirc
-20:32 <@dertobi123> Calchan: indeed. -council for now. and of course, after our approval.
-20:33 <@Calchan> was it usually cross posted on -dev-announce?
-20:33 <@Calchan> can't remember
-20:33 <@Betelgeuse> Calchan: after being approved
-20:33 <@Betelgeuse> and yes approved summaries to -dev-announce
-20:33 <@leio> so we handle the summary through private alias first from now on?
-20:33 <@solar> drafts should really hit aliases only.
-20:33 <@Calchan> Betelgeuse, thanks, ok then no need to post to dev, -council or -project is enough
-20:33 <@Calchan> solar, agreed, alias only for drafts
-20:34 <@solar> and -dev-announce seems logical.
-20:34 <@solar> ok so moving on.
-20:34 <@Calchan> solar, and cross-posted on 0council until we decide else
-20:34 <@leio> well, where do we forward the discussion to (Reply-to)
-20:34 <@solar> 2.2.2. Do we need a backup?
-20:34 <@leio> -council until decided otherwise sounds good.
-20:35 <@Calchan> leio, where it's cross posted
-20:35 <@dertobi123> we don't need a backup, but it'll be nice to have one
-20:35 <@leio> no, if necessary the council members should pick it up anyway
-20:35 <@Calchan> dertobi123, we don;t *if* we can know soon enough when he isn't available
-20:36 <@Calchan> and in his case I think we can
-20:36 <@dertobi123> hrm
-20:37 <@Calchan> for example he warned early enough that he wouldn'
-20:37 <@Betelgeuse> I think we should vote on whether to use private or public for summary drafts
-20:37 <@Calchan> t be available this week
-20:37 <@Betelgeuse> I don't like putting the secretary to the private alias so then there would be some public communication unless something else private is created.
-20:37 <@Calchan> Betelgeuse, good point
-20:38 <@leio> doesn't have to be on the private alias, we just use reply to all
-20:38 <@ulm> leio: exactly
-20:38 <@solar> likewise is what I would think.
-20:38 <@leio> which we need to often do anyway when replying an outside e-mail
-20:38 <@Betelgeuse> I don't like making stuff private unless absolutely necessary.
-20:39 <@Calchan> solar, why don't we simply vote on this?
-20:39 <@solar> but vs sending out what could be heated hot topics it's imo to get the tone set by what we all felt was the outcome of a given meeting.
-20:39 <@ulm> Betelgeuse: we don't want any third party pick up our draft summaries
-20:39 <@solar> vs what the sec alone thinks it might of been
-20:41 <@leio> if meetings go smooth, making a summary out of a clear log doesn't really involve any interpretation. We just haven't had clear resolutions on some topics in the past, slipping to the next thing, etc
-20:41 <@leio> (relates to meeting chairing)
-20:42 <@solar> Do we need to vote on this? public vs private drafts?
-20:42 <@Calchan> solar, I think we should
-20:42 <@solar> I vote for private drafts then
-20:42 <@Calchan> and honestly I'm torn between both
-20:42 <@Betelgeuse> public
-20:43 <@dertobi123> private
-20:43 <@ulm> private
-20:43 <@Calchan> I'll say public, it worked until now
-20:43 <@Calchan> leio?
-20:43 <@leio> public
-20:44 <@Calchan> dammit
-20:44 <@solar> 3 private / 3 public = tie for now.
-20:44 <@Calchan> let's ask for lu_zero's vote by mail
-20:44 <@Calchan> there's no emergency on that
-20:44 <@dertobi123> agreed
-20:45 <@solar> fair enough. Ready to move on?
-20:45 <@Calchan> sure
-20:45 <@leio> I have a compromise suggestion though - gets posted to private when ready from secretary, if no hard objections within ~12 hours it becomes a public draft, and then gets confirmed as final.
-20:45 <@leio> Waiting for lu_zero vote sounds good.
-20:45 <@Calchan> leio, 12 hours is tough due to timezones
-20:46 <@leio> it's to ensure 1-2 council members get a chance to read it before it goes public, not to have everyone do it
-20:46 <@leio> if those 1-2+ don't see anything bad, there probably isn't
-20:46 <@leio> anyways, lets just wait for lu_zero
-20:46 <@Calchan> leio, I'd disagree with that, but let's move on
-20:47 <@solar> 3) GLEP 39
-20:47 <@solar> 3.1. Can the council decide on the process of voting amendments to GLEP 39
-20:47 <@solar>   without an all-developers vote?
-20:47 <@Calchan> yes
-20:47 <@Betelgeuse> I think we can just use votify and have an approved marker to vote on multiple changes at once.
-20:48 <@Betelgeuse> those above pass and those below don't
-20:48 <@Calchan> Betelgeuse, that would be for a later question, but does this imply you vote yes to this one?
-20:49 -!- comprookie2000 [n=david@gentoo/developer/comprookie2000] has quit [Client Quit]
-20:49 <@Betelgeuse> Calchan: What I said is the existing process imho so there's no need for council to say everything so no.
-20:49 <@Calchan> specifically that would be for the implementation of 3.2, not even 3.2 itself
-20:49 <@Calchan> Betelgeuse, OK
-20:49 <@dertobi123> i tend to say no
-20:50 <@Calchan> others?
-20:50 <@solar> Having lived in the USA. I've seen first hand what happens when a group/pres can give itself unlimited powers. They powers granted to the council were given to them by the devs. So imo it's the devs via votify who can change GLEP-039
-20:51 <@dertobi123> solar: well, same goes for germans
-20:51 <@dertobi123> that's why i tend to "no"
-20:51 <@Betelgeuse> solar: I don't specifically understand what you refer in the first sentence but guessing it's not terrible important.
-20:52 <@Betelgeuse> Absolute power corrupts absolute etc.
-20:52 <@dertobi123> plus i'd like to see glep-39 being moved to something non-glep (formal counciil-constituion or something similiar, jmbsvicetto has made a proposal on that)
-20:52 <@Betelgeuse> +ly
-20:52 <@solar> Betelgeuse: in the US Bush gave himself powers that he was not really in power to give to himself. But being he was in a power posiion. Nobody questioned it (no matter how scary the choices)
-20:52 <@solar> Betelgeuse: or that exactly. "Absolute power corrupts absolute etc."
-20:53 <@Calchan> dertobi123, and others before but apparently nobody cared
-20:53 <@dertobi123> well, at least jmbsvicetto and i do care
-20:53 <@Betelgeuse> I don't see that being a priority.
-20:53 <@dertobi123> that's something to start with
-20:53 <@Betelgeuse> But feel free to drive the action.
-20:53 <@dertobi123> Betelgeuse: indeed. that's something longer-term for the next year
-20:53 <@solar> I also do somewhat think 3.2.2 has some merit.
-20:54 <@Calchan> solar, if we vote no to 3.1, it's up to devs to vote on 3.2
-20:54 <@Calchan> solar, so let's get 3.1 voted first
-20:54 <@solar> but lets face it. over time the council will have less qualified people in it so it concerns me.
-20:55 <@leio> I vote yes to 3.1
-20:55  * dertobi123 still no
-20:55 <@Calchan> yes too
-20:55 <@Betelgeuse> no
-20:55 <@solar> no
-20:55 <@leio> ulm?
-20:55 <@ulm> no
-20:56 <@solar> 2 yes / 4 no.
-20:56 <@solar>   3.3. If no to 3.1 make it an action to see with the elections project that
-20:56 <@solar>   all developers vote on 3.2 (who, by when?).
-20:57 <@Betelgeuse> no need
-20:57 <@ulm> too special
-20:57 -!- mode/#gentoo-council [+v jmbsvicetto] by dertobi123
-20:57 <@ulm> we should prepare a son-of-glep39 and let devs vote on that
-20:57 <@Betelgeuse> for example
-20:58 <@Calchan> ulm, I don't see why it prevents us from filling the hole in glep39 that forgets to say how to amend it in the meantime
-20:59 <@Calchan> an all dev vote would be very quick to organize, and at leat we'd know for sure what devs think
-21:00 <+jmbsvicetto> Calchan: I do think we might take the chance and rethink our "metastructure organization"
-21:01 <@dertobi123> can we agree on to discuss this on-list until the next meeting?
-21:01 <+jmbsvicetto> Calchan: Do we want to have a "Gentoo constitution", do we want to have the organization details discussed through and documented on a GLEP? If so, a regular GLEP or do we want to create a new type and set particular rules for it?
-21:01 <@solar> I'm in full agreement with thinking it's time to rethink the structure.
-21:01 <@Calchan> my point with a text whic tires to replace glep 39 is I've been working on one for almost a year, have called for help, abd very few cares, even fewer helped
-21:02 <@Calchan> solar, thining is not enough, assuming we even do it
-21:02 <@Calchan> thinking
-21:02 <@Calchan> at some point we need to start doing something and doing it little by little on glep39 is one way to go
-21:02 <+jmbsvicetto> Calchan: I think we can split the "thinking" in 2 parts: 1. the process, how to change it and where to document it, 2. What type of structure we want
-21:03 -!- Arfrever [n=Arfrever@gentoo/developer/arfrever] has joined #gentoo-council
-21:03 <+jmbsvicetto> Calchan: I think 1 is doable in a "short" timeframe. 2 might take a longer time
-21:03 <@Calchan> jmbsvicetto, you'll soon see that you'll be alone, I've been experiencing that for a year now
-21:04 <@Calchan> but this is getting off topic, do we do 3.3 or not?
-21:04 <@leio> first part of part 1) was what we were voting about here
-21:04 <+jmbsvicetto> Calchan: I understand that, but if can reach some agreement about 1, then people can put forth proposals about 2 and get it decided through a vote
-21:04 <+jmbsvicetto> +we
-21:05 <@solar> I would expect that proccess to take ~2-3 months
-21:05 <@Calchan> let's decide abpout 3.3 first
-21:05 <@Calchan> we're getting awfully late here
-21:06 <@Betelgeuse> Calchan: The evening is young :D
-21:06 <@Calchan> Betelgeuse, I'm at work if you don't mind, and feeding my kids takes priority
-21:07 <@solar> ok. So what do you want to accomplish with 3.3 exactly Calchan?
-21:07 <@Calchan> solar, I want to ask devs how they wantgentoo to modify glep39, and that implies replacing it
-21:08 <@solar> ok so start a thread?
-21:08 <@solar> And CC: -council and -dev ml
-21:08 <@Betelgeuse> no
-21:08 <@Betelgeuse> only one mailing list
-21:08 <@solar> cross-posting kinda sucks.
-21:08 <@Calchan> solar, there was a thread to which nobody replied
-21:09 <@solar> but -dev reaches the max number of devs. -council to keep it official
-21:09 <@Calchan> if you guys really cared you would have given your opionion on this already
-21:09 <@Calchan> so don't pretend you do now
-21:09 <@Betelgeuse> solar: You can start the thread via -dev-announce
-21:09 <@Betelgeuse> solar: that's the way to reach all
-21:11 -!- hparker [n=hparker@gentoo/developer/hparker] has joined #gentoo-council
-21:11 <@solar> -dev-announce seems logical. But it's been mostly a post-only mailing list with very little interactive threads
-21:11 <@dertobi123> -dev-announce and f'up to -council
-21:11 <+jmbsvicetto> solar: set reply-to to the dev ml
-21:11 <@Calchan> solar, we're not going to cross post anything on -council to -dev-announce
-21:13 <@Calchan> solar, so how about we vote whether we want to do 3.3 and get done with it?
-21:13 <@Calchan> again, we're late
-21:13 -!- ed-209 [n=cc@pool-98-114-205-197.phlapa.fios.verizon.net] has joined #gentoo-council
-21:13 <@leio> ok, so I understand we need an action for "No" having happened for 3.1 and 3.3 wasn't something that everyone agreed on afterall (while commenting agenda)?
-21:13 <@solar> Calchan: I'm not sure what exactly you want to vote on.
-21:13 <@solar> but sure. Let the devs decide if they want a restructure.
-21:14 <@Calchan> can we move on?
-21:14 <@solar> and elections handles the vote. it only seems like somebody needs to fire up a thread on the topic. If it gets no feedback then nobody cares
-21:14 <@solar> Please yes.
-21:14 <@solar> 4. Meeting schedule (10 minutes)
-21:15 <@solar> I vote for 4.1.2 at this time every month.
-21:15 <@Calchan> same here
-21:16 <@Betelgeuse> Calchan: will it be that you only have an hour?
-21:16 <@Betelgeuse> Of course having it biweekly eats more hours too.
-21:16  * dertobi123 agrees, once a month, same time as today
-21:16 <@Betelgeuse> monday is good
-21:16 <@ulm> once a month is fine
-21:17 <@ulm> and monday is o.k. for me
-21:17 <@Betelgeuse> Let's try to phrase the exact things to vote on in the agenda.
-21:17 <@Calchan> ys please
-21:17 <@solar> the same time UTC as this one?
-21:17 <@Betelgeuse> Otherwise once a month is problematic to get things done.
-21:17 <@Betelgeuse> works for me
-21:17 <@dertobi123> wfm, too
-21:17 <@Calchan> Betelgeuse, we don't have to wait fo rthe meeting to get anything done though
-21:18 <@Betelgeuse> Calchan: yes sure
-21:18 <@leio> once a month is fine, given more mailing list activity. Same time is fine for me (at least while its summer time)
-21:18 <@Betelgeuse> Calchan: but we need to change from past behavior
-21:19 <@leio> or actually we can discuss more in this channel too outside meetings.
-21:19 <@ulm> that would be the third monday every month, ri
-21:19 <@ulm> ght?
-21:19 <@Calchan> leio, email is best because backlogs disappear
-21:19 <@solar> If something comes up that calls for a vote of something before the monthly meeting. I would have no objection for a quick get together. Or if we handle it via email it needs to be made very clear we are voting
-21:20 <@leio> Calchan: realtime discussion to prep something for e-mail vs more official records, etc, yeah
-21:20 <@Calchan> solar, have we reached a decision on 4.1?
-21:21 <@solar> ok so it seems like we reached a consensus on 4.1.2
-21:21 <@solar> that this time works good for everybody (cept maybe lu_zero?)
-21:21 <@Calchan> solar, I didn't say it would work for me all the time
-21:22 <@Calchan> hence 4.2
-21:22 <@Calchan> sorry, 4.3
-21:22 <@solar> 4.3) I would rather not. By default I think we should assume it's exactly 4 weeks from the last one.
-21:23 <@solar> however. I will be on vacation then next month
-21:24 <@Calchan> solar, I can't promise I'm available on mondays or any other days, so dertobi123's doodle poll made sense in my case
-21:24 <@dertobi123> we should have a default meeting time.
-21:24 <@leio> so you mean every 4 weeks but possibly changing day within the week..?
-21:24 <@Calchan> k on a default though
-21:24 <@dertobi123> if the default doesn't work -> announce it *early* and we can arrange to find a better date
-21:25 <@Betelgeuse> indeed
-21:25 <@solar> I'm in favor of 1100PST/1800UTC
-21:25 <@Calchan> dertobi123, ok with that, what is early?
-21:25 <@dertobi123> solar: me too
-21:25 <@dertobi123> 18utc on mondays seems to work in general for everyone
-21:25 <@dertobi123> so i'd prefer to switch just the weeks
-21:25 <@dertobi123> and stick to mondays
-21:26 <@dertobi123> if that doesn't work too - well, we should be able to arrange something different then
-21:26 <@dertobi123> Calchan: and early is something like "at least 10 days before the default meeting date"
-21:26 <@Calchan> dertobi123, will try
-21:26 <@leio> (I think per GLEP39 we still have proxies and slacker marks)
-21:27 <@leio> (but accommodating when possible and early enough sounds ok)
-21:28 <@solar> 5. Wrap up, comments, open questions.
-21:29 <@solar> now seems a good time to remove the +m ?
-21:29 -!- mode/#gentoo-council [-m] by solar
-21:29 <@leio> ok, so did we go with "We meet monthly on mondays 18.00 UTC and with at least 10 day notice a doodle poll can be arranged for a different time" or should we vote on that, and is monthly every 4 weeks or every n'th week of the month
-21:30 <@dertobi123> leio: we go with that, yeah. every 4 weeks by default
-21:30 < igli> I'd just like to say I'm impressed: I've never seen an executive group not vote more power to themselves. Also, please bear in mind that users find -council ML intimidating to post to. previous councils have been quite clear on keeping it to discussion around meetings and for external, not wider issues within community; there was -dev, now there's -project too. And it's much easier (less flames) to move it from -project to -dev than the other way round.
-21:30 <+jmbsvicetto> About my mail, I've left out proxies and slacker marks as I'd like to see other opinions before making a proposal - I think we can even left that open for the vote
-21:31 < fmccor|home> Thanks.  As some of you know, I have strong feelings about GLEP39 --- we (the developers) did choose it from a list of several alternatives.
-21:31 <@solar> note that every for weeks as pointed out might not be ideal as saying every First/Last week of the month.
-21:31 <@solar> four
-21:31 <@Betelgeuse> Last week is fine by me.
-21:31 <@dertobi123> solar: we should announce the default meeting time at the end of each meeting plus in the summary.
-21:32 <@dertobi123> and then it doesn't matter which week it is
-21:32 <+jmbsvicetto> The 4 weeks problem is summed up as 52/4 = 13 ;)
-21:32 <@solar> Oh one last thing. Who wants to do the summary for the this meeting?
-21:32 <@Calchan> sorry, I had lost my screen due to internet issues, consider me out now
-21:33 <@Calchan> I'll post comments on the meeting to the alias later
-21:33 <@leio> I can do the summary draft
-21:33 <@solar> thank you
-21:33 <@dertobi123> ok, next meeting on august 17th?
-21:34 <@ulm> fine with me
-21:34 <@leio> fine
-21:34 <@Betelgeuse> fine
-21:34 <@solar> no objections
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090817-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090817-summary.txt
deleted file mode 100644
index 387d59cb27..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090817-summary.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: absent
-Calchan: here
-dertobi123: here 
-leio: here
-lu_zero: absent, slacker mark
-solar: absent, proxied by ssuominen
-tanderson(secretary): here
-ulm: here
-
-There was no agenda for this meeting. However solar suggested that we discussed
-the tenth anniversary effort although without any specific intention.
-
-The council talked generally about the 10th anniversary release but no
-decisions or plans to move forward were made.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090817.txt b/xml/htdocs/proj/en/council/meeting-logs/20090817.txt
deleted file mode 100644
index 3d24dfd6ff..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090817.txt
+++ /dev/null
@@ -1,211 +0,0 @@
-13:58 < ssuominen> It's 1800 UTC?
-13:59 <@leio> in 2 minutes, yes
-13:59 <@dertobi123> not yet
-13:59  * ssuominen runs ntpdate
-14:00 <+tanderson> now it is
-14:00 < ahf> hah.
-14:00 <+tanderson> ahf: did I get it at :00 ? :)
-14:00 < ahf> you did.
-14:00 <@leio> Ok. Who's chairing?
-14:01 -!- gwendely [n=Administ@4103ds5-ynoe.0.fullrate.dk] has joined #gentoo-council
-14:02 <@leio> lets start with a rollcall then first..
-14:03 <@Calchan> here
-14:03 < ssuominen> here (proxying solar)
-14:03 <@ulm> \o/
-14:03 <@dertobi123> <- here
-14:04 < ssuominen> I never saw an agenda for this meeting. There's none?
-14:04 <@dertobi123> there's none
-14:04 < ssuominen> nod
-14:04 <@dertobi123> besides the request to discuss "10 years gentoo"
-14:05 <@Calchan> isn't anybody shamed?
-14:05 <@leio> lu_zeor/lu_zero, betelgeuse?
-14:05 <@dertobi123> and if zmedico is around - i'd happy to get a status update of eapi-3 implementation in portage :)
-14:05 <@Calchan> because I know I am
-14:05 < ssuominen> well, latest about 10.0 livecd's (from what I know)
-14:05 <@dertobi123> +be
-14:05 < ssuominen> 00:37 <likewhoa> updates now are about 40 new packages and kernel changes for both x86/amd64, plan on adding multiple kernel images to the isos and  hybridiso option for the image next.
-14:05 < ssuominen> likewhoa won't be back until friday from his trip to work on the cd's
-14:06 -!- Poly-C_atwork [n=Poly-C@gentoo/developer/Polynomial-C] has quit [Read error: 104 (Connection reset by peer)]
-14:06 < likewhoa> Calchan: why the shame?
-14:06 <@dertobi123> likewhoa: because we did suck on putting an agenda together
-14:06 <@dertobi123> which we wanted to do a week beforehand
-14:06 < likewhoa> dertobi123: agreed
-14:06 < ssuominen> likewhoa: good, you're around :)
-14:07 <@Calchan> not only that, we did suck at doing anything since last meeting
-14:07 < likewhoa> ssuominen: just got here as leio said 'lets start'
-14:07 <@ulm> Calchan: it's holiday season though
-14:08 < ssuominen> yeah, it's quiet as usual this time of year
-14:08 <@ulm> but that's no real excuse
-14:08  * likewhoa agrees
-14:08 <@dertobi123> we should appoint someone who does make sure we have an agenda for next meeting (one week beforehand)
-14:08 < likewhoa> on at being not an excuse that is
-14:09 <@dertobi123> if noone else wants to - i can do that
-14:09 <@ulm> dertobi123++
-14:09 <@leio> I did some poking around at some projects I deem council related, but nothing noteworthy indeed, work deadlines and high priority other gentoo work in case of me
-14:10 <@leio> I was going to propose making some responsible for the next meeting as well, and always so. I think we briefly discussed that last time too?
-14:10 <@dertobi123> likewhoa: you have the specs in some public repository? any images to test around somewhere?
-14:10 <@dertobi123> we should make sure that cd will be tested as much as possible
-14:11 < likewhoa> dertobi123: I put up some images at http://weboperative.com/gentoo/downloads/livecds
-14:11 < ssuominen> Would something as marking 2008.0 profiles deprecated and instructing users to move into 10.0 ones at the same day when new LiveCD's are out something that needs councils attention?
-14:11 <@dertobi123> whee? installer?
-14:11 < likewhoa> and specs are at svn co svn://anonsvn.gentoo.org/releng/trunk/releases/10.0
-14:11 <@dertobi123> cool :)
-14:12 < likewhoa> dertobi123: well they will be livedvds, but initially was working on the livecd specs
-14:12 <@leio> ssuominen: maybe. I personally wouldn't want casual users moving over earlier than the release though
-14:12 <@leio> likewhoa: feel free to contact me about any GNOME related things, I'd like to see that top notch there
-14:12 < ssuominen> leio: people have already started moving, i don't see anything bad in that
-14:12 < likewhoa> dertobi123: currently new changes have not been committed but I do have a request for some testers.
-14:13 < ssuominen> i guess it's more of covering my own ass by requesting councils support for that move (dropping in the deprecated file to all arch's 2008.0 profiles when the livecds are out)
-14:13 <@dertobi123> ssuominen: i very much dislike marking the 2008.0 as deprecated that soon
-14:13 < likewhoa> leio: well desktop is xfce but I could use some testers for any gnome apps that might be on there. :)
-14:13 < ssuominen> ;)
-14:13 <@leio> ssuominen: I mostly have profile reorganizations in mind, changing some things potentially drastically (e.g my gnome profile mail)
-14:14 <@leio> likewhoa: it should be GNOME, it was made to be xfce for space reasons, which I believe are solved by now, or can be solved on time
-14:14 <@leio> (in 2008.0)
-14:14 <@dertobi123> ssuominen: haven't checked yet, but mailwrapper isn't use.default'ed anymore, right?
-14:14 < ssuominen> remi wanted to unmask new xcb in 10.0 ones (from package.mask) and there's make.defaults change that USE=qt3 and USE=esd isn't default anymore
-14:14 < ssuominen> otherwise they are identical
-14:14  * leio thinks we are a bit uncoordinated here
-14:14 < ssuominen> dertobi123: see above reasoning ^
-14:15 < likewhoa> leio: well solar mentioned he wanted it to be a livedvd since it will be circulated on some IT magazines, hence why I started to add new packages. I guess we need to discuss this with him.
-14:15 <@dertobi123> ssuominen: you want a bug report to remove mailwrapper or can you just commit that "fix"? :)
-14:16 <@dertobi123> leio: we are - basically because we lack an agenda
-14:16 < ssuominen> dertobi123: i'm not familiar with that issue in fact, you dropped that like a bomb ;)
-14:16 < likewhoa> leio: I have no problem using gnome.
-14:16 <@dertobi123> i'd prefer to have both kde and gnome and to make users able to choose what they want to use ;)
-14:16 < ssuominen> targets/server/make.defaults has make.defaults of mailwrapper
-14:17 < ssuominen> *use default
-14:17 <@ulm> maybe it would be a good thing to have a tracker bug for the livecd/dvd package set
-14:17 <@leio> likewhoa: lets discuss that later in my GNOME team capacity, I pretty much hear about you the first time now
-14:17 <@dertobi123> ulm: yep
-14:18 < likewhoa> leio: ok
-14:18 <@leio> yeah, KDE too on LiveDVD case makes perfect sense. We need all of the desktops on there work good though, which is a good motivation to get it into good shape for non-installer regular use as well. Release as a QA motivator
-14:19 <@ulm> and we need Emacs of course ;)
-14:19 <@ulm> which is not on any install media currently
-14:19 <@dertobi123> and we need a bug to track those requests ;)
-14:19 <@ulm> yes ;)
-14:19 <@Calchan> has anybody talked to releng about this new livecd/dvd?
-14:20 <@leio> by my understanding solar has
-14:20 <@leio> ssuominen?
-14:21 < ssuominen> yes, solar has, and agaffney should be informed as well
-14:21 < tove> "request to discuss "10 years gentoo"" -- does it only mean a new release? was it on any mailinglist?
-14:21 < ssuominen> (the profiles was created by my, solar and agaffney's consensus)
-14:21 < ssuominen> for the release
-14:22 < ssuominen> dertobi123: there's dozens of ebuilds using mailwrapper in IUSE, i'd very much like to get more information on that move :)
-14:23 <@dertobi123> ssuominen: plain simple: doesn't work, lots of bugs, deprecated.
-14:23 < likewhoa> I need a way to know which users will be available to test the iso images as they are made. What can be done?
-14:23 < ssuominen> dertobi123: in short: the IUSE should be removed from affected ebuilds and mailwrapper masked for removal?
-14:24 <@dertobi123> ssuominen: that's a partially happening for quite some time, i've been slacking on getting mailwrapper removed for quite some time though ;)
-14:24 < ssuominen> dertobi123: i can pull some treecleaning strings ;P
-14:24 <@dertobi123> likewhoa: what about including smolt-gentoo and collecting hardware-profiles from the test images?
-14:25 <@dertobi123> likewhoa: if you need testers some forums announcement or just a thread in the forums is a good start to get "a few" testers :)
-14:25 < ssuominen> sticky forums thread
-14:26 < likewhoa> I also like to make a request on #gentoo's topic mentioning the upcoming "screenshot contest" we could use more exposure on that.
-14:27 <@dertobi123>  #gentoo's topic isn't something the council needs to discuss
-14:27 < bonsaikitten> likewhoa: mention it in #-ops, we should find some space in /topic
-14:28 < likewhoa> dertobi123: I might need to talk to you about your last request as I am not that familiar with smolt usage, but I'll look into it myself before hand.
-14:29 <@dertobi123> seeing that we have only about 6 or 7 weeks left until our 10th birthday, what about weekly status updates on the -dev lists?
-14:29 <@dertobi123> likewhoa: sebastian pipping is working on that (summer of code project), see the -dev list or just mail him :)
-14:29 < likewhoa> i will
-14:30 < likewhoa> I won't be active until this coming friday, but I have lots of updates for the spec file and new images.
-14:31 <@leio> any other things the council should see happen for the 10th birthday, release related and any other plans or activities?
-14:33 <@dertobi123> birthday parties around the world would be cool - but not really having pr@g.o that's not realistic
-14:33 < likewhoa> I am not sure if catalyst will support multiple desktop environments and I am sure it won't support multiple kernels specially 32/64bit kernels and hybridiso to name a few. I will need to customize the image for those options and more.
-14:34 <@dertobi123> or talk to agaffney to get as much feature as possible into catalyst :)
-14:35 < likewhoa> I will :)
-14:35 < ssuominen> dertobi123: opened a bug for mailwrapper and punted it from make.defaults
-14:35 <@dertobi123> ssuominen: :]
-14:36 <@ulm> ssuominen: there's already bug 158003
-14:36 < Willikins> ulm: https://bugs.gentoo.org/158003 "Remove mailwrapper"; Gentoo Linux, Applications; NEW; wschlich@g.o:wschlich@g.o
-14:36 < ssuominen> utter fail
-14:36 <@dertobi123> args
-14:36  * ssuominen swears he did search
-14:37 <@dertobi123> heh
-14:37 <@dertobi123> my fault
-14:37  * dertobi123 hides
-14:37 <@leio> I'm sure council doesn't need to worry about these small things
-14:37 <@leio> regarding birthday parties, we should see what PR and dabbott think of it
-14:38 <@leio> (under small things, I mean specific bugs to get fixed by the release finalizing)
-14:39 <@leio> I plan to arrange something simple birthday-wise locally at least in my case
-14:39 < ssuominen> leio: true
-14:39 <@dertobi123> dito
-14:40 < likewhoa> Well I was planning on making a bunch of gentoo related screenshots, maybe something PR can work with me on.
-14:40 < likewhoa> s/screenshots/wallpapers/
-14:41 < likewhoa> maybe a 10 year roadmap 2010 calendar perhaps
-14:42 < ssuominen> We used to have the gentoo artwork project too, but nothing came out of it..
-14:42 < ssuominen> cla started it
-14:42 -!- impulze [n=impulze@eta-ori.net] has joined #gentoo-council
-14:42 < ssuominen> but might ask him still?
-14:43 < likewhoa> I'll ping him then
-14:45 <@leio> lets get this discussion going on mailing list too
-14:45 <@leio> I trust ssuominen and likewhoa will start appropriate threads as appropriate for points of discussion, right? :)
-14:46 < likewhoa> I'll let ssuominen start the initial thread.
-14:46 <@leio> and tracker bug
-14:47 < ssuominen> likewhoa: let's discuss shortly on query of the context of the thread (summarize above)
-14:47 < likewhoa> that too, just pm the bug # and i'll cc myself.
-14:47 < likewhoa> ok ssuominen
-14:47 <@leio> ok, what else birthday related?
-14:48 < likewhoa> leio: Whatever became of the new gentoo.org layout project? After 10 year we still have the same website.
-14:49 < likewhoa> sorry if this is not a related discussion.
-14:49 < ssuominen> the appropiate bugs to change gentoo docs are already open for 10.0 profile change, eselect profile usage, etc.
-14:49 < ssuominen> will link them to the tracker
-14:50 <@leio> I think there can be thread to ask what achievable could be done, and we should oversee things happening
-14:50 <@leio> Should we move on to any other topics? (open floor, etc)
-14:50 < ssuominen> yes
-14:51 <@leio> dertobi123: so you take responsibility for the next meetings agenda? (and then next meeting someone else can take it for the next one after that)
-14:51 <@dertobi123> leio: yep
-14:52 <@leio> Next question would be - When is the next meeting
-14:52 <@dertobi123> september 14th?
-14:53 <@leio> I had some vague thoughts of earlier meeting due to missing agenda, but there was an automated (but Thursday mention) e-mail with no replies, so September 14th sounds good for me too. Others?
-14:54 <@ulm> fine with me too
-14:54 <@Calchan> godd for me too
-14:54 <@Calchan> s/good/godd/
-14:54 -!- dertobi123 changed the topic of #gentoo-council to: Next meeting Monday September 14th 1800UTC.
-14:54 <@Calchan> or vice versa
-14:54 <@dertobi123> heh
-14:54 <@dertobi123> anything left for today?
-14:55 <@dertobi123> who can write a short summary?
-14:55 <@leio> do we have tanderson doing that?
-14:55 <+tanderson> leio: yes
-14:55 <@dertobi123> ok, cool
-14:55 <+tanderson> leio: I didn't see anything much to summarize though
-14:56 < Arfrever> Re implementation of EAPI="3" in Portage: There was almost no progress in the last month :) .
-14:56 <@leio> any idea when you can work on it? Now that we have meetings on Monday, weekend isn't that ideal
-14:56 <@dertobi123> Arfrever: arg :(
-14:56 < Arfrever> dertobi123: zmedico is busy with implementation of support for Python 3.*.
-14:56 < Philantrop> tanderson: "The council discussed anything coming to their mind vaguely related to the 10th anniversary." <-- here you are! ;-)
-14:57 < tove> "The decision was made to wait for lu_zero's vote by email.
-14:57 < tove> " -- did he?
-14:57 <+tanderson> Philantrop: not helpful
-14:57 < tove> wrt public or alias drafts
-14:58 <@dertobi123> tove: iirc no
-15:00 <@ulm> in spite of EAPI 3 being delayed, we should start working on the EAPI 4 feature list at some time
-15:01  * bonsaikitten stabs ulm a bit
-15:01 < bonsaikitten> we should work on deprecating obsolete EAPIs then too
-15:01 < Arfrever> I would like to request inclusion of support for multiple ABIs in EAPI="4".
-15:02 <@ulm> Arfrever: we shouldn't have the council discuss all the details, imho
-15:02 <@leio> at some time sounds good. Do we have a working group to "bless" to work on it at the beginning? :)
-15:03 <@ulm> leio: that's exactly what we need
-15:03 <+tanderson> leio: Calchan had some ideas about that iirc
-15:04 <@Calchan> read my manifesto
-15:05 <+tanderson> leio: did you mean "any idea when you can work on it" to me?
-15:06 <@leio> tanderson: yes
-15:06 <+tanderson> oh
-15:06 <+tanderson> I'll work on it over the week
-15:06 <+tanderson> I just used the weekend because it was simpler and it was only a 48 hour delay
-15:08 -!- bearsh [n=quassel@adsl-245-48-fixip.tiscali.ch] has quit ["No Ping reply in 90 seconds."]
-15:09 -!- bearsh [n=quassel@adsl-245-48-fixip.tiscali.ch] has joined #gentoo-council
-15:09 <@dertobi123> so, we're done?
-15:09 <@leio> regarding EAPI, I think if someone wants to kickstart the next one already without EAPI=3 being implemented in portage, I see the best course of action being to form a working group that the council can trust this work with and propose it on the mailing list or for the next meeting to discuss (mailing list should be quicker..). Any objections?
-15:10  * Calchan wonders where leio got that idea from
-15:10 <@leio> I don't know, disregard that
-15:12 <+tanderson> I'll volunteer,
-15:14 <@leio> it was my view of the most productive course of action, which was to propose something concrete to the council on mailing list to discuss or for the meeting, which to my knowledge is the normal course of action anyway, so that's where I got the idea from..
-15:15 <@leio> us being proactive is another choice, but ulm is a council member... or we can choose to block any EAPI-4 work until 3 is done..
-15:16 <@ulm> leio: of course eapi-3 should have priority, but we can't postpone work on 4 indefinitely
-15:18 <@leio> being proactive would also be assigning someone (perhaps a council member) with the task of EAPI-4 and go from there
-15:19 <+tanderson> why don't we have a general committee for these types of things(EAPI issues mainly)? (not my idea, but it's a good one)
-15:20 <@leio> We are well over an hour, should we close the open floor and meeting and continue post-meeting and mailing list?
-15:20 <@Calchan> I was under the impression we were done for a long time
-15:22 <@leio> fine, we are or were done...
-15:23 <@dertobi123> ok
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090914-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20090914-summary.txt
deleted file mode 100644
index f91be26d75..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090914-summary.txt
+++ /dev/null
@@ -1,39 +0,0 @@
-Roll Call:
-===========
-Betelgeuse: here 
-Calchan: absent
-dertobi123: here 
-leio: here
-lu_zero: here
-solar: here
-tanderson(secretary):  absent, but logged it
-ulm: here
-
-Update on LiveCD/DVD for Gentoo 10.0.
-====================================
-    
-        Ned Ludd(solar) commmented that things were progressing fine. A new snapshot
-    will be taken on September 20th and the cutoff date will be the 4th of
-    October.
-
-A Way to Modify the PMS such that it doesn't directly involve the EAPI Process.
-===============================================================================
-
-        Joshua Jackson(tsunam) requested a decision on a process to modify PMS
-    without involving the EAPI Process.
-
-    There was discussion about whether PMS is a documenting simply documenting
-    the ebuild API or if it is a broader document covering the entire tree.
-    Agenda Item[1] 3.1 was deferred until the next meeting to be discussed on
-    mailing lists beforehand. 
-
-Discussion of the Need for a PMS/EAPI committee outside of the council.
-=======================================================================
-
-        Of the three proposals(An external committee consisting of package manager
-    representatives, a council member or two, and perhaps members of the PMS
-    project; Using the existing PMS project; Something completely different),
-    the council chose to do something complete different and what will be done
-    will be discussed on list or next meeting.
-
-[1]: http://archives.gentoo.org/gentoo-council/msg_96c702e85f79b8f5e22472ae2c961534.xml. 
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20090914.txt b/xml/htdocs/proj/en/council/meeting-logs/20090914.txt
deleted file mode 100644
index 38b04fbfde..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20090914.txt
+++ /dev/null
@@ -1,262 +0,0 @@
-18:00 <@lu_zero> =)
-18:00  * dertobi123 yawns
-18:01  * lu_zero yawns as well
-18:01 <@dertobi123> luca!
-18:01 <@lu_zero> quite an annoying monday ^^;
-18:02 <@lu_zero> dertobi123 I'm ALIVE!
-18:02 <@lu_zero> (sort of)
-18:02 <@dertobi123> great :)
-18:02 -!- mode/#gentoo-council [+m] by solar
-18:02 <@dertobi123> so, rollcall?
-18:02 <@ulm> here
-18:02 <@lu_zero> \o/
-18:03 <@solar> solar here. but might have to leave. see above note
-18:03 <@dertobi123> k
-18:04 <@dertobi123> leio, Betelgeuse, Calchan ... wake up!
-18:04 -!- arkanoid [n=arkanoid@exherbo/developer/arkanoid] has joined #gentoo-council
-18:05 <@ulm> sigh
-18:05 <@leio> sorry, I've been sick
-18:07 <@dertobi123> ok, agenda item 1.1: who's logging?
-18:08 <@leio> I'm always logging, fixed my clock now as well.
-18:08 <@dertobi123> ok
-18:08 <@dertobi123> for 1.2 we have Betelgeuse and Calchan missing
-18:09 <@leio> has the agenda been publicized?
-18:09 <@ulm> leio: see topic
-18:09  * dertobi123 sighs
-18:09  * leio looks at topic
-18:09 <@dertobi123> look at the topic, gentoo-council@g.o, dev-announce@g.o and council@g.o please
-18:10 <@leio> ok, I see, I just didn't see it in my client, because I apparently haven't opened mail client to filter it for the past days due to being ill, sorry
-18:11 <@dertobi123> so, who wants to chair this meeting?
-18:12 <@lu_zero> dertobi123 you would?
-18:13 <@dertobi123> if noone else does ... yeah
-18:13 <@dertobi123> any updates on 2.1 "everything on 10 years gentoo"?
-18:13 <@dertobi123> if you need voice please /msg
-18:14 -!- miknix [n=miknix@gentoo/developer/miknix] has quit [Client Quit]
-18:15 <@solar> it's been going fine. the 20th is our cutoff day and 4th is the bday
-18:16 <@dertobi123> solar: you're going to take a new snapshot on 20th or putting in security updates until then?
-18:17 <@Betelgeuse> i am online in a couple minutes
-18:18 <@Betelgeuse> phone now
-18:21 <@dertobi123> well, lets move on
-18:21 <@dertobi123> 3.1
-18:21 <@dertobi123> ciaranm answered this topic is obsolete
-18:21 -!- mode/#gentoo-council [+v tsunam_] by dertobi123
-18:21 <@Betelgeuse> need to setup better reminders
-18:21 <@dertobi123> tsunam_: can you confirm?
-18:22 <@dertobi123> (or ulm?)
-18:22 <@dertobi123> or Fauli?
-18:22 <@solar> tsunam/jmbsvicetto: ping ^
-18:22 <@solar> my understanding is userrel is not saying it's obsolete
-18:22 <@ulm> i haven't heard anything from them
-18:25  * dertobi123 sighs
-18:25 <@ulm> see http://bugs.gentoo.org/show_bug.cgi?id=273261#c18
-18:25 <@ulm> but I don't know if such a meeting took place
-18:25 <@dertobi123> so we do skip this one? any objections?
-18:26 <@dertobi123> if there's still something to discuss or decide we can do so via mail
-18:26 <@ulm> dertobi123: fauli has something to say
-18:26 -!- mode/#gentoo-council [-v Fauli] by dertobi123
-18:26 -!- mode/#gentoo-council [+v Fauli] by dertobi123
-18:26 <@dertobi123> args
-18:26 <@lu_zero> ^^
-18:26 <@dertobi123> yeah
-18:26 -!- mode/#gentoo-council [+v trelane] by solar
-18:26 <+Fauli> :)
-18:26 <@solar> trelane is asking to speak
-18:26 <@lu_zero> well that
-18:26 <@lu_zero> Fauli first
-18:27 <+Fauli> The only thing I wanted to add, that I neither have heard anything or any progress.
-18:27 <@dertobi123> ok, thanks Fauli
-18:27 <+tsunam_> I'm here sorry for my delay
-18:28 <+tsunam_> dertobi123: to answer the query. No this is not resolved, ciaran would just like to have it considered resolved
-18:28 <@dertobi123> so, is there any progress?
-18:29 <+tsunam_> that's pending the discussion on this matter
-18:29 <+tsunam_> dertobi123: however I'm not hopeful that there will be progress quite frankly. But that gets into my personal experiences with the management of the PMS project and I'll avoid bringing that into the matter as it serves no purpsoes in the discussion
-18:30 <+tsunam_> would help if I could type correctly however ~_~
-18:30 <@ulm> tsunam_: that will be addressed in 3.2
-18:30 <@lu_zero> =\
-18:30 <@lu_zero> trelane you wanted to add something
-18:30 <+tsunam_> to address this issue however, there is currently one method of change for anything currently
-18:31 <+tsunam_> that's an EAPI
-18:31 <+tsunam_> by the name its and Ebuild API
-18:31 <+tsunam_> there's things that have been added to be under the PMS standard that are not directly ebuilds
-18:32 <+trelane> (I'm deferring to tsunam_ to finish)
-18:32 <@Betelgeuse> pms = package manager spec
-18:32 <+tsunam_> following a guideline is appropriate for getting the approval however an EAPI has a far more rigorous(sp?) process for approval as it should
-18:32 <@Betelgeuse> not ebuild api
-18:33 <@ulm> the crucial question is if package.mask directories were established Portage behaviour before EAPI 0
-18:33 <@ulm> if yes then PMS should just be updated
-18:33 <@Betelgeuse> no
-18:33 <@ulm> if no then it should go into EAPI 4
-18:34 <@dertobi123> ulm: ack
-18:34 <@Betelgeuse> it's a vdry recent feature
-18:34 <+tsunam_> ulm: that's the issue I see is that EAPI is for ebuilds
-18:34 <+Fauli> tsunam_: But PMS specifies the surroundings, too.
-18:34 <+tsunam_> its shoehorning something into a system that its not really well served by
-18:34 <+Fauli> And profiles is a surrounding.
-18:34 <+tsunam_> Fauli: it does, and I'm not suggesting that PMS shouldn't
-18:35 <+tsunam_> Fauli: what I'm suggesting is that EAPI's are quite possibly not the best location for those surrounding items
-18:35 <+Fauli> Betelgeuse: Zac told on the bug that it was available in all 2.1 versions.
-18:35 <+trelane> Betelgeuse, Zac with specificity says it is not a very recent feature http://bugs.gentoo.org/show_bug.cgi?id=273261#c36
-18:35 <+Fauli> tsunam_: Where else?
-18:35 <@Betelgeuse> 2.1 is recent
-18:35 <+tsunam_> that there might and could/should be implemented a new method of modifications to those surrounding features
-18:36 <+Fauli> tsunam_: I see it differently, but this leads to far. Let's concentrate on this topic.
-18:37 <+tsunam_> Betelgeuse: branch 2.1 created 3 years ago
-18:37 <+tsunam_> Betelgeuse: not so recent
-18:37 <+trelane> Betelgeuse, package.* support has been existant since the 2.1 dev cycle
-18:38 <@leio> and when was EAPI-0 defined?
-18:38 <+trelane> leio, October of last year IIRC
-18:38 <@Betelgeuse> EAPI 0 is supposed to be very ancient portage
-18:38 <+tsunam_> Fauli: that's something to discuss the where...perhaps another mechinism within PMS
-18:39 <+tsunam_> Fauli/ALL: I don't wish to remove anything from PMS
-18:39 <+trelane> Betelgeuse, was a specific version ever set?  3 years is pretty ancient in software terms
-18:39 <+tsunam_> All I'm suggesting/wishing for is that there's consideration that EAPI's are not the best area for things that are surrounding and not directly related to Ebuild API
-18:39 <@Betelgeuse> I would write a long explanation if my phone allowed
-18:40 <@Betelgeuse> my laptop refuses to connect
-18:40 <@dertobi123> ok, to sum up: there's something to discuss which could (and should!) happen on a mailinglist
-18:40 <+Fauli> tsunam_: Profiles are directly linked to ebuilds as some syntax (package atoms) will be used there.
-18:40 <+Fauli> dertobi123: Propose one.
-18:40 <+tsunam_> leio: believe and don't quote me that PMS came into being about 2007, so the draft would of started about then as well
-18:41 <@dertobi123> -dev or -pms mailinglist, dev to reach more people
-18:41 <@dertobi123> Fauli: ^^
-18:41 <+Fauli> Ok.
-18:41 <+trelane> dertobi123, this has been discussed ad infinitum et ad nauseum on the bug referenced in tsunam_'s request and is now before the council for some sort of direction forward.
-18:41 <@ulm> tsunam_: December 2006 if I believe the git log
-18:42 <@ulm> but I don't know if that was already any usable version
-18:42 <@dertobi123> trelane: there's been lots of discussion, but no real suggestions for improvements
-18:43 <+tsunam_> dertobi123: because quite frankly any suggestion is soundly rejected
-18:43 <+tsunam_> because "there's EAPI" for that
-18:43 <@dertobi123> rejected by whom?
-18:43 <+trelane> dertobi123, I for one would like clarified ciaran's notion that EAPI's do amend the profiles/ portion of the tree.  There seems to be a great deal of confusion on this issue.
-18:43 <+trelane> dertobi123, Ciaran
-18:43 <+trelane> (hence that bug's existence)
-18:44 <@dertobi123> simply put it, it doesn't matter what ciaranm is rejecting
-18:44 <+trelane> dertobi123, then could he possibly stop rejecting it if he has no power to do so as it only muddies the issue?
-18:44 <@dertobi123> at least not for gentoo
-18:45 <+trelane> (by the way I think we're organically proceeding to 3.2 in this discussion here)
-18:45 <+tsunam_> I'd like to keep them seperate if possible
-18:45 <+tsunam_> as they are two different issues
-18:45 <@dertobi123> we're not going solve 3.1 today
-18:45 <@dertobi123> +to
-18:45 <+trelane> agreed, dertobi123 with the chair's permission I'd like to proceed to 3.2 (I think tsunam_ would as well), thus leaving 3.1 unresolved
-18:46 <@dertobi123> if there are no other objections, then lets move on to 3.2 - let's get 3.1 discussed on lists and on our agenda for our next meeting
-18:46 <@dertobi123> -other
-18:46 <+Fauli> Ok
-18:47 <@ulm> fine with me
-18:47 <@lu_zero> ok
-18:47 <@solar> ok
-18:47 <@dertobi123> ok, 3.2
-18:47 <+trelane> I'd like to start by discussing the background of 3.2 as it affects (effects?) the previously mentioned bug
-18:47 <@dertobi123> as 3.2 was proposed by ulm i'd like to hear from him first of all
-18:48 <@ulm> trelane: we've just decided the discussion on said bug is finished for this meeting
-18:48 <@ulm> dertobi123: see my message to -council, where I proposed 3.2.{1,2,3}
-18:49 <@ulm> I'd like to hear the council members' opinion on it
-18:49 <@dertobi123> so we can vote upon that, ok?
-18:49 <@solar> I would go with 3.2.3
-18:49 <+tsunam_> I'd at least like some kind of idea if the council believes that there would be value in having changes to the surrounding items implemented on a fairly quick basis, but I'll bring that up in whatever discussion place it takes point in
-18:49  * lu_zero would as well
-18:50 <@ulm> solar: please be more specific
-18:50 <@dertobi123> lu_zero: as well, please
-18:50 <@solar> as the existing system does not really work for the masses and seems targeted towards benefiting a very few while limiting the rest of gentoo and it's ideas
-18:51 <@dertobi123> i'd choose 3.2.1 if we do opt to keep pms/eapi and it's surroundings and not choose some *completely* different
-18:52 <@ulm> solar: but we also need some process for updating the spec
-18:52 <@lu_zero> I'm not exactly happy with both .1 and .2 proposals
-18:53 <@lu_zero> and seems that the pms related stuff usually lead to feuds
-18:53 <@dertobi123> solar: what would be your different and improved system?
-18:53 <@Betelgeuse> The spec is not a problem. Portage coding is.
-18:53 <@solar> the current system more or less has to be approved by outside forces that many ppl plain and simply don't get along with. When you have that direct conflict all the time it hurts more than helps us as a distro.
-18:53 <@solar> dertobi123: I don't know the end solution. But 3.2.1 and 2.3.2 are not without problems
-18:53 <+tsunam_> gent's can you link to the 3.2.1, 3.2.2,3.2.3 specs for those who are not aware of what the solutions you are talking about
-18:53 <@solar> s/2.3.3/3.2.2/
-18:54 <@dertobi123> i'm pretty sure we could find something better, than 3.2.1 and 3.2.2 ... yeah
-18:54 <@solar> it's in the topic.
-18:54 <@ulm> tsunam_: http://archives.gentoo.org/gentoo-council/msg_96c702e85f79b8f5e22472ae2c961534.xml
-18:54 <@Betelgeuse> ciaramn is fine with Gentoo devs in charge
-18:55 <@lu_zero> even if the dev would be bonsaikitten ?
-18:55 <+trelane> Betelgeuse, he causes a huge problem for the larger community
-18:56 <@Betelgeuse> not every dev
-18:56 <+trelane> no, but quite a few of them.  for PMS to work it must be easy for outside projects such as Gentoo, Sabayon, and yes even Paludis to interface with
-18:57 <@Betelgeuse> he asked me and dev_zero at least
-18:57 <+trelane> right now only 1/3 of those groups can interface
-18:57 <+trelane> s/Gentoo/Funtoo in the above please
-18:57 <+trelane> though adding Patrick I'd say Gentoo might be apt as well
-18:57 <@dertobi123> so, to sum up: we tend to prefer 3.2.3 ... let's collect ideas for 3.2.3 until our next meeting and/or on list
-18:58 <@dertobi123> objections?
-18:58 <@ulm> dertobi123: right, let's postpone it. also calchan is not here, he also had some ideas about this topic
-18:58 <@lu_zero> ok
-18:58 <+tsunam_> what will occur in the meantime?
-18:58 <+trelane> dertobi123, I'd like to specify a lpcation for this (preferably a bug) where commentary and a proposal can be worked on
-18:58 <@Betelgeuse> i can't see agenda easily
-18:59 <@dertobi123> trelane: file one, but discussion should happen on a list (again -dev or -pms would make sense)
-18:59 <@ulm> trelane: bugzilla is horrible for long discussions
-18:59 <@ulm> dertobi123: let's go for -pms, and we can announce it on -dev-announce once
-18:59 <@Betelgeuse> mail list please
-19:00 <@dertobi123> ulm: ok
-19:00 <+trelane> I'm fine with -pms so long as this doesn't drag out on -dev?
-19:00 <+trelane> I will agree with Ciaran regarding the trolls.
-19:00 <@dertobi123> let's get it discussed on -pms
-19:00 <+trelane> it hurts both sides of the argument.
-19:00 <+trelane> thanks :)
-19:00 <+tsunam_> I'll have to read the archives on that then as I don't subscribe to -pms
-19:00 <@dertobi123> so, i'd propose to postpone 4, doesn't make sense to handle it today as Calchan is missing
-19:01 <@Betelgeuse> fine
-19:01 <@dertobi123> 5.1 next meeting, next logical date is october 12th
-19:01 <+tsunam_> Betelgeuse: you stated "not all devs" are you suggesting that if the Council wanted to put a member onto a advisory board and it wasn't approved by the current management that we'd have a larger issue to deal with at that time?
-19:01 <@dertobi123> ok for everyone?
-19:01 <@Betelgeuse> if someone is missing we should call them
-19:02 <@lu_zero> dertobi123 ok
-19:02 <@ulm> ok
-19:03 <@Betelgeuse> fine
-19:03 <@dertobi123> okies, so 5.2 - who's taking care of our agenda for october 12th?
-19:03 <@solar> Being that there was missing members from the council at this meeting. How would be feel about getting back together before then?
-19:04 <@Betelgeuse> I will write a post on PMS when by a computer
-19:04 <@Betelgeuse> i can do earlier
-19:04 <@dertobi123> solar: depends. if people request items for the agenda and don't show up it's quite useless to schedule a meeting before then. if there's useful discussion regarding that eapi/pms stuff we can of course schedule a meeting inbetween our regular schedule.
-19:05 <@lu_zero> solar which time?
-19:05 -!- arkanoid [n=arkanoid@exherbo/developer/arkanoid] has left #gentoo-council []
-19:05 <+tsunam_> Betelgeuse: I would suggest that if Ciaranm is fine with Gentoo dev's being lead on PMS that it should extend to all dev's having a catch on "no no not this dev" is not commiting to the idea that he's suggesting he's okie with
-19:06 <@Betelgeuse> do I get a slacker mark?
-19:06 <@solar> tsunam_: imo what Ciaranm is is not not fine with is 100% moot to what we do at gentoo
-19:06 <@leio> were you missing from previous meeting?
-19:06 <@Betelgeuse> I was away last time
-19:06 <@dertobi123> Betelgeuse: being 17 minutes late i'd say yes
-19:07 <+tsunam_> solar: I agree and that's kind of the point I'm making..that IMO there's an attempted ACE card being held back
-19:07 <@solar> if we can't think and act on our own. Then we all failed
-19:07 <+tsunam_> to more or less veto a nomination
-19:07 <@Betelgeuse> what was the limit
-19:08 <@Betelgeuse> hard to access 39 atm
-19:08 <@solar> you were here. There was no real voting that went on.
-19:08 <+trelane> solar, while I agree, he's certainly still hijacking the agenda
-19:08 <@dertobi123> okies, so again 5.2 - who's taking care of our agenda for october 12th?
-19:08 <@Betelgeuse> i can do
-19:09 <@Betelgeuse> unless slackered out
-19:09 <+tsunam_> solar: no, but just saying depending on what the council comes up with for 3.2.3 it has potential
-19:09 <@ulm> Betelgeuse: the meeting effectively started at 20:10 so I'd say you were not really late
-19:09 <@dertobi123> ok, so next meeting on october 12th, Betelgeuse takes care of agenda
-19:09 <@dertobi123> if it does make sense to have a meeting between the regular ones we decide so on list
-19:09 -!- mode/#gentoo-council [-m] by solar
-19:09 -!- mode/#gentoo-council [-vvvv trelane tsunam_ Fauli tanderson] by solar
-19:09 <@dertobi123> next one is open floor
-19:10 <@solar> tsunam_: sadly I think the council with probably be locked on this topic.
-19:10 < tsunam_> solar: *nods*
-19:10 <@solar> only way I see to solve the initial problem is to declare it obsolete
-19:10 < jmbsvicetto> So the whole discussion about PMS will move to the -pms ml?
-19:11 <@dertobi123> solar: might be an option.
-19:11 <@solar> but it's good to have things documented. Everybody loves a manpage
-19:11 -!- Zorry [n=zorry@fu/coder/zorry] has joined #gentoo-council
-19:12 <@solar> but should it be what we live by?? Harder to solve that
-19:12 < trelane> jmbsvicetto, seems so
-19:12 <@dertobi123> it has its advantages, but when it's main advantage is to slow down development and cause endless discussions ...
-19:12 < bonsaikitten> well, if it actively disallows innovation it's bad
-19:13 <@dertobi123> not actively, in-actively it might
-19:13 < bonsaikitten> uhm, package.mask as directory has been possible for >18 months
-19:13 < jmbsvicetto> dertobi123: I don't think the discussion is what's "slowing down" development. Instead, the way the discussion is taking place and the people that currently have authority over it would be to blame
-19:13 < bonsaikitten> not allowing it is kinda very silly
-19:13 <@solar> I have to pee very badly. Thank you all for coming and sharing your input
-19:14 <@solar> well not to the bathroom. But other input
-19:14 <@dertobi123> heh
-19:14 <@dertobi123> solar: have a nice pee :P
-19:14 <@Betelgeuse> i would like to drive where i have computer working
-19:14 < trelane> jmbsvicetto, I'd prefer to stop short of blaming Fauli as I would assert that effective control over the problem is effectively impossible
-19:14 <@dertobi123> jmbsvicetto: agreed.
-19:15 <@Betelgeuse> is the official part still on?
-19:15 <@dertobi123> no, we're done
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091012-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20091012-summary.txt
deleted file mode 100644
index f0e07cadcd..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20091012-summary.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Summary of Gentoo council meeting 12 October 2009
-=================================================
-
-Roll call
----------
-betelgeuse
-weaver (proxy for calchan)
-dertobi123
-leio
-lu_zero
-solar
-ulm
-
-Why follow up for items from last meeting never happened
---------------------------------------------------------
-
-Vote:
-People volunteer to follow up but if there's none the chair takes
-care of it and also reminds the volunteer
-
-Results:
-betelgeuse: ues
-ulm: yes
-leio: yes
-weaver: yes
-lu_zero: yes
-solar: neutral
-dertobil123: no
-
-EAPI 3 update
--------------
-
-zmedico didn't attend to give update
-
-Preservation of file modification times
----------------------------------------
-
-Reopening EAPI 3 for mtimes:
-
-betelgeuse, no
-leio: yes
-ulm: yes
-weaver: yes
-dertobil123: yes
-lu_zero: no
-solar: neutral
-
-Selecting from implementation alternatives
-http://bugs.gentoo.org/264130#c26
-
-leio: A
-weaver: A
-lu_zero: A
-ulm: B
-dertobil123: A
-betelgeuse: A|B
-solar: no vote
-
-Open floor
-----------
-
-Topic items:
-* multilib-portage
-* upgrade paths for old systems
- - leio and solar will do follow up
-* ulm will chair next meeting
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091012.txt b/xml/htdocs/proj/en/council/meeting-logs/20091012.txt
deleted file mode 100644
index 508048ac86..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20091012.txt
+++ /dev/null
@@ -1,331 +0,0 @@
-18:00 <@Betelgeuse> rollcall
-18:00 <@dertobi123> <- here
-18:00 <@leio> here
-18:00 <+tanderson> <--- here
-18:00 <@lu_zero> here
-18:00 <@Betelgeuse> weaver, solar
-18:00 <@Betelgeuse> ulm:
-18:00 < weaver> here
-18:00 <@ulm> here
-18:01 <@Betelgeuse> !seen solar
-18:01 < Willikins> Betelgeuse: solar was last seen 44 seconds ago, saying "araujo: not really. But the EAPI mess they created in system is to be frowned upon."
-18:01 -!- ssuominen [n=ssuomine@gentoo/developer/ssuominen] has joined #gentoo-council
-18:01 <@Betelgeuse> He should be around soon then.
-18:02 < likewhoa> Betelgeuse: he's currently active in #gentoo-ten, letting him know now.
-18:02 <+tanderson> he's active in #-dev too
-18:03 -!- jlec [n=jlec@ip-62-143-31-170.unitymediagroup.de] has joined #gentoo-council
-18:03 <@solar> damn I hate UTC. I figured it was not for another hr
-18:04 <@lu_zero> ^^;
-18:04 <@leio> date -u :)
-18:04 < weaver> everyone needs to just switch to utc
-18:04 <@Betelgeuse> Ok let's start with item 1.
-18:05 <@Betelgeuse> I propose it's the duty of the meeting chair to post any follow up and the secretary should remind him if it's not done when summaring is being approved.
-18:05 <@Betelgeuse> Then we don't have to wonder whose job things are.
-18:06 <@leio> That sounds reasonable when we are rotating chairs
-18:06 <@Betelgeuse> yes
-18:07 <@Betelgeuse> When someone accepts chair for a meeting they should be prepared to follow up too in the future.
-18:07 <@lu_zero> ok
-18:07 <@ulm> fine
-18:08 < weaver> sounds good
-18:08 <@dertobi123> i disagree - imho those who want things to be discussed should be the ones getting the discussion going on
-18:08  * solar seconds dertobi123 
-18:08 <@leio> that sounds reasonable too...
-18:08 <@dertobi123> i.e. of Calchan wants to discuss some glep39 stuff, i expect him to show up on the meeting and also to get discussion going
-18:08 <@dertobi123> s/of/if
-18:09 <@leio> then again, we should be proactive as a team and follow up on these things collectively and get them concluded
-18:10 < weaver> dertobi123: i think the point was if the council makes an actionable item, someone needs to be responsible for acting on it
-18:11 <@Betelgeuse> dertobi123: I have no problem with someone else taking responsilibity but the chair should do it if they don't.
-18:11 <@Betelgeuse> Otherwise nothing happens.
-18:11 <@ulm> dertobi123: if you take the "PMS/EAPI committee" example of last meeting, who should have acted on it, in your opinion?
-18:11 <@dertobi123> weaver: and the ones being responsible are those who want to see things happen - not necessarily the council itself which decided further discussion on that matter is necessary
-18:11 <@dertobi123> ulm: hrm, you?
-18:12 < weaver> the flexible solution i think is for every item on the agenda that the council decides to act on, to designate the person responsible
-18:12 < weaver> don't you guys do that already? :P
-18:12 <@lu_zero> better if there is one or more volunteers
-18:12 <+tanderson> I think if an actionable item is delayed, put one person in charge of that item
-18:12 <+tanderson> It's been done in the past and should work fine
-18:12 <@ulm> dertobi123: I disagree, because I had made two propositions
-18:13 <@ulm> dertobi123: the ones who voted for "something different" should have followed up with something concrete here
-18:13 <@solar> fine. dump it all and go back to eapi=0
-18:13 <@dertobi123> ulm: but then you want a decision, so it's your interest to get the discussion started
-18:13 <@dertobi123> solar: agreed.
-18:14 <@Betelgeuse> solar: let's stay on the topic at hand
-18:14 <@solar> that is my follow up.
-18:14 <@lu_zero> ulm so far the "kill pms for good" seemed to be the best solution =)
-18:15 <+tanderson> assigning someone for each item(and noting it in the summary) seems fine...
-18:15 <@Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer.
-18:15 -!- antarus|home [n=antarus@gentoo/developer/antarus] has joined #gentoo-council
-18:15 <@lu_zero> seems good
-18:16 <@ulm> also ok
-18:18 <@dertobi123> if there are no volunteers that specific topic is dead
-18:18 <@dertobi123> no one interested in getting things discussed, no important topic
-18:19 <@Betelgeuse> dertobi123: And what about purely administrative topics like slacker handling?
-18:20 <@dertobi123> Betelgeuse: what needs to be followed or discussed on such topics?
-18:21 <@Betelgeuse> dertobi123: Last time people did not vote on my slacker handling during the meeting so follow up was needed, not the best example
-18:21 <@Betelgeuse> Any way please vote so we can move to the next topic.
-18:21 <@leio> Vote on what?
-18:22 <@Betelgeuse> leio: 18:15 <@Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer.
-18:22 <@dertobi123> Betelgeuse: at the end of our last meeting it was clear you won't get a slacker mark, nothing to follow up (besides a summary being wrong in that aspect)
-18:22 <@solar> I have no input either way. Do whatever you guys feel is right
-18:22 <@leio> and additionally note in the summary as agreed
-18:23 <@lu_zero> seems balanced
-18:23 <@leio> (I suggest action points like, ACTION: description (volunteer), and noting down on top who was the chair)
-18:24 <@Betelgeuse> weaver: around?
-18:24 < weaver> yes
-18:24 <@Betelgeuse> weaver: your opinion?
-18:25 <@ulm> leio: that's a detail, do you think we must vote on it?
-18:25 <@leio> no
-18:25 < weaver> I vote on:  <Betelgeuse> So let's say: People volunteer to follow up but if there's none the chair takes care of it and also reminds the volunteer.
-18:25 <@leio> I'll just bend tanderson arm to do it like that :)
-18:25 <+tanderson> bahaha, usually works too =)
-18:26 <@ulm> I vote yes, too
-18:26 <@leio> I votes yes, to be clear
-18:26 <@dertobi123> no, obviously
-18:26 < weaver> ok, let's move on then
-18:26 <@Betelgeuse> So yes: Betelgeuse, ulm, leio, weaver neutral: solar no: dertobi123
-18:27 <@Betelgeuse> Topic 2
-18:27 <@Betelgeuse> zmedico: Are you here?
-18:27 <@dertobi123> uhrm, what abou lu_zero?
-18:27 <@Betelgeuse> damn counted like it was seven but failed
-18:28 <@solar> moot. Majority rule?
-18:28 <@leio> we have four yes already though, but I didn't see a clear vote from weaver
-18:28 < weaver> yes
-18:28 < weaver> ^ vote
-18:28 <@Betelgeuse> Please be more active than every 5 minutes
-18:28 <@lu_zero> I already voted long ago...
-18:28 <@lu_zero> anyway yes
-18:29 < weaver> ok, zmedico is not here to give us an EAPI 3 report?
-18:29 <@Betelgeuse> My guess is that no progress has been done.
-18:30 <@Betelgeuse> But it's just a guess.
-18:30 <@leio> When I inquired on #gentoo-dev a few days ago, he said that he wants to get a 2.1.7 release out before working on EAPI 3
-18:30 <@Betelgeuse> I don't remember reading any bug spam related to EAPI 3
-18:30 < antarus|home> the 2.1.7 release was this past weekend
-18:30 <@dertobi123> well, 2.1.7 is out ;)
-18:30 <@leio> I didn't ask if EAPI 3 work will follow immediate after that or not ;p
-18:30 <@ulm> If bug 273620 is accurate, then there are still several things missing
-18:30 < Willikins> ulm: https://bugs.gentoo.org/273620 "[TRACKER] sys-apps/portage EAPI 3 implementation"; Portage Development, Core; NEW; s.mingramm@gmx.de:dev-portage@g.o
-18:31 <@Betelgeuse> ulm: and they are the actually time taking parts
-18:31 -!- reavertm_ [n=reavertm@83.27.157.92] has joined #gentoo-council
-18:31 <@ulm> Betelgeuse: yes, looks like :(
-18:32 -!- Tommy[D] [i=bnc@gentoo/developer/tommy] has joined #gentoo-council
-18:32 <@Betelgeuse> Maybe we could offer a bounty for EAPI 3.
-18:33 <@Betelgeuse> But that's to discuss with trustees.
-18:33 <@lu_zero> I'd let another month pass and then think about it seriously
-18:33 <@leio> We could get an update very soon from Zac outside meeting time and post it in an e-mail for everyone to read
-18:34 <@dertobi123> we *should*
-18:34 <@Betelgeuse> So who volunteers to ask him?
-18:35 < antarus|home> why not just send him an email?
-18:35 <@Betelgeuse> antarus|home: email can be used to ask?
-18:35 <@ulm> well, if noone else volunteers... I can ask him
-18:36 <@Betelgeuse> ok
-18:36 <@Betelgeuse> I don't see anything further we can do for point 2 so let's move to case 3.
-18:37 <@Betelgeuse> Let's discuss 5 minutes and vote.
-18:37 <@Betelgeuse> I think if we open the list then we will have others requesting the same.
-18:37 <@solar> I'll vote right now that it should be left up to the respective PM's on how they want to deal with it.
-18:37 <@Betelgeuse> When energy could be better spend getting EAPI 3 out and work on EAPI 4 to be faster.
-18:37 <@leio> We can demand an implementation to exist
-18:37 <@solar> as mtimes can not be counted on in the first place (think compressed file systems)
-18:38 <@ulm> solar: that's exactly what we shouldn't do because it will result in breakage
-18:38 <@lu_zero> I second that
-18:38 <@lu_zero> ulm exactly how?
-18:38 <@ulm> there's good reason why portage preserves them
-18:39 <@ulm> lu_zero: see http://bugs.gentoo.org/263387 as one example, but there are several others
-18:39 <@solar> sure there is. But it can't be counted on. But can't be enforced properly ever
-18:40 <@leio> I don't see why a PM should mangle what the build systems make install does
-18:40 < weaver> I don't have an opinion as I'm not informed of upsides and downsides of mtime modification
-18:41 <@ulm> leio: right, it should try to preserve as much as possible when merging D to ROOT
-18:42 <@solar> there are valid reasons. But why are we going outside of the ebuild syntax and into behaviors that are best left up to the programmers coding the respective PM's ?
-18:42 <@solar> seems an overstep of the council
-18:42 <@ulm> solar: because the ebuild cannot do anything if the PM decides to mangle mtimes
-18:42 <@leio> We seem to be involved because paludis PM disagrees with portage and pkgcore PM
-18:43 < weaver> the PM spec is not just for syntax of the ebuilds
-18:43 <@Betelgeuse> Vote: Reopen EAPI 3 for mtimes?
-18:43 <@Betelgeuse> I vote no.
-18:43 <@solar> then perhaps they can duke it out?
-18:43 <@ulm> solar: see <http://bugs.gentoo.org/83877#c36> for horrible "solutions" on the ebuild level ;)
-18:43 <@leio> and because it is asserted it's an EAPI feature
-18:44 -!- reavertm [n=reavertm@gentoo/contributor/reavertm] has quit [Read error: 110 (Connection timed out)]
-18:44 <@leio> I vote yes
-18:44 <@ulm> I vote yes, obviously
-18:44 < weaver> hmm
-18:44 < weaver> I understand that calchan would vote yes
-18:44 <@ulm> weaver: calchan requested the feature for portage, btw ;)
-18:44 < weaver> so, I vote yes
-18:44 <@dertobi123> i vote yes, too
-18:45 <@lu_zero> yes also for me
-18:46 <@ulm> solar?
-18:46 <@Betelgeuse> yes: leio ulm  weaver dertobi123  lu_zero no: Betelgeuse ?: solar
-18:47 <@Betelgeuse> Then we need the wording.
-18:47 <@solar> ulm: I'm not sure right now. Majority rule.
-18:48 <@Betelgeuse> ulm: So do you have a short pros and cons to give about the options?
-18:49 <@ulm> Betelgeuse: Obviously A is the simplest and gives all control to the ebuild
-18:50 <@ulm> B will optionally allow the PM to update "old" time stamps
-18:50 < weaver> i'm sorry, where are the A/B/... described?
-18:50 <@ulm> and C will make that updating mandatory, but please note that C is not "zero cost" for Portage
-18:51 <@ulm> weaver: http://bugs.gentoo.org/264130#c26
-18:51 < weaver> ok thanks
-18:51 < weaver> what's the definition of an "old" mtime?
-18:52 <@leio> what do you mean under optionally in option B? PM can freely choose to do that or not, or the ebuild instructs it with some variable?
-18:52 <@ulm> weaver: time before the build process of the package started
-18:52 <@ulm> leio: PM can freely choose
-18:53 -!- lxnay|two [n=lxnay@host-78-14-152-87.cust-adsl.tiscali.it] has joined #gentoo-council
-18:53 <@ulm> leio: i.e. most likely Portage and Pkgcore would just preserve mtimes
-18:53 <@ulm> Paludis would update "old" ones
-18:53 < weaver> would that break stuff?
-18:53 -!- few [n=few@port-ip-213-211-233-28.reverse.mdcc-fun.de] has joined #gentoo-council
-18:54 <@ulm> weaver: hopefully not, but i've checked for lisp, python, and ghdl only
-18:54 <@Betelgeuse> zmedico prefers A
-18:54 <@ulm> right
-18:54 < weaver> then let's go with A
-18:55 < antarus|home> ulm: the intention is to prevent rebuilds with build systems based on mtime?
-18:55 <@ulm> antarus|home: the intent is more directed at runtime
-18:55 <@Betelgeuse> Please vote on a A|B|C and let's see if we get a majority (if not ready please note):
-18:55 <@ulm> antarus|home: e.g., .py vs .pyc or .lisp vs .fasl
-18:55 <@leio> A
-18:55 -!- Zorry [n=zorry@fu/coder/zorry] has joined #gentoo-council
-18:56 <@lu_zero> A
-18:56 < weaver> A
-18:56 <@dertobi123> A
-18:56 <@ulm> B
-18:57 -!- NeddySeagoon [n=NeddySea@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-18:57 <@ulm> (but I can live with A too)
-18:57 <@Betelgeuse> I am neutral between A and B.
-18:57 <@dertobi123> (i can live with b, too - but prefer A)
-18:58 <@leio> I understand B is the same as A in case of portage and pkgcore
-18:58 <@ulm> leio: right
-18:58 <@Betelgeuse> leio: yes
-18:59 <@Betelgeuse> A: leio, lu_zero, weaver, dertobi123 B: ulm A|B: Betelgeuse ?: solar
-18:59 < weaver> is there a specific option that ciaran/paludis is objecting against?
-18:59 <@ulm> weaver: he (they?) prefer C
-19:00 <@ulm> and paludis complies to none of the options presently
-19:00 < weaver> ok
-19:00 <@ulm> s/to/with/
-19:00 < weaver> I understand we have a majority on A, so let's move on then?
-19:01 <@Betelgeuse> The hour allotted is up. Anyone need to go or can we have some time for open floor?
-19:01  * leio has time
-19:02  * weaver has time
-19:02  * lu_zero has time
-19:02  * ulm has time
-19:02 <@Betelgeuse> Tommy[D] wanted us to talk about the multilib stuff.
-19:02 <@Betelgeuse> I havent' had much time to look into it.
-19:02 <@Betelgeuse> In the thread zmedico was saying it needs EAPI changes.
-19:02  * dertobi123 has some minutes
-19:02 <@Betelgeuse> So most likely EAPI 4 and as such would take time.
-19:02 <@leio> me neither, I hope to dig into that, have had various thoughts about that on my own, would be nice to see what they have done there
-19:03 -!- dabbott|work [n=david@gentoo/developer/comprookie2000] has quit ["Heading home"]
-19:03 <@lu_zero> I used myself the multilib overlay and is quite interesting (and useful)
-19:03 < Tommy[D]> Betelgeuse: did you also read my reply to him?
-19:04 <@Betelgeuse> Tommy[D]: it wasn't immediately evident from that
-19:05 < Tommy[D]> Betelgeuse: so optional, additional features would require EAPI, but not the basic functions
-19:05 <@ulm> Tommy[D]: would that require to change ebuilds lateron?
-19:05 <@ulm> i.e. when the "optional, additional features" have been implemented
-19:06 -!- antarus|home [n=antarus@gentoo/developer/antarus] has left #gentoo-council []
-19:06 < Tommy[D]> ulm: i use multilib-portage with main tree, if the ebuilds and build system respects the env, no changes are needed
-19:07 < weaver> i have no opinion on this
-19:07 < Tommy[D]> the only place, where you either need to depend a specific portage version (with multilib support) or an EAPI, which requires PM with multilib support, is the *DEPEND on libs/packages with additional 32bit libs
-19:07 < weaver> and i'm not aware if Calchan does
-19:08 <@Betelgeuse> For me I would like zmedico to first fogus on EAPI 3 before this stuff
-19:08 <@Betelgeuse> Of course he does what he wants with his time.
-19:08 < weaver> yes I believe eapi 3 needs to be pushed out ASAP
-19:09 < weaver> it's been delayed and it has a bunch of useful features
-19:09 < Tommy[D]> i did implent the current version of multilib-portage, based on previous work done by other people and i would continue working on it, so the main work would be a code review by zmedico
-19:09 <@Betelgeuse> Tommy[D]: Sure but it's a major feature to Portage
-19:10 <@Betelgeuse> Tommy[D]: Testing etc would slow down EAPI 3 to stable
-19:10 <@Betelgeuse> Tommy[D]: If it stays in trunk, then fine.
-19:10 < Tommy[D]> the main issue is that zmedico once got a council warning because of some changed or additional feature, thats why i request the discussion and later decision here
-19:11 < Tommy[D]> Betelgeuse: i would not mind, if it stays in 2.2_rc* for now, while EAPI-3 could go into 2.1.*
-19:11 <@Betelgeuse> Tommy[D]: Yes he did change EAPI 0 behavior without our blessing.
-19:11 <@Betelgeuse> Tommy[D]: Before I can vote on this it needs to be clear to me whether this does that.
-19:12 <@Betelgeuse> Tommy[D]: I think PMS currently says phases can run only once.
-19:12 <@Betelgeuse> I don't know what that is based upon.
-19:12 < Tommy[D]> it violates current PMS in at least 1 point: execute every phase at max once
-19:12 < weaver> this sounds like something we should intentionally delay until after EAPI 3 is out
-19:12 <@lu_zero> I think that could be relaxed
-19:13 <@lu_zero> still it could be done in parallel and make push it as the main part of eapi 4
-19:13 < Tommy[D]> my implementation would require something like "preserve none-default env vars in filesystem between phase switches"
-19:13 <@Betelgeuse> We can do an EAPI 4 that is fast for zmedico to implement.
-19:13 <@Betelgeuse> for needs in this
-19:14 <@Betelgeuse> and other fast stuff
-19:14 < weaver> as long as the people involved are sure it won't delay EAPI 3
-19:14  * leio has no opinion about this until some research
-19:15 <@solar> Till our devs learn how to use the existing EAPI's properly I have no desire to introduce another eapi
-19:15 <@Betelgeuse> solar: devs beside direct Portage deps should always use the latest
-19:15 < weaver> solar: how are they used improperly?
-19:15 < Tommy[D]> multilib-portage itself can be added without any additional EAPI
-19:15 <@solar> weaver: system. There is no clean upgrade path.
-19:15 < NeddySeagoon> Betelgeuse solar is that a reason to depreciate and remove old EAPIs ?
-19:16 <@Betelgeuse> NeddySeagoon: the stay in vdb
-19:16 <@leio> portage oralready requires EAPI-2 :9
-19:16 <@Betelgeuse> NeddySeagoon: We can make repoman require latest EAPI for new ebuilds
-19:16 <@Betelgeuse> NeddySeagoon: But only after discussion
-19:16 <@solar> that is sick
-19:17 < weaver> sick as in good or bad
-19:17 <@solar> bad and in evil and a dumb idea
-19:17 <@Betelgeuse> solar: there's fatal and warning repoman levels, this would fall in the latter
-19:17 < weaver> i don't see why not, as long as revisions are allowed in older eapis
-19:17 < Tommy[D]> Can multilib-portage inclusion be added to agenda of next meeting? And i would like to see comments, requests and discussion about it until then
-19:17 < NeddySeagoon> Betelgeuse, that would be good.  PMs have to be capable of removing old stuff ... but we should encourage the use of the current/latest EAPI
-19:17 <@solar> Betelgeuse: there is no clean upgrade path in that
-19:18 <@Betelgeuse> solar: You only need an upgrade path for direct Portage deps
-19:18 <@solar> I'm in favor of reverting lots of system packages back to EAPI=0
-19:18 <@Betelgeuse> solar: So you can get to new Portage
-19:18 < weaver> solar could you elaborate on what the problem is, I'm not familiar with it
-19:18 <@solar> weaver: take a box from 2008 and try to upgrade it. You can't
-19:18 < weaver> what happens?
-19:18 <@Betelgeuse> python
-19:18 < weaver> oh
-19:19 < Tommy[D]> weaver: old portage, which doesnt know EAPI-2 cannot upgrade because newer portage requires newer python, but all pyhton packages have EAPI-2
-19:19 <@Betelgeuse> python people decided for all to break upgrade path without warning.
-19:19 <@solar> gotta give it to bonsaikitten for one time. He had the right idea on how to allow a mix. You always keep one ebuild at EAPI=0
-19:19 < weaver> oh. can't we roll a transitional verison of portage that would deal with this issue specifically?
-19:19 <@Betelgeuse> I am not opposed to forcing them to add EAPI 0 upgrade path back.
-19:20 <@Betelgeuse> weaver: We don't need to.
-19:20 <@solar> this means you need a python-2.6 and eselect* at 0
-19:20 <@Betelgeuse> Just need python people to do their job.
-19:20 < weaver> i guess...
-19:20 <@Betelgeuse> They can't make decisions like that for everyone.
-19:21 <@Betelgeuse> solar: Could you take responsibility on working with them trying to get EAPI 0 back there?
-19:21 <@ulm> solar: hm? eselect is still at EAPI 0
-19:21 <@Betelgeuse> If it doesn't work out, we can put it on the agenda nexttime.
-19:21 <@ulm> solar: with good reason
-19:22 <@Betelgeuse> Who wants to chair next time?
-19:22 <@solar> Betelgeuse: I'm not sure I'm nice enough to work with them (I have much anger about this topic).
-19:22 <@leio> and take care of the agenda
-19:23 <@ulm> solar: sounds like you're the right person for it then :p
-19:23 <@solar> leio: I would second this for the next round then. 07:19PM <Betelgeuse> I am not opposed to forcing them to add EAPI 0 upgrade path back.
-19:24 <@solar> ulm: I do much better work when I'm happy. Gentoo 10 was a hit
-19:24 < weaver> should I volunteer Calchan to do this? :]
-19:24 <@Betelgeuse> weaver: probably not
-19:25  * ulm can take it
-19:25 <@leio> lets say I can look with solar into the upgrade path business
-19:26 <@Betelgeuse> ulm: chair or upgrade path?
-19:26 <@ulm> Betelgeuse: chair
-19:26 <@Betelgeuse> ok ulm chair and leio EAPI 0
-19:26 <@solar> leio: that would work. TeamWork++
-19:26 <@Betelgeuse> I call this meeting done. Thanks everyone.
-19:26 < weaver> thank you
-19:26 <@solar> thanks Betelgeuse
-19:26 <@ulm> question of understanding: followups are for the _previous_ chair, right?
-19:27 <@Betelgeuse> ulm: I would follow up from today.
-19:27 <@ulm> Betelgeuse: k
-19:27 <@Betelgeuse> I will make sure leio does.
-19:27 <@Betelgeuse> And you ask zmedico.
-19:28 <@lu_zero> please let's try to use more the council alias
-19:28 <@Betelgeuse> private is bad
-19:29 <@lu_zero> we have also the council ml
-19:29 <@Betelgeuse> better
-19:29 <@lu_zero> still both of them are quicker and easier to follow than -dev
-19:29 <@Betelgeuse> following -dev comes with the job
-19:30 -!- reavertm_ is now known as reavertm
-19:30 <@solar> the alias is proper for some things.
-19:30 <@solar> Not going to send a personal reminder to the entire list just to make sure ppl don't get the slacker mark.
-19:30 <@Betelgeuse> sure alias is fine for that
-19:30 <@Betelgeuse> but not discussing technical stuff etc
-19:31 <@solar> nod
-19:31 <@Betelgeuse> I am off to write a short essay that's due today.
-19:31 <@solar> well unless you don't want input from some ppl.
-19:31 <@solar> anyway cya.
-19:31  * dertobi123 nods
-19:32  * lu_zero runs away as well
-19:32 <@lu_zero> nite ^^
-19:33 < weaver> have fun people
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091109-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20091109-summary.txt
deleted file mode 100644
index 2db4480471..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20091109-summary.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Summary of Gentoo council meeting 9 November 2009
-=================================================
-
-Roll call
----------
-betelgeuse
-calchan
-dertobi123
-leio
-lu_zero
-patrick (proxy for solar)
-ulm
-
-EAPI 3 status
--------------
-Some progress, see tracker bug 273620. 8 out of 20 items are still
-missing.
-
-Upgrade path for old systems
-----------------------------
-Vote (unanimous): The ebuild tree must provide an upgrade path to a
-stable system that hasn't been updated for one year.
-
-Action: leio will start a discussion on gentoo-dev on if and how to
-support upgrading systems that are outdated more than a year.
-
-Prefix support in main Portage tree
------------------------------------
-The council unanimously supports the general idea, but sees need for
-additional discussion.
-
-Action: ulm will follow up on the open questions on gentoo-dev.
-
-Usage of bash 3.2 features in Portage tree
-------------------------------------------
-Vote (6 yes, 1 no): Usage of bash 3.2 features in the Portage tree is
-allowed. PMS will be updated accordingly.
-
-Vote (6 yes, 1 no): Ebuilds must be completely parsable with =bash-3.2*,
-any use of later bash features will be reverted.
-
-Preservation of file modification times in EAPI 3
--------------------------------------------------
-Postponed.
-
-Next meeting
-------------
-7 December 2009, 19 UTC.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091109.txt b/xml/htdocs/proj/en/council/meeting-logs/20091109.txt
deleted file mode 100644
index af8ed5d751..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20091109.txt
+++ /dev/null
@@ -1,518 +0,0 @@
-21:00:03 <ulm>	O.K., let's start
-21:00:05 ---	ulm sets mode +m #gentoo-council
-21:00:13 *	lu_zero murmurs things about xen-fullvirt and clock drifts
-21:00:22 ---	ulm gives voice to DrEeevil
-21:00:32 <ulm>	who's logging?
-21:00:42 <Betelgeuse>	I do as usual
-21:00:44 <leio>	Many probably are, me included
-21:00:59 <ulm>	roll call
-21:01:03 <leio>	here
-21:01:05 <Betelgeuse>	\o/
-21:01:06 *	lu_zero here
-21:01:12 *	dertobi123 yawns
-21:01:18 <DrEeevil>	here, representing solar
-21:01:43 <Calchan>	Im here
-21:02:26 <ulm>	we have too many topics for 60 minutes, so is it o.k. if we extend to 90 min today?
-21:02:33 <Betelgeuse>	yes
-21:02:39 <ulm>	or has anybody to leave sooner?
-21:02:39 <leio>	yes
-21:02:43 <lu_zero>	ulm fine
-21:02:48 <leio>	err, 90 minutes is OK 
-21:02:54 <DrEeevil>	ok
-21:02:56 <dertobi123>	would be nice if we can make it within 60 minutes
-21:03:27 <ulm>	dertobi123: "would be nice"? is this a veto?
-21:03:44 <Betelgeuse>	dertobi123: unlikely
-21:03:48 <dertobi123>	not a veto, just a "would be nice"
-21:03:52 <ulm>	k
-21:04:02 <lu_zero>	ulm I think the idea is to have the extension last the required time
-21:04:06 <Betelgeuse>	but do try to be active so if we vote ulm doesn't have to wait etc
-21:04:07 <lu_zero>	(less than 30 min)
-21:04:09 <Calchan>	90 minutes is KO here
-21:04:11 <Calchan>	OK
-21:04:40 <ulm>	I see no objections then
-21:04:56 <ulm>	2. Approve summary of October meeting
-21:05:07 <ulm>	no summary ready, afaik
-21:05:17 <ulm>	so we can skip this topic
-21:05:25 <Betelgeuse>	anyone want to pickup from tanderson ?
-21:05:32 <leio>	I started work on it, but can't have it ready before tomorrow evening
-21:05:50 <leio>	I can do both previous and this meeting
-21:05:54 <Betelgeuse>	leio: ok good
-21:05:58 <lu_zero>	thank you =)
-21:05:59 <Calchan>	leio, thanks
-21:06:26 <ulm>	leio: thanks
-21:06:26 ---	lu_zero gives voice to zmedico
-21:06:59 <ulm>	lu_zero: right, let's move to 3. Follow-ups from previous meeting
-21:07:14 <ulm>	zmedico: any update on EAPI 3 status?
-21:08:39 <ulm>	anyone else?
-21:08:49 <lu_zero>	zmedico maybe didn't expect us to be this fast
-21:09:21 <ulm>	there's quite some progress in tracker bug 273620 compared to one month ago
-21:10:09 <lu_zero>	8/20 missing
-21:10:16 <ulm>	yeah
-21:10:52 <Betelgeuse>	the items done are simple and quick
-21:11:30 <lu_zero>	most of the missing ones do not appear this bad as well
-21:11:34 <ulm>	right, but obviously there's progress
-21:12:11 <ulm>	should we move on?
-21:12:30 <Betelgeuse>	I think so
-21:12:32 <lu_zero>	Upgrade paths
-21:12:34 <Calchan>	ulm, yes let's move and maybe get back to this if zac shows up
-21:12:41 <ulm>	Calchan: k
-21:12:41 <lu_zero>	I agree
-21:13:18 <ulm>	leio: "Upgrade path for old systems"
-21:13:23 <leio>	I personally do not think in-tree versions of python certainly need to be EAPI-0 (but have to be EAPI-1), as presumably the system that is getting updated already has a python installed, so just a version of portage that supports newer EAPI (and its direct and indirect dependencies) need to work with EAPI-0, this includes depending on only a python version that used to be EAPI-0 and available for a long time. The main question in my mind
-21:13:23 <leio>	 is deciding how far back we want to support things _now_, and go from there to always support back to that point. Some ideas include making periodic portage tree snapshots and whitelisting necessary system packages for distfiles mirrors, so that it is always possible to upgrade step by step through these snapshots. I will follow-up on gentoo-dev for wider discussion with good initial discussion starting write-up soon
-21:14:18 <leio>	how much ago from today we want to support also related to the bash-3.2 question later in the agenda
-21:14:29 <leio>	relates*
-21:14:31 <Calchan>	I think the underlying question in all of this is how long we want to maintain upgrade paths, once we know that it's easy to see what was stable this long ago and if anything was broken then we fix it
-21:14:53 <Betelgeuse>	I would keep main tree in shape for one year.
-21:15:06 <Betelgeuse>	Then if we can provide snapshots and a guide that would be great.
-21:15:17 <Calchan>	I'd definitely agree with that
-21:15:19 <lu_zero>	Betelgeuse how many back snapshot/years ?
-21:15:20 <Betelgeuse>	Would mainly mean someone periodically tries to updgrade form an old snapshot.
-21:15:28 <DrEeevil>	as long as it is "simple" like keeping around only one version of all system packages (or all deps of portage) it has a low enough cost
-21:15:39 <Betelgeuse>	lu_zero: I would say two years.
-21:15:49 <Betelgeuse>	I have seen many times people trying to update around a year marker
-21:15:56 <Betelgeuse>	but beyond two years seems two much work
-21:16:04 <Betelgeuse>	s/two/too/
-21:16:22 <dertobi123>	we can archive snapshots every - say - three months and it's system packages distfiles
-21:16:23 <leio>	I don't think the cost in keeping support for upgrading from older system is big after we start doing it - users can go step by step, upgrade package manager to 2009 upgrade path snapshot helper, then to 2010, then to 2011, etc
-21:16:36 <lu_zero>	if we just have them incremental (snap0 -> snap1 -> ... -> current stable)
-21:16:38 <Betelgeuse>	If we have a good schedule for testing upgrades it should be quite simple.
-21:16:50 <lu_zero>	won't take more work but just space
-21:16:52 <leio>	only cost there would be distfiles and snapshot mirroring space
-21:16:55 <Betelgeuse>	I think someone just needs to take responsibility and start a project for this.
-21:17:10 <dertobi123>	i wouldn't say "we do this for 2 years" - as long as that's working it might be a benefit for people upgrading from much older boxes
-21:17:57 <Calchan>	dertobi123, as long as the snapshots are being done it's just a matter of disk space on our servers to keep them around
-21:18:06 <dertobi123>	Calchan: exactly, yes
-21:18:08 <lu_zero>	so we agree that we'll keep as many snapshot as possible within our infra/mirror limit or 2 years?
-21:18:18 <DrEeevil>	and that is negligible - system is ~100MB per snapshot
-21:18:34 <Calchan>	so there's no point limiting the storage to 2 years
-21:18:58 <leio>	I'll get a gentoo-dev discussion going in the coming days, summarizing all the current thoughts and ideas
-21:19:06 <lu_zero>	ok
-21:19:11 *	dertobi123 nods
-21:19:12 <ulm>	leio: sounds good
-21:19:27 <Betelgeuse>	leio: Could you start a project page too while at it?
-21:19:34 <Calchan>	lu_zero, let's say we require 2 years of snapshots and that beyond that it's infra's decision to keep what's older
-21:19:52 <lu_zero>	Calchan sounds good
-21:20:03 *	Calchan smells good too
-21:20:57 <leio>	Betelgeuse: maybe after discussion?
-21:21:02 <Betelgeuse>	leio: sure
-21:21:08 <Betelgeuse>	leio: just making sure someone follows up
-21:21:13 <Betelgeuse>	leio: and it's not just discussion and then nothing
-21:21:15 <leio>	Ok, but I'm not confident I can be involved with that project in the longer term
-21:21:19 <Calchan>	isn't there a 3 year retention requirement with the GPL ? we could sync with that too
-21:21:36 <leio>	that requirement applies to for-profits I think
-21:21:44 <Betelgeuse>	leio: sure but if you can't find someone just bring it up that we need someone
-21:21:45 <leio>	err, for non-community-distribution
-21:21:50 <leio>	Betelgeuse: nod
-21:23:02 <ulm>	anything else for this topic?
-21:23:22 <lu_zero>	we could move
-21:23:32 <ulm>	4. Prefix support in main Portage tree
-21:23:38 <Calchan>	hold on, what's the plan?
-21:23:41 <leio>	Calchan: actually good point, I think the alternative provided by 3c in GPL-2 only covers object code noncommercial distos
-21:23:49 <leio>	distros*
-21:24:02 <Calchan>	leio starts a discussion on -dev and we vote on the outcome of that next time?
-21:24:21 <Betelgeuse>	ulm: I think we should vote on the one year tree requirement
-21:24:42 <Betelgeuse>	to make it explicit
-21:24:58 <Calchan>	Betelgeuse, would that imply reverting any breakage that wouldn't satisfy the one year tree requirement?
-21:25:11 <Betelgeuse>	Calchan: yes
-21:25:12 -->	mpagano (n=mpagano@gentoo/developer/mpagano) has joined #gentoo-council
-21:25:19 <Calchan>	Betelgeuse, ok, thanks for the clarification
-21:25:40 <Calchan>	ulm, so do we vote?
-21:25:42 <Betelgeuse>	I would leave how to handle older than that to the leio started discussion and the resulting proejct
-21:25:44 <ulm>	Betelgeuse: can you word the question we should vote on?
-21:25:45 <leio>	I'd find it more reasonable to vote on this next time then
-21:26:11 <Betelgeuse>	ulm: Ebuild tree should provide upgrade path to a system that hasn't been updated in a year.
-21:26:29 <ulm>	Betelgeuse: leio has a point, there was no vote foreseen on the agenda
-21:26:50 <Betelgeuse>	ulm: You can ask if people are not ready to vote
-21:26:54 <Calchan>	ulm, so what? let's not find lame excuses for not making progress
-21:27:03 <Betelgeuse>	ulm: They can just say not ready
-21:27:09 <Betelgeuse>	ulm: Then we just don't get a majority
-21:27:19 <ulm>	ok, let's give it a try then ;)
-21:27:20 <leio>	the proposed wording sounds good to me for a todays vote too. I'd like some "at least" wording though
-21:27:24 <Calchan>	ulm, great
-21:27:45 <Calchan>	leio, good point
-21:27:50 *	dertobi123 agrees with leio
-21:28:01 <leio>	and s/should/must
-21:28:23 <ulm>	"Ebuild tree must provide upgrade path for at least one year."
-21:28:26 <Calchan>	so does everybody with the wording: "Ebuild tree must provide upgrade path to a system that hasn't been updated in at least one year"
-21:28:41 <ulm>	or that
-21:28:47 <lu_zero>	since the time of the newer snapshot?
-21:29:12 <ulm>	and maybe s/system/stable system/
-21:29:15 <leio>	this is irregardless of snapshots. Snapshots would provide a way to upgrade from even older systems
-21:29:16 <lu_zero>	since "an year" is a sliding definition
-21:29:55 -->	grobian (n=grobian@gentoo/developer/grobian) has joined #gentoo-council
-21:29:58 <Calchan>	lu_zero, sliding, but that means that I any time you don't need to resort to snapshots if you updated in the past year
-21:30:02 <leio>	"Ebuild tree must provide an upgrade path to a stable system that hasn't been updated for one year" would sound good to me
-21:30:18 <ulm>	^^ please vote on this
-21:30:24 <lu_zero>	fine for me
-21:30:28 <ulm>	yes from me
-21:30:29 <dertobi123>	ok for me
-21:30:30 <Betelgeuse>	yes
-21:30:34 <Calchan>	agreed, leio's wording is clear enough
-21:30:38 <Calchan>	and I vote yes
-21:30:46 <leio>	my "at least" proposal made it more confusing, sorry :)
-21:30:48 <leio>	I vote yes
-21:31:06 <ulm>	DrEeevil?
-21:31:30 <DrEeevil>	yes
-21:31:41 <ulm>	unanimous then
-21:31:48 <ulm>	let's move on
-21:31:50 <leio>	I propose adding in the summary also this: "The council encourages trying to keep ebuild tree upgrade path support for older system than a year as well"
-21:32:05 <leio>	but not important, this will be discussed in the thread I bet.
-21:32:16 <Calchan>	leio, I would keep that for the thread
-21:32:24 ---	ulm gives voice to grobian
-21:32:38 <ulm>	next topic "4. Prefix support in main Portage tree"
-21:33:13 <ulm>	grobian: can you give an outline of the proposal?
-21:33:43 <grobian>	ehm, well, it's pretty simple
-21:34:03 <grobian>	we propose to simply make a preparation for full prefix support to portage
-21:34:19 -->	reavertm (n=reavertm@aegv10.neoplus.adsl.tpnet.pl) has joined #gentoo-council
-21:34:26 <grobian>	that means that the variables EPREFIX, ED and EROOT will be initialised to the values '', D and ROOT
-21:34:51 <Calchan>	what are the implications for non-prefix devs?
-21:34:52 <grobian>	this gives the advantage that we don't have to set ED and EROOT in every ebuild we require them
-21:34:55 <Calchan>	and users
-21:35:23 -->	Innocenti (n=Innocent@ramonvanalteren.xs4all.nl) has joined #gentoo-council
-21:35:24 <grobian>	implications are outlined in my earlier mail to -dev
-21:35:29 <leio>	I'm worried about the implications of this being an EAPI feature in relation to the upgrade path concerns and usage of these variables in eclasses
-21:36:01 <grobian>	leio: can you be more specific?
-21:36:15 <Calchan>	grobian, do you have a link in the archives? I can't seem to find it anymore
-21:36:17 <leio>	eclasses use $D, $ROOT and so on
-21:36:33 <grobian>	leio: yes
-21:36:45 <ulm>	grobian: does it mean we have to substitute all occurences ${D} -> ${ED} and ${ROOT} -> ${EROOT} in ebuilds and eclasses?
-21:36:52 <leio>	the eclasses and ebuilds involved in package manager deptree should remain lower EAPI (EAPI-0 right now) to support upgrading the package manager
-21:37:07 <grobian>	ulm: unfortunately not all of them, that's why we need to make a distinction between the two
-21:37:29 <grobian>	leio: yes, but we can set ED if ED is not set to D, making them compatible in EAPI0
-21:37:36 <grobian>	(and up)
-21:37:38 <leio>	which means portage EAPI-2+prefix provided variables can't be relied upon (upgrade path stuff going to be discussed on gentoo-dev soon). Maybe the eclasses and ebuilds involved in there can define those themselves then
-21:38:06 <leio>	and for those eclasses and ebuilds that are allowed to upgrade EAPI requirements, it is a convenience
-21:38:09 <grobian>	leio: that's why we proposed using use prefix || local ED=${D}
-21:38:39 <leio>	ok, so something to just communicate very well if this is accepted
-21:38:46 <grobian>	Calchan: I'm searching
-21:38:52 <Calchan>	grobian, thanks
-21:39:15 <leio>	agenda had some link. That one?
-21:39:44 <grobian>	http://article.gmane.org/gmane.linux.gentoo.devel/63527/match=gentoo+prefix+eprefix
-21:40:20 <ulm>	yeah, that's the one in the agenda
-21:40:26 <ulm>	only on gmane
-21:40:34 <grobian>	see that thread for the idea to inject this inter-eapi that will allow to skip to do the conditional ED and EROOT
-21:40:40 <leio>	the details on the need for separate variables slightly still escapes me
-21:41:11 <grobian>	leio: look at the make DESTDIR=${D} install example
-21:42:16 <Betelgeuse>	grobian: Maybe the prefix-vars eclass idea is simpler. It's easier to remove in the future if we have something better.
-21:42:33 <grobian>	leio: if you insert the offset in there, you simply get a double offset, because you supplied it during configure too
-21:42:33 <Betelgeuse>	grobian: If we use an EAPI for uninstall the support stays there for quite a while
-21:42:38 <grobian>	Betelgeuse: it's only not possible
-21:43:08 <Betelgeuse>	grobian: how come?
-21:43:15 <grobian>	Betelgeuse: D and ROOT need not to be set when the ebuild is sourced
-21:43:33 <leio>	grobian: I think I got it. The point was that DESTDIR remains $D and the problem happens if you need to access things post make install
-21:44:02 <grobian>	leio: yes, you want to avoid writing ${EPREFIX} all the time, hence the shorthand ED
-21:44:56 <leio>	would dobin and similar methods automatically get ${EPREFIX} in front for defaults with a new EAPI?
-21:45:19 <grobian>	leio: no, but they would in the Prefix EAPI, as is implemented now
-21:46:13 <grobian>	the EAPI we talk about now is just a mere convenience EAPI that allows to avoid lots of conditional code such that Prefix and gx86 can share the same ebuilds
-21:46:42 <Calchan>	grobian, would that EAPI slot in between EAPI3 and EAPI4?
-21:46:44 <grobian>	it basically all needed
-21:46:47 <leio>	the question was if the default locations would be changed in the new EAPI feature you are proposing to be accepted :)  And if insinto and such would add $EPREFIX in front automatically, or all such places need to be updated as well. But this is perhaps getting into too much details for this point of time
-21:46:51 <Calchan>	grobian, or could that be EAPI4?
-21:46:51 <ulm>	grobian: only feature being the new variables?
-21:46:59 <grobian>	leio: nothing changes for gx86
-21:47:36 <ulm>	Calchan: let's postpone the eapi details, we have an extra topic for it
-21:47:44 <grobian>	Calchan: we need it now, and very fast, otherwise I'll stop waiting and just add lots of conditional code
-21:47:48 <ulm>	s/eapi/eapi numbering/
-21:47:50 <leio>	but they can't share the same ebuilds if insinto and dobin and so on don't have EPREFIX in front of the arguments
-21:48:29 <ulm>	leio: EPREFIX is empty in main tree
-21:48:30 <grobian>	ulm: a prefix enabled package manager can do offset installs using those variables
-21:48:30 <leio>	ok, they can if your portage branch does add that automatically for these functions
-21:48:42 <Calchan>	grobian, how come you need it fast? I understand the workload issue but I think it's not a reason to take chances with the tre
-21:49:18 <Calchan>	e
-21:49:30 <grobian>	Calchan: because we already started doing that, and then zmedico came with this idea, so we suspended for that, because it sounds good to us
-21:49:46 <lu_zero>	grobian your effort could be merged with the multilib idea we more or less discussed the past council?
-21:50:11 <grobian>	leio: yes, the prefix portage is doing that exactly, meaning that if EPREFIX='', it behaves as normal portage
-21:50:14 <lu_zero>	grobian which would be a confortable timeframe for you?
-21:50:15 <Calchan>	grobian, I think the details of prefix and its implications should be reviewed, and I would want to involve QA in that as they're usually the ones picking up the pieces
-21:50:22 <grobian>	lu_zero: it's completely unrelated IMO
-21:50:45 <Betelgeuse>	grobian: To vote on I would like to have the finished spec for the new EAPI text.
-21:51:02 <Betelgeuse>	When when we have that we should see where we are with EAPI 3.
-21:51:03 <Calchan>	that's the bare minimum
-21:51:03 <lu_zero>	grobian I see
-21:51:06 <grobian>	lu_zero: well, zmedico told me he could do it pretty fast, so that's what I'm counting on
-21:51:20 <lu_zero>	grobian fast as in week but not months
-21:51:27 <lu_zero>	or fast as in yesterday? ^^
-21:51:36 <grobian>	I can still wait a week
-21:51:47 <Calchan>	what after that?
-21:51:57 <grobian>	then I'll just continue I started on
-21:52:06 <grobian>	s/on/with/
-21:52:39 <Calchan>	grobian, you may want to hold back making major changes to ebuilds you don't maintain
-21:52:40 <leio>	hopefully getting acks from relevant maintainers...
-21:52:47 <lu_zero>	the request is just a minimal change that will be completely transparent for non-prefix users?
-21:52:57 <grobian>	Calchan: that's why we get maintainers in the loop
-21:53:07 <grobian>	like we wrote in the mail
-21:53:14 <Betelgeuse>	I don't see a problem with going forward with maintainer blessing in the meanwhile.
-21:53:27 <grobian>	lu_zero: yes
-21:53:30 <Calchan>	grobian, is what you started doing reversible?
-21:53:45 <Betelgeuse>	For non prefix users at least.
-21:53:53 <grobian>	Calchan: yes, by basically sedding ED to D
-21:54:12 <grobian>	Betelgeuse: prefix users already have ED and EROOT
-21:54:13 <leio>	basically, but not quite - too short keyword to sed :)
-21:54:24 <Calchan>	grobian, and are you touching any system packages?
-21:54:28 <lu_zero>	${D} =P
-21:54:39 <lu_zero>	anyway
-21:54:49 <grobian>	Calchan: not yet, but prefix code is already in toolchain*.eclass with ack from spanky
-21:54:57 <leio>	"system packages" is quite relative these days, unfortunately. E.g pam -> pam-base[gnome-keyring] -> gnome-keyring -> ...
-21:55:37 <ulm>	we are already behind schedule
-21:55:49 <ulm>	so how do we go on from here?
-21:56:02 <ulm>	should we vote if council generally supports the idea?
-21:56:07 <lu_zero>	I like the idea of merging prefix with the main portage
-21:56:08 <Calchan>	grobian, I would agree with the move once this has been properly reviewed, but inflicting us a one week deadline is rather unrealistic
-21:56:39 <grobian>	Calchan: we can always benefit from it when it comes later
-21:56:54 <Calchan>	grobian, benefit of what?
-21:57:08 <grobian>	an eapi that we don't need to set ED or EROOT in
-21:57:31 <Calchan>	I think you're pushing the schedules here
-21:57:47 <Calchan>	and again I understant the impact on your workload
-21:57:54 <grobian>	sorry, I feel I just made a simple request
-21:58:09 <grobian>	you could see me coming I guess
-21:58:15 <Betelgeuse>	7w 30
-21:58:20 <ulm>	if the only change is definition of three variables there can't be much danger of damaging anything
-21:59:03 -->	NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-21:59:08 <grobian>	if the position of the portage team is of any value to you, I think you should consult them
-21:59:20 <Calchan>	grobian, I was going to propose that
-21:59:50 <Calchan>	one thing that bothers me is that it affects past EAPIs
-22:00:03 <grobian>	in what way does it do that?
-22:00:06 <Betelgeuse>	Calchan: no?
-22:00:50 <Calchan>	mmhhh... this would prove I didn't understant the whole thing correctly
-22:01:10 <Calchan>	which would mean I'm not ready to vote on this
-22:01:21 <grobian>	Calchan: if EAPI="2+prefix" ; then define ED, EROOT, EPREFIX ; fi
-22:01:28 <ulm>	we are at this topic since 30 min and I propose to move discussion to -dev ml
-22:01:44 <ulm>	since I don't see us converging towards a vote
-22:01:57 <lu_zero>	ulm 4.1 could be voted already
-22:02:01 <Calchan>	grobian, don't eclasses need to be modified?
-22:02:02 <Betelgeuse>	grobian: Couldn't we go with having ROOT and D available on global scope immediately?
-22:02:31 <grobian>	Calchan: eclasses: yes, take KDE eclasses as example
-22:02:55 <grobian>	Betelgeuse: I don't like stacking many things in one, but then I won't mind either
-22:03:23 <Calchan>	grobian, I will but not now, we're running late with the meeting
-22:03:39 <lu_zero>	the main problem is that 1 week is a pretty short time
-22:03:50 <ulm>	let's vote on 4.1 then "Does the council generally support this idea?"
-22:04:01 <ulm>	and say if you're not ready
-22:04:08 <lu_zero>	I like the idea
-22:04:24 <Calchan>	ulm, does that mean the general idea of eventually having prefix in the tree?
-22:04:38 <ulm>	Calchan: that's the implication
-22:04:40 <leio>	I support the intention of getting all this into the main tree, but unsure of the first step proposed right now.
-22:04:42 <dertobi123>	in general i like it and want to see it happen, but as the past about 30 minutes proved - there are lots of things to discuss
-22:04:58 <Betelgeuse>	I support having prefix eventually merged to main tree but I won't vote on EAPis without a written spec.
-22:05:07 *	ulm also supports the idea in general
-22:05:09 <lu_zero>	Betelgeuse that is 4.2
-22:05:31 <Betelgeuse>	lu_zero: in my opinion ties back to 4.1
-22:05:51 <Calchan>	I would vote yes
-22:06:08 <ulm>	DrEeevil?
-22:06:27 <DrEeevil>	I support the idea and grobian's plan
-22:06:34 <DrEeevil>	the timeline is debatable
-22:07:09 <ulm>	so we have unanimous support for the general idea, but there's need for additional discussion
-22:07:23 <ulm>	let's postpone 4.2 to next meeting then
-22:07:28 <lu_zero>	ok
-22:07:41 <DrEeevil>	ok
-22:08:05 <ulm>	grobian: you can live with that?
-22:08:30 <leio>	We need a PMS patch, no?
-22:08:30 <Calchan>	grobian, would you start a discussion on that and make sure we get relevant feedback on this, so that we can vote on this next time?
-22:08:33 <ulm>	grobian: and please get the discussion on -dev ml going
-22:08:43 <grobian>	sure I can, but may I request you all to do a little bit of homework for next meeting then?  That'll save you some time in here ;)
-22:09:14 <Calchan>	grobian, seriously, your message was posted a bit late for me to research that thouroughly enough
-22:09:17 <grobian>	ulm: all questions have been addressed in the mail as far as I can see, so I would request you to put the questions out there, so I can reiterate
-22:09:27 <Betelgeuse>	Calchan: the original message was on gentoo-dev quite a while ok I think
-22:09:48 <Calchan>	Betelgeuse, a bit short for me, slow and old brain and all that
-22:09:55 <Calchan>	plus life
-22:09:57 <grobian>	3 weeks, 1 day, 10 hours and 57 minutes ago
-22:09:58 <Betelgeuse>	Calchan: 3 weeks ago
-22:10:05 <ulm>	grobian: o.k., i'll followup on the ml then
-22:10:08 <Calchan>	3 weeks? ok than, I slacked
-22:10:12 <ulm>	next topic: "5. Usage of bash 3.2 features in Portage tree"
-22:10:17 <leio>	grobian: will you write a PMS patch?
-22:10:30 <grobian>	leio: if you request me to do so, I'm willing to do
-22:10:52 <Calchan>	grobian, please do, if we have all material ready for next time it'll be easier
-22:11:15 <grobian>	Calchan: ok, I'll do
-22:11:18 <ulm>	patrick's message is here: http://archives.gentoo.org/gentoo-council/msg_ed3cba3e0ded55c4e497451af46ea55b.xml
-22:11:25 <leio>	grobian: at some point it will be necessary if the discussion leads to a potential accepting of it, the sooner the better. Things might be clearer for the discussion as well if there's a concrete detailed PMS patch to discuss
-22:11:25 <Calchan>	grobian, thanks
-22:11:27 <ulm>	we've moved on ;)
-22:11:39 <ulm>	stop discussing topic 4 please
-22:12:03 <Calchan>	this issue can easily be answered with the decision we've made in 3.2
-22:12:18 <ulm>	right, it's linked to that
-22:12:29 <Calchan>	is 3.2 stable for at least a year?
-22:13:00 <ulm>	DrEeevil: can you answer this?
-22:13:08 <DrEeevil>	bash 3.2 has been stable for much more than a year
-22:13:22 <DrEeevil>	bash 3.2 was added Oct 2006 and stabled May 2007
-22:13:54 <leio>	that part sounds OK. Now the problem is it being part of EAPI-0 and how amending of that is done as a process
-22:14:30 <Calchan>	is it that urgent that we can't wait for EAPI3?
-22:14:40 <DrEeevil>	unrelated to EAPI
-22:14:41 <Betelgeuse>	Calchan: You should know global scope issues
-22:14:45 <DrEeevil>	please stop confusing things :)
-22:14:47 <Calchan>	oh right
-22:14:49 <Betelgeuse>	Calchan: To parse the EAPI out
-22:14:49 <Calchan>	sorry
-22:15:28 <Betelgeuse>	leio: We as a council can decide for EAPI 0.
-22:15:35 <lu_zero>	I think we could safely amend pms
-22:15:57 <ulm>	if we want to be consequent, we should either revert all usage of 3.2 features in the tree, or allow 3.2 in general
-22:16:03 <DrEeevil>	exactly
-22:16:12 <DrEeevil>	reverting will be a very unpleasant thing to do
-22:16:14 <ulm>	probably it's too late for the first option already
-22:16:35 <dertobi123>	given the fact that we have bash 3.2 stable for >2 years i think this mostly is a non-issue. therefore i'd prefer "fixing" pms and requiring bash-3.2 thus allowing it in general
-22:16:48 <ulm>	but we should make sure that this won't happen again for bash 4.0
-22:16:51 <Betelgeuse>	Let's see for any bash >3.2 features they will be reverted
-22:16:54 <lu_zero>	I'd go with the simpler way
-22:17:04 <ulm>	Betelgeuse: exactly
-22:17:05 <lu_zero>	Betelgeuse agreed
-22:17:06 <Calchan>	is there any chance that we could end up in a situation where we can't parse the ebuild and thus not get the EAPI?
-22:17:20 <DrEeevil>	Calchan: bash4 features potentially
-22:17:30 <DrEeevil>	bash 3.0/3.2 changes are small enough to be parseable
-22:18:20 <--	dabbott|work has quit (Client Quit)
-22:18:29 <Calchan>	DrEeevil, so why do we care about requiring 3.2 then?
-22:18:40 <Betelgeuse>	Ideally we would have repoman parsing the ebuilds with a 3.2 parser.
-22:18:45 <DrEeevil>	Calchan: because it is actively used
-22:19:12 <DrEeevil>	either we allow it (fix PMS) or we don't (fix tree), but having the spec and the product disagree like that is bad
-22:19:20 <Calchan>	DrEeevil, I would tend to consider that an error if it can't be relied on
-22:19:33 <DrEeevil>	Calchan: an error with >150 occurances in eclasses only
-22:19:51 <Calchan>	DrEeevil, can't be sedded?
-22:19:58 <DrEeevil>	Calchan: no, not that easy
-22:20:09 <DrEeevil>	and people will not appreciate having good features removed
-22:20:09 <ulm>	Calchan: and what would be the point?
-22:20:35 <Calchan>	ulm, teaching people to not use features they can't rely on?
-22:20:51 <ulm>	Calchan: we can do this for bash 4.0 features ;)
-22:21:00 <dertobi123>	ulm: we *should* or better *must*
-22:21:06 <DrEeevil>	Calchan: you're about a year late for that
-22:21:10 -->	Zorry (n=zorry@fu/coder/zorry) has joined #gentoo-council
-22:21:21 <Calchan>	DrEeevil, so what?
-22:21:22 <DrEeevil>	people warned back then and noone seemed to care, so it started to get used more and more
-22:21:27 <DrEeevil>	procedural fail.
-22:22:02 <ulm>	I think all arguments have been said and we can vote: "Should usage of bash 3.2 features in the Portage tree be a) forbidden (i.e. tree reverted to 3.0), b) allowed (i.e. PMS changed), or should c) the issue be ignored?"
-22:22:17 <DrEeevil>	we've been doing (c) for long enough
-22:22:31 <lu_zero>	still is an option
-22:22:44 <ulm>	lu_zero: that's why it's listed
-22:22:51 <dertobi123>	i think c is not an option to vote upon
-22:23:19 <Calchan>	I still don't know what is to be gained by using 3.2, and from what I understand not much if anything
-22:23:42 <DrEeevil>	Calchan: I see it mostly as a matter of having a correct specification
-22:23:57 <DrEeevil>	if PMS is supposed to have any relevance it needs to document reality
-22:24:08 <dertobi123>	reality already is that we have 3.2 features being used and the only thing we can do about this *now* is to change pms to reflect that behaviour but also to make sure such doesn't happen again with bash-4
-22:24:10 <Calchan>	which doesn't matter if people don't foolow it like they did
-22:24:26 <DrEeevil>	dertobi123: agreed
-22:25:01 <DrEeevil>	Calchan: they weren't, in any way, sanctioned
-22:25:15 <DrEeevil>	hey, why not use the shiny features!
-22:25:19 <ulm>	we may also have a stronger point for forbidding 4.0 features if PMS reflects the real status of the tree
-22:25:39 <Betelgeuse>	If we can make repoman fail people won't add new features
-22:25:50 <Betelgeuse>	I bet much of it is just because people don't know/notice
-22:26:03 <DrEeevil>	the bash 3.2 features were quite conscious
-22:26:09 <Betelgeuse>	DrEeevil: PMS authors can't really upgrade the bash version but the council should
-22:26:56 <ulm>	so vote please: "Should usage of bash 3.2 features in the Portage tree be a) forbidden (i.e. tree reverted to 3.0), or b) allowed (i.e. PMS changed)"
-22:27:03 <Betelgeuse>	b
-22:27:05 <ulm>	i vote for b
-22:27:07 <Calchan>	Betelgeuse, I'd agree with you but it's still not a good enough reason to let people not respect a decision previously made by the council
-22:27:11 <DrEeevil>	b
-22:27:15 <lu_zero>	b
-22:27:20 <Calchan>	a
-22:27:26 <dertobi123>	b
-22:27:32 <leio>	b
-22:27:38 <tanderson>	I'd like to request some general consensus that we shouldn't repeat things like this however
-22:27:54 <tanderson>	So people can't introduce 4.0 features and then say "PMS should reflect reality!"
-22:27:56 <ulm>	I count 1a 6b
-22:28:10 <ulm>	tanderson: that was my next point
-22:28:15 <Betelgeuse>	ulm: Vote on >3.2 features will be reverted please
-22:28:24 <ulm>	Betelgeuse: yep
-22:28:55 <tanderson>	ulm: great, I would likely quit if people tried that one. :p
-22:29:02 <Betelgeuse>	Calchan: Yes but being able to use 3.2 features is useful
-22:29:08 <ulm>	"Should features of >=bash-4 be disallowed and reverted in the tree?"
-22:29:09 <lu_zero>	I'm ok with reverting as well
-22:29:32 <Calchan>	why not >3.2, just in case
-22:29:35 <Betelgeuse>	Calchan: The only way of getting there without this that I know of is glep 55...
-22:30:03 <ulm>	Calchan: hm, 3.2_p39 > 3.2
-22:30:12 <ulm>	give me a proper version spec ;)
-22:30:12 <leio>	or the many counter proposals of glep 55, but lets not go there
-22:30:16 <Calchan>	Betelgeuse, agreed, but I still have a problem with people not respecting rules
-22:31:31 <Betelgeuse>	Calchan: Nothing in our docs really teaches what's 3.2
-22:31:31 <lu_zero>	Calchan rules must be clear
-22:31:41 <Betelgeuse>	Calchan: We don't teach new recruits either
-22:31:41 <Betelgeuse>	Calchan: I will add a new question based on these votes
-22:32:30 <DrEeevil>	Calchan: if there is no enforcement (even after repeatedly pointing out the issue) then there's no motivation to respect the rules
-22:32:30 <Betelgeuse>	ulm: Ebuilds must be parseable with =bash-3.2*
-22:32:43 <ulm>	Betelgeuse: perfect :)
-22:33:24 <leio>	global scope or all of it?
-22:33:34 <ulm>	all of it
-22:33:37 <Betelgeuse>	leio: all of it
-22:33:37 <DrEeevil>	all of it
-22:33:38 <leio>	(global scope DEPEND could >bash-4)
-22:33:48 <leio>	ok, just to be clear :)
-22:33:50 <ulm>	so please vote on: "Ebuilds must be completely parseable with =bash-3.2*, any use of later bash features will be reverted."
-22:33:58 <Betelgeuse>	yes
-22:34:01 <ulm>	yes
-22:34:05 <dertobi123>	yes
-22:34:18 <DrEeevil>	yes
-22:34:23 <leio>	yes
-22:34:25 <lu_zero>	yes
-22:34:49 <ulm>	Calchan?
-22:34:58 <tanderson>	DrEeevil: rules don't get removed simply because noone obeys them
-22:35:15 <DrEeevil>	tanderson: that's how democracy usually works
-22:35:29 <Calchan>	DrEeevil, no that's anarchy
-22:35:36 <Calchan>	ulm, sorry I lost internet for a while
-22:35:54 <Betelgeuse>	DrEeevil: In democracy you take the changes to the people in charge who change the rules
-22:35:55 <Calchan>	I'm ok with the wording although I voted against that
-22:36:08 <DrEeevil>	civil disobedience
-22:36:12 <lu_zero>	well
-22:36:14 <ulm>	o.k, so 6 yes, 1 no
-22:36:17 <DrEeevil>	the rosa parks kind of thing
-22:36:26 <Betelgeuse>	DrEeevil: is not needed if the system works
-22:36:27 <lu_zero>	people in charge listen to the other people usually
-22:36:42 <leio>	Someone please find out at some point what developer helping features bash-4 would provide to see if we should start thinking of ways how to allow it properly without breaking anything (yes, I realize this will involve glep55 or alternatives, it's for prioritizing work on such a solution or not)
-22:36:49 <tanderson>	DrEeevil: and you don't see civil disobedience before going to authority do you?
-22:37:06 <DrEeevil>	tanderson: you try to ignore the discussions on the mailinglist about a year ago
-22:37:08 <Betelgeuse>	Calchan: You had a timebox?
-22:37:08 <Calchan>	you guys can finish this discussion next time you meet at the pub
-22:37:18 <lu_zero>	now...
-22:37:20 <Betelgeuse>	Any way we are pass 90 mins
-22:37:23 <DrEeevil>	tanderson: it was discussed and ignored
-22:37:23 <ulm>	we're over time
-22:37:25 <Calchan>	Betelgeuse, no, just crappy internet at work
-22:37:38 <ulm>	can we still discuss topic 6?
-22:37:49 <ulm>	or should we postpone it?
-22:38:06 <Betelgeuse>	We can but I will need to go visit neighbourghs shortly
-22:38:17 <Betelgeuse>	I will be back in 10 mins
-22:38:28 <dertobi123>	postpone.
-22:38:31 <lu_zero>	I'd rather postpone
-22:39:13 <Calchan>	can we make sure we keep the discussion on this alive so that next time all we need to do is vote?
-22:39:19 <ulm>	Calchan: sure
-22:39:35 <Calchan>	we should do that more in general by the way
-22:39:45 <ulm>	so let's postpone topic 6 "Preservation of file modification times in EAPI 3 "
-22:39:52 <Calchan>	council metings are not a good time for technical discussions
-22:39:56 <ulm>	right
-22:40:13 <ulm>	any other business?
-22:40:24 <leio>	When is the next meeting
-22:40:26 <dertobi123>	next meeting. when? who's taking care of the agenda?
-22:40:27 <ulm>	who will take chair for the next meeting?
-22:40:39 <Calchan>	I can if nobody wants
-22:40:55 <dertobi123>	what about december 7th? that's in 4 weeks
-22:41:17 <ulm>	general question is if we shall keep the 4 weeks interval
-22:41:32 <ulm>	we originally said third monday in month
-22:41:48 <Calchan>	we may need to start thinking of christmas time, not everybody may be available 4 weeks after dec 7
-22:42:09 <leio>	that is 4th January
-22:42:22 <dertobi123>	we can do december 7th and something mid-january
-22:42:36 <Calchan>	leio, which proves again that I can't count to 4... ;)
-22:43:16 <ulm>	so let's note december 7th 19 UTC, calchan prepares agenda and takes the chair
-22:43:23 <Calchan>	jan 4th is ok with me although I'll just be flying back from japan after 2 weeks without internet
-22:43:35 <Calchan>	ulm, ok
-22:43:59 <ulm>	leio: you followup on the upgrade path thingy?
-22:43:59 <lu_zero>	Calchan you'll be in tokyo?
-22:44:12 <leio>	ulm: yes
-22:44:14 <Calchan>	lu_zero, 1h north of tokyo
-22:44:21 <ulm>	so, open floor
-22:44:23 ---	ulm sets mode -m #gentoo-council
-22:44:55 <lu_zero>	Calchan make sure if you could attend the tlug event if you hadn't already ^^;
-22:45:15 ---	ulm removes voice from DrEeevil grobian
-22:45:26 <Calchan>	lu_zero, when/where? not sure I can make it though
-22:46:11 <leio>	fyi, reavertm said bash-4 would mostly provide associative arrays (array indexes with strings instead of just numeric indeces), which is probably not very important to have for ebuild/eclasses
-22:46:18 <leio>	ulm: you get to kick me if I don't do so ;)
-22:46:42 <ulm>	leio: will do
-22:46:54 <ciaranm>	bash 4 has a tr replacement builtin, which is handy. but since it's only handy for global scope things...
-22:47:59 <ulm>	one more thing, can somebody get the automatic council reminders going again?
-22:48:23 <ulm>	there used to be a ml posting (by vapier I think) two weeks in advance
-22:48:25 <leio>	maybe someone could contact vapier and ask to tweak the cron script
-22:48:38 <leio>	it's still happening, just with wrong dates at wrong times
-22:50:05 <Betelgeuse>	hard to cron when the dates are not solid
-22:50:23 <Betelgeuse>	the one who does the agenda should schedule reminders and send them
-22:50:35 <ulm>	or that
-22:50:43 <ulm>	but I forgot last time
-22:51:09 <Betelgeuse>	Calchan: please add a note to your calendar
-22:51:27 <ulm>	anyway, seems there are no pressing topics for open floor
-22:51:39 <ulm>	so let's call it end of meeting
-22:51:46 <ulm>	thanks everybody
-22:52:03 <Calchan>	Betelgeuse, thanks ;o)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091207-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20091207-summary.txt
deleted file mode 100644
index fd87258e27..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20091207-summary.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-Summary of meeting of December 7th, 2009
-
-Attendance
-==========
-Present:
- Betelgeuse
- Calchan
- dertobi123
- leio
- solar
- ulm
-
-Missing:
- lu_zero
-
-
-Agenda
-======
-EAPI-3 status
-Prefix support
-mtime preservation
-
-
-ACTIONS
-========
-* Discuss voting by e-mail post-meeting in case of absence
-* ulm to talk with Zac Medico about defining current portage mtime
-  preservation behaviour for documenting in EAPI-3
-* dertobi123 to check what day of the week is best for council members
-  nowadays and what week to hold the next meeting, possibly rescheduling
-  the next meetings date
-* lu_zero missed the meeting while having a slacker mark, figuring out
-  what happens next (via e-mails) is necessary before the 18th December,
-  2009.
-
-
-EAPI-3 status
-=============
-The ETA of EAPI-3[1] is roughly 3 months. The currently implemented
-EAPI-3 items have no significant benefits to warrant a new EAPI with
-only the items that are already implemented.
-Because prefix support will be EAPI-3 (see below), the EAPI items
-referenced here will be referred to as EAPI-4 in the future.
-
-[1]: http://bugs.gentoo.org/show_bug.cgi?id=273620
-
-
-Prefix support
-==============
-The council accepts (4x yes, 2x abstain) the technical proposition
-about Prefix support made to it by now, in the form of a PMS patch[2],
-answers by the Prefix team members to the discussion thread[3] and the
-portage branch[4] implementing this.
-
-The council majority voted for a quick prefix-specific EAPI bump,
-from here-on known as EAPI-3. The previously intended collection
-of EAPI changes for a EAPI-3 will likely be referenced from now on
-as EAPI-4 instead.
-
-[2]: http://archives.gentoo.org/gentoo-dev/msg_62b5df924d6e9e74c94149e7e7f17d23.xml
-[3]: http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml
-[4]: http://sources.gentoo.org/viewcvs.py/portage/main/branches/prefix/
-
-
-mtime preservation
-==================
-The council majority voted to document precisely the current behavior
-of portage and what can be relied upon as part of the upcoming EAPI-3
-(prefix support EAPI), so that since EAPI-3 the current portage
-behaviour can be relied upon from all compliant package managers.
-The exact behaviour needs to still get documented, however.
-
-
-Next meeting
-============
-The date for the January meeting is still to be decided. Mondays are
-now incompatible with solar's schedule. Calchan has volunteered to
-follow-up discussions before the meeting and write the agenda if the
-date was pushed back a week at least. Betelgeuse will not be available
-during week 2 (Jan 10-16).
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20091207.txt b/xml/htdocs/proj/en/council/meeting-logs/20091207.txt
deleted file mode 100644
index 934b2e5038..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20091207.txt
+++ /dev/null
@@ -1,483 +0,0 @@
-21:00:09 <leio>	Mon Dec  7 19:00:03 UTC 2009
-21:00:10 <Betelgeuse>	Calchan: ping?
-21:00:13 *	robbat2|na is here is for any questions/issues with his gleps
-21:00:32 <Calchan>	Betelgeuse, pong
-21:01:02 <Betelgeuse>	Calchan: your show
-21:01:12 <Calchan>	robbat2|na, great, sorry for the screwup, I do too many things at the same and didn't see you were requesting that for january only
-21:01:21 <Calchan>	Betelgeuse, yes I was on -dev with grobian
-21:01:29 <Calchan>	so who's here?
-21:01:36 <leio>	I'm here, but see my e-mail
-21:01:40 <robbat2|na>	i only said january as IIRC they had to be posted a month in advanced
-21:01:42 <Betelgeuse>	Calchan: can you please add a link to the agenda to topic
-21:02:20 -->	NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-21:02:23 ---	Calchan has changed the topic to: http://archives.gentoo.org/gentoo-council/msg_55e2123621095cba53e2fe4d700bfb76.xml
-21:02:29 <Betelgeuse>	thx
-21:02:54 <Calchan>	Betelgeuse, note that there's a couple changes in the htread
-21:03:04 <Betelgeuse>	Calchan: yes I read the thread
-21:03:07 <Calchan>	solar said he would very probably not be here
-21:03:16 <Calchan>	and we have his votes by email
-21:03:22 <Betelgeuse>	Calchan: but best to ahve something for the audience
-21:03:22 <Calchan>	in case we want to use them
-21:03:57 <Betelgeuse>	Calchan: He preferred post votes so he can see leading discussion and I think we should do that
-21:03:58 *	dertobi123 yawns
-21:04:14 <Calchan>	Betelgeuse, let's vote
-21:04:18 <Calchan>	later
-21:04:35 <Calchan>	ulm, lu_zero ping
-21:04:40 <ulm>	here
-21:04:46 <Calchan>	ok
-21:05:25 <Calchan>	so we seem to have: Betelgeuse, leio, ulm, dertobi123 and Calchan
-21:05:47 <Calchan>	you guys want to wait for lu_zero a bit more or assume he won't be showing up?
-21:06:16 <Betelgeuse>	Calchan: The agenda had 5 minutes so go with that
-21:06:29 <Calchan>	ok, who's logging?
-21:06:31 <leio>	I am
-21:06:32 <Betelgeuse>	There's no votes due before point 3 any way
-21:06:35 <Betelgeuse>	Calchan: I do
-21:06:42 *	ulm does too
-21:06:43 <Calchan>	and who wants to chair?
-21:07:02 <Calchan>	as I wrote I can do it if you prefer
-21:07:22 <Betelgeuse>	Calchan: You did a good job with the agenda so if you don't mind
-21:07:28 <Calchan>	ok
-21:07:31 <Calchan>	and thanks
-21:07:42 <Calchan>	1.4 remarks on the agenda
-21:07:58 <Calchan>	let's move the many GLEPs discussion to open floor, do you agree?
-21:08:05 <Betelgeuse>	fine
-21:08:06 <leio>	yes
-21:08:09 <ulm>	i've already sent remarks in my e-mail reply
-21:08:29 <Calchan>	dertobi123?
-21:08:30 <solar>	my work meeting got cancled. So looks like I can be here.
-21:08:36 <Calchan>	solar, yay
-21:08:40 <dertobi123>	Calchan?
-21:09:02 <Calchan>	dertobi123, are you ok with moving the glep discussion to open florr and not voting for this meeting?
-21:09:07 <dertobi123>	sure
-21:09:11 <Calchan>	solar, too?
-21:09:20 <dertobi123>	guess that was already decided on list
-21:09:25 <Calchan>	ok then
-21:09:40 <Calchan>	do we skip the vote by email discussion as solar is here?
-21:09:43 <solar>	I have no objections to glep-58 moving fwd as it causes no impact to anybody
-21:09:44 <Calchan>	I'd say yes
-21:10:01 <Betelgeuse>	yes better suited for discussion by email for example
-21:10:43 ---	Calchan gives voice to zmedico
-21:11:02 <Calchan>	ok, let's switch to 2 EAPI3 status
-21:11:16 <Calchan>	zmedico, you said ETA in roughly 3 months
-21:11:36 <Calchan>	in your mail, could you elaborate or was it a very rough guess?
-21:12:45 <Calchan>	while we're waiting for zac, what do you guys think of doing an EAPI bump with what's already done?
-21:12:50 <dertobi123>	tbh lets remove those eapi-3 status updates from this and the upcoming agendas. it's done when it's done. it doesn't help nor speeds up the process to discuss this again and again
-21:12:54 -->	Zorry (n=zorry@fu/coder/zorry) has joined #gentoo-council
-21:13:09 <Betelgeuse>	Calchan: It only makes sense if there's something valuable already done.
-21:13:23 <Betelgeuse>	Calchan: No reason for having a new one if devs have no need for it.
-21:13:25 <ulm>	Calchan: I don't see any use for that, maybe except for prefix
-21:13:32 <Calchan>	dertobi123, I was actually going to ask zmedico how we could help him and his team
-21:13:41 <Betelgeuse>	Calchan: vim *.py
-21:13:52 <Betelgeuse>	s/vim/${EDITOR/
-21:14:51 <Calchan>	so the general opinion is that there's nothing worth yet to justify a pre-3 EAPI bump?
-21:15:44 <Calchan>	anybody?
-21:15:56 <Betelgeuse>	the things done are mainly removing deprecated stuff and cleanups
-21:16:15 <ulm>	new (and old) devs have to learn additional stuff for every additional EAPI
-21:16:27 <dertobi123>	i don't think it's helpful to split up eapi-3 now
-21:16:28 <ulm>	so we should keep their number limited
-21:16:32 <Betelgeuse>	Calchan: None of the main EAPI 3 features are done.
-21:16:36 <dertobi123>	ulm: agreed
-21:17:00 <Calchan>	ok, then if nobody has anything to add let's leave it a tthis and switch to prefix
-21:17:12 <Calchan>	and we're almost on time
-21:17:25 <solar>	what advantage is it to make others wait on feautres when they are ready?
-21:17:52 <Betelgeuse>	solar: There's nothing in the tracker that would make a big difference for devs
-21:18:37 ---	Calchan gives voice to grobian
-21:18:50 <Calchan>	solar, ok to switch to 3. prefix?
-21:19:29 <Calchan>	looks like it
-21:19:52 <Calchan>	so, have you guys reviewed the material posted by the prefix team in response to our requests?
-21:20:12 <Calchan>	I mean the answers to our questions, the PMS patch and the portage stuff
-21:20:12 <ulm>	yes, and looks good to me
-21:20:47 <Betelgeuse>	Calchan: I havent' seen a pms patch going through gentoo-pms at least
-21:20:54 <Calchan>	it looks good to me too, although I can't comment much on portage code (i.e. it went over my head)
-21:21:14 <ulm>	Betelgeuse: http://archives.gentoo.org/gentoo-dev/msg_62b5df924d6e9e74c94149e7e7f17d23.xml
-21:21:19 <Calchan>	Betelgeuse, good point, but you have seen the one posted to the list, right?
-21:21:32 <Calchan>	s/the list/the -dev list/
-21:22:22 <Calchan>	my only comment is that it refers to the prefix stuff as coming with EAPI3 and that would have to be fixed if we vote to make a quick EAPI bump before
-21:22:38 <Betelgeuse>	Calchan: yes there was one there
-21:22:38 <Calchan>	and I was satisfied with the answers
-21:24:06 <Calchan>	obviously there's some polishing required with all this, but we can vote now on whether we want prefix in the tree as it's been presented to us
-21:24:14 <Calchan>	I vote yes
-21:24:33 <ulm>	I vote yes
-21:24:38 <dertobi123>	yes too
-21:25:02 <solar>	yes
-21:25:11 <Calchan>	Betelgeuse?
-21:25:27 <Calchan>	leio?
-21:25:53 <Betelgeuse>	Calchan: yes having prefix support eventually in the main three is worthwhile
-21:25:57 <leio>	I abstain from voting, as I have not been able to review yet what has been presented to us. But in what way would this "wanting prefix in the tree" be as?
-21:26:19 <leio>	We already voted on the previous meeting on the general desire to see prefix in the main gentoo-x86 portage tree
-21:26:45 <Calchan>	leio, the question today is do we accept the technical proposition that is made to us today?
-21:26:52 <Calchan>	leio, but you can abstain
-21:26:56 <Calchan>	this is ok
-21:27:01 <leio>	thanks for clarification, good for summary
-21:27:07 <Calchan>	Betelgeuse, do we have a yea from you?
-21:28:24 <Calchan>	right now we have 4 yes, 1 abstention, and one that I think is a yes but would like confirmation ( Betelgeuse)
-21:28:28 <Betelgeuse>	Calchan: I will abstain from voting on the PMS patch itself as I haven't read/seen any follow up with pms committers
-21:28:50 <Calchan>	Betelgeuse, ok, how do we count you though?
-21:29:00 <Calchan>	for summary purposes only
-21:29:08 <Calchan>	because we already have a majority
-21:29:31 <Betelgeuse>	Calchan: If you clarify the vote as being about the patch: abstain
-21:29:36 <Betelgeuse>	We already voted on intentions
-21:30:08 <leio>	I'm unclear on what is that technical proposition that is made to us today - is it the PMS patch at http://archives.gentoo.org/gentoo-dev/msg_62b5df924d6e9e74c94149e7e7f17d23.xml ?
-21:30:14 <Calchan>	Betelgeuse, ok, although we have the PMS patch and lots of answers we didn't have previously
-21:30:34 <Calchan>	leio, PMS patch, all the answers in the thread, the portage branch
-21:30:57 <leio>	That's quite far reaching and hard or vague to summarize, but OK...
-21:31:17 <Calchan>	ok, then we have 4 yes and 2 abstentions
-21:31:34 <Calchan>	prefix can proceed to the tree
-21:31:47 <Calchan>	3.2 EAPI bump for prefix
-21:31:56 <Calchan>	we have the following choices:
-21:32:02 <Calchan>	3.2.1. Should we make a quick, prefix-specific EAPI bump?
-21:32:10 <Calchan>	3.2.2. Should we wrap together prefix plus whatever features of EAPI3 which are already ready into an intermediate EAPI and ship that now?
-21:32:14 <Calchan>	3.2.3. Should we add prefix to EAPI3 and ship it all together when what's missing of EAPI3 is ready?
-21:32:33 <Calchan>	does anybody need clarifications on the above propositions?
-21:32:39 <Calchan>	we can discuss a bit and then vote
-21:32:45 <Betelgeuse>	I don't think 3.2.2. makes sense. It's easier to have an EAPI that only prefix devs need to care about or then having altogether useful EAPI 3.
-21:32:54 <Calchan>	Betelgeuse, agredd
-21:33:20 <ulm>	so 3.2.1 means we rename EAPI 3 to EAPI 4? and EAPI 3 would be the prefix one?
-21:33:35 <Betelgeuse>	ulm: We don't have to name EAPI N
-21:33:38 <Calchan>	ulm, I think the naming is just a cosmetic issue
-21:33:43 <Betelgeuse>	ulm: It can be 2+prefix for example
-21:33:47 <Calchan>	we can decide that later
-21:33:49 <Betelgeuse>	to make it clear
-21:34:07 <ulm>	Betelgeuse: true, but integers make a nice scheme ;)
-21:34:32 <ulm>	nicer than 2+prefix or 2/prefix or whatever
-21:34:53 <Calchan>	ulm, we could go 2.1 for example
-21:35:02 <leio>	Increasing integer strings seem easier to remember by developers (2+prefix would work now, but confusion starts with EAPI-3 then existing - does it include prefix support or not, etc)
-21:35:24 <leio>	but naming is naming, which option is the first question I suppose
-21:35:35 <solar>	problem with that is there are places in the tree that use EAPI as an int.
-21:35:47 <Calchan>	guys let's vote on the "what kind of bump first" we'll decide on the naming later, OK?
-21:35:51 <Betelgeuse>	solar: those are QA violations
-21:35:53 <ulm>	solar: is that so? eclasses?
-21:36:04 <ulm>	Calchan: o.k.
-21:36:21 <solar>	ulm: I think some eclass and everywhere that checks for EAPI's <= 2
-21:36:30 <Calchan>	I vote for 3.2.1, aka let's make a quick bump now
-21:36:50 <ulm>	3.2.1 from me, too
-21:36:53 <solar>	3.2.1 Yes as EAPI=3
-21:37:07 <Betelgeuse>	Calchan: Do you know the latest opinion from grobian on this one?
-21:37:21 <Calchan>	Betelgeuse, last time I heard he didn't care much
-21:37:27 <dertobi123>	3.2.1 or 3.2.3 for me, both work for me
-21:37:28 <Calchan>	grobian?
-21:37:35 <grobian>	well
-21:37:50 <grobian>	as I said, there is an option 3.2.4
-21:38:04 <Calchan>	dertobi123, you sound like my wife... ;o) pick just one... anyone
-21:38:32 <grobian>	while 3.2.1 would be very very very cool, there is a little problem wrt to implementation, since Prefix Portage is autotool based, and normal Portage is not
-21:38:41 <dertobi123>	Calchan: it's not to choose anyone ...
-21:39:14 <Calchan>	grobian, I'm not sure what difference you make between what you propose and 3.2.1 but go ahead and explain us
-21:39:17 <leio>	3.2.1 or 3.2.2 from me (it's not a yes/no vote, I can't just pick one)
-21:39:21 <grobian>	hence 3.2.4: make a quick bump on EAPI that is upwards compatible with Prefix, and then get the full implementation sorted out lateron
-21:39:58 <Calchan>	grobian, full implementation of what? prefix?
-21:40:04 <Calchan>	if so what could change?
-21:40:19 <grobian>	Calchan: if you guys go for 3.2.1 I need to work with zmedico for some time to get prefix branch merged with trunk, delaying EAPI3
-21:40:46 <grobian>	in principle the prefix branch is ready and waiting
-21:40:56 <Calchan>	grobian, then why the possible delay?
-21:41:28 <ulm>	grobian: any numbers? is it a matter of hours? days?
-21:41:28 <grobian>	Calchan: because Prefix branch is based on trunk, not on the 2.1 branches, and uses a different build system
-21:42:07 <grobian>	ulm: I think it is a bad idea to blindly rely on my python coding skills for ~arch of Gentoo Linux
-21:42:16 <grobian>	simply like that
-21:42:26 <grobian>	so zmedico needs to review
-21:42:59 <grobian>	therefore we would like to have the specification available in the next EAPI
-21:43:21 <grobian>	so we can use Prefix next to normal Gentoo
-21:43:28 <Calchan>	grobian, not a show stopper to me, get your thing in a working state and with the proper build system quick enough that it doesn't delay EAPI3
-21:43:44 <Betelgeuse>	Well not delay by months
-21:43:52 <Betelgeuse>	a month no-one notices
-21:44:05 <grobian>	Calchan: if that's what you want, I can try and put the maximum efforts in it to get that done
-21:44:08 <Calchan>	grobian, then we'll take bets on who's ready first, if I lose you get whipped ;o)
-21:44:26 <grobian>	Calchan: it'll be a joint with zmedico
-21:44:35 <grobian>	so I'll always win
-21:44:44 <grobian>	because the code is already there
-21:45:09 <Calchan>	nobody cares what I think, let's vote though
-21:45:29 <ulm>	Calchan: see above
-21:45:30 <grobian>	I'd be delighted with 3.2.1
-21:45:30 <Calchan>	could you guys please say again which one(s) you'd vote for even if there's more than one?
-21:45:36 <ulm>	3.2.1
-21:45:49 <solar>	<solar> 3.2.1 Yes as EAPI=3
-21:45:53 <Calchan>	under the assumption that the prefix team is going to be fast enough with the implementation
-21:45:56 <Calchan>	solar, thanks
-21:46:00 <Calchan>	and ulm
-21:46:01 <dertobi123>	still 3.2.1 or 3.2.3 for me, both work for me
-21:46:13 <Calchan>	I'm for 3.2.1 and 3.2.2
-21:46:25 <Calchan>	we'll have to do a quick majority vote here, but no big deal
-21:46:36 <Betelgeuse>	3.2.4
-21:46:49 <leio>	3.2.1 or 3.2.2
-21:46:59 <grobian>	3.2.4 conflicts with your earlier decision this evening, by the way
-21:47:33 <ulm>	Calchan: looks like we'll have to do a condorcet vote now ;)
-21:47:51 <Calchan>	ulm, no majority will be enough since it's not a secret vote
-21:48:05 <Calchan>	I'm missing one vote... who?
-21:48:10 <Calchan>	ah leio
-21:48:14 <Calchan>	?
-21:48:25 <leio>	21:46> <leio> 3.2.1 or 3.2.2
-21:48:42 <Calchan>	ok, the results are:
-21:48:55 <Calchan>	3.2.1: 5
-21:49:00 <Calchan>	3.2.2: 2
-21:49:05 <Calchan>	3.2.3: 3
-21:49:13 <Calchan>	sorry
-21:49:18 <Calchan>	3.2.3: 1
-21:49:28 <Calchan>	3.2.4: 1
-21:49:37 <Calchan>	looks like 3.2.1 wins
-21:49:59 <Calchan>	barring any computational error from my pen&paper computer system
-21:50:03 ---	fox2mike_ is now known as fox2mike
-21:50:26 <Calchan>	so now we can discuss how we call it
-21:50:34 ---	fox2mike is now known as Guest9920
-21:50:43 <Calchan>	we already know solar wants to call it EAPI3
-21:50:49 <Calchan>	others?
-21:50:54 <Betelgeuse>	!= 3
-21:50:59 <ulm>	let's call it EAPI 3
-21:51:28 <leio>	EAPI 3
-21:51:33 <dertobi123>	eapi3 works for me, if we rename what was eapi3 to eapi4
-21:51:43 <ulm>	dertobi123: agreed
-21:51:57 <Calchan>	I'd vote for some 2 < number < 3
-21:51:59 <Calchan>	like 2.1
-21:52:37 <ABCD>	FYI, currently Portage itself treats EAPI as an integer (unless I'm mistaken)
-21:52:59 <Calchan>	so we have 4 votes for EAPI3 and 2 against
-21:53:05 <Calchan>	EAPI3 it is then
-21:53:31 *	Calchan slaps ABCD with a PMS printout for speaking without voice :o)
-21:53:35 <Betelgeuse>	ABCD: It should be fixed then
-21:53:56 *	ABCD also notes that this channel isn't +m...
-21:54:08 <Calchan>	ABCD, yes, we suck
-21:54:09 <ulm>	right, it should be fixed, but by calling it 3 we don't risk any breakage
-21:54:32 <Calchan>	any more comments on the prefix topic?
-21:54:38 <leio>	Do we write EAPI-3, EAPI 3 or EAPI3? :)
-21:54:39 <grobian>	ABCD: you're mistaken ;)
-21:54:59 <ulm>	leio: EAPI=3 :p
-21:55:11 <Calchan>	grobian, congrats btw, you just got yourself and your team a shitload of work
-21:55:19 <grobian>	yeah, thanks a lot!
-21:55:41 <dertobi123>	heh
-21:55:51 <Calchan>	if there's no more comments on prefix then we'll move on
-21:56:06 <Calchan>	4. GLEPs 58, 59, 60 and 61 is moved to open floor, so:
-21:56:11 <Calchan>	5. mtime preservation
-21:56:13 <Calchan>	ysy
-21:56:14 <Calchan>	yay
-21:56:50 <Calchan>	does anybody want to discuss anything on this topics before we vote?
-21:56:52 <Betelgeuse>	What's the opinion of pkg maintainers who need mtime preservation?
-21:57:00 <Betelgeuse>	Do we have any around?
-21:57:05 ---	Calchan gives voice to ferringb
-21:57:07 <ulm>	Betelgeuse: me ;)
-21:57:23 <Calchan>	ciaranm isn't here
-21:57:24 <Betelgeuse>	ulm: yay remembered right then but wasn't sure
-21:57:44 <Calchan>	whoever you are, if you want to talk for paludis just ping me
-21:57:52 <ulm>	Betelgeuse: the feature is really needed for several lisp packages
-21:58:03 <Calchan>	although you don't need voice to speak as we're not +m
-21:58:28 <Betelgeuse>	ulm: Yes but what's your preferred way out of 5.n doing in ebuild side?
-21:58:43 <ulm>	Betelgeuse: both 5.1 and 5.3 work
-21:59:17 <Calchan>	ulm, do I understand 5.1 works if it's made equal to 5.3 or works unconditionally?
-21:59:20 <ulm>	5.2 would require that we change at least two eclasses and several (about 50?) ebuilds
-21:59:38 <solar>	5.2 seems like it's written in order to make us reject it
-21:59:39 <ulm>	Calchan: it works unconditionally
-21:59:47 <Calchan>	ulm, ok thanks
-22:00:23 <Calchan>	solar, I find the solution rather elegant even if less practical than the others
-22:00:39 ---	Guest9920 is now known as fox2mike
-22:00:55 <solar>	I find the lack of stripping objects in the name of saving mtime to be stupid
-22:01:18 <Calchan>	do we want to vote now? I rebooted my pen&paper computer system
-22:01:39 <Betelgeuse>	I am off to toilet, I will go with whatever ulm chooses as they are the ones using it
-22:01:47 <ulm>	solar: so mtimes for stripped objects should be preserved too, in your opinion?
-22:02:23 <Calchan>	ulm, I'd say yes if we wanted to make it the right wa, the real question is do we?
-22:02:25 <solar>	ulm: as noted. Being that there is no consensus among PM devs. 5.3 seems ideal for now.
-22:02:33 <leio>	strip from toolchain has a --preserve-dates option btw
-22:02:56 <Calchan>	ok, solar votes 5.3, ulm and Betelgeuse 5.1 or 5.3, others>
-22:03:01 <Calchan>	?
-22:03:13 <ulm>	Calchan: I'd prefer 5.1 but 5.3 works too
-22:03:25 <solar>	ulm: the way 5.2 is written. It favors mtime over stripping. IE skip stripping it sounds like
-22:03:42 <Calchan>	ulm, I can count you as 5.1 if you want, my system has an eraser :o)
-22:03:57 <solar>	and limits it to a given eapi vs being retroactive and a basic feature of the PM
-22:04:53 <Calchan>	ulm? so you want 5.1, or 5.1 and 5.3?
-22:05:13 <Calchan>	and I vote 5.3 btw
-22:05:21 <ulm>	Calchan: 5.1 with fallback to 5.3 ;)
-22:05:34 <dertobi123>	5.3 wfm
-22:05:40 <Calchan>	leio?
-22:06:02 <leio>	abstain
-22:06:07 <Calchan>	ok
-22:06:38 <Calchan>	we have 2 for 5.1 and 5 for 5.3
-22:06:58 <Calchan>	so we'll document protage's behavior and will put that into PMS
-22:07:08 <ulm>	Calchan: count me as 5.1 please
-22:07:16 <Calchan>	ulm, can you take care of that with for example zmedico ?
-22:07:30 <ulm>	*sigh* yes
-22:07:47 <Calchan>	ulm, ah ok, so we have 2 for 5.1 and 3 for 5.3
-22:08:01 <leio>	into PMS as EAPI-0 clarification or?
-22:08:29 <ulm>	leio: EAPI 4, unless we vote otherwise now
-22:08:59 <Calchan>	EAPI3+1 for me
-22:09:06 <Calchan>	=EAPI4
-22:09:16 <Betelgeuse>	3 or 4
-22:09:33 <Calchan>	ah right, sticking that with prefix is a good idea
-22:09:49 <ulm>	good idea
-22:09:56 <leio>	Calchan: can you write out how you counted who as to avoid any misunderstandings?
-22:10:05 <Calchan>	leio, ok
-22:10:20 <Calchan>	Betelgeuse and ulm 5.1
-22:10:32 <Calchan>	dertobi123, solar and Calchan 5.3
-22:10:39 <Calchan>	leio abstention
-22:10:49 <Calchan>	is it ok for everybody?
-22:10:53 <ulm>	yes
-22:10:57 <solar>	I can go either way on 5.x
-22:11:09 <Betelgeuse>	Calchan: then we don't have a decision?
-22:11:24 <Betelgeuse>	Calchan: There's someone missing
-22:11:27 <Calchan>	solar, then make your mind and tell us
-22:11:34 <solar>	Nobody said anything about making it a new EAPI however
-22:12:12 <solar>	portage is not going to limit it's behavior to do this only-if-eapi>=3
-22:12:17 <Calchan>	solar, let's decouple the EAPI issue then
-22:12:24 <solar>	please lets.
-22:12:27 <ulm>	solar: It wouldn't make any practical difference for portage and pkgcore
-22:12:34 <ulm>	since they already comply
-22:12:55 <Calchan>	solar, the point would be to document what can be relied upon starting with EAPI3
-22:12:56 <solar>	ulm: right. But till this meeting nobody said anything about making it an EAPI change.
-22:12:59 <Calchan>	not changing enyhting
-22:14:59 <ulm>	so, have we accepted 5.3 or what?
-22:15:00 <Calchan>	so, anybody who wants to reconsider his vote? solar? then we can discuss the eapi issue
-22:15:13 <leio>	Note that on 12th October meeting we re-opened what was known as EAPI-3 for mtime preservation
-22:15:46 <leio>	(but nvm)
-22:16:32 <Calchan>	solar? do you reconsider your vote or you keep 5.3?
-22:17:46 <solar>	I'm still in favor of 5.3
-22:17:49 <Calchan>	ok
-22:17:53 <leio>	On 12 October meeting we also voted "A: current Portage and Pkgcore behaviour, all mtimes are preserved" with a clear majority, was this topic re-opened since then?
-22:18:18 <ulm>	leio: no, just clarifications to it
-22:18:23 <leio>	ok.
-22:18:26 <Calchan>	leio, the issue was about documenting
-22:18:35 <Betelgeuse>	leio: Basically sub seconds involved
-22:18:46 <solar>	I need to go. For any remaining open topics and I don't think any remain. See email.
-22:19:31 >grobian<	hey, do you have quick links for the prefix support discussion thread and a link to the prefix portage branch, for the purpose of the meeting summary?
-22:19:31 <Calchan>	solar, thanks, I think we're good
-22:20:28 <dertobi123>	we're done?
-22:20:33 <Calchan>	now the question is do we apply the documenttion change to all EAPIs retroactively? to the newly defined EAPI3? or to EAPI4?
-22:20:47 <Betelgeuse>	3
-22:20:51 <Calchan>	dertobi123, no but we'll use his email
-22:20:56 <Calchan>	I vote 3 too
-22:21:36 <ulm>	3
-22:21:40 <leio>	I vote EAPI3 or retroactively
-22:21:48 <Calchan>	dertobi123?
-22:22:21 <dertobi123>	for all eapis retroactively makes sense for me, as that's what portage is doing for quite some time - but making it part of our new eapi-3 works as well
-22:22:34 <ulm>	really it doesn't make any practical difference
-22:22:37 <Calchan>	thanks
-22:22:53 <Calchan>	so we have 5 votes for EAPI3 and 2 for retroactive
-22:23:17 <leio>	so basically "Since EAPI-3 this behaviour can be relied on in all PMS compliant package managers"
-22:23:20 <Calchan>	we'll define mtime preservation based on what portage does today in EAPI3 onwards
-22:23:36 <ulm>	right
-22:23:50 <dertobi123>	ack
-22:23:52 <Calchan>	and ulm you'll take care of the with whoever? is it ok?
-22:24:08 <ulm>	Calchan: I'll talk to Zac
-22:24:13 <Calchan>	and anymore comments on this topic before we switch?
-22:24:49 <leio>	ACTION: ulm to talk with Zac about defining current portage behaviour for documenting in EAPI-3
-22:24:59 <Calchan>	thanks leio
-22:25:07 <Calchan>	and I understand we can move on
-22:25:23 <Calchan>	6.1 logs? summary? I can do summary if nobody wants
-22:25:31 <leio>	I have the summary almost ready
-22:25:39 <leio>	Logs I will commit today
-22:25:40 <Calchan>	leio, great thanks
-22:25:41 <ulm>	leio++
-22:25:42 <dertobi123>	leio++ for that
-22:25:43 -->	Ramonster (n=ramonvan@ramonvanalteren.xs4all.nl) has joined #gentoo-council
-22:25:54 <Calchan>	6.2 next meeting?
-22:26:03 <Calchan>	I'd like to delay by one week
-22:26:08 <leio>	Sorry for slacking on the previous ones (see my private e-mail), writing it during the meeting works a lot better
-22:26:23 <leio>	I am fine with either delaying or not
-22:26:28 <Calchan>	we've been meeting every 4 weeks instead of every month so we gained a couple weeks on the way
-22:26:40 <Calchan>	and I'm not sure my brain and liver will be up to speed
-22:27:07 <Betelgeuse>	4 or 18 are best for me in January
-22:27:14 <Betelgeuse>	well != 11
-22:27:21 <Betelgeuse>	Exams on 12
-22:27:26 <dertobi123>	so, january 18th then?
-22:27:44 <Betelgeuse>	solar probably has a work meeting
-22:27:44 <Calchan>	18th seems a bit late, in which case I don't mind doing it on the 4th
-22:28:08 <Betelgeuse>	so we might want to ask what suits him
-22:28:28 <Calchan>	Betelgeuse, I'll see with him if another day of the week would help
-22:28:47 <Calchan>	Betelgeuse, your exams are on the 12th only or all week?
-22:28:48 <ABCD>	May I request that the council consider adding *.xz/*.tar.xz to unpack() for the new EAPI-3 (instead of waiting until EAPI-4)? (or should that wait until the next meeting? Portage already has support, but disabled for older EAPIs)
-22:28:54 <Betelgeuse>	Calchan: all week
-22:29:09 <Calchan>	ABCD, not the time and place to do that, send an email to the list as usual
-22:29:18 <ABCD>	Calchan: okay
-22:29:29 <Calchan>	Betelgeuse, so let's see with solar what day in the week of the 4th he prefers
-22:29:51 <Calchan>	does anybody have a preference for a day in that week?
-22:30:13 <Betelgeuse>	before friday
-22:30:22 <leio>	not me, but maybe we need to re-consider Monday if his meetings are always on Mondays?
-22:30:32 <leio>	(I mean not for just one meeting, but overall)
-22:30:41 -->	ulm__ (n=ulm@p4FD3F0D7.dip.t-dialin.net) has joined #gentoo-council
-22:30:43 <Calchan>	leio, yes
-22:30:51 <dertobi123>	what about starting a new doodle-poll for the january meeting?
-22:31:11 <--	ulm has quit (Nick collision from services.)
-22:31:17 ---	ulm__ is now known as ulm
-22:31:20 <Calchan>	so if everybody agrees we'll have next meeting on that week of january which starts on the 4th, we need to decide what day exactly
-22:31:31 <ulm>	sorry, network hiccup
-22:31:33 <Calchan>	dertobi123, great, can you take care of that?
-22:31:46 <Betelgeuse>	who does the agenda next time?
-22:31:57 <dertobi123>	Calchan: i'll try to do so, yeah
-22:32:17 <leio>	ACTION: dertobi123 to check what day of the week is best for council members nowadays, possibly rescheduling the next meetings date
-22:32:27 <Calchan>	and follow up topics, just doing the agenda is not enough, devs need to be pushed to do the right thing
-22:32:47 ---	ChanServ gives channel operator status to ulm
-22:33:21 <Calchan>	I can't do the agenda as I will be without internet for 2 weeks around christmas and new year
-22:34:25 ---	dabbott|away is now known as dabbott
-22:34:32 <Calchan>	if nobody volunteers I can do it if we delay the meeting by at least one week
-22:34:33 <Betelgeuse>	I will mostly be reading for exams so I would prefer someone else
-22:34:50 <Calchan>	Betelgeuse, yes, don't sabotage your exams
-22:35:16 <Betelgeuse>	Calchan: Well Finnish system gives you infinite retries
-22:35:25 <Calchan>	I don't mind doing it if we agree to delay
-22:35:32 <Calchan>	Betelgeuse, but life doesn't ;o)
-22:35:35 <Betelgeuse>	So sabotaging is impossible :)
-22:35:45 <dertobi123>	works for me, besides that i'd like to see luca or solar doing an agenda, too
-22:36:40 <dertobi123>	btw. luca ...
-22:36:56 <Calchan>	dertobi123, luca has been pretty much inactive so he may not have enough time (and I'd prefer this be done correctly as it's important) and solar is reconsidering all his gentoo activities due to work
-22:38:04 <Calchan>	dertobi123, please add to your the possibility to delay the meeting to the week of the 18th, in which case I can take care of the agenda
-22:38:14 <Calchan>	s/to your/to your poll/
-22:38:39 <dertobi123>	so well, yeah ... speaking of luca ... he missed the july and august meetings according to the logs and he missed this meeting, too. if we follow glep 39 it's time to elect a replacement for luca :/
-22:38:41 <leio>	that's like two polls then, day in general, and week
-22:39:09 <Calchan>	dertobi123, we usually don't elect and pick the next in list
-22:39:18 <Calchan>	which would be bonsaikitten
-22:39:30 <Betelgeuse>	Calchan: that's for stepping down
-22:39:33 <Betelgeuse>	Calchan: not slackers
-22:39:34 <bonsaikitten>	uh-oh :)
-22:39:39 <leio>	to my knowledge we elect, but tend to elect the next in list
-22:39:49 <Calchan>	Betelgeuse, right, sorry
-22:40:04 <Betelgeuse>	New elections it is then.
-22:40:05 <dertobi123>	"a new election is held to replace that person"
-22:40:20 <Calchan>	whoever that is I want to make sure that person will be committed to the coucil though
-22:40:23 <Betelgeuse>	We already voted not to change GLEP 39 ourselves
-22:40:57 <Calchan>	Betelgeuse, yes sorry, my brain is low on sugar, I need lunch :o)
-22:40:58 <ulm>	dertobi123: but we had _reopen_nominations in the last ballot
-22:41:20 <ulm>	so we take the next candidate if he ranks above it
-22:41:32 <Calchan>	ulm, reopen nominations is to hold another entire election
-22:41:45 <Calchan>	or I'm mistaken again?
-22:42:01 <ulm>	Calchan: i'm not sure
-22:42:17 <Calchan>	I propose that we have that discussion off list
-22:42:45 <Calchan>	and if necessary vote for a new member before the end of next week
-22:42:51 <dertobi123>	ulm: _reopen_nominations isn't even mentioned in glep39
-22:43:04 <ulm>	Calchan: youre right, glep 39 says "a new election is held to replace that person."
-22:43:48 <--	ohnobinki has quit (verne.freenode.net irc.freenode.net)
-22:43:48 <--	kallamej has quit (verne.freenode.net irc.freenode.net)
-22:43:48 <--	robbat2|na has quit (verne.freenode.net irc.freenode.net)
-22:43:48 <--	TomJBE has quit (verne.freenode.net irc.freenode.net)
-22:43:48 <--	Caster has quit (verne.freenode.net irc.freenode.net)
-22:43:49 <--	ahf has quit (verne.freenode.net irc.freenode.net)
-22:44:05 <Calchan>	dertobi123, which is what I meant when I said that glep 39 had been impliciteley and explicitely modified in the past without a vote and I wanted us to decide on a mechanism to do that roperly, but nobody seemed to care so I gave up
-22:44:22 -->	robbat2|na (i=nobody@gentoo/developer/robbat2) has joined #gentoo-council
-22:44:22 -->	TomJBE (n=tb@gentoo/contributor/tomjbe) has joined #gentoo-council
-22:44:22 -->	ohnobinki (n=ohnobink@ohnobinki-1-pt.tunnel.tserv9.chi1.ipv6.he.net) has joined #gentoo-council
-22:44:22 -->	Caster (i=Caster@gentoo/developer/caster) has joined #gentoo-council
-22:44:22 -->	ahf (i=ahf@irssi/staff/ahf) has joined #gentoo-council
-22:44:22 -->	kallamej (n=kallamej@gentoo/developer/kallamej) has joined #gentoo-council
-22:44:27 <Calchan>	that was n the first meetings
-22:44:36 *	dertobi123 remembers
-22:45:01 <Calchan>	if you guys are interested I can reactivate this at some point and we can discuss it again
-22:45:30 <dertobi123>	iirc we did vote to hold a general vote of all developers to amend glep39, but someone want to check the logs to be sure ;)
-22:45:49 <dertobi123>	Calchan: at least it's something that should be fixed
-22:46:01 <leio>	http://www.gentoo.org/proj/en/council/meeting-logs/20090720-summary.txt
-22:46:12 <Calchan>	dertobi123, we only voted that we couldn't decide be didn't vote on who could
-22:46:29 <Calchan>	whatever, this is not a discussion for right now, let's wrap up this meeting
-22:46:57 <Calchan>	6.2 dertobi123 will setup polls for what week and what day to meet next time
-22:47:03 *	dertobi123 nods
-22:47:34 <Calchan>	6.3 I volunteer to do the agenda next time unless we don't shift the meeting by at least one week or somebody else volunteers
-22:48:01 <Calchan>	and we will decide of who replaces lu_zero (vote or not) by the end of next week
-22:48:12 <Calchan>	actually before the 18th
-22:48:21 <Calchan>	if everybody is OK with that
-22:48:39 <Calchan>	after that date I'm without internet
-22:48:52 <dertobi123>	works for me, i'm mostly w/o internet starting the 18th
-22:49:06 <Calchan>	does everybody agree?
-22:49:13 <solar>	yes
-22:49:28 <Calchan>	solar, ah you're back :o)
-22:49:51 <solar>	had to pick up my lunch. I've been back watching the chat for the past ~10mins
-22:50:31 <Calchan>	if everybody agress then I'll declare the floor open to everybody for discussion of whatever including gleps 57 to 61
-22:50:50 <Calchan>	and I'll run to the microwave to prepare my lunch because I'm starving :o)
-22:50:50 <dertobi123>	okies, off to bed now. nn
-22:51:02 <Calchan>	good meeting, thanks guys
-22:51:22 <leio>	Does anyone have links handy for prefix support portage branch and the discussion thread about it?
-22:51:36 <dertobi123>	thanks for preparing the agenda and chairing this meeting, Calchan. well organized one :)
-22:52:24 <ulm>	yeah, thanks Calchan
-22:53:29 <solar>	leio: it was in calchans first mail to -dev ml about the agenda
-22:54:08 <solar>	http://archives.gentoo.org/gentoo-dev/msg_e588558e19aefd9f477f452cfdce955a.xml (you can follow this backwards)
-22:54:17 <leio>	oh, right
-22:55:29 <--	darkside_ (n=darkside@gentoo/developer/darkside) has left #gentoo-council
-22:55:50 <leio>	Presumably http://sources.gentoo.org/viewcvs.py/portage/main/branches/prefix/ for the branch
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100118-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100118-summary.txt
deleted file mode 100644
index 8cccc731db..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100118-summary.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-Summary of the meeting of January 18th, 2010
-
-Attendance
-==========
-Present:
- Betelgeuse
- Calchan
- dertobi123
- leio (proxied by wired)
- scarabeus
- solar
- ulm
-
-Agenda
-======
-Final approval of prefix and mtime preservation
-Moving xz unpacking from EAPI4 to EAPI3
-Final approval of EAPI3
-Approval of GLEPs 57 to 61
-Merging of multiple ABIs code into the portage 3.3 branch
-
-prefix
-======
-The final implementation of prefix was unanimously approved for inclusion in
-EAPI3.
-
-mtime preservation
-==================
-The final implementation of mtime preservation was unanimously approved for
-inclusion in EAPI3.
-
-xz unpacking in EAPI3
-=====================
-xz unpacking was planned for EAPI4 but was already ready. Porting this feature
-to EAPI3 is trivial. The council approved xz unpacking to be included in
-EAPI3.
-
-Final approval of EAPI3
-=======================
-EAPI3 was approved by the council.
-
-GLEP 57
-=======
-GLEP57 was approved by the council.
-
-GLEPs 58 to 61
-==============
-The vote on GLEPs 58 to 61 was postponed due to more discussions being
-necessary.
-
-Multiple ABIs
-=============
-The council unanimously rejected the request for inclusion of the Multiple
-ABIs code in the portage 2.2 branch. Instead it was suggested to follow Zac's
-(zmedico) recommendation of maintaining it in a separate branch which is going
-to be made easier by the fact that the portage repository is being switched to
-git. Zac offered to help Thomas (tommy) with that.
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100118.txt b/xml/htdocs/proj/en/council/meeting-logs/20100118.txt
deleted file mode 100644
index b8f5ea6ec8..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100118.txt
+++ /dev/null
@@ -1,576 +0,0 @@
-21:00:06 ---	dertobi123 sets mode +m #gentoo-council
-21:00:09 <dertobi123>	hi
-21:00:11 <Calchan>	Betelgeuse, dertobi123, solar?
-21:00:14 <Betelgeuse>	Calchan: yes
-21:00:26 *	scarabeus aroundy :]
-21:00:31 <Calchan>	ok, so it looks like we're only missing solar
-21:00:45 <solar>	why do you say that?
-21:00:59 <Calchan>	solar, oh sorry, hi :o)
-21:01:06 <scarabeus>	:]
-21:01:54 <Calchan>	ko, so who's logging?
-21:02:00 <Betelgeuse>	I am
-21:02:03 <Calchan>	good
-21:02:13 <Calchan>	anyone else, just in case?
-21:02:14 *	wired logging as well
-21:02:17 <Calchan>	great
-21:02:21 <Calchan>	roll call
-21:02:25 <ulm>	here
-21:02:31 <wired>	here, proxy for leio
-21:02:32 <scarabeus>	here
-21:02:44 <Betelgeuse>	still here
-21:02:46 <Calchan>	I'm obviously here :o)
-21:02:47 <solar>	likewise
-21:03:01 <Calchan>	dertobi123, is here too, still alive ? ;o)
-21:03:13 <dertobi123>	yep
-21:03:15 <dertobi123>	somewhat
-21:03:17 <Calchan>	great
-21:03:23 <Calchan>	who wants to chair?
-21:03:39 <Calchan>	I can as I know the topics, but anybody else is welcome to volunteer
-21:03:45 <solar>	Please do
-21:03:45 <Betelgeuse>	feel free
-21:03:46 <ulm>	Calchan: no objections
-21:03:53 <Calchan>	ok then
-21:04:02 <Calchan>	any remarks on the agenda?
-21:04:22 <Betelgeuse>	Calchan: Could get comments on the council web app at end if there's time but unlikely
-21:04:30 <Betelgeuse>	Calchan: As I didn't get much on the mailing list
-21:04:33 <Betelgeuse>	and scarabeus is new
-21:04:35 <Calchan>	after 4 we need to officially approve eapi3 if the status report of 2 and 3 is OK
-21:04:54 <ulm>	yes
-21:05:02 <Calchan>	Betelgeuse, yes, let's discuss that i n the open floor part if you want
-21:05:16 -->	ssuominen (n=ssuomine@gentoo/developer/ssuominen) has joined #gentoo-council
-21:05:22 <Calchan>	I couldn't comment on that, I was too busy with other ongoing subjects
-21:05:35 <Calchan>	any other comments?
-21:05:48 ---	Calchan gives voice to grobian
-21:06:11 <Calchan>	ok, let's moce to 2. prefix status
-21:06:23 -->	Cardoe (n=Cardoe@gentoo/developer/Cardoe) has joined #gentoo-council
-21:06:34 <Calchan>	grobian, can you tell us how prefix is progressing?
-21:06:39 <Calchan>	my typing sucks today
-21:06:43 <grobian>	Calchan: fairly well, I'd say
-21:06:51 <grobian>	as far as I know, portage is ready
-21:07:00 <Calchan>	ok, what was done, and what still needs to be done?
-21:07:03 <grobian>	it seems the PMS patch needed a final review by the council
-21:07:09 <Calchan>	ok
-21:07:18 <grobian>	so thanks to ulm the patch has been brought into a final state
-21:07:40 <grobian>	I personally see nothing that needs to be done
-21:07:49 <Calchan>	grobian, am I right in thing that there's nothing pending before finmal approval?
-21:07:51 <grobian>	lots of peeps actually started porting stuff
-21:07:56 <Calchan>	/thing/thinking/
-21:08:21 <grobian>	Calchan: as far as I am aware, all objections/questions by PMS team were dealt with
-21:08:30 <grobian>	I'd have to ask ulm to make that official
-21:08:42 <ulm>	yes, I think so
-21:09:05 <Calchan>	so if other council members agree we will consider prefix done and not a blocker for final approval of eapi3 then
-21:09:09 <ulm>	there were no more comments on the last version of the patch
-21:09:25 <Calchan>	can I get a quick yes from everybody on the above question? just a formality...
-21:09:27 <--	Arfrever has quit (Client Quit)
-21:09:41 <Calchan>	so that's a yes from me
-21:09:43 <dertobi123>	here's your "yes"
-21:09:45 <wired>	+1 here
-21:09:46 <ulm>	yes
-21:09:51 <scarabeus>	here is 1 "yes"
-21:09:52 <Betelgeuse>	the approval is done by having something to tag in PMS before
-21:10:03 <Betelgeuse>	if it's not committed yet then there's no commit to review and tag yet
-21:10:13 <ulm>	sigh
-21:10:18 <Betelgeuse>	but conceptually yes
-21:10:22 <Calchan>	Betelgeuse, we have a patch so it's as good
-21:10:23 <ulm>	it's committed: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f49a53b3a97dbe299f1b71dad5a6bf5b9b6805ba>
-21:10:32 <Calchan>	ulm, thanks
-21:10:32 <Betelgeuse>	ulm: good
-21:10:44 <Calchan>	solar? although we seem to have a majority here
-21:11:40 <solar>	Calchan: one moment
-21:11:44 <Calchan>	solar, sure
-21:13:22 <Calchan>	solar, let's move one as we have a majority anyway, and feel free to chime in with your opinion on that at any time during the meeting when you're more available
-21:13:38 <Calchan>	so let's move to : 3. mtime preservation status
-21:13:41 <Calchan>	ulm?
-21:14:08 <Calchan>	I seem to remember there was a minor point still to be dealt with, what was it again?
-21:14:18 <ulm>	no, all issues resolved
-21:14:26 <Calchan>	nothing that I would consider big enough to block eapi3 approval though
-21:14:30 <ulm>	consensus with PMS team and all PM authors
-21:14:40 <Calchan>	ulm, but can you still please remind us what it was?
-21:14:47 <Calchan>	just out of curiosity
-21:15:10 <solar>	Calchan: I voted last month to approve the prefix stuff. My vote from then still stands. So yes.
-21:15:12 <ulm>	there was an issue with nanosecond time stamps
-21:15:18 <Calchan>	solar thanks
-21:15:27 <Calchan>	ulm ah yes
-21:15:30 <ulm>	but it has been resolved
-21:15:49 <ulm>	here's the commit in PMS: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=51690686a39149f89a64b80b5d6074cc56c46e1a>
-21:16:02 <Calchan>	ok, so do we all agree on final approval of mtime preservation for eapi3?
-21:16:06 <Calchan>	yes from here
-21:16:09 <ulm>	yes
-21:16:13 <dertobi123>	yep
-21:16:52 <scarabeus>	yep
-21:16:56 <Betelgeuse>	yes
-21:17:03 <solar>	reading
-21:18:26 <wired>	looks good, yes
-21:18:49 <Calchan>	alright we have a majority anyway, solar you can take your time
-21:18:53 <solar>	what is this subsecond stuff being slipped in?
-21:19:27 <ulm>	solar: basically, it says that subseconds must be set to zero or preserved exactly
-21:19:39 <solar>	ulm: that is new.
-21:19:51 <solar>	so does this turn it's value into a float/double ?
-21:20:15 <ulm>	solar: no, only intergers involved
-21:20:19 -->	yporti (n=yporti@r306-pb-passacinco.ibys.com.br) has joined #gentoo-council
-21:20:19 <ulm>	*integers
-21:21:07 <Calchan>	solar, ulm, can we move forward or you need more time to discuss this now?
-21:21:32 <ulm>	Calchan: move forward please, we can discuss it later
-21:21:38 <Calchan>	ulm, ok thanks
-21:21:46 <Calchan>	4. Should we move xz unpacking from EAPI4 to EAPI3?
-21:21:51 <ulm>	solar: it's all fine, trust me ;)
-21:21:57 <Calchan>	this was actually my fault that this was not discussed last time
-21:22:19 <Calchan>	we had a PMS patch ready already, prtage has that implemented for quite some time
-21:22:23 <Calchan>	and it's trivial
-21:22:32 -->	Fauli (n=Opfer@gentoo/developer/fauli) has joined #gentoo-council
-21:22:42 <dertobi123>	then lets get that in to eapi 3
-21:22:47 <Betelgeuse>	My point previosly and still is keeping EAPI 3 as something that most developers wouldn't need to know the contents of
-21:22:59 <scarabeus>	its two liner iirc :]
-21:23:00 <Calchan>	dertobi123, we still need to vote on xz though
-21:23:13 <Betelgeuse>	If we have repoman verifying proper .xz usage then it's fine for me
-21:23:23 <Calchan>	and its a yes from me
-21:23:35 <scarabeus>	well it is nothing required to know if portage handles it iself :]
-21:23:37 <dertobi123>	Calchan: that was my vote ;)
-21:23:41 <solar>	fine as well on .xz
-21:23:45 <Calchan>	can anybody answer Betelgeuse on repoman? ping me in private if you need voice
-21:24:02 <wired>	and a yes from me
-21:24:24 <Calchan>	we already have a majority anyway
-21:24:25 <scarabeus>	iirc it does not bail out now, since we have xz packages in kde4.4 snapshots
-21:24:37 <scarabeus>	and we supply the .xz tarballs and own extract function
-21:24:51 <scarabeus>	only problem with it is depending on proper tar version that supports xz
-21:25:01 <Betelgeuse>	scarabeus: Should we start forcing EAPI 3 or later for .xz?
-21:25:05 <Betelgeuse>	Such a repoman patch is easy
-21:25:26 <ulm>	.xz in eapi 3 fine for me as well
-21:25:40 <Betelgeuse>	What does Portage do for .xz files in EAPIs 0 1 2?
-21:25:44 <scarabeus>	we should push it throught, because few upstreams use only xz as sources, and the custom unpacks are lame
-21:25:53 <ulm>	Betelgeuse: unpack ignores them
-21:26:06 <Betelgeuse>	I remember some extension being pushed without EAPI bump but it was probably lzma related
-21:26:28 <Calchan>	as far as I can see we have everything approved for eapi3 so unless you speak now we have final approval for it
-21:26:50 <Betelgeuse>	ulm: Ok which is probably not what the user wants so EAPI 3 repoman check should be ok
-21:27:04 <ulm>	Calchan: so we include xz or not?
-21:27:15 <dertobi123>	we do
-21:27:17 <Calchan>	ulm, looks like it, yes :o)
-21:27:20 <ulm>	k
-21:27:23 <solar>	Calchan: assume yes from me on the eapi3 mtime.
-21:27:30 <Betelgeuse>	I will file a bug for repoman and xc
-21:27:31 <Calchan>	solar, ok thanks
-21:27:36 <Calchan>	Betelgeuse, good point
-21:27:48 <Calchan>	should we move forward?
-21:28:13 <Calchan>	5. GLEP 57
-21:28:23 <Betelgeuse>	https://bugs.gentoo.org/show_bug.cgi?id=301426
-21:28:45 <Calchan>	it's in informational glep on tree signing and security in general
-21:29:06 <Calchan>	if you want to discus it (briefly) speak now, or we'll move to vote on it
-21:29:46 <ulm>	Calchan: we don't approve eapi 3?
-21:29:59 <Betelgeuse>	I was mainly thinking do we need informational docs as GLEPs
-21:30:01 -->	romi (n=Rodrigo@mail.ltia.fc.unesp.br) has joined #gentoo-council
-21:30:09 <Calchan>	ulm, you want a specific vote for it? that's ok with me
-21:30:23 <Calchan>	let's vote for final approval of eapi3 then
-21:30:27 <Calchan>	yes
-21:30:30 <ulm>	Calchan: i think it would be appropriate
-21:30:35 <scarabeus>	yes for eapi3
-21:30:35 <ulm>	yes
-21:30:35 <dertobi123>	here's your yes :)
-21:31:04 <Calchan>	grobian, can you please take care of the champagne in the meantime?
-21:31:12 <Betelgeuse>	yes
-21:31:13 <grobian>	Calchan: you're just too late
-21:31:17 <dertobi123>	Betelgeuse: wrt informational docs - i don't think we *need* those as GLEPs, but it doesn't hurt to have one as a GLEP
-21:32:00 <Calchan>	we have a majority for eapi3 final approval, so as of right now eapi3 is offically official
-21:32:24 <Betelgeuse>	ulm: as you have commit rights it's easiest for you to tag it
-21:33:02 <Calchan>	let's move to GLEP 57 now
-21:33:05 <ulm>	Betelgeuse: I don't, but I'll ask fauli
-21:33:15 <wired>	yes for eapi3 for formality :)
-21:33:17 <solar>	We are going to have a hard time talking about these gleps 57-61 if robbat2 does not show up.
-21:33:26 <Betelgeuse>	ulm: The tags have been signed by council members
-21:33:37 <scarabeus>	the first one is ok
-21:33:40 <ulm>	Betelgeuse: ok, will do then
-21:33:49 <scarabeus>	it just sums up the reasons and whats going on :]
-21:33:55 <Calchan>	solar, he said he probably wouldn't though and I think most of us have discussed it with him before
-21:34:21 <Betelgeuse>	ulm: I remember using a bundle or something like that and emailing that to someone who can commit
-21:34:58 <Calchan>	technically all we need to do is vote yes or no, and no might mean not yet, discussions should have happened before as this has been in the making for years
-21:35:12 ---	Calchan gives voice to Fauli
-21:35:53 <Calchan>	Fauli, you have voice now so go ahead
-21:35:59 <Fauli>	Betelgeuse: I can commit, as Ciaran is not available for some days.
-21:36:15 <Fauli>	As soon as you are ready, send it my way.
-21:36:26 <--	Cardoe has quit (Remote closed the connection)
-21:37:18 <Calchan>	ok, so since there does not seem to be any discussion about glep 57, let's vote
-21:37:37 <Calchan>	I vote yes, as in it's informational only but states some necessary goals
-21:37:54 <ulm>	yes for 57
-21:38:06 <scarabeus>	glep 57 - yep
-21:38:15 <dertobi123>	yes
-21:38:21 <Betelgeuse>	yes
-21:38:26 <solar>	yes
-21:38:41 <Calchan>	good, we have a majority for yes, glep 57 is approved
-21:38:52 <Calchan>	6. GLEP 58
-21:39:39 <Calchan>	58 is about implementing metamanifest which does not require developper action
-21:39:56 <Calchan>	same thing, vote or comment please
-21:40:04 <Betelgeuse>	I assume robbat2 has done testing in practise from the latter GLEPs so no objections here
-21:40:14 -->	_robbat2laptop (n=robbat2@gentoo/developer/robbat2) has joined #gentoo-council
-21:40:15 <dertobi123>	first we'd need to vote for glep-60, as this one is required by 57
-21:40:22 ---	Calchan gives voice to _robbat2laptop
-21:40:26 <Calchan>	yay
-21:40:33 <_robbat2laptop>	sorry, in work meeting, and had bad wifi till now
-21:40:41 <ulm>	the size of the metamanifest is very large if there are no subdir (i.e. categories + eclass + profiles) metamanifests
-21:40:56 <Calchan>	_robbat2laptop, we approved 57 and were just starting 58
-21:41:11 <_robbat2laptop>	ulm, the metamanifest spec does specify subdirs Manifests are strongly suggested
-21:41:15 <Calchan>	ulm, agreed but there's glep 61 to the rescue
-21:41:39 <ulm>	_robbat2laptop: maybe council should support this suggestion then
-21:42:13 <Calchan>	ulm, we can make a specific note of it but it being in the glep already is enough for me
-21:42:41 <Calchan>	I would vote yes on this one, my only concern is about infra havong the manpower to actually implement that
-21:42:56 <_robbat2laptop>	Calchan, there's a functional MetaManifest generation prototype already
-21:43:03 <_robbat2laptop>	in my other dir on the gentoo CVS repo
-21:43:10 <solar>	and how is the final file?
-21:43:13 <solar>	how big
-21:43:33 <Betelgeuse>	_robbat2laptop: Have you tested how much slowers emerge --sync becomes?
-21:43:44 <ulm>	solar: I think it was 8 MB if without subdir manifests
-21:43:59 <Calchan>	ulm, compressed or not?
-21:44:21 <_robbat2laptop>	8MB uncompressed without subdirs
-21:44:37 <Calchan>	not that big of a deal then
-21:44:46 <_robbat2laptop>	if subdirs are used, it's about 8.05MB raw
-21:45:16 <ulm>	the compression factor cannot be good for SHA hashes
-21:45:39 <ulm>	mainly factor of 2 for ascii -> binary
-21:45:48 <Calchan>	_robbat2laptop, can you confirm that e.g. users on low bandwidth can deactivate this?
-21:45:49 <_robbat2laptop>	better than 2:1
-21:46:00 <_robbat2laptop>	Calchan, they can add --exclude MetaManifest*
-21:46:12 <_robbat2laptop>	they wouldn't be able to validate the tree as easily
-21:46:19 <_robbat2laptop>	but that is a tradeoff they have to decide
-21:46:43 <Calchan>	then if it can be deactivated and we have an already (at least partially) working implementation I vote yes
-21:46:47 <Calchan>	what about others?
-21:47:00 <Betelgeuse>	_robbat2laptop: I don't think you answered the speed implications
-21:47:34 <_robbat2laptop>	Betelgeuse, without the split, it's a new MetaManifest file nearly every rsync pass
-21:47:57 <Betelgeuse>	_robbat2laptop: I mean how long does verifying the Manifests add to the time
-21:47:58 <_robbat2laptop>	with the subdir split, the extra data transfered is <2MB in my tests
-21:48:03 <scarabeus>	we should maybe enforce the splits instead of recommending
-21:48:22 <Calchan>	scarabeus, good point
-21:48:23 <Betelgeuse>	_robbat2laptop: Mainly if there's anything major for older machines?
-21:48:23 <wired>	2mb isn't that bad
-21:48:40 <wired>	scarabeus: that sounds good
-21:48:47 <Calchan>	_robbat2laptop, what's the cost/implications of splitting?
-21:48:48 <_robbat2laptop>	Betelgeuse, I had full signature verification of _every_ Manifest and MetaManifest in <5 seconds, plus any IO time
-21:49:07 <Betelgeuse>	_robbat2laptop: ok thanks
-21:49:14 <_robbat2laptop>	cputime ~5 seconds on a not fast P4 box, ~3 years ago
-21:49:14 <solar>	Calchan: in short it's faster if split.
-21:49:35 <_robbat2laptop>	yes, because the subdir MetaManifests might not have changed between passes
-21:49:35 <Calchan>	solar, that's what I thought but I was afraid there was a downside to it
-21:49:44 <_robbat2laptop>	~50 more inodes
-21:49:48 <solar>	8M ? there is too much overhead in this format
-21:49:57 <_robbat2laptop>	8M uncompressed
-21:49:59 <Calchan>	if there is no downside I'd be in favor of making it mandatory
-21:50:05 <_robbat2laptop>	that's why there was the compression GLEP
-21:50:10 <solar>	I just hashed the entire tree sha1 @ around 3.6M
-21:50:47 <ulm>	but sha256/512 is longer
-21:51:26 <Calchan>	are we ready to vote on this or do you need more time to discuss?
-21:51:33 <_robbat2laptop>	http://dev.gentoo.org/~robbat2/MetaManifest.bz2
-21:51:38 <solar>	_robbat2laptop: You are not filering the files that are moot?
-21:51:45 <_robbat2laptop>	from July 2008
-21:51:51 <solar>	like ChangeLog/metadata.xml and other manifests?
-21:52:04 <_robbat2laptop>	solar, every file should turn up in exactly on Manifest file
-21:52:11 <_robbat2laptop>	*exactly one
-21:52:16 <_robbat2laptop>	MetaManifest or Manifest
-21:52:25 <_robbat2laptop>	but no single file should be in more than one Manifest
-21:53:58 <solar>	is there any valid reason to checksum metadata.xml or ChangeLog files in this format?
-21:54:26 <_robbat2laptop>	solar, the added filetypes GLEP deals with when they can be excluded
-21:55:08 <ulm>	_robbat2laptop: about 2/3 of the metamaifest size are due to metadata/cache?
-21:55:19 <_robbat2laptop>	ulm, yes unfortuntely
-21:55:22 <solar>	what number is that? these gleps kinda make you just back and forth. Making it a bit difficult to follow
-21:55:26 <_robbat2laptop>	and those files DO need to be protected
-21:55:42 <wired>	scarabeus: 60
-21:55:46 <wired>	oops
-21:55:50 <wired>	solar: ^^ :)
-21:56:48 <_robbat2laptop>	58 - MetaManifest itself, 59 - hash types (SHA512), 60 - filetypes, 61 - compression
-21:57:12 <Calchan>	are we ready to vote on glep 58?
-21:57:52 <solar>	no
-21:58:04 <solar>	I can say. I'm ok with the idea as a whole and would like to see a compressed per cat metamanifests
-21:58:19 <Calchan>	solar, you need more time to discuss or you're voting no?
-21:58:20 <solar>	but these gleps don't allow you to vote on one of them.
-21:58:49 <solar>	and 60 looks like a format change in portage
-21:58:58 <_robbat2laptop>	ok, let's just tackle them in a different order for a sec.
-21:59:06 <_robbat2laptop>	61 is allowing compression in ANY manifest
-21:59:09 <_robbat2laptop>	not just the MetaManifest
-22:00:43 <Calchan>	solar, if you think they're not ready to be approved then vote no, ok?
-22:00:55 <solar>	wait a sec plz.
-22:01:08 <solar>	you guys even know what you are voting on?
-22:01:26 <Betelgeuse>	as much as always :)
-22:01:39 <Calchan>	solar, I have provisions to add to my vote but I'm ready to vote
-22:02:11 <dertobi123>	guess i do, and given the impact i'm against rushing this through today, especially if anyone of us has points he'd like to see adressed before voting
-22:02:21 <Calchan>	tjose provisions are btw that it is optional for the user and not on by default a tthe beginning, and that subdir splitting is mandatory
-22:04:02 <_robbat2laptop>	Calchan, is having the users that don't want it add --exclude MetaManifest* to their sync options acceptable?
-22:04:52 <Calchan>	_robbat2laptop, I wuold prefer the contrary at the beginning, i.e. users having to turn the feature on to use it
-22:04:55 <_robbat2laptop>	Betelgeuse, dertobi123, leio, scarabeus, solar, ulm: could you list what changes you would like?
-22:05:04 <scarabeus>	can we go throught rest of those (1glep in 4) and add all comments under which it can be accepted, and we can proceed with vote next time on all of them at once if anyone is not against?
-22:05:15 <_robbat2laptop>	Calchan, ok, if we roll out an upgrade of portage that includes that?
-22:05:30 <wired>	perhaps we could tackle these gleps one/two at a time?
-22:05:34 <Calchan>	_robbat2laptop, yes ok from me at this condition
-22:05:35 <_robbat2laptop>	ok, so no metamanifest yet, move on to the next glep
-22:05:53 <Calchan>	scarabeus, wired hold on, let's stick to the agenda for the time being
-22:05:54 <_robbat2laptop>	i'll represent GLEP58 with more changes
-22:06:14 <Calchan>	glep 59 is rather orthogonal to the others
-22:06:31 <Betelgeuse>	_robbat2laptop: GLEP 59 seems a bit outdated for python versions but that's just cosmetical
-22:06:39 <Betelgeuse>	_robbat2laptop: Could make it reflect the current situation
-22:06:41 <Calchan>	has everybody read it and does any og you have questions for _robbat2laptop?
-22:06:42 <_robbat2laptop>	58, 59, 60, 61 are all orthangonal
-22:06:45 <solar>	_robbat2laptop: Re; Like. I'd like to simply see the MetaManifests in the per category basis compressed. Not including bloat files that portage already ignores by allowing you to --exclude=metadata.xml and --exclude=ChangeLog ; With no changes to the existing Manifest format
-22:07:03 <--	billie has quit (Remote closed the connection)
-22:07:08 -->	billie (n=billie@gentoo/developer/billie) has joined #gentoo-council
-22:08:07 <Calchan>	_robbat2laptop, I had the following question about 59:
-22:08:29 <Calchan>	Second paragraph of "Checksum depreciation". Is the description still up-to-date about python support of various checksums? How about using external executables when python does not have support for a desirable checksum?
-22:08:45 <solar>	so the first parts can be introduced w/o major bloat or behavior changes in the PM. We review the overhead it causes on the rsync servers and decide from there if it safe to move fwd.
-22:09:48 <_robbat2laptop>	Calchan, yes, py2.5 and newer all support SHA512
-22:10:18 <Calchan>	we're seriously late now, here's what I propose:
-22:10:24 <dertobi123>	solar: i like that suggestion
-22:10:58 <Calchan>	it doesn't look liketoday  we're going to approve any of these gleps except for the informational one we have already approve
-22:11:16 <wired>	solar's suggestion is nice, or we can go the other way around and implement 59/60/61 first, then finish up with 58 when they're done
-22:11:38 <Calchan>	so I suggest that one of us (me if nobody volunteers but I would prefer somebody else) gathers a list of questions/remarks/provisions for robin tio update his gleps fpor next time
-22:11:56 <Calchan>	how's that?
-22:12:00 <_robbat2laptop>	i'll post each glep in the body of a mail to -dev
-22:12:12 <_robbat2laptop>	if you have an item, post a reply there as a new thread
-22:12:35 <Calchan>	does everybody agree postponing the rest of these gleps?
-22:12:47 <_robbat2laptop>	they've been presented for 2 months already, so I don't know why none of you except ulm have come to me with questions/changes
-22:12:59 <scarabeus>	actualy we technicaly can accept the 61, and if we will not accept the Metamanifest itself, that section of sentence can be removed
-22:12:59 <scarabeus>	because that glep apply to the Manifest2 too
-22:13:16 <scarabeus>	_robbat2laptop: i read them on saturday first time ;]
-22:13:27 <Calchan>	scarabeus, let's keep that for when we have a clearer view
-22:13:33 *	solar has been reading them for ~4 years
-22:13:59 <Calchan>	if nobody disagrees right now with postponing I'll move to the next point]
-22:14:39 <Betelgeuse>	_robbat2laptop: Because we need that web app of mine
-22:15:06 <scarabeus>	can we make mandatory that next time we will only vote on them and all concerns will have to be settled up to that meeting (so we dont end up like today?)
-22:15:21 <_robbat2laptop>	any if you don't present your question in the next month
-22:15:24 <ulm>	scarabeus: +1
-22:15:26 <_robbat2laptop>	you hold your tongue
-22:15:29 <Calchan>	scarabeus, eh, let me guess, you're new, right? ;o)
-22:15:41 <solar>	Calchan knew before the meeting that we would not vote on all. But would be doing this in phases
-22:15:42 <scarabeus>	:D
-22:16:08 <Calchan>	solar, I'll pretend I disagree
-22:16:20 <scarabeus>	okey okey :D
-22:16:26 <Calchan>	solar, what I actually told you is that you could vote no if you thought this wasn't ready
-22:16:48 <wired>	metamanifest aside, what are the objections to the other gleps?
-22:17:02 <Calchan>	I wasn't forcing anybofy to vote or even less agree to this, I was just putting this on the agenda as requested by robin
-22:17:12 <Calchan>	on the other hand you guys could have done your homework
-22:17:18 <Calchan>	anyway
-22:17:33 <Calchan>	10. Do we want to merge the code maintained by Tomas Sachau for multiple ABIs into portage 2.2 or should it be kept in a separate repository for now?
-22:17:46 <_robbat2laptop>	i'm going to part here now
-22:17:47 <scarabeus>	there i have question
-22:17:47 <_robbat2laptop>	thanks
-22:17:51 <scarabeus>	how is the git migration
-22:17:59 <_robbat2laptop>	scarabeus, RESO LATER
-22:17:59 <scarabeus>	s/how/where/
-22:18:14 <scarabeus>	i mean migration for portage as the manager :]
-22:18:22 <--	_robbat2laptop (n=robbat2@gentoo/developer/robbat2) has left #gentoo-council ("back to my other meeting")
-22:18:28 <scarabeus>	because if portage is on git, tommy just can have another branch
-22:18:37 <Calchan>	scarabeus, when you have such questions you should ask in advance for them to be put on the agenda
-22:18:59 <Calchan>	scarabeus, and you don't need to be a council member for that, you don't even need to wait for a council meeting
-22:19:21 <Calchan>	let's go back to:
-22:19:25 <Calchan>	10. Do we want to merge the code maintained by Tomas Sachau for multiple ABIs into portage 2.2 or should it be kept in a separate repository for now?
-22:19:25 <dertobi123>	imho that's nothing we'd need to vote on, it's zac's decision whether he wants to maintain the code in portage svn/git or not
-22:19:53 <Calchan>	but zac and thomas have asked for us to decide on that
-22:20:08 <wired>	I think they just want the format decision
-22:20:34 <scarabeus>	well if zac is ok with it, i think portage-2.2 can be experimental for bit longer :]
-22:20:53 <scarabeus>	where "bit" can vary :]
-22:20:54 <Calchan>	note that zac's opinion is to not merge that to portage 2.2 yet, but as the portage repo is being switched to git it will make it easier for him to help thomas maintain it, which ws thomas' main concern
-22:21:14 <Betelgeuse>	go with git and do whatever branch magic wanted
-22:21:17 <scarabeus>	which is what i said above with the question if they migrated to git yet?
-22:21:20 <dertobi123>	Betelgeuse++
-22:21:28 <dertobi123>	besides that, i'd still say it's up to zac
-22:21:42 <Calchan>	scarabeus, there's a bug for that in the agenda if you want to read it
-22:22:11 <scarabeus>	see;read
-22:22:38 <Calchan>	alright, so far we have:
-22:22:56 <Calchan>	no , go with git instead from Betelgeuse
-22:23:10 <Calchan>	and I have the same opinion/vote
-22:23:26 <Calchan>	dertobi123 says it's up to zac and zac says no
-22:23:27 <solar>	same. no portage-maintree. yes on new branch.
-22:23:45 <scarabeus>	branch is 100% fine with me too
-22:23:46 <Calchan>	that's 4 nos with solar's
-22:23:48 <wired>	leave it up to zac
-22:24:04 <solar>	we attempted to. He did not want to think for himself this time
-22:24:06 <Calchan>	alright, we have a decision then, that's no to 10
-22:24:06 <ulm>	no from me to, leave it to zac
-22:24:09 <ulm>	*too
-22:24:16 ---	Calchan gives voice to Tommy[D]
-22:24:20 <Calchan>	hi Tommy[D]
-22:25:03 <Calchan>	afaik the migration of the portage repo to git should happen any day now
-22:25:16 <wired>	a git branch would be nice though
-22:25:26 <Tommy[D]>	most say "no, go with git", but as robbat2 just said, that wont happen for now, so that means "no, no integration in the experimental portage-2.2* branch"
-22:25:56 <Tommy[D]>	and also "no intregration within the next future"
-22:25:56 <Betelgeuse>	Tommy[D]: that was about main tree
-22:25:56 <Calchan>	Tommy[D], the no above was for the migration of the tree to git, not the portage repo
-22:26:15 <solar>	right. That is also a no on portage-2.2
-22:26:39 <Calchan>	Tommy[D], the portage repo *is* being switched to git right now, it got delayed a bit for technical reasons but it's any day now
-22:26:42 <--	romi has quit (Client Quit)
-22:27:31 <solar>	You can branch in svn as well.
-22:27:38 <Betelgeuse>	but it sucks
-22:27:44 <wired>	is it possible to somehow put the whole mutilib code behind a USE flag in 2.2 to get more people to test it?
-22:27:45 <solar>	but it's not enough to hold anybody back
-22:27:47 <Calchan>	Tommy[D], again zac has agreed to help you maintain this, the fact that it's going to be an official branch maintained with zac will make it more visibla and it will get more testing
-22:28:21 <Tommy[D]>	Can those, who vote against integration give me their technical reasons against it, preferable via mail on the #-dev ML thread?
-22:28:22 <scarabeus>	wired: it can be FEATUREised, but the branch is easier
-22:28:26 <Betelgeuse>	Calchan: Well I doubt there's really much people on anything else put main tree releases
-22:28:39 <scarabeus>	wired: specialy with the GIT eclass
-22:29:15 <wired>	scarabeus: yeah but I was hoping for releases not live ebuilds :)
-22:29:31 <Betelgeuse>	Tommy[D]: What do you mean with integration?
-22:30:19 <Tommy[D]>	Betelgeuse: my request was merging into portage-2.2* branch, it was voted against, so i would like to know the reasons for the votes
-22:30:25 <Calchan>	Betelgeuse, Tommy[D], wired, scarabeus: I propose you go on with that discussion during the open floor session in a couple minutes
-22:30:49 <solar>	Tommy[D]: baby steps buddy.
-22:31:01 <Calchan>	let's finish with 11 and you can all resume this discussion
-22:31:07 <Calchan>	11. Conclusion
-22:31:12 <Calchan>	11.1 Action list. Who does what and when?
-22:31:38 <Calchan>	as actions I have gahter a list of questions/changes for robin
-22:31:52 <Calchan>	or lists if we want to do this per glep
-22:31:58 <Calchan>	who wants to do it?
-22:32:00 <Betelgeuse>	I am in Finland only the first Monday of February
-22:32:13 <Betelgeuse>	Otherwise I am in Bryssels or Vancouver
-22:32:16 <Calchan>	Betelgeuse, we'll come to that hold on
-22:32:31 <Betelgeuse>	Calchan: Don't ask both :)
-22:32:47 <Betelgeuse>	Calchan: Any way it excludes me from good agenda work
-22:33:00 <Calchan>	as I said I can volunteer for the questions to robin but I would really prefer somebody more technical takes care of it
-22:33:12 <Calchan>	solar?
-22:33:33 <Calchan>	anybody?
-22:33:36 <Betelgeuse>	solar seemed to have the most to need for changing things so would make sense
-22:33:50 <ulm>	Calchan: I can take it if nobody else volunteers
-22:33:51 <solar>	I can send him my last sentance. I expect he has his reasons for wanting to include metadata.xml/ChangeLog (I just don't understand them)
-22:34:10 <solar>	I don't know what concerns the rest of you had in the same/similar respects
-22:34:13 <Calchan>	ulm, thanks, I'll help you with that if you need
-22:34:37 <Calchan>	ok 11.2 Who takes care of the summary and log for this meeting? When?
-22:34:49 <Calchan>	when have leio and tanderson as volunteer for that
-22:34:59 <Calchan>	so I think we're covered
-22:34:59 <Betelgeuse>	Calchan: leio volunteered so I have no objections
-22:35:04 <ulm>	we still don't have a summary for october 2009 btw
-22:35:22 <Calchan>	ulm, leio said he was working on that in his latest email
-22:35:31 <Calchan>	11.3 Next meeting date/time.
-22:35:41 <Calchan>	I have a problem with the 15th of februiary
-22:35:47 <solar>	8th?
-22:35:51 <Calchan>	but any other days is ok
-22:35:55 <Calchan>	I like the 8th
-22:36:13 <scarabeus>	its right after fossdem right?
-22:36:16 <scarabeus>	looks fine
-22:36:16 <dertobi123>	8th is ok, every other monday in february might not work for me
-22:36:17 <grobian>	yep
-22:36:45 <Calchan>	Betelgeuse?
-22:36:47 <ulm>	8th ok for me too
-22:37:05 <solar>	good. that is better for robins gleps to not make him wait another month
-22:37:26 <Betelgeuse>	Calchan: I would need to remember when I am flying back
-22:37:37 <Betelgeuse>	Calchan: I am guessing I am back before 19UTC
-22:37:45 <Betelgeuse>	Calchan: I will mail if that's not the case
-22:37:54 <Calchan>	Betelgeuse, ok, we can confirm the date on the alias after the meeting
-22:38:07 <Calchan>	11.4 Who will follow-up discussions and prepare the agenda for the next meeting?
-22:38:09 <Betelgeuse>	Calchan: I will mail and ask
-22:38:16 <Betelgeuse>	Calchan: s/mail/phone/
-22:38:23 <Calchan>	as always I volunteer but that shouldn;'tprevent any of you to step up
-22:39:13 <Calchan>	ok, I'll do it then
-22:39:23 <Calchan>	12. Open floor (ad libitum)
-22:39:39 <Betelgeuse>	19:25
-22:39:43 <Calchan>	you can discuss multilib again now, and any other topic
-22:39:47 <Betelgeuse>	19UTC doesn't work
-22:40:02 <Betelgeuse>	I am home 20UTC
-22:40:04 <Calchan>	Betelgeuse, are you availableon the tuesday?
-22:40:10 <Betelgeuse>	yes
-22:40:35 <Calchan>	then I propose tuesday, let's settle that on the alias
-22:40:53 <Calchan>	somebody takes care of the +m while I go have some lunch?
-22:41:03 ---	Betelgeuse sets mode -m #gentoo-council
-22:41:10 <Betelgeuse>	Calchan: /mode -m ?
-22:41:17 <solar>	Tommy[D]: I still have a bunch of questions about the multilib/stuff. I'll be back in 10-15 if you want to chat some more
-22:41:44 <Tommy[D]>	wrt git branch: that wont help with additional testers/users, since they would do the same as now, in addition they would have to use a live version or something like my current multilib branch, so that would be of no big advance
-22:42:07 <grobian>	erhm?
-22:42:24 <grobian>	has always been an advantage to me, tbh
-22:42:44 *	solar was thinking the same. grobian did prefix for years before it got accepted
-22:42:49 <Tommy[D]>	if someone knows about multilib-portage and wants to use it, he can already follow the doc lines from our channel and easily use it
-22:42:50 <Fauli>	Tommy[D]: You raise the visibility a lot inside the official repository.
-22:43:14 <grobian>	and syncing it with trunk is reasonably easy these days
-22:43:22 <Tommy[D]>	all others wont use it now and wont use it, when it is a different branch of portage git tree
-22:43:47 <spatz>	I thought the main priority was getting help from zac in maintaining it, which a git branch can provide
-22:43:51 <Betelgeuse>	Tommy[D]: The item on the agenda was never about main tree use
-22:43:58 <Betelgeuse>	what spatz said
-22:44:06 <Tommy[D]>	Fauli: that is goal, higher visibility will raise the amount of testers/users and possible volunteers
-22:44:06 <wired>	I still feel that a features/use method in 2.2 would really boost multilib testing
-22:44:22 <Fauli>	Betelgeuse: Quick about PMS: You take care of the signing tag?
-22:44:42 <Betelgeuse>	Fauli: I can if needed
-22:44:53 <Betelgeuse>	Fauli: My key is probably best connected any way
-22:44:58 <Tommy[D]>	Betelgeuse: my request was merging into portage-2.2* branch, which is (masked by testing keyword and package.mask) main tree
-22:45:13 <Fauli>	Betelgeuse: I will commit one last patch (xz support move from 4 to 3) and merge a branch for the cheat sheet.
-22:46:08 <Betelgeuse>	Tommy[D]: http://archives.gentoo.org/gentoo-council/msg_4134a24b5a92a4684b8b393fd0013fb7.xml
-22:46:20 <Betelgeuse>	Tommy[D]: Other options not being good enough for you doesn't come clear from that
-22:46:52 <Betelgeuse>	Tommy[D]: It explicitly says there it not being about main tree
-22:47:06 <Tommy[D]>	Betelgeuse: What is unclear about "into portage 2.2"?
-22:47:11 <Betelgeuse>	Tommy[D]: read the whole thing
-22:47:34 <Betelgeuse>	Tommy[D]: You can't make the start magically revert what comes after
-22:48:41 <Betelgeuse>	answering the question there git and branches is in my opinion the best approach
-22:49:11 <Tommy[D]>	Betelgeuse: 10. is written in an unclear way.... on one side, it allows to vote on inclusion in portage-2.2, on the other side, it writes about "no main tree", so what should one use?
-22:49:57 <Fauli>	Tommy[D]: Don't be too hasty, be happy that you can play in the official repo and test it widely.
-22:50:13 <Tommy[D]>	Betelgeuse: and my request explicitly targeted portage-2.2 since it is the experimental branch and hardmasked
-22:50:51 <Tommy[D]>	Fauli: What do you mean by "test it widely"?
-22:51:16 <Fauli>	Tommy[D]: More testers attracted by the "official" status...
-22:51:24 <Betelgeuse>	Tommy[D]: 20:20 <@Calchan> note that zac's opinion is to not merge that to portage 2.2 yet, but as the portage repo is being switched to git it will make it easier for him to  help thomas maintain it, which ws thomas' main concern
-22:51:45 <Betelgeuse>	Tommy[D]: I doubt most council members want to force zac
-22:52:03 <leio>	2.2 really really should get released finally, these rc61's are embarrassing imho, but that apparently involves fixing all cornercase bugs of sets and preserve-libs, more experimental stuff in it doesn't help. However it being restricted behind a certain release candidate EAPI string that can be used in overlays only could be an option
-22:52:03 <Tommy[D]>	Fauli: i am not sure about that point, if one is interested in multilib-portage, he will use it anyway, i dont think the repo will make a big difference
-22:52:15 <Fauli>	Tommy[D]: As solar said, baby steps.
-22:52:44 <leio>	wired: thanks for proxying, hope it is a useful experience
-22:52:50 <wired>	can someone tell me why we're not making this optional for 2.2 users?
-22:52:58 <tanderson>	anything in the official repos automatically has more 'credence' and 'reliability' even if it isn't. And the result is more eyes on the code
-22:52:59 <ohnobinki>	tommy[d]: but you'll still get more publicity if it's in the ``official'' portage repository at all
-22:53:33 <Betelgeuse>	more but if it will make a difference is not certain
-22:53:42 <wired>	leio: no problem, it was really interesting :)
-22:53:45 <Tommy[D]>	Betelgeuse: i asked him about main tree integration and he said, he would principally ok with it, but requested a council ok before, that was the main reason for my request
-22:54:07 <spatz>	btw, why is portage->git RESO LATER? :(
-22:54:14 <Betelgeuse>	Tommy[D]: Then there's probably a communication break between zac and Calchan
-22:54:19 <Betelgeuse>	Tommy[D]: Or different times of asking
-22:54:44 <Tommy[D]>	Betelgeuse: different times and different questions
-22:54:46 <grobian>	Tommy[D]: IMO your multilib thing is a same sort of boat like Prefix, if you want it in portage mainline, Zac will only do it if the council has said yes
-22:55:01 <grobian>	Tommy[D]: and the council only says yes if you do all the specing stuff
-22:56:21 <Tommy[D]>	grobian: i have also seen a request for a "team" or similar as backup, which currently does not happen and wont happen without being in (even hardmasked 2.2 version of ) portage
-22:56:22 <Betelgeuse>	Any way I want to leave the office finally as it's 11PM
-22:56:46 <Betelgeuse>	So bye everyone
-22:57:02 <Betelgeuse>	Tommy[D]: Too bad it didn't work out as you wanted but at least it should be moving forward
-22:57:05 <grobian>	Tommy[D]: did that someone also define the minimum amount of members for a team?
-22:57:26 <grobian>	Tommy[D]: Prefix has been a one-man-show for most of its live
-22:58:38 <Tommy[D]>	grobian: i think, that was Calchan and he wanted a team like amd64 arch team as backup, so it wont be a one-man-show with the bus factor
-22:59:23 <grobian>	Tommy[D]: I just wanted to help you, but anyway, you can make it as black as you prefer
-22:59:53 <wired>	leio: I didn't get to say much but I tried to help wherever i could and I think I gained some knowledge of how you do things :)
-23:00:12 <Tommy[D]>	grobian: he did not define the number, no
-23:03:01 <Tommy[D]>	grobian: let me quote Calchan from his mail: http://dpaste.com/147117/
-23:03:12 <grobian>	Tommy[D]: I read that\
-23:04:06 <grobian>	you can easily claim support is no problem given the support that you claim to have by many devs and users wanting it
-23:05:30 <Tommy[D]>	grobian: the problem is this: this is moral support or something like "would like to use it", but not much in the direction of helping with the code or maintainence or similar :-/
-23:06:00 <grobian>	Tommy[D]: I see so many parallels...
-23:06:30 <grobian>	Maybe if I'm brave, I'd say that 4-5 years ago I also felt like prefix should be integrated in mainline portage "right now"
-23:06:52 <grobian>	I'm a bit of a slow person
-23:07:13 <grobian>	so you'd probably do it faster, but you need some time to get your idea to cristalise
-23:07:31 <Tommy[D]>	i think, it might take months, if not years, until all is done, when it continues the current way because of my limited time and python knowledge
-23:07:33 <grobian>	there are many questions, and many critics
-23:07:41 <solar>	grobian seems of gained some wisdom over the years.
-23:07:46 <grobian>	lol
-23:10:00 <Tommy[D]>	currently i only remember a suggested improvement from vapier, which i currently work on (first default ABI, then others, if needed instead of all ABIs in every phase) and comments on flag naming (i have no problem changing that scheme, once the code works)
-23:10:45 <solar>	I still don't understand how pkgconfig can properly give you results back
-23:11:28 <ohnobinki>	pkgconfig installs its files into into /usr/$(get_libdir)/pkgconfig which automatically picks up ABI differences...
-23:12:06 <solar>	not always.. cd /usr/share/pkgconfig ; grep lib *
-23:12:26 <Tommy[D]>	solar: there is a .pc file for every ABI, which only contains the details for that ABI
-23:12:47 <solar>	and how does pkg-config know which one to call ?
-23:12:59 <ohnobinki>	solar: those packages would have bugs filed against them
-23:13:36 <ohnobinki>	http://pkg-config.freedesktop.org/wiki/CrossCompileProposal
-23:14:08 <Tommy[D]>	the dir, where pkg-config searches is set depending on the current ABI (so it searches in /usr/lib32 for 32bit ones and /usr/lib64 for 64bit ones)
-23:15:01 <leio>	ohnobinki: those that install to /usr/share/pkgconfig? I will INVALID all of em ;p
-23:15:35 <ohnobinki>	leio: for the ones deserving attention, I'll swim upstream then :-p
-23:15:50 <leio>	ohnobinki: They will INVALID it too, read the manuals :)
-23:16:02 <leio>	ABI independent .pc files go to /usr/share/pkgconfig
-23:16:29 <ohnobinki>	leio: solar pointed out a few ABI-dependent ones in /usr/share/pkgconfig, those are the ones I'm referring to
-23:16:29 <leio>	so those packages simply shouldn't be installed twice, they are ABI independent packages.
-23:16:38 <solar>	leio: and we are saying there is ABI dependent files in /usr/share/pkg..
-23:16:44 <leio>	ok, got a list?
-23:16:46 <ohnobinki>	although I can't find any on my system...
-23:17:08 <solar>	gnome-mime-data-2.0.pc:libdir=/usr/lib64
-23:17:22 <Tommy[D]>	i have udev.pc and xtrans.pc in /usr/share/pkgconfig
-23:17:24 <leio>	gnome-mime-data is ABI independent
-23:17:31 <ohnobinki>	solar: that one's not ABI-dependent
-23:17:51 <leio>	udev is ABI independent (libudev.pc isn't(
-23:17:55 <solar>	then it should not define any libdir should it?
-23:18:21 <leio>	xtrans is ABI independent (C code and aclocal file)
-23:18:56 <--	grobian has quit ("Zzzzz")
-23:18:58 <leio>	you will have an issue with udev as the same portage package installs both /usr/share/pkgconfig/udev.pc and /usr/share/${libdir}/pkgconfig/libudev.pc
-23:19:09 <leio>	scratch a "share" from the latter
-23:19:31 <ohnobinki>	I don't see the issue there ;-)
-23:19:36 <leio>	So I presume the meeting is over and I can commit a raw log the next time I'm waiting on something workwise? :)
-23:19:58 <Tommy[D]>	so the issue in this case is not my concept, but instead what some packages install and should not install
-23:20:02 <leio>	the issue is if you want to install it for both 64bit and 32bit from a monolith package or something
-23:20:17 <solar>	this is going to be a nightmare to cross-compile. probably be limited to non multilib cross-compiles in the future
-23:21:02 <leio>	Tommy[D]: I don't know, I don't think I have a multilib specification or PMS patch to read
-23:22:17 <Tommy[D]>	leio: i currently answer question and have my code, i prefer to improve the code, when i have the time over writing specs
-23:23:19 <Tommy[D]>	leio: did you read my #-dev ML discussion with vapier, where i wrote about the basic implementation?
-23:24:42 <leio>	Not yet
-23:27:11 <leio>	is that write-up something that be converted into an initial spec sort of thing so you don't need to write it up all the time or find all the snippets that explain it when a new thread comes up and the previous one is already forgotten? :)
-23:29:30 <Tommy[D]>	i use a different workdir for every ABI and preserve a specified set of vars, with that, i do loop in every src* phase over all ABIs with the default one as last one
-23:29:58 <Tommy[D]>	during src_install i have an additional function, which does additional steps (like preserving headers, which differ per ABI or preserve requested binaries and generating a wrapper-symlink for them)
-23:30:05 <--	darkside_ (n=darkside@gentoo/developer/darkside) has left #gentoo-council
-23:33:16 <Tommy[D]>	leio: this was the mail: http://archives.gentoo.org/gentoo-dev/msg_9b89064c248dd2639501a3a8140b7474.xml
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100208-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100208-summary.txt
deleted file mode 100644
index 9f0991dd3f..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100208-summary.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Summary of the meeting of February 8th, 2010
-
-Attendance
-==========
-Present:
- Betelgeuse
- Calchan
- leio
- scarabeus
- solar
- ulm
-Missing:
- dertobi123
-
-Agenda
-======
-Vote on GLEPs 58 to 61
-Open discussion on VDB
-
-GLEPs 58 to 61
-==============
-GLEPs 58, 59 and 60 were approved unanimously by all present members. GLEP 61
-was approved with four votes for it, one against and one abstention.
-
-VDB discussion
-==============
-The council believes that specifying a unified VDB cache could prevent package
-managers from innovating. The council also considers that the use of e.g. a
-timestamp to facilitate working (or experimenting) with different VDB caches
-is a nice thing, but prefers leaving the decision whether to implement such a
-feature to the developers of the package managers.
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100208.txt b/xml/htdocs/proj/en/council/meeting-logs/20100208.txt
deleted file mode 100644
index 0e22b8b7a8..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100208.txt
+++ /dev/null
@@ -1,285 +0,0 @@
-22:00:44 <Calchan>	alright, woodpecker's clock says it's time
-22:00:51 <Calchan>	do we have everybody?
-22:01:01 <Calchan>	Betelgeuse will be late and is excused
-22:01:02 <scarabeus>	yep
-22:01:18 *	ulm is here
-22:01:26 <leio>	here
-22:01:28 <Calchan>	we had leio and solar just a few minutes ago
-22:01:37 -->	FuzzyRay (~pvarner@gentoo/developer/FuzzyRay) has joined #gentoo-council
-22:02:06 <Calchan>	can somebody please set +m whil I take care of some of the logistics?
-22:02:12 ---	leio sets mode +m #gentoo-council
-22:02:54 <Calchan>	oh, I'm just seeing tobias may not be with us today
-22:03:17 <solar>	he voted already in case he can't make it. i take that as being present (not a slacker)
-22:03:25 <Betelgeuse>	here
-22:03:37 <Betelgeuse>	got intoo the car
-22:03:43 <Calchan>	Betelgeuse, wow, I hope you didn't lose your driver's license ;o)
-22:03:50 <scarabeus>	:]
-22:03:51 <Betelgeuse>	let's see how long the battery lasts
-22:03:57 <Betelgeuse>	I am not driving :)
-22:04:23 <Calchan>	ok
-22:04:25 <Betelgeuse>	3G sucks phone battery like hell
-22:04:31 <Betelgeuse>	and it's already low
-22:04:42 <Calchan>	so we have everybodu except for tobias who will be excused
-22:04:54 <Calchan>	who wants to chair?
-22:04:57 <Betelgeuse>	no
-22:05:11 <leio>	I don't think we have any excusing concept per our current rules, unfortunately
-22:05:48 <Calchan>	leio, we don't, youre right
-22:06:09 <scarabeus>	we might create some, because he at least cared about voting, (so he is not slacking)
-22:06:23 <leio>	we have voted to not being able to change GLEP39 on our own
-22:06:32 <Betelgeuse>	not do that now
-22:06:53 <Betelgeuse>	get into the aganda please
-22:06:59 <leio>	yes please
-22:07:01 <Calchan>	before we go to deep in discussions ...
-22:07:03 <Calchan>	who wants to chair?
-22:07:07 <Calchan>	as usual I volunteer to chair if nobody doesn't, but don't let that stop you
-22:07:11 <Betelgeuse>	so much on plate
-22:07:28 <Betelgeuse>	Calchan: with lack of vlunteers feel free
-22:07:32 <Betelgeuse>	I would if I had a connection
-22:07:37 <solar>	Calchan: just go. Betelgeuse is on limited phone battery.
-22:07:42 <Calchan>	alright then
-22:07:51 <Calchan>	any remarks regarding the agenda?
-22:08:01 -->	Zorry (~zorry@fu/coder/zorry) has joined #gentoo-council
-22:08:26 <Calchan>	ok, let's switch to the first topic then
-22:08:36 <Calchan>	glep 58
-22:09:00 <leio>	(as for 1.1, I'm logging and will be committing the raw log post-meeting before sleep)
-22:09:01 <Calchan>	I hope you have all read the agenda items and the material that was linked in there in order to make that a quick vote if possible
-22:09:16 <Calchan>	leio, thanks, I forgot abou tthat
-22:09:25 <scarabeus>	i did read them
-22:09:27 <Betelgeuse>	I always log
-22:09:49 <Calchan>	so, does anybdoy have any comment regarding glep 58?
-22:09:54 <Calchan>	if not we'll proceed to vote
-22:09:55 <Betelgeuse>	I read allthe GLEPS during gregkh's talk
-22:10:08 <Betelgeuse>	after which robbat2 committed some stuff
-22:10:30 <leio>	can we change any grammatical things after acceptance or not? :)
-22:10:32 <solar>	Calchan: only thing is that the timestamps seem to differ. You list 6-12 months while robin noted 18months .
-22:10:33 <ulm>	Calchan: shouldn't we vote on 60 first?
-22:10:42 <ulm>	it's a prerequisite of 58
-22:11:49 <Calchan>	ulm good point
-22:12:03 <Calchan>	so what's the general feeling, do you guys want to vote on 60 forst?
-22:12:31 <Betelgeuse>	fine b me
-22:12:34 <Calchan>	now that ulm says it, it seems logical to me although I don't mind too much
-22:12:50 <Calchan>	let's discuss/vote 60 first then
-22:12:55 <leio>	yes, we can do 60 first as a prerequisite. As for comments about 60 I can't phantom a case where AUX would really have to be duplicated with a new type of entry
-22:13:16 <leio>	as I don't see any of the new ones covering package directories
-22:13:27 <leio>	any files in package directories*
-22:14:03 <ulm>	leio: OTHER covers them
-22:14:28 <ulm>	if they aren't in EXEC anyway
-22:14:35 <leio>	"Choosing a file", point 5 suggests otherwise?
-22:14:39 <Betelgeuse>	Were'n't comments supposed to be before the meeting
-22:14:48 <Betelgeuse>	so that we an just vote today
-22:15:00 <scarabeus>	yeah just voting was supposed
-22:15:09 <Betelgeuse>	so let's do that
-22:15:29 <Calchan>	Betelgeuse is right, leio and ulm if you consider the above to be a blocker then just vote no please, ok?
-22:15:35 <Calchan>	and I vote yes
-22:15:48 <ulm>	I vote yes for glep 60
-22:15:50 <Betelgeuse>	yes
-22:15:53 <scarabeus>	yes
-22:16:18 <solar>	I vote yes on all of them
-22:16:26 <Calchan>	leio?
-22:16:42 <Betelgeuse>	Calchan: Might be easier to ask if someone objects to any of them
-22:16:44 <Betelgeuse>	I don't
-22:16:51 <leio>	I see what is meant there, but it should be more clearly written
-22:16:52 <leio>	I vote yes
-22:16:59 <Betelgeuse>	Then we can use time more efficiently
-22:17:18 <Calchan>	Betelgeuse, technically we have to vote o each of then individually, and it can be done quickly so let's do it
-22:17:25 <Betelgeuse>	Calchan: ok
-22:18:03 <Calchan>	NeddySeagoon just reminded me that we hae a missing member who sent in his vote by mail
-22:18:40 <Calchan>	but as we don't have a rule for that I told him we can't use votes by mail
-22:18:48 <Calchan>	we'll have to discuss that someday though
-22:18:52 <Calchan>	ok, 60 is go
-22:18:57 <Calchan>	let's vote on 58 now
-22:19:04 <scarabeus>	58 - yes
-22:19:09 <ulm>	yes for 58
-22:19:11 <leio>	58 - yes
-22:19:14 <Calchan>	yes for 58
-22:19:18 <solar>	yep
-22:19:42 <Betelgeuse>	yes
-22:19:50 <Calchan>	58 is accepted too
-22:20:03 <Calchan>	let's vote on 59 now
-22:20:09 <Betelgeuse>	yes
-22:20:14 <solar>	yes to all
-22:20:27 <scarabeus>	59 - yep
-22:20:32 <ulm>	yes for 59
-22:20:44 <Calchan>	yes here too
-22:20:51 <leio>	yes
-22:20:55 <solar>	Do any council ppl vote no on any of robins gleps? perhaps we can save some time per Betelgeuse suggestion?
-22:21:06 <scarabeus>	solar: we have to actively name it anyway
-22:21:15 <scarabeus>	due to proccess as i see it
-22:21:27 <leio>	I'll be curious how zac will do whirlpool though :)
-22:21:48 <Calchan>	leio, we talked of using external binaries
-22:22:00 <leio>	not important for the meeting
-22:22:01 <Calchan>	59 is go so we only have 61 left now
-22:22:05 <Calchan>	yes on 61
-22:22:28 <Betelgeuse>	yes
-22:22:34 <scarabeus>	yup
-22:22:36 <ulm>	abstain on 61
-22:23:54 <Calchan>	yes from me
-22:24:37 <leio>	no (due to the part covering per-package manifests)
-22:25:11 <Calchan>	we already know solar wnated to vote yes on 61, although if you could confirm that would be nice
-22:25:59 <Calchan>	so we have 4-2 for glep 61
-22:26:17 <solar>	pita :p
-22:26:18 <solar>	yes
-22:26:29 <Calchan>	solar, that's my second name ;o)
-22:26:48 <ulm>	Calchan: I see 4 yes 1 no 1 abstention
-22:26:59 <Calchan>	ulm, indeed
-22:27:27 <Betelgeuse>	I am almost home. Will move from car to apparatement
-22:27:35 <Calchan>	ulm, I'll scan you a copy of my conting sheet to prove you I did note your abstention ;o)
-22:27:42 <Calchan>	Betelgeuse, ok
-22:27:57 -->	reavertm (~quassel@gentoo/developer/reavertm) has joined #gentoo-council
-22:28:41 <Calchan>	alright, any comments about these gleps?
-22:29:11 <Calchan>	if there aren't any we'll switch to the next topic
-22:29:26 <Calchan>	here's how it will work though: it'
-22:29:27 <solar>	only that he finish editing them to orig spec that we had agreed on
-22:29:37 -->	antarus (~antarus@gentoo/developer/antarus) has joined #gentoo-council
-22:29:38 <leio>	well, I'm supposed to keep my mouth shut, as I'm late with comments ;)
-22:29:58 <solar>	leio: don't let that hold you back. If you have a concern raise it
-22:30:08 <Calchan>	s an open ended discussion, I will ask you to conclude before 2100UTC since we are a few minutes late
-22:30:24 <Calchan>	at which point we'll conclude the meeting wehatever the outcome of the discussion
-22:30:27 <leio>	glep 60 is confusing about AUX
-22:30:27 <Calchan>	agreed?
-22:30:49 <Calchan>	leio, let's discuss that during the open floor
-22:31:02 <Calchan>	ok, let's discuss the VDB issue
-22:31:18 <Calchan>	I have proosed a few topics, but feel free to add more
-22:31:37 <Calchan>	Do we care about VDB caches currently not being compatible across
-22:31:38 <Calchan>	package managers?
-22:32:09 <scarabeus>	would be nice to have it same, at least for us (read me) who have both pkgcore and portage :]
-22:32:12 <solar>	While it would be nice. I would leave that up to the pkg-mgr maintainers
-22:33:31 <Calchan>	the point is if we don't care there's nothing that prevents package manager maintainers to experiment with various stuff without needing a timestamp or other mechanism
-22:33:46 <Calchan>	it would make many people lives easier though
-22:34:24 <Calchan>	here ws another question, but we can still discuss the previous one at the same time
-22:34:42 <Calchan>	Do we want to develop a way to work with more than one type of VDB cache (similar to Brian's proposal or not) or do we prefer investing our time into developing a new VDB?
-22:34:54 <solar>	neither
-22:35:04 <Calchan>	solar, can you expand a bit?
-22:35:32 <solar>	if you read up to the last thing I said. It still holds true for this statement
-22:36:13 <solar>	but to go into more details. The VDB is imo outside of our scope at this time. it's not PMS. The PMS ppl clearly don't want it in. I happen to think they are right.
-22:36:44 <Calchan>	solar, talkig about PMS, is a VDB cache EAPI material, i.e. should it be defined in PMS?
-22:36:59 <solar>	No I don't think so.
-22:37:10 <leio>	how can it even be...
-22:37:18 <leio>	(EAPI material)
-22:37:19 <solar>	portage for example allows the use of more then one type of vdb backend.
-22:37:31 <solar>	and I would hate to limit them to 1 type.
-22:38:04 <solar>	so if we define anything at this time. I feel we would harm future growth more then help it
-22:38:28 <Calchan>	leio, agreed, on the other hand I think it's worth thinking whether even not being EAPI material if it shouldn't be in PMS anyway
-22:38:31 <leio>	We keep trying to slap things under EAPIs that can't be, they cover packages and to provide an upgrade path. That doesn't work for an uniform all-covering cache
-22:38:49 <Calchan>	solar, on of the remark was about it not being versioned, meaning that it could be
-22:39:19 <leio>	(nor profiles/ in my opinion, but that's some old somewhat never-ending discussion)
-22:39:28 <Calchan>	leio, that all boild down to: should PMS only cover EAPIs or can it be broader?
-22:39:34 <leio>	the movement is towards not relaying on VDB in packages, I think that's good
-22:39:43 -->	PSYCHO___ (~scarabeus@gentoo/developer/scarabeus) has joined #gentoo-council
-22:39:43 ---	ChanServ gives channel operator status to PSYCHO___
-22:40:00 <leio>	to actually support these other types of VDB in portage (built_with_use == bad, etc)
-22:40:07 <--	scarabeus has quit (Ping timeout: 260 seconds)
-22:40:43 ---	PSYCHO___ is now known as scarabeus
-22:40:46 <leio>	I think package manager authors should be able to innovate to come up with the most efficient cache
-22:40:48 <Calchan>	so another question now: what do you think about Brian's proposal in general?
-22:41:01 <Calchan>	both form the necessity and implementation point of view
-22:41:18 -->	[mrf] (~mrf@unaffiliated/mrf/x-6141039) has joined #gentoo-council
-22:41:35 <scarabeus>	i think we need such thing
-22:42:57 <Calchan>	scarabeus, thanks, any other opinions?
-22:43:10 <scarabeus>	the proposal sounds ok to me (thats why i wanted to talk about it :P) but i am not exactly what you would call expert in that area :]
-22:44:11 <Calchan>	mine is that there doesn't seem to be any harm caused by it, so if it helps some of us I would tend to say why not
-22:45:33 <solar>	it's outside of our scope. But personal feeling is there is no harm in updating the mtime of /var/db/pkg
-22:46:03 <leio>	yes, why not, while we are sort of stuck with current VDB and if it increases performance, but not sure if I'd want to decide on that if package manager/tool authors could just agree on it :)
-22:47:13 <Calchan>	leio, agreed here, I'm looking forward to the day they can all talk without us, on the other hand I consider them disagreeing a healthy thing
-22:47:53 <leio>	if that leads to a best solution with discussions..
-22:48:00 <Calchan>	so I didn't think we could reach that stage, but are we ready to make a decision on Brian's proposal?
-22:48:11 <solar>	no
-22:48:15 <--	reavertm has quit (Ping timeout: 276 seconds)
-22:48:26 <Calchan>	solar, I was going to add the following:
-22:48:42 <solar>	still no. This is an open discussion. Not a vote :p
-22:49:31 <scarabeus>	solar: he dont want to hear yes/no i guess :] that is not point of open floor :D
-22:50:03 <Calchan>	scarabeus, this isn't the open floor it's topic 6
-22:50:44 <scarabeus>	i am bit slightly off :P
-22:50:49 <scarabeus>	dont bite me :P
-22:50:51 <scarabeus>	mea culpa
-22:52:42 <scarabeus>	not open floor but open discussion
-22:52:44 <scarabeus>	:]
-22:53:13 <solar>	Calchan: did you have something else to add?
-22:53:39 <Calchan>	to conclude with this my opinion is that I would be happy that any package manager who wants to join in this vdb timestamp feature is welcome to do so
-22:53:51 <Calchan>	solar, I was typing, I'm a bit slow today ;o)
-22:54:04 <scarabeus>	ok so my statement on the matter is that: If zac implemented it in portae and was the same implemented in pkgcore i would be happy person so i would like to see that happen
-22:54:06 <solar>	The question was "but are we ready to make a decision on Brian's proposal" (for that statement alone. I'm saying no. No as it's outside of the scope.) If the VDB is going to be documented it's on a per pkg mgr basis at this point. We cant impose rules unless all the VDB equivs get a unified format.spec. Then that brings us back to hampering innovation.
-22:54:25 <Calchan>	if any of you want to summarize his opinion now it would help the poor guy who is going to make the meeting summary
-22:54:58 <Calchan>	solar, thanks, that's a nice summary from you
-22:55:19 <Calchan>	solar, and btw it's perfectly ok to answer no to any of my questions ;o)
-22:55:20 <leio>	on the other hand, if some package manager isn't participating in the vdb timestamp feature, it means it is not usable if user is using both a package manager not doing it, and one doing it
-22:55:45 <solar>	but it's not a bad idea. Zac and ferringb are welcome to do it. think they are even already
-22:55:48 <Calchan>	leio, I would say then it's up to the users of this package manager to lobby the maintainers to ad the feature
-22:56:15 <leio>	meanwhile it breaks everything for the participating package manager or something
-22:56:34 <ulm>	it's only a problem if they use more than one pkg manager at the same time
-22:57:28 <Calchan>	ulm, in the future it would only be a problem if they use one package manager that doesn't have the feature alibng with others
-22:57:47 <ulm>	right
-22:57:49 <Calchan>	ulm, as long as they use only package managers that have the feature they can use as many as they want
-22:58:25 <Calchan>	are we done on this topic?
-22:58:59 <leio>	not sure how one would summarize this topic in a meeting summary, indeed :)
-22:59:17 <Calchan>	leio, if you want I'll take care of it
-22:59:37 <Calchan>	let's conclude the meeting then
-22:59:49 <Calchan>	actions
-23:00:05 <Calchan>	leio, do you want to investigate this AUX issue?
-23:00:12 -->	PSYCHO___ (~scarab@gentoo/developer/scarabeus) has joined #gentoo-council
-23:00:13 ---	ChanServ gives channel operator status to PSYCHO___
-23:00:20 <Calchan>	although we did accept the glep we can always ask for some minor tuning
-23:00:30 <leio>	what kind of acceptance we gave to these gleps? Can they be changed anymore at all?
-23:00:50 <Calchan>	leio, we are the council, we have powerz ;o)
-23:00:51 <solar>	leio: yes. That was one of our conitions
-23:00:59 <Betelgeuse>	leio: even GLEP 1 should be updated
-23:01:28 <solar>	they have to be fixed up before changes are pushed around in the tree.
-23:01:38 <leio>	I will talk with Robin
-23:01:42 <Calchan>	any other actions for next meeting that I'm not seeing?
-23:01:47 <solar>	we really rushed them. It's sad robin was not here
-23:02:19 <Betelgeuse>	I wouldn't say the time available for people to discuss rushing.
-23:02:49 <Calchan>	7.2 Who takes care of the summary and log for this meeting? When?
-23:02:58 <Calchan>	I can do the summary if that helps
-23:03:10 <Calchan>	unless leio or anybody else wnats to do it
-23:03:15 <solar>	Betelgeuse: rushing as in robin did not finish documenting everything in the gleps. Some of the data needs to be yanked etc.
-23:03:58 <Calchan>	wo will commit the logs and when?
-23:04:03 <leio>	as said before, I will commit the log today
-23:04:09 <Calchan>	leio, ok thanks
-23:04:12 <leio>	(well, after midnight my time)
-23:04:37 <Calchan>	next meeting: can we already agree on a date/time or do we discuss it off-list?
-23:05:00 <scarabeus>	1 or 8
-23:05:07 <scarabeus>	i cant 15.
-23:05:16 <scarabeus>	and then 22 and 29 again i can
-23:05:20 <Betelgeuse>	I don't have travelling schedule for Mars
-23:05:27 <Calchan>	I'd prefer 8, 3 weeks to organize a meeting is short
-23:05:40 <solar>	I like the 8th next month. It's a full 4 weeks away.
-23:05:43 <scarabeus>	yeah 8 i can
-23:05:46 <Calchan>	although I did it this time I had to rush it
-23:05:50 <ulm>	8 ok for me too
-23:06:19 <Calchan>	ok let's put 8 as a tentative date and confirm that on list during this coming week but no later, ok?
-23:06:25 <scarabeus>	ack
-23:06:31 <Betelgeuse>	8 is fine
-23:06:38 <Calchan>	same time as usual I guess, which is 1 hour earlier than today
-23:06:50 <Calchan>	i.e. 1900 UTC
-23:07:02 <Calchan>	Who will follow-up discussions and prepare the agenda for the next meeting?
-23:07:34 <Calchan>	as usual I volunteer
-23:07:44 <Calchan>	but feel free to take that off my plate
-23:07:50 <scarabeus>	if is it just reading the mails and putting it together i can help (hey i can at least try :])
-23:08:08 <Calchan>	scarabeus, ok thanks, let's be in touch about this then
-23:08:46 <scarabeus>	ok my mail is obvious i live in CET and i am on irc most of the time expect monday and thursday :]
-23:09:01 <Calchan>	scarabeus, there's a lot of dicussing with people in the background too though, if only to make sure they'll answer on the lists
-23:09:19 <solar>	scarabeus: but mondays around 1900 UTC work ok for you in general?
-23:09:32 <scarabeus>	yep, basicaly yes
-23:09:40 <scarabeus>	i have 3 hours gap there :]
-23:10:04 <Calchan>	are you guys ok with opening the floor and ending the meeting?
-23:10:12 <Betelgeuse>	yes
-23:10:14 <scarabeus>	yep
-23:10:39 <ulm>	yes
-23:10:39 <leio>	is that open floor discussion not part of a meeting anymore? (for what to commit as raw log)
-23:11:15 <Calchan>	leio, feel free to commit whatever's relevant to your eyes, bytes aren't that expensive these days
-23:11:52 <leio>	well, that's just why I ask right now, it has more meaning (are council members supposed to try to stick around and participate, etc)
-23:12:04 <leio>	anyway, yeah, lets remove moderation, you are chair and say when meeting is over :)
-23:12:16 <scarabeus>	:]]
-23:12:44 *	solar declares it lunchtime then cya.
-23:13:08 ---	scarabeus sets mode -m #gentoo-council
-23:13:14 <scarabeus>	so lets see :]
-23:13:28 <antarus>	we need tree signing like yesterday
-23:13:33 <antarus>	plz2make it happen
-23:13:41 <antarus>	I don't even care if it is osprey signing post commit
-23:13:43 <antarus>	I'll take anything
-23:14:11 <solar>	done
-23:19:12 <scarabeus>	its quite quiet open floor
-23:19:21 <scarabeus>	i hear the pin to drop :P
-23:19:47 <ulm>	scarabeus: don't disturb the silence
-23:20:31 <NeddySeagoon>	scarabeus, close the meeting and do a runner
-23:21:14 <scarabeus>	:]
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100308-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100308-summary.txt
deleted file mode 100644
index 13a3f76285..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100308-summary.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Summary of the meeting of March 8th, 2010
-
-Attendance
-==========
-Present:
- Betelgeuse
- Calchan
- dertobi123
- leio
- scarabeus
- solar
- ulm
-
-Voting by email
-===============
-Ideas seemed to converge on how to vote by email but it was noted that this
-would constitute a change of GLEP39 which the council can't modify without an
-all-developers vote. Since there were already other changes planned or
-suggested to GLEP 39 it was decided that the council would work on a new text
-and submit it to a vote when ready. Calchan has volunteered to gather all ideas
-and work on the text.
-
-Do we want a policy for changes in metadata.xml?
-===================================================
-Adding such information to metadata.xml was considered a bad idea for two
-reasons: this information is of no use to the users and would bloat the file
-for no good reason, and it would be a technical answer to a mostly social
-problem. It was suggested that reducing territoriality could help. Ideas were
-proposed like making it official that after sending an email to the
-maintainers and waiting one week anybody could touch a package.  In the end it
-wasn't clear what exact problem was to be solved. So scarabeus volunteered to
-animate the discussions on the mailing list. The goal is to find out what the
-source of the problem is and what solution(s) we can apply.
-
-Conclusion
-==========
-See above for actions.
-The next meeting will be on April 19th 2010.
-ulm will take care of following discussions and preparing the agenda.
-
-Open floor
-==========
-vapier suggested that we keep the Gentoo calendar updated with the council
-meeting dates, which was done for the next meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100308.txt b/xml/htdocs/proj/en/council/meeting-logs/20100308.txt
deleted file mode 100644
index d4144dae02..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100308.txt
+++ /dev/null
@@ -1,376 +0,0 @@
-20:56:39 ---	solar has changed the topic to: http://archives.gentoo.org/gentoo-council/msg_9fac75691c9845051a8cef0fb9b24115.xml
-21:00:03 <Calchan>	Alright, roll call
-21:00:11 *	dertobi123 is here
-21:00:14 <Betelgeuse>	yes
-21:00:37 <scarabeus>	yep
-21:00:38 <leio>	here
-21:00:52 <Calchan>	I have booted my pen&paper computer so I'm ready to go ;o)
-21:01:04 <ulm>	here
-21:01:52 <Calchan>	scarabeus and solar were here a few minutes ago and I'm sure they'll show up at some point
-21:02:02 <scarabeus>	Calchan: what?
-21:02:09 <scarabeus>	Calchan: i already replied to the roll call
-21:02:10 <scarabeus>	:D
-21:02:23 <Calchan>	scarabeus, blame age ;o)
-21:02:31 <solar>	here
-21:02:33 <Calchan>	I mean my age, I'm geting blind
-21:02:46 <Calchan>	alright, we have everybody
-21:03:11 <Calchan>	Betelgeuse, I know you're logging, who else? just in case Betelgeuse has internet issues
-21:03:22 <leio>	as usual..
-21:03:27 <Calchan>	good
-21:03:39 <Calchan>	who wants to chair this meeting?
-21:04:12 <Calchan>	as usual I volunteer but if anybody else wnats I'll be happy to let you do it
-21:04:33 <Calchan>	no candidates?
-21:04:33 <solar>	Calchan: I think it's assumed you will chair the rest of the council meetings
-21:04:38 <dertobi123>	just do it, please :)
-21:04:41 <dertobi123>	solar: ack :P
-21:04:42 <Calchan>	solar, heh thanks
-21:04:43 <scarabeus>	:]
-21:04:44 <Betelgeuse>	Calchan: You probably know best what you would like to accomplish with 2
-21:05:29 <Calchan>	Betelgeuse, I actually don't assume anything and have no pesonal agenda, what I want is us to talk about it
-21:05:32 <Calchan>	ok then
-21:05:42 <Calchan>	any comment abou tthe agenda before we go?
-21:06:20 <solar>	lets go.
-21:06:21 <scarabeus>	as this is the last chance to change agenda, we should add the "Glep 39 change process/approach" to it, because now we have no chance to change it, and it kinda blocks numero uno
-21:06:51 <dertobi123>	uhrm, no ... discuss stuff like that on-list please
-21:06:53 <Calchan>	scarabeus, agreed but we're not going to vote on anything today, so glep 39 doesn't get in the way yet
-21:07:20 <scarabeus>	ok lets keep it on list then, i will sent mail after meeting :]
-21:07:23 <Calchan>	and changing glep 39 isn't something we can add to the agenda at the last minute, see my answer to vapier
-21:07:51 <Calchan>	scarabeus, since you joined us recently you might not rememebr that I was the one raising this issue at the beginning of our term
-21:08:28 <Calchan>	and the council decided that it couldn't change glep 39 on its own, which is silly because it had been done before
-21:08:35 <Calchan>	anyway, back to the agenda
-21:08:36 <solar>	#2 I'm in favor of allowing ppl to vote by email or use a www based app such as Betelgeuse proposed as long as the majority is present.
-21:08:43 <Calchan>	2. Voting by email (20 minutes)
-21:08:58 <Betelgeuse>	I agree with solar.
-21:09:21 <Calchan>	I think the tool is irrelevant, but I agree voting by email should be allowed
-21:09:22 <dertobi123>	i'm in favour of people voting before the meeting by email or to cast *all* votes after a meeting on web-based app
-21:09:47 <scarabeus>	i would preffer the web-app after the meeting
-21:09:55 <scarabeus>	so they can read last minute notes from meeting too
-21:10:21 <Calchan>	the problem for anything done after the meeting is as we tend to slack we need to be strict on deadlines
-21:10:22 <scarabeus>	but it should be also limited somehow, so none can vote lets say 20 days after the meeting
-21:10:28 <Calchan>	and it delays all processes again
-21:10:37 <scarabeus>	it should be 72 hours
-21:10:46 <scarabeus>	thats enough to get connection at least somehow
-21:10:48 <Calchan>	scarabeus, we should limit it to like 48 hours no more
-21:10:58 <scarabeus>	or even 48 :] i just tried to be nice
-21:11:01 <scarabeus>	i can go with 2 days :]
-21:11:03 <solar>	after the notes are posted?
-21:11:16 <scarabeus>	after the log is posted
-21:11:23 <Calchan>	solar, that would take too long, how about after the logs are posted
-21:11:24 <Calchan>	?
-21:11:33 <solar>	I've seen long delays in the notes being posted however
-21:11:41 <dertobi123>	48 hours just after the meeting ended
-21:12:00 <solar>	and it's the persons own responsiblity to find the notes?
-21:12:19 <Betelgeuse>	If we use a web application, deadlines are easy to enforce.
-21:12:20 <leio>	you can read the raw log, summaries can't cover everything needed to know
-21:12:34 <Calchan>	solar, is there any way we can have the logs posted automatically right at the end of the meeting?
-21:12:42 <dertobi123>	solar: as this only affects people which were absent, i see no problem with that
-21:12:48 <solar>	script-o-magic maybe
-21:13:00 *	solar is ok with that. stamp it/seal it and let move on.
-21:13:24 <solar>	no really. So it boils down to email vs web app. Either is fine with me
-21:13:24 <leio>	there are meeting bots that can do something like that. Other than that I've been commiting raw logs within hours of meeting end too the past couple meetings
-21:14:05 <Betelgeuse>	Calchan: A bot.
-21:14:11 <Calchan>	now, we all seem to converge on an agreement on how to vote by email, although it might need a bit of polishing and working on some details, but how do we factor in the fact this is a change of what glep 39 says and that we have decided we can't change glep 39?
-21:14:30 <solar>	we are not
-21:14:31 <Betelgeuse>	Calchan: 50% still needs to be there.
-21:14:42 <Betelgeuse>	If someone-misses they can vote after.
-21:14:42 <scarabeus>	50% still needs to attend
-21:14:43 <leio>	I think the glep39 doesn't say per se that we can't do vote in other places too
-21:14:48 <Calchan>	solar, can you please elaborate?
-21:14:58 <Betelgeuse>	GLEP 39 doesn't require us to vote in meetings at all.
-21:15:00 <Calchan>	leio, but it doesn't say we can
-21:15:07 <Calchan>	Betelgeuse, ok, good point
-21:15:15 <ulm>	leio: but it says that only those who show up can vote
-21:15:34 <ulm>	"Council decisions are by majority vote of those who show up (or their proxies)."
-21:15:40 <Calchan>	another good point
-21:16:03 <dertobi123>	well, if i don't vote in a meeting, but sent my votes before i'm somewhat proxying myself
-21:16:06 <leio>	yeah, I made and quoted it before, then thought that doesn't cover all votes, but "Council decisions" sounds broad
-21:16:11 <dertobi123>	same if we're voting afterwards
-21:16:35 <Betelgeuse>	I think the best approach is to move the whole vote after the meeting.
-21:16:42 <Betelgeuse>	And do it in 48 hours after it.
-21:16:43 <scarabeus>	well we should have the proccess of glep39 update and update the text to fit our needs
-21:16:55 <Calchan>	so it seems we first need to decide whether allowing vote by email requires a change of glep 39
-21:17:17 <dertobi123>	scarabeus: get the discussion started and submit a proposal on which fellow developers can vote :P
-21:17:19 <Betelgeuse>	GLEP 39 should be updated so that someone comes up with a new text.
-21:17:37 <Calchan>	scarabeus, again agreed, but it's a hot topic, please the logs and emails around the time of the first council meetings of this term
-21:17:37 <Betelgeuse>	Then open it for comments and finally submit it for developer vote.
-21:17:44 <Betelgeuse>	Don't have discussion first.
-21:17:45 <Calchan>	Betelgeuse, but who does that if council can
-21:17:47 <Calchan>	t?
-21:18:04 <Betelgeuse>	Calchan: Anyone can.
-21:18:19 <scarabeus>	foundation guys
-21:18:23 <scarabeus>	woudl be sane choice
-21:18:27 <scarabeus>	they should be our coutnerpart
-21:18:37 <scarabeus>	or all devs
-21:18:38 *	dertobi123 sighs.
-21:18:43 <Calchan>	scarabeus, I'm guessing they don't care and don
-21:18:47 <Calchan>	t wan tto interfere
-21:18:57 <scarabeus>	hey in that case why you voted we cant touch that glep :D
-21:19:05 <scarabeus>	if none cares :]
-21:19:18 <Betelgeuse>	the council can still come up with the new text
-21:19:20 <Calchan>	scarabeus, I voted for us to be able to change that glep, so don't look at me
-21:19:23 <Betelgeuse>	we can't just approve it
-21:19:38 <scarabeus>	question is, who approves it then
-21:19:50 <leio>	condorcet voting by elections team, probably
-21:19:56 <Betelgeuse>	scarabeus: developer vote by elections team
-21:20:03 <dertobi123>	please take a look at the July 20th 2009 summary
-21:20:04 <Betelgeuse>	yes/no
-21:20:16 <ulm>	leio: why condorcet? it's just yes or no
-21:20:21 <Betelgeuse>	ulm: same results
-21:20:25 <Betelgeuse>	ulm: doesn't matter
-21:20:31 <Calchan>	ok, so it seems that we need to prepare a change on glep 39, and as there are other things to change in there than just voting by email I suggest we batch them together
-21:20:39 <leio>	shrug, tradition. No need to argue then also what voting method it has to be ;p
-21:21:10 <ulm>	Calchan: yes, throw out all the outdated cruft
-21:21:21 <ulm>	especially in "Rationale" and "Motivation"
-21:21:25 <Calchan>	ulm, yes, and also see vapier's mail
-21:21:40 <ulm>	and change the title ;)
-21:21:52 <Calchan>	so, do we have a volunteer to lead that effort?
-21:22:16 <--	Ford_Prefect has quit (Read error: Connection reset by peer)
-21:23:04 <Calchan>	mmmkay... so what I propose is I gather all required changes (voting by email, vapier's stuff, ulm's stuff) and submit it to you guys
-21:23:38 <Calchan>	and we work on it all together with me as your sexy secretary, and we submit that to a vote of all devs
-21:23:50 -->	Ford_Prefect (~ford_pref@gentoo/developer/ford-prefect) has joined #gentoo-council
-21:24:21 <scarabeus>	Calchan: and i hope you will wear some nice gentoo t-shirt if you want to present yourself as sexy secretary :D
-21:24:21 <ulm>	sounds good
-21:24:23 <scarabeus>	sounds sane
-21:24:50 <dertobi123>	Calchan: please make separate patches so developers can vote on each of the changes separately
-21:25:08 <Calchan>	dertobi123, interesting idea, ok will do
-21:25:39 <Betelgeuse>	I think it should be intirely new GLEP
-21:25:40 <Calchan>	I will first gather an informal list before making patches though
-21:25:45 <Betelgeuse>	and leave 39 as deprecated
-21:26:09 <Calchan>	Betelgeuse, we could do that to, it would make things easier
-21:26:25 *	solar thinks so as well.
-21:26:52 <scarabeus>	we should implement it as approach for everything, expect typo changes all gleps would go to deprecated and presented as new glep
-21:26:53 <Calchan>	and on the voting by email subject it looks we all agree and only some details need to be worked out
-21:27:14 <Calchan>	scarabeus, that or we version them
-21:27:43 <scarabeus>	we never agreed even on versioning eclasses :D how do you want us to version gleps :P
-21:27:52 <dertobi123>	well, in general glep 39 shouldn't be a glep, but the council's constitution ... if we're creating a new one, make it the council's constitution, not yet another glep
-21:28:01 <Calchan>	scarabeus, we just do it, it isn't that difficult if we decide it
-21:28:35 <Calchan>	dertobi123, I've been wanting to do that for a long time but when I talked about it it was met with scepticism
-21:28:45 <Calchan>	whatever it's spelled in english
-21:28:49 <dertobi123>	heh
-21:28:55 <scarabeus>	we can haz constitution
-21:29:23 <Calchan>	ok, that can be one of the topics to discuss among all the others and we may have devs vote on that
-21:29:54 <Calchan>	anything else to add to that topic before we switch to thwe next one?
-21:30:36 <Calchan>	wow, we're right on schedule
-21:30:48 <Calchan>	3. Do we want of a policy for changes in metadata.xml? (20 minutes)
-21:31:14 <Calchan>	who starts?
-21:31:23 <solar>	Not sure about a policy. But shoving that info into metadata.xml is just flat out wrong
-21:31:27 <scarabeus>	it looks weird
-21:31:31 <Calchan>	how about solar, you had an interesting proposal?
-21:31:32 <scarabeus>	and definitely not in metadata
-21:31:35 <Calchan>	dammit, slow fingers
-21:32:01 <solar>	reason for that being is the end user gets this data and it provides them zero advantage. It bloats the tree.
-21:32:12 <Calchan>	agreed here
-21:32:28 <Betelgeuse>	solar: Easy to filter out in CVS --> rsync
-21:32:31 <ulm>	it would be a technical solution for a social problem
-21:32:45 <solar>	Betelgeuse: not if it's in metadata.xml (any other file is fine)
-21:32:56 <Calchan>	is there any way we can have such changes help us getting toward less territoriality?
-21:33:02 <solar>	antarus suggested owners.xml
-21:33:05 <Calchan>	one cookie for ulm :o)
-21:33:17 <Betelgeuse>	I sometimes find myself touching some dev-java/ stuff that's not maintained by me so repoman reminding me would be useful in that case
-21:33:22 <vapier>	Calchan: you should keep the calendar up-to-date with council meetings
-21:33:50 <ulm>	just use common sense, we don't need more complicated rules
-21:33:57 <Calchan>	vapier, can we discus that in the open floor session?
-21:34:37 <vapier>	yeah
-21:34:38 <ulm>	ask the maintainer, and if he doesn't answer within reasonable time then just fix it
-21:34:46 <scarabeus>	i think the rule "You dont maintain -> ask first" is quite clear
-21:35:05 <Betelgeuse>	I could write a repoman check for checking against metadata.xml and herds.xml disabled if only changing KEYWORDS
-21:35:08 <scarabeus>	and only thing we should implement is some repoman warning "I hope you ask since you dont maintain this"
-21:35:12 <Betelgeuse>	Should remind people enough
-21:35:14 <solar>	ulm: yes. So far it's only one questionable seed in this entire mix. Seeing as devrel/QA or other did not slam the hammer down. it would be nice to make this overcomplex. But Betelgeuse has a good point about repoman.
-21:35:16 <Calchan>	scarabeus, indeed and it makes sense, the problem occurs when maintainers are slow to answer due to real life
-21:35:27 <dertobi123>	ulm: agreed ... besides having a tard or two every other year screwing up that one did work for years ....
-21:35:35 <scarabeus>	Calchan: well i always wait at least 10 days
-21:35:44 <scarabeus>	Calchan: expect security fix, nothing need more rush
-21:35:55 <Calchan>	scarabeus, and some will think that 2 days is enough, some will think it's one month
-21:36:07 <Betelgeuse>	We could also write some common time to devmanual
-21:36:07 <scarabeus>	they can always ask us in QA
-21:36:08 <ulm>	dertobi123: and for that case metadata information wouldn't help I guess
-21:36:13 <Calchan>	so we could always set a time limit but that's one more rule, do we need it?
-21:36:15 <dertobi123>	ulm: indeed ...
-21:36:15 <Betelgeuse>	about how soon you can commit if there's no response
-21:36:17 <scarabeus>	to look over that fix
-21:36:18 <Betelgeuse>	currently it's fuzzy
-21:37:00 <ulm>	Betelgeuse: one week?
-21:37:09 <scarabeus>	sounds like sensible time
-21:37:14 <scarabeus>	because it always contains weekend
-21:37:15 <scarabeus>	:]
-21:37:23 <dertobi123>	this topic is somewhat useless ... there's no problem to solve. if someone screws up -> get their account locked.
-21:37:28 <Calchan>	how about letting anybody touching anything as long as it is masked?
-21:37:40 <Calchan>	dertobi123, unfortunately it isn't that easy
-21:37:50 <dertobi123>	it is ...
-21:37:52 <solar>	ok so policy.
-21:37:52 <Betelgeuse>	Lot of people are well reachable so allowing touching is not good.
-21:37:59 <Calchan>	dertobi123, we have to leave people a certain margin for error, they
-21:38:01 <Calchan>	re not robots
-21:38:16 <dertobi123>	having loads of policy just for some tards is just plain bullshit
-21:38:20 <solar>	policy proposal. No useless data in metadata.xml (that's what #3 is about right?)
-21:38:33 <Calchan>	Betelgeuse, ok, (I was raising an hypothetical idea here, not pushing anything)
-21:38:43 <Calchan>	solar, right
-21:38:45 <scarabeus>	yeah lets stop that bikeshed on -dev about that metadata changes
-21:38:45 <solar>	where useless is stuff that does not help the end user in anyway. Ie internal stuff only.
-21:38:48 <ulm>	solar: right, it's useless in the users' tree
-21:39:54 <solar>	can we keep it that simple then?
-21:40:41 <Calchan>	solar, didn't you propose we keep this in another file at some point?
-21:41:00 <scarabeus>	that policy is complicated, so i would vote against it anyway
-21:41:00 <Betelgeuse>	I propose we vote on the week timeline?
-21:41:22 <Calchan>	Betelgeuse, we could do that, yes
-21:41:26 <leio>	I bet cvs->rsync can strip the tags with a simple xml tool. Having them in there or not is a different question, which we don't know if we should put our nose in it or not right now
-21:41:38 <Calchan>	anybody opposed to us voting on this?
-21:41:46 *	dertobi123 
-21:42:04 <solar>	Calchan: that was antarus. But I think that is somewhat outside the scope.
-21:42:16 <ulm>	leio: it would break the Manifest files
-21:42:41 <solar>	repoman in theory could check it from any dir.
-21:43:07 <Calchan>	dertobi123, you're opposed to us voting on making it official that after one week of warning one could touch any package?
-21:43:40 <Betelgeuse>	Calchan: Just have a vote. If people don't want a policy they vote no.
-21:43:45 <Betelgeuse>	To stay in status quo.
-21:43:56 <dertobi123>	Calchan: i'm opposed to randomly put things up to vote just somewhen during the meeting
-21:44:02 <Calchan>	Betelgeuse, I'd agree with that but I wanted to hear his reasons, it could be intersting
-21:44:22 <scarabeus>	Betelgeuse: it is another topic, the change for the devmanual, i would say first we close this topic and then lets vote on open floor
-21:44:25 <scarabeus>	we can do that no?
-21:44:29 <scarabeus>	sorry i bit disappeared
-21:44:50 <Calchan>	dertobi123, good point, so we should think this over a bit more, and if needed put it on the agenda for net time?
-21:45:08 <solar>	correct
-21:45:12 <Calchan>	scarabeus, open floor isn't for voting
-21:45:18 <dertobi123>	Calchan: yeah ...
-21:45:23 <scarabeus>	or put it before the open floor
-21:45:23 <ulm>	Calchan: right, we shouldn't rush into such a vote. put it on the next meeting's agenda
-21:45:36 <Calchan>	scarabeus, it's to let users and devs  interact with us directly
-21:45:38 <scarabeus>	but it is 3 minutes to vote, so we can do that next month
-21:45:58 <scarabeus>	just one thing, we should really somehow punish people not obeying that rule
-21:46:09 <Betelgeuse>	scarabeus: use current process
-21:46:26 <Betelgeuse>	scarabeus: devrel will act if evidence is presented
-21:46:44 <Calchan>	scarabeus, and bugs filed, and a chance to correct behavior given
-21:46:58 <Calchan>	I'm talking yoda style more and more, I'm getting worried
-21:47:19 <scarabeus>	force use, you must stop
-21:47:27 <Calchan>	heh
-21:47:46 <scarabeus>	:D
-21:48:11 <Calchan>	ok, so does any one of us volunteer to lead that topic on mailing lists and if needed make a proposition for next time?
-21:48:31 <scarabeus>	about the devmanual change of the packages changes?
-21:48:34 <scarabeus>	yeah i will do it
-21:48:54 <Calchan>	scarabeus, thanks
-21:48:56 <scarabeus>	pachages touching
-21:48:58 <dertobi123>	you volunteering to do something and don't know what to do? :P
-21:49:05 <dertobi123>	you're
-21:49:06 <dertobi123>	*
-21:49:08 <scarabeus>	nah just making sure
-21:49:17 <dertobi123>	heh
-21:49:29 <Calchan>	anybody wwants to add something?
-21:49:39 <solar>	I'm having a hell of a time following you guys. It sounds like you got way off topic of #3. Has that ended?
-21:50:08 <Calchan>	solar, I was making sure everybody had a chance to say whatver they wanted to say
-21:50:14 <scarabeus>	solar: you want to vote about it? most of us said no :]
-21:50:18 <Calchan>	so go ahead if there's anything you want to add
-21:51:20 <leio>	I understood the question is if we want to have policies for changes in metadata.xml at all, not if we support <changespolicy> tag or file
-21:51:35 <Calchan>	leio, indeed
-21:51:48 <solar>	I've already made my basic proposal related to #3 "No useless data in metadata.xml where useless is stuff that does not help the end user in anyway. Ie internal stuff only."
-21:51:48 <Calchan>	scarabeus, ^^^
-21:51:49 -->	nirbheek|netboo (~nirbheek@gentoo/developer/nirbheek) has joined #gentoo-council
-21:51:52 <leio>	as a random comment, I see nothing wrong with territorialism
-21:52:22 <leio>	if exercised by an always available team
-21:52:23 <dertobi123>	leio: the question is not even related to metadata.xml strictly - it is more about "do we want to solve a social problem with a technical solution?"
-21:52:46 <Betelgeuse>	dertobi123: it's not purely social as I pointed out
-21:53:09 <scarabeus>	Betelgeuse: well i think the devmanual update is better than load of new xml tags
-21:53:26 <Calchan>	scarabeus, you mean devmanual or dev handbook?
-21:53:36 <scarabeus>	demanual/dev handbook
-21:53:40 <Calchan>	scarabeus, not the same
-21:53:46 <Betelgeuse>	they are two different things
-21:53:50 <dertobi123>	Betelgeuse: well, make it 95% social then - doesn't really change my pov
-21:54:27 <scarabeus>	ok dev handbook is about policies so i speak about that one :]
-21:54:33 <Betelgeuse>	The deadline might be better in CVS part of dev handbook than devmanual.
-21:54:54 <scarabeus>	yep
-21:55:00 <Betelgeuse>	http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=2
-21:55:02 <Betelgeuse>	Maybe here
-21:55:07 -->	blueness (~hnsctq40@2001:470:1d:170:224:8cff:fe54:4052) has joined #gentoo-council
-21:55:09 <Calchan>	scarabeus, anyway don't bother about making a patch for the dev handbook yet, once we have the answer to our question it will be easy to do, let's work on the answer first, and maybe on the question too as douglas adams would say
-21:55:25 <scarabeus>	:]
-21:55:46 <Calchan>	I'm not kidding, finding out exactly what problem we are trying to solv eis essential here
-21:55:55 <scarabeus>	yes i get it
-21:56:26 <Calchan>	ok, do we leave it at that or does anybody have anything to add?
-21:57:09 <dertobi123>	no, trying to find the problem to solve ... that sums it up quite good
-21:57:32 <Calchan>	the current conclusion is scarabeus will look at the thread on ml, identify what the problem is and how we can solve it if there's anything to solve, and report back next month
-21:57:53 <Calchan>	and it's not forbidden to help him, whoever you are
-21:58:16 <Calchan>	alright, final topic then
-21:58:26 <Calchan>	4. Conclusion (10 minutes)
-21:58:31 <Calchan>	4.1 Action list. Who does what and when?
-21:58:49 <Calchan>	see above for scarabeus, and I'll work on the glep 39 thing
-21:58:56 <Calchan>	anything else?
-21:59:06 <dertobi123>	no
-21:59:22 <Calchan>	4.2 Who takes care of the summary and log for this meeting? When?
-21:59:48 <Calchan>	I can do that in the next 2 days, it's no big deal
-21:59:53 <leio>	Log I will commit within a couple hours
-21:59:57 <Calchan>	unless somebody else wnats to do it
-22:00:10 <Calchan>	leio, thanks
-22:00:22 <Calchan>	4.3 Next meeting date/time.
-22:00:35 <Calchan>	how about april 8th?
-22:00:44 <Calchan>	april 1st is risky ;o)
-22:00:47 <solar>	no
-22:00:55 <Calchan>	sorry, wrong calendar
-22:00:57 <leio>	8th seems like a Thursday ;p
-22:00:57 <Calchan>	not a monday
-22:00:58 <solar>	8th is on the Thursday. How about the 12th?
-22:01:03 <leio>	How about 5th
-22:01:10 <Calchan>	I was just testing you guys ! ;o)
-22:01:13 <ulm>	leio: easter monday ;)
-22:01:18 <solar>	is there a rush of topics for next month?
-22:01:19 <scarabeus>	5 or 19 are ok with me
-22:01:21 <scarabeus>	not 12
-22:01:23 <dertobi123>	5th is easter monday, prefer 12th ...
-22:01:28 <ulm>	12th ok for me too
-22:01:31 <leio>	I need a calendar with comments and special days or something
-22:01:32 <ulm>	or 19th
-22:01:50 <Calchan>	5th and 12th are ok with me
-22:01:54 <dertobi123>	19th might work as well
-22:02:30 <Calchan>	it seems it's one of those complicated ones, how about we settle that on the alias?
-22:02:57 <dertobi123>	just makes it even more difficult ...
-22:03:08 <Calchan>	dertobi123, not untrue
-22:03:22 <dertobi123>	what about the 19th? ok for everyone?
-22:03:39 <Calchan>	is everybody ok with the 19th?
-22:03:42 <Calchan>	I am
-22:04:03 <leio>	I am. We shouldn't make the meeting after that another 6 weeks interval then, but 4 or so.
-22:04:21 <Betelgeuse>	yes
-22:04:29 <Calchan>	leio, but some are not available on the 5th and some others on the 12th
-22:04:41 <Calchan>	leio, and as long as we have a meeting amonth we're ok
-22:05:13 <leio>	yes, I'm saying hopefully the May meeting can then happen on 17th (4 weeks after 12th April), not a longer interval again
-22:05:30 <Calchan>	ah ok, I misunderstood
-22:05:36 <dertobi123>	10th might work as well
-22:05:42 <leio>	we'll see then, all of 5th, 12th and 19th April are OK for me
-22:05:44 <dertobi123>	(10th may that is)
-22:06:17 <Calchan>	so let's tentatively settle for the 19th then, those who haven't spoken have say 48 hours to do so
-22:06:34 <Calchan>	4.4 Who will follow-up discussions and prepare the agenda for the next meeting?
-22:07:03 <ulm>	Calchan: I can prepare the agenda, unless you want to do it again ;)
-22:07:14 <Calchan>	ulm, thanks a lot
-22:07:47 <Calchan>	anything to add before open floor?
-22:08:23 <solar>	thank you
-22:08:43 <Calchan>	thanks solar
-22:08:44 <Calchan>	the floor is open then
-22:09:04 <Calchan>	vapier?
-22:09:27 <Calchan>	I'm running to the microwave, I'll be back in a couple minutes
-22:09:56 <vapier>	Calchan: you should keep the calendar up-to-date with council meetings
-22:10:04 <vapier>	i dont have anything else to add :P
-22:10:15 <scarabeus>	:D
-22:10:18 <solar>	haha. He waited all that time to repeat himself :)
-22:10:35 <leio>	no, meanwhile he watched us dance
-22:11:00 <scarabeus>	vapier: you cant do this, now i have to clean up the table with spit coffee, laughter is disaster at some points :D
-22:11:34 <Calchan>	vapier, what calender are you talking about?
-22:11:50 ---	solar has changed the topic to: Tentative Next Council meeting Apr 19th at 1900UTC, i.e. 2000CET, 1400EST, 1200MST, 1100PST.
-22:12:10 <scarabeus>	guys on web page lu_zero is still marked as slacker
-22:12:16 <scarabeus>	and elections where i was elected are missing
-22:12:21 <scarabeus>	just now spotted
-22:12:59 <leio>	scarabeus: what web page?
-22:13:06 <scarabeus>	http://www.gentoo.org/proj/en/council/
-22:13:38 <leio>	scarabeus: Oh, some weird section that has been added at some point
-22:13:42 <vapier>	Calchan: it's linked from gentoo.org frontpage
-22:13:46 <vapier>	it's on the left side
-22:13:58 <vapier>	if you dont have access, i can add you now ... just tell me your gmail account
-22:17:18 <vapier>	same for any other Gentoo dev
-22:17:38 >vapier<	mart.raudsepp
-22:20:36 <leio>	ok, anyone else for open floor speak?
-22:20:42 <Calchan>	vapier: first name . last name at gmail dot com
-22:21:10 -->	NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-22:22:00 <vapier>	done
-22:22:13 <Calchan>	vapier, thanks
-22:22:41 <vapier>	there's an old recurring event on there i guess will need updating/deleting
-22:24:16 <--	Ford_Prefect has quit (Quit: Ex-Chat)
-22:25:16 <Calchan>	vapier, I'll look into that, also I'm just now think that we'll switch to summer time  and we might want to take that into account
-22:28:51 <scarabeus>	i guess we are over meeting right? i am going to disappear if none wants something from me :]
-22:29:11 <Calchan>	scarabeus, yes, thanks for your participation
-22:29:47 <scarabeus>	we should more thank you for coordination, we just do what others elected us to do (at least try best to do so) :]
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100419-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100419-summary.txt
deleted file mode 100644
index 156788413c..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100419-summary.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Gentoo Council 2010-04-19 meeting agenda / summary:
-
-Role call:
- all showed up.
-
-Glep 39 refresh status update
- original ML thread at http://archives.gentoo.org/gentoo-project/msg_642482b9a9bc12e7d87fde8e6878f13c.xml
- - no new details, just a rough intention to have it ready sometime prior to 07/10
-
-metadata.xml policy changes
- - a discussion was had offlist (private), although no resolution came of it in this meeting
-
-Have doman use -il8n naming scheme in EAPI4.
- - relevant bug https://bugs.gentoo.org/303919
- - passed
-
-Bugzilla Policy for handling stablereq keywordin bugs:
-  After the maintainer has accepted that a package is good for
-  stable (by being the assignee or reporter), the preferred way to assign the bug
-  is the bug can be either assigned to the arch, or the arch can be CCed and the 
-  maintainer is the assignee.
-
-Bugzilla resolutions/keyword changes:
- - LATER/REMIND resolutions are to be removed
- - LATER is to be added as a keyword
- - OBSOLETE resolution is to be added
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100419.txt b/xml/htdocs/proj/en/council/meeting-logs/20100419.txt
deleted file mode 100644
index 93afbd6099..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100419.txt
+++ /dev/null
@@ -1,431 +0,0 @@
-21:00:33 <ulm>	somebody logging?
-21:00:46 <leio>	I am as usual
-21:00:51 <solar>	I'm not logging
-21:00:51 <leio>	committing after meeting
-21:00:57 <solar>	thanks leio
-21:01:04 *	dertobi123 yawns
-21:01:13 <Calchan>	hi guys, I just want to warn you that I'm feeling terrible today health wise
-21:01:33 <Calchan>	and I haven't slept in 30 hours so if I stop responding you'll know I'm sleeping
-21:01:33 <solar>	don't cough on us then. But noted you are here.
-21:01:50 <Calchan>	solar, it's not that, don't worry
-21:01:57 <ulm>	Betelgeuse?
-21:02:00 <Betelgeuse>	ulm: yes
-21:02:13 <ulm>	ok, everyone is there
-21:02:13 <scarabeus>	so everyone here we can say :]
-21:02:28 <solar>	ok. well that means Calchan probably wont chair today due to his health problems.
-21:02:38 <solar>	ulm: would you be willing to chair this meeting?
-21:02:49 <Calchan>	solar, good point, thanks
-21:03:04 <ulm>	solar: can do, unless someone else wants to
-21:03:37 <solar>	any objections? if not lets get started please
-21:04:09 <ulm>	ok, I'll take the chair then
-21:04:17 <ulm>	we're at 1.4 already :)
-21:04:35 <ulm>	any remarks on the agenda?
-21:04:47 <Calchan>	no
-21:04:53 <Betelgeuse>	no
-21:05:03 <scarabeus>	nope
-21:05:44 <ulm>	none it seems
-21:05:54 <ulm>	so 2. Follow-ups from previous meeting
-21:06:21 <Calchan>	do I start?
-21:06:25 <ulm>	Calchan: you want to say something about GLEP 39?
-21:06:32 <ulm>	yes
-21:06:52 <Calchan>	I have posted the discussion topics as planned in order to gether inpu tfrom the community
-21:07:09 <Calchan>	I forgot one and maybe more will come
-21:07:52 <Calchan>	the target is to have everything dpone before the nominations for next term
-21:08:16 <Calchan>	I will work backward from there to make a planning
-21:08:39 <ulm>	ok
-21:08:44 <Calchan>	I'm a bit disappointed by the small number of reactions so far but not surprised
-21:09:14 <Calchan>	any comments from you guys about what has been done so far?
-21:09:14 <ulm>	so not much to discuss until we have more responses on the ML
-21:09:18 <Betelgeuse>	Calchan: easier to push for your own ideas :)
-21:09:18 <scarabeus>	maybe we really could inspire ourselves by debian approach, how was suggested there
-21:09:28 <scarabeus>	:]
-21:09:30 <scarabeus>	or that
-21:09:35 <solar>	I've not had a chance to read that yet.
-21:09:52 <Calchan>	scarabeus, good point, I didn't have the strength to answer that comment but yes
-21:10:04 <leio>	I'll need to work through it later this week or so too, been busy with GSoC with the time I have
-21:10:12 <scarabeus>	well their document is well written and easy to understand
-21:10:15 <Calchan>	just add any idea even from debian to the thread
-21:10:16 <scarabeus>	so we can at least base off it
-21:10:22 <dertobi123>	same as solar for me ...
-21:10:22 <Calchan>	the point of this is to brainstorm
-21:11:04 <Calchan>	that's ok, it's a long term effort anyway
-21:11:23 <scarabeus>	we should just make sure to cook it before next elections :]
-21:11:33 <Calchan>	ulm, I'm done if there are no more questions
-21:11:40 <Calchan>	scarabeus, I'll make sure of that
-21:11:51 <antarus>	can you link to the thread somewhere (summary or agenda?)
-21:12:23 <Calchan>	antarus, http://archives.gentoo.org/gentoo-project/msg_642482b9a9bc12e7d87fde8e6878f13c.xml
-21:12:34 <Calchan>	and all the depending threads
-21:12:36 <ulm>	antarus: no open floor yet ;)
-21:13:12 <ulm>	any other comments on this topic?
-21:13:16 -->	reavertm (~quassel@gentoo/developer/reavertm) has joined #gentoo-council
-21:13:36 <solar>	other then just to say thanks to Calchan for following up.
-21:13:49 <ulm>	next is "policy for changes in metadata.xml"
-21:13:52 -->	darkside_ (~darkside@gentoo/developer/darkside) has joined #gentoo-council
-21:13:56 <ulm>	scarabeus?
-21:14:13 <scarabeus>	ok, i sent fancy mail to the wrong lists as Denis properly pointed out
-21:14:24 <scarabeus>	but the reaction was slightly more than zero
-21:14:25 <Calchan>	scarabeus, sorry I was a bit harsh that day
-21:14:34 <ulm>	scarabeus: where did you send it?
-21:14:40 <scarabeus>	core and council
-21:14:43 <scarabeus>	i should've use dev
-21:14:59 <Calchan>	scarabeus, I think it should have been appraoched differently, we can discuss that after the meeting if you want
-21:15:49 <ulm>	scarabeus: can you summarise the replies, or post a pointer to them?
-21:16:20 <ulm>	or should we reiterate and postpone to next meeting?
-21:16:33 <scarabeus>	my mail addressed 2 points
-21:16:33 <scarabeus>	devrel is not reacting on qa reported issues -> that one we can say is solved
-21:16:33 <scarabeus>	users are touching ebuild they dont maintain -> here i want to say something :]
-21:16:33 <Calchan>	ulm, I'd say postpone, let's reboot that
-21:16:58 <scarabeus>	or we can postprone it, and we can discuss the policy with rest qa guys, and Calchan or any other of you guys can chip in
-21:17:09 <scarabeus>	actualy i think the policy text i wrote is quite nice
-21:17:09 <scarabeus>	http://dpaste.com/185381/
-21:17:19 <dertobi123>	do we still have some qa guys around?
-21:17:21 <scarabeus>	yet it needs some sane override mechanism, where some poeple dont mind touching
-21:17:23 <ulm>	scarabeus: and maybe resend the message to -dev ml
-21:17:56 <Calchan>	scarabeus, it looks good to me, but it's only nice if it's what devs want
-21:18:23 <scarabeus>	dertobi123: we do qa ;] even tho people mostly see the removals ;D
-21:18:32 <Betelgeuse>	scarabeus: a typo in exceptions? ws and breaking installs in same category?
-21:18:32 <ulm>	at least it's a good starting point for discussion
-21:18:41 <scarabeus>	ok i will sent one more mailie to the -dev
-21:18:54 <scarabeus>	and we see what responses we will collect till next meeting then
-21:18:55 <Betelgeuse>	ah know I got it
-21:20:01 <ulm>	can we move to the next topic?
-21:20:10 <dertobi123>	mh yeah
-21:20:12 <Calchan>	yes please
-21:20:19 <scarabeus>	move move :]
-21:20:34 <ulm>	3. "doman -i18n" option
-21:20:55 <ulm>	I hope everybody had a look at bug 303919
-21:20:57 <willikins>	ulm: https://bugs.gentoo.org/303919 "Prefer -i18n option of doman to filename language suffix"; Gentoo Hosted Projects, PMS/EAPI; NEW; billie@g.o:pms-bugs@g.o
-21:21:14 <solar>	it seems like it's been worked out, and only needs approval
-21:21:20 <ulm>	in a nutshell:
-21:21:24 <leio>	I don't get the tying to EAPI
-21:21:28 <leio>	go on
-21:21:36 <ulm>	- PMS doesn't document -i18n
-21:21:51 <ulm>	- we wnat to fix the behaviour for the next EAPI
-21:21:54 <ulm>	*want
-21:22:07 <ulm>	leio: it's a slight change of behaviour
-21:22:36 <leio>	I'm concerned about the gradual switchover. Isn't it about where the files get installed on the system, what directory, or I misunderstood completely?
-21:22:37 <ulm>	i.e. the option should be preferred to the filename language tag
-21:23:08 <ulm>	leio: right
-21:23:19 <ulm>	it's about man pages like foo.pl.1
-21:23:44 <ulm>	which are most likely about a perl script, not a page in Polish
-21:23:56 <leio>	Why with a fresh install I should get some localized man pages under one name, and others in another
-21:23:59 <ulm>	in EAPI 3 there's no way to handle that
-21:25:35 <Betelgeuse>	ulm: we could try a vote as people should be prepared, if for some reason someone doesn't understand they can abstain / vote no.
-21:25:47 <ulm>	Betelgeuse: right
-21:25:49 <Calchan>	wfm
-21:26:07 <scarabeus>	lets vote
-21:26:37 <Calchan>	I vote yes for this in eapi4
-21:26:41 <Betelgeuse>	yes
-21:26:50 <scarabeus>	i vote yes
-21:26:50 <solar>	as an english only speaker and knowing very little about i18n behaviors. I have no objections as long as those ebuilds don't die on uclibc. so yes
-21:27:03 <dertobi123>	yes
-21:27:04 <ulm>	please vote on "doman -i18n as outlined in bug 303919 should be included in EAPI 4"
-21:27:07 <willikins>	ulm: https://bugs.gentoo.org/303919 "Prefer -i18n option of doman to filename language suffix"; Gentoo Hosted Projects, PMS/EAPI; NEW; billie@g.o:pms-bugs@g.o
-21:27:12 <ulm>	I vote yes, obviously
-21:27:16 <dertobi123>	heh
-21:27:22 <Betelgeuse>	ulm: slow :)
-21:27:25 <scarabeus>	:]
-21:27:49 <ulm>	leio?
-21:27:52 <leio>	I have no objections against an extra argument possibility, so if I understand what we are voting on right, then yes
-21:28:09 <ulm>	ok, unanimous then
-21:28:25 <Betelgeuse>	ok my stuff then
-21:28:27 <Betelgeuse>	Any questions?
-21:28:28 <ulm>	next topic 4. bugzilla policy
-21:28:55 <Betelgeuse>	or clarifications rather
-21:29:00 <leio>	Does the bugzilla votes consider bugs where initially there are multiple arches involved?
-21:29:42 -->	ferringb (~ferringb@gentoo/developer/ferringb) has joined #gentoo-council
-21:29:48 <Betelgeuse>	Initially with multiple arches you CC them all.
-21:29:56 <Betelgeuse>	like currently - no change
-21:30:16 -->	billie (~billie@gentoo/developer/billie) has joined #gentoo-council
-21:30:29 <dertobi123>	guess leio's talking about when there's only a single left on a bug
-21:30:33 <leio>	yes
-21:30:39 <dertobi123>	eh, single arch*
-21:30:46 <Betelgeuse>	I didn't remember to put that on the list but we can vote on that too if everyone is ready.
-21:30:48 <leio>	I don't like things getting reassigned to that one remaining last arch then
-21:31:17 <ulm>	leio: maybe we should vote on this point separately
-21:31:20 <Betelgeuse>	let's handle this first
-21:31:32 <solar>	on 4.1 (b) seems ideal to me as it allows to most flexibility.
-21:31:35 <Betelgeuse>	if there's time at the end we can revisit
-21:32:00 <scarabeus>	i would go with b too
-21:32:08 <Betelgeuse>	Read the instructions.
-21:32:19 <dertobi123>	having worked on both ppc and hppa arch teams ... i'm for 4.1 (b) ... both ways work for me
-21:32:26 <Betelgeuse>	Let's start voting on a:
-21:32:28 <Betelgeuse>	I vote yes.
-21:32:29 <leio>	(but I think this [when one arch is left] can be a maintainer decision if to reassign or not, if we don't disallow assigning to arches for keyword/stable bugs with 4c)
-21:32:37 <solar>	err.
-21:32:45 <solar>	a) no b) yes c) no
-21:32:49 <solar>	same thing Betelgeuse
-21:32:54 <leio>	what is a?
-21:33:01 <ulm>	leio: see agenda
-21:33:06 <scarabeus>	a) no b) yes c) no
-21:33:14 <leio>	I see it as a three-way choice, not three yes/no's?
-21:33:14 <dertobi123>	b) yes, a) and c) no
-21:33:15 <ulm>	leio: The single arch in question is the assignee
-21:33:26 <Betelgeuse>	solar: that way is not the same thing
-21:33:40 <ulm>	right, it's a three-way choice :]
-21:33:42 <Betelgeuse>	solar: I only vote yes to b) if a doesn't get majority
-21:33:47 <Calchan>	Betelgeuse, we're only talking about stabilizations here right? not about adding a new ~arch keyword
-21:33:48 <ulm>	so vote on 4.1 a, b, or c as outlined in the agenda
-21:33:56 <Betelgeuse>	Calchan: keywording bugs
-21:34:06 <Betelgeuse>	Calchan: the descriptions needs to be more clear
-21:34:21 <ulm>	solar, scarabeus, dertobi123: I take this as "b" from you
-21:34:25 <Betelgeuse>	Calchan: +For example to the start.
-21:34:29 <scarabeus>	ulm: yes
-21:34:31 <dertobi123>	ulm: yeah ;)
-21:34:38 <leio>	so only about new ~arch keywords?
-21:34:39 <ulm>	I vote "b" too
-21:34:53 <Betelgeuse>	IF you guys had problems the voting method, why didn't you comment on the agenda?
-21:34:58 <Betelgeuse>	+with
-21:35:28 <leio>	the agenda says it's a choice between a, b and c as far as my english deciphers
-21:35:32 <leio>	I vote "b"
-21:35:43 <ulm>	Betelgeuse: it's a choice between 3 possibilities
-21:35:45 <solar>	he is asking for the entire lot sorta.
-21:35:51 <ulm>	Betelgeuse: you can only have one of them
-21:36:00 <Betelgeuse>	whatever I vote a
-21:36:11 <dertobi123>	guys, kiss - keep it simple and stupid ...
-21:36:16 <ulm>	Calchan: your vote?
-21:36:23 <Betelgeuse>	ulm: voting a,b,c could scatter
-21:36:35 -->	djc (~djc@gentoo/developer/djc) has joined #gentoo-council
-21:36:42 <Calchan>	ulm, b with the mention that I would like the maintainer to at least be CCed
-21:36:47 <ulm>	Betelgeuse: that's why I included a run-off vote ;)
-21:37:04 <leio>	err, ok, we are voting on STABLEREQ, right? Sorry for the confusion
-21:37:12 <Betelgeuse>	We waste more time arguing on the change than just going with the agenda says.
-21:37:20 <ulm>	Calchan: doesn't always make sense
-21:37:25 <solar>	leio: we are still on 4.1
-21:37:27 <ulm>	e.g. if the maintainer is the reporter
-21:37:31 <--	djc (~djc@gentoo/developer/djc) has left #gentoo-council
-21:37:35 <Betelgeuse>	leio: We should have same policy for all keywording bugs.
-21:37:49 <Calchan>	ulm, I think the maintainer deserves to know at least, he can then remove himsel fif he wants
-21:37:52 <ulm>	ok, I count 1 a, 6 b, 0 c
-21:37:58 <Betelgeuse>	Calchan: That was already covered in the threads.
-21:38:08 -->	NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-21:38:17 <Betelgeuse>	I should have done a better job for the agenda text.
-21:38:19 <Calchan>	Betelgeuse, I just wanted to mention it in the meeting :o)
-21:38:28 <Betelgeuse>	But stuff is clear if you read the thread.
-21:38:31 <leio>	b, but if maintainer isn't the assignee, it should get CCed at first
-21:38:33 <--	Ford_Prefect has quit (Quit: Ex-Chat)
-21:38:56 <ulm>	Betelgeuse: the outcome of the vote would've been the same regardless of voting procedure
-21:39:03 <Betelgeuse>	ulm: in this case yes
-21:39:30 <Betelgeuse>	ulm: I put it there because I considered my way fastests to reach a decision.
-21:39:31 <ulm>	next is "bugzilla resolutions"
-21:39:39 <solar>	I personaly tend to think the order they are listed in the metadata.xml is how they want it assigned.
-21:39:53 <Betelgeuse>	solar: there's nothing to say it works that way
-21:40:46 -->	Zorry_N900 (~user@gentoo/developer/zorry) has joined #gentoo-council
-21:40:50 <ulm>	questions/discussion about LATER and REMIND resolutions?
-21:40:53 -->	PSYCHO___ (~scarab@gentoo/developer/scarabeus) has joined #gentoo-council
-21:40:53 ---	ChanServ gives channel operator status to PSYCHO___
-21:41:04 *	PSYCHO___ slightly disconnected
-21:41:12 <PSYCHO___>	something relevant on that vote already happened?
-21:41:21 <Betelgeuse>	Just a note that infra could take a while to implement it.
-21:41:30 <Betelgeuse>	We can still make it a policy already to not use them.
-21:41:32 <ulm>	PSYCHO___: no
-21:41:40 <PSYCHO___>	oka
-21:42:00 <solar>	4.2 Infra said it could do it around to the removal of the existing bug resolutions in the bugs-3 migration. Can add later and bosolete
-21:42:01 <dertobi123>	Betelgeuse: urm, policy won't work quite well for that
-21:42:14 <solar>	So my vote is yes
-21:42:34 <Betelgeuse>	Also note that Remove means remove for new markings.
-21:42:42 <Betelgeuse>	Not Remove from already resolved.
-21:43:21 <Betelgeuse>	I vote yes.
-21:43:25 <dertobi123>	from what robbat said in infra an hour ago, that won't be possible? (i might be wrong on that?)
-21:43:55 <solar>	<robbat2> i'll add the new RESO+keyword for now, but disabling the others is going to get RESO AFTER_BUGZILLA3
-21:44:11 <dertobi123>	ah, ok
-21:44:27 <dertobi123>	whatever, yes on all 3 proposed changes then
-21:44:57 <Calchan>	we could send an email to -dev-announce to not use them and remove them from the docs to start
-21:45:18 <Betelgeuse>	Calchan: I can also try to remember to run a periodic search and yell at people.
-21:45:21 <Calchan>	ulm, and yes on all 3 questions
-21:45:22 <PSYCHO___>	yes from me but we could wait to the bugzie 3 migration with actualy turning it on :]
-21:45:37 <Calchan>	Betelgeuse, in case you need help with the yelling you know who to ask ;o)
-21:45:37 <solar>	he might not be able to purge them w/o mass bug spam. So it may just be a hidden resolution for while
-21:46:00 <ulm>	I vote yes too
-21:46:02 <ulm>	leio?
-21:46:13 <solar>	PSYCHO___: $nick -> scarab.. please
-21:46:33 <PSYCHO___>	i cant :(
-21:46:38 <PSYCHO___>	it is still here
-21:46:39 <leio>	can the chair please spell out what we are actually voting here to avoid confusion again?
-21:46:40 <PSYCHO___>	wait a sec
-21:46:56 <leio>	are we voting on the first point of removing LATER and REMIND, or all of them right now, or what
-21:46:58 <ulm>	leio: vote on "Remove LATER and REMIND from resolutions."
-21:47:21 <ulm>	one point after the other ;)
-21:47:29 <leio>	yes, but conditionally on "Add LATER as a keyword" getting decided as a "yes" too.
-21:47:53 <ulm>	next vote: "Add LATER as a KEYWORD"
-21:47:57 <leio>	yes
-21:47:59 <Calchan>	yes
-21:48:01 <ulm>	I vote yes
-21:48:22 <Betelgeuse>	yes
-21:48:31 <dertobi123>	still yes
-21:49:16 <ulm>	5 yes, so we've a majority
-21:49:20 <ulm>	scarabeus, solar?
-21:49:29 <solar>	we already voted
-21:49:32 <solar>	both said yes
-21:49:34 <PSYCHO___>	well i can say yes on this acc
-21:49:41 <Betelgeuse>	For OBSOLETE there's some overlap with CANTFIX
-21:50:28 <scarabeus>	i vote yes for all 3
-21:50:31 <Betelgeuse>	but I still like for more accurate describing
-21:50:36 <Calchan>	Betelgeuse, but OBSOLETE can be considered a special case of CANTFIX
-21:50:43 <Calchan>	so that still works imo
-21:50:46 <solar>	yes, but that can't be avoided.
-21:50:46 <scarabeus>	now lets hope now the connection to quassel core holds :]
-21:50:55 <Betelgeuse>	Calchan: basically what I was saying
-21:51:07 <Calchan>	Betelgeuse, sorry, slow brain today
-21:52:40 <Calchan>	ulm, are we voting on OBSOLETE?
-21:52:40 <ulm>	I suggest we just vote on "Add resolution OBSOLETE". if you think it's redundant you can vote no
-21:52:49 <ulm>	Calchan: we do
-21:52:53 <Betelgeuse>	yes
-21:52:58 <leio>	I vote yes
-21:52:58 <Calchan>	ok, it's a yes from me then
-21:52:58 <dertobi123>	yes
-21:53:03 <scarabeus>	yup
-21:53:09 <ulm>	yes
-21:53:41 <solar>	yes
-21:53:57 <ulm>	all three votes unanimous then
-21:54:14 <ulm>	and we are in time :)
-21:54:24 <ulm>	5 conclusion
-21:54:35 <ulm>	5.1 action list
-21:54:35 <solar>	nearly an unanimous entire agenda
-21:55:21 <ulm>	scarabeus: you follow up on 2.2?
-21:55:42 <PSYCHO___>	yes
-21:55:47 <PSYCHO___>	i sent the text via quasell
-21:55:49 <PSYCHO___>	it will arrive
-21:55:52 <PSYCHO___>	give it some time ;D
-21:56:06 <ulm>	k
-21:56:18 <ulm>	anything else for 5.1?
-21:56:31 <Betelgeuse>	ulm: documentation needs updating
-21:56:41 <Betelgeuse>	ulm: I'll see if I can find a volunteer
-21:57:01 <scarabeus>	ok i will do my postproned item and sent the mail to the -dev as soon as i gather opinion of other qa members, and i hope there will be some constructive updates :]
-21:57:01 <scarabeus>	ok i will do my postproned item and sent the mail to the -dev as soon as i gather opinion of other qa members, and i hope there will be some constructive updates :]
-21:57:09 <scarabeus>	see it works :]
-21:57:19 <ulm>	I'll take care of "doman" for pms
-21:57:42 <Calchan>	scarabeus, make sure you gather input from all devs, not just QA
-21:58:08 <solar>	Please. I dislike putting that into policy myself.
-21:58:28 <Calchan>	scarabeus, a policy that devs don't want has no chance of being respected
-21:58:37 <solar>	cuz something bonsaikitten did. sucks to punish all devs
-21:58:57 <scarabeus>	well thats why i want simple override method
-21:59:03 <ulm>	5.2 who takes care of log and summary?
-21:59:17 <scarabeus>	and dont worry, just qa first then -dev-ml
-21:59:26 <leio>	I take care of log
-21:59:38 <Calchan>	ulm, I can take care of the summary tomorrow
-21:59:43 <scarabeus>	i guess each of us is there rite? :]
-21:59:54 <ulm>	Calchan, leio: thanks
-22:00:11 <ulm>	5.3 next meeting date
-22:00:20 <solar>	May 17th
-22:00:49 <dertobi123>	works for me
-22:00:59 <solar>	or 12th. If we don't have more then 3 items. then 17th would be better imo
-22:01:02 <Calchan>	I'm open all mondays next month
-22:01:22 <solar>	sorry 10th
-22:01:33 <Calchan>	solar, let's do 17th, we may have a rich agenda next time due to glep 39
-22:01:36 <ulm>	both 10th and 17th work for me
-22:01:55 <Betelgeuse>	17th is better
-22:01:59 <ulm>	any objections on May 17th?
-22:02:00 <leio>	both work for me
-22:02:10 <ulm>	18 UTC as usual
-22:02:14 <Calchan>	yes
-22:02:41 <PSYCHO___>	17 ok for me
-22:02:53 <PSYCHO___>	time ok too :]
-22:02:59 <ulm>	ok, 2010-05-17 18 UTC then
-22:03:07 <ulm>	5.4 who will follow-up discussions and prepare the agenda?
-22:03:14 <Calchan>	I can take care of the agenda, makes sense if there's alot about glep 39, unless somebody want sot do it
-22:03:41 <solar>	sounds good
-22:04:05 <ulm>	Calchan: thank you again
-22:04:10 <Calchan>	sure
-22:04:26 <ulm>	open floor then
-22:04:45 <solar>	6.1) is not for the council. Kick it over to the foundation
-22:04:47 <Calchan>	ulm, thanks for chairing, you did a good job, it's not an easy task
-22:05:03 <solar>	or PR
-22:05:19 <Calchan>	solar, good point
-22:05:20 <NeddySeagoon>	Can the council publish a meetings calendar for the remainder of their term ?
-22:05:29 <spatz>	scarabeus: please don't forget to add an exception for when the maintainer is away
-22:05:31 <ulm>	solar: formally infra is responsible for the website
-22:05:36 <Calchan>	NeddySeagoon, what do you mean? decide on the dates now?
-22:05:36 <ferringb>	so... anyone mind clarifying why REQUIRED_USE original discussion from the ml (consensus among other things, and more than enough time), why it got dropped, and when it'll actually be addressed? :)
-22:05:43 <NeddySeagoon>	Calchan, yes
-22:06:00 *	ferringb has poked a few folk about this, but considering no response and the proper forms were followed...
-22:06:04 <NeddySeagoon>	and try to stick with them
-22:06:07 <solar>	ulm: we did this years ago. there were www contests etc.
-22:06:09 <ulm>	ferringb: I thought we had discussed this already
-22:06:27 <solar>	when new code is ready that meets the requirements infra set some years ago. It can be done
-22:06:33 <Calchan>	NeddySeagoon, difficult for me, these meetings happen during office hours and the best I can do is lock a date one month in advance
-22:06:47 <solar>	but that is outside the scope of the council imo
-22:07:29 <Calchan>	ferringb, you need to get your glep accepted, discussed and then approved before the council can vote on it
-22:07:36 <ferringb>	Calchan: it's not a glep
-22:07:51 <ferringb>	Calchan: I may've used the glep format to write the sucker up, but that was purely so the council would have the data in one place
-22:07:52 <Calchan>	ferringb, oh I thought you were talking about a glep
-22:08:00 <Calchan>	sorry then
-22:08:23 <ferringb>	ulm: partially.  I'm still not particularly happy w/ the reasoning, and I'm intent on making enough noise stuff like this doesn't get dropped on the floor without at least telling people why
-22:08:40 <ferringb>	it's not like it was a backroom request.  the call for requests went out, pretty clear it was asked for
-22:08:53 <ulm>	ferringb: I had also thought it was a GLEP, due to http://dev.gentoo.org/~ferringb/gleps/required-use.html
-22:09:00 *	ferringb sighs
-22:09:10 <ferringb>	fine, if that's your thought
-22:09:18 <ferringb>	why didn't you publically state "can't vote on it due to xyz" ?
-22:09:25 <solar>	well you gave it a number, called it a "This GLEP proposes"
-22:09:29 <ferringb>	instead it sits, and I have to run y'alls asses down to find out why it got ignored
-22:09:32 <solar>	so it looks like a draft glep to us
-22:09:39 <ferringb>	solar: number is actually required to generate html
-22:09:45 <Calchan>	ferringb, you are talking to council members here, so make sure you're unambiguous and explicit as much as possible as we're kinda thinck ;o)
-22:09:45 <ferringb>	an annoying restriction actually
-22:10:09 <ferringb>	Calchan: ok, explicit: do not go dropping requests without explaining why
-22:10:13 <ferringb>	even a "don't have time" is fine
-22:10:19 <ulm>	ferringb: we've discussed that before I finalised the agenda :(
-22:10:37 <Betelgeuse>	ulm: I think what ferringb would have wanted as a faster reaction
-22:10:43 <ferringb>	ulm: aware of the justifications; the point I'm after here is the lack of response ;)
-22:11:26 <ferringb>	think of it this way; y'all think it's a glep.  thus far no pms change has been glepped, but whatever, ok.  if someone had even *commented* on it stating "sorry, can't touch it", could've done something about it.  instead it's 5-6 weeks of wait, instead of 1-2.
-22:11:29 <Betelgeuse>	To note for the people doing agenda in the future: Answer all requests int he thread.
-22:11:35 <ferringb>	Betelgeuse: exactly
-22:11:58 <ferringb>	preferably not 5 minutes before you've assembled a proto agenda also
-22:12:06 <Calchan>	ferringb, we suck more often than not, sorry
-22:12:16 <ferringb>	Calchan: people suck more often than not, welcome to the human race
-22:12:26 <ulm>	Betelgeuse: I've contacted everyone on irc, should be as good
-22:12:35 <ferringb>	the people who don't suck are the ones who correct mistakes so they don't repeat 'em ;)
-22:12:41 <Calchan>	ferringb, don't look at me, I don't look human today ;o)
-22:13:03 <solar>	I'd like to see ^^ in it's own section. It's easy to overlook the introduction of new operators that we know will probably become a desired feature elsewhere that !? ( :[] ) syntax is used
-22:13:15 <ferringb>	solar: well, we've got a month to discuss that, don't we? ;)
-22:13:18 <ferringb>	and yes, that was cheap
-22:13:34 <ferringb>	solar: I'll work on splitting that up for potential license reuse
-22:13:36 <Betelgeuse>	ulm: yeah but hard for others to know you have talked on IRC
-22:14:00 <ferringb>	ulm: also, I poked you... and that was after the schedule was set (I find out on my own) ;)
-22:14:52 <ferringb>	basically, if you put out a "request for council discussion points" on dev, stuff that shows up there either include, or respond explaining why not.  simple enough request, and preferably done during the week/two, rather than last minute
-22:14:58 <ferringb>	last minute being fine if the schedule doesn't fit mind you
-22:15:03 <ferringb>	either way, </lecture>
-22:15:23 <solar>	ok. well you have all our ears now for input/feedback.
-22:16:00 <ferringb>	alternatively, approve everything I hand your way... preferably w/ a resolution stating that my word is law so I don't have to burn a month or two for everything I'm after :P
-22:16:09 <solar>	I think the idea is neat. I don't see you saying the PM has to do anything. It's just a key that can be used if it exists right?
-22:16:19 <--	PSYCHO___ has quit (Quit: WeeChat 0.3.1.1)
-22:16:35 <ferringb>	solar: rephrase your question... also, can it wait a bit?  need to run down someone work wise for a second
-22:17:10 <--	Zorry_N900 has quit (Quit: Leaving)
-22:17:15 <Philantrop>	ferringb: You actually said yourself it's a GLEP: http://article.gmane.org/gmane.linux.gentoo.devel/66105
-22:17:52 <Calchan>	ferringb, /win 11
-22:17:56 <Calchan>	dammit
-22:18:31 <solar>	ulm: did we cover OpenFloor 6.2 ?
-22:18:53 <ferringb>	Philantrop: "wrote it up as a glep" doesn't mean drop it on the floor with zero explanation
-22:19:24 <ulm>	solar: not yet
-22:19:28 <ulm>	6.2 "centralise developer documentation"
-22:19:29 <Calchan>	solar, it's open floor so anybody who wants to discuss it is welcome, it doesn't necessarily have to be council members though
-22:19:53 <Betelgeuse>	yeah it's not open floor if it's rigidly controlled :)
-22:19:59 <Philantrop>	ferringb: No, I just wanted to make clear why the council may have seen it as a GLEP.
-22:19:59 <ulm>	I'd thought yngwin would comment on 6.1 and 6.2
-22:20:01 <ferringb>	Philantrop: further, preceeding proposal still had zero commentary from the council, my intent in writing that doc was purely so they had all the details/info in a single spot, not to get nailed by fricking red tape
-22:20:09 <ulm>	butt looks like he isn't here
-22:20:12 <ulm>	*but
-22:20:25 <ferringb>	Philantrop: I grok the view.  annoyance there is the wasted month ahead due to no communication ;)
-22:20:29 <Philantrop>	ferringb: Don't shoot the messenger. :-)
-22:20:34 <solar>	I just want to make sure it does not get lost.
-22:20:36 *	ferringb is in a shooty mood
-22:20:54 <ferringb>	solar: around in a few hours re: discussing ^^ btw
-22:21:17 <solar>	on 6.1. Sounds good if yngwin is going to voluenteer to take lead on it. Or so is my suggestion to him
-22:21:40 <Betelgeuse>	I have been giving tasks related to 6.2 for people contacting me for small tasks.
-22:21:45 <solar>	ferringb: I need to get out after this meeting is over. Around this evening
-22:21:52 <ulm>	solar: he already volunteered on that one
-22:21:59 <Betelgeuse>	but so far most have failed to deliver anything
-22:22:15 *	yngwin is not volunteering for anything until my devrel issue is resolved
-22:22:35 <Calchan>	I think 6.2 is a damned good idea though, one we realy need, but it needs to be done in a way that we don't step over the doc team's toes
-22:22:52 <Betelgeuse>	Calchan: developer documentation is not controlled by doc team in any way
-22:22:55 <ulm>	yngwin: right, I remember so said something like that
-22:22:56 <Betelgeuse>	Calchan: I control it all pretty much
-22:25:02 <Calchan>	Betelgeuse, I thought devmanual was under QA's umbrella, and what I meant is we could consider going further, but that was just an idea
-22:25:16 <Betelgeuse>	Calchan: It is under QA but I can push.
-22:26:03 <Betelgeuse>	Calchan: I would hope QA being more active in maintaining it.
-22:27:06 <solar>	I don't see that happening on it's own.
-22:34:31 <Betelgeuse>	Seems discussions has quieted down.
-22:34:46 <Betelgeuse>	Time for me to move on then. Thanks for everyone.
-22:36:20 <ferringb>	solar: 'k, can discuss then
-22:40:04 <ulm>	can we close the meeting?
-22:40:37 <leio>	yes, so this would be my raw log cut-off point :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100517-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100517-summary.txt
deleted file mode 100644
index 3f52cae557..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100517-summary.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-Gentoo Council 2010-05-17 meeting agenda / summary:
-
-role call:
- all present
-
-
-Glep 39 discussion:
- discussion points:
-  - http://archives.gentoo.org/gentoo-project/msg_79dc0c2dc7d8987a9c9ecaaa30e17bb2.xml
-  - http://archives.gentoo.org/gentoo-project/msg_6009db554b00ae9de67047206c7698be.xml
-  - http://archives.gentoo.org/gentoo-project/msg_3806fe4e42dc8ce013e247a081e3d4a0.xml
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100517.txt b/xml/htdocs/proj/en/council/meeting-logs/20100517.txt
deleted file mode 100644
index 321dd8ecef..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100517.txt
+++ /dev/null
@@ -1,304 +0,0 @@
-21:00:29 <Calchan>	alright, woodpecker says it's time
-21:00:34 *	dertobi123 yawns
-21:00:39 <leio>	here
-21:00:53 <Calchan>	leio is logging, Betelgeuse is probably logging as always, so we should be OK
-21:00:56 <solar>	here
-21:01:00 <ulm>	here
-21:01:04 <Betelgeuse>	here
-21:01:11 <Calchan>	solar, oh great, nice you could make it
-21:01:15 <solar>	sorta
-21:01:42 *	jmbsvicetto looks in
-21:02:12 <Calchan>	so only scarabeus is missing right now
-21:02:26 <Calchan>	let's give him some time while we finish the intro
-21:02:30 <scarabeus>	damn sorry
-21:02:33 <scarabeus>	i am around
-21:02:35 <Calchan>	ah good
-21:02:37 <scarabeus>	but eating dinner
-21:02:42 <scarabeus>	i thought i have 5 more minutes :D
-21:02:43 <scarabeus>	ok
-21:02:44 <Calchan>	so, who wants to chair?
-21:02:45 <scarabeus>	we can go :
-21:02:47 <scarabeus>	]
-21:03:21 <Calchan>	no answer, should I do it then?
-21:03:41 <Calchan>	ko, I'll do it
-21:03:47 <dertobi123>	just do it
-21:03:55 <Calchan>	any remarks on the agenda before we start?
-21:04:32 <Calchan>	dertobi123, did I correctly answer your worries about this meeting being useless in my email?
-21:05:16 <dertobi123>	well
-21:05:24 -->	javaJake (~javaJake@unaffiliated/javajake) has joined #gentoo-council
-21:05:32 <Calchan>	dertobi123, ?
-21:06:08 <Calchan>	anyway, lets go on
-21:06:14 <Calchan>	2. Review of GLEP 39 overhaul propositions (30 minutes)
-21:06:16 <dertobi123>	well, i still think it's quite useless do go through all proposed changes
-21:06:29 <dertobi123>	but anyways, just move on ;)
-21:06:39 <Calchan>	let's not go though all of them but just talk a bou the ones that might not be OK then
-21:07:01 <Betelgeuse>	I'll just iterate that voting should move to the web app after GSoC is over.
-21:07:09 <Betelgeuse>	Otherwise doing the webapp is kind of pointless.
-21:07:13 <Calchan>	as I said in one of my emails some of the propositions are me interpreting what devs want
-21:07:31 <Calchan>	Betelgeuse, great, I'm looking forward to it
-21:07:51 <Calchan>	let's start with http://archives.gentoo.org/gentoo-project/msg_79dc0c2dc7d8987a9c9ecaaa30e17bb2.xml
-21:07:59 <dertobi123>	Calchan: put the proposed ballots up for review a week before voting starts and everyone is able to send in fixes
-21:08:23 <leio>	Calchan: maybe you want to link to the summaries instead?
-21:08:37 <Calchan>	leio, sorry that was the thread
-21:08:50 <Calchan>	http://archives.gentoo.org/gentoo-project/msg_df5433a1e6cbe479462da8f5fe588299.xml
-21:09:19 <Calchan>	^^^ the 5 choices that seem to appear from all the discussions we had
-21:09:41 <Calchan>	the current situation would be number 2
-21:09:59 <Calchan>	anything you want to add or delete from that list?
-21:10:32 <scarabeus>	the last one is uttery dull, we should not be able to switch out votes
-21:10:51 <Calchan>	scarabeus, it was proposed by somebody, can't remember who though
-21:10:54 -->	NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-21:11:25 <Calchan>	scarabeus, but agreed it looks weird
-21:11:28 <scarabeus>	it should be number 3
-21:11:34 <ulm>	take off the last two points
-21:11:46 <ulm>	they make no sense
-21:11:56 <scarabeus>	actualy no
-21:11:59 <scarabeus>	even that is bad
-21:12:15 <Calchan>	ulm, number 4 is what was done a couple time this year and wasn't accepted so it makes sense to have it on the ballot
-21:12:36 <scarabeus>	4. is most sane if we dont see the votes before we actualy vote
-21:12:45 <Calchan>	btw, the idea is not to discuss the propositions but decide which ones should go on the ballot. If you disagree with some of the propositions (hopefully), then just talk them down on the corresponding thread and vote against them
-21:12:46 <scarabeus>	because it might affect our decision to see how others decided :]
-21:13:07 <ulm>	scarabeus: so?
-21:13:17 <ulm>	it's the same now
-21:13:46 <scarabeus>	probably yea, since we dont have anonymous voting
-21:13:55 <scarabeus>	but now the time you have to do it is bit shorter :]
-21:14:13 <Calchan>	anybody else against having 3 and 4 on the ballot? if not I'll consider we have a majority for keeping them
-21:14:15 <dertobi123>	Calchan: this should also not be about what is on the ballot, since it's not us to decide what people want on the ballots.
-21:14:39 <ulm>	Calchan: 3 and 4? or 4 and 5?
-21:14:46 <Calchan>	dertobi123, agreed in this case, you'll see later that some of the proposals are the result of my interpretation
-21:14:51 <Calchan>	ulm, sorry, 4 and 5
-21:14:55 <ulm>	or do you start counting from zero
-21:15:01 <ulm>	;)
-21:15:15 <Calchan>	ulm, it's still monday morning here ;o)
-21:15:46 <scarabeus>	i am definitely against last one and number 3 if i count from 1
-21:15:56 <scarabeus>	noone should be able to affect council meeting after it ends
-21:16:13 <leio>	against having it on a ballot, or your opinion of what we should choose..?
-21:16:38 <Calchan>	scarabeus, make sure you make the difference between your personal opinion  and whether it makes sense on the ballot
-21:16:54 <ulm>	Calchan: well, put them all on the ballot. we can trust devs not to vote for the stupid ones
-21:16:58 <Calchan>	leio, was that for 4 and 5?
-21:17:19 <leio>	Calchan: that was directed to scarabeus, same meaning what you said
-21:17:25 <Calchan>	ulm, that's also my opinion for the ballot, as for voting yeah, I think some are wrong or don't make sense
-21:17:27 <scarabeus>	keep them all indeed, if we can see how they can break transparency devs are smart enough too
-21:17:30 <solar>	3 & 4 are fine.
-21:18:06 <Calchan>	ok, so let's make it simpler: anybody against having all these on the ballot, and if so which one?
-21:18:33 <Calchan>	I'm ok with all of them on the ballot, scarabeus and ulm too it seems, others?
-21:18:33 <solar>	"- There should be no vote by email." imo should not be there
-21:19:22 <leio>	I don't think the option for developers to choose to keep the status quo should be removed from the ballot
-21:19:27 <Calchan>	solar, I agree that it may be stupid, but some think we should only vote on meetings, thus I put it on the ballot draft, vote will sort them out
-21:20:01 <Calchan>	so solar you're against 1 and 5 or just 1?
-21:20:01 <solar>	we are not required to vote via IRC. Only to hold a monthly meeting
-21:20:40 <solar>	giving ppl the option to choose on something we already decided on seems silly.
-21:20:57 <Calchan>	solar, what we're required to do now and what we'll do in the future based on devs wishes are different things
-21:21:04 <solar>	and as Betelgeuse pointed out there is a webapp in development.
-21:21:39 <Calchan>	Betelgeuse, can you associate the webapp with any of these choices or do you want to add another one for it?
-21:21:51 <scarabeus>	me would like webapp that would make things more fluent
-21:21:55 <Betelgeuse>	Calchan: It should talk about voting during a meeting and outside it.
-21:22:20 <Calchan>	Betelgeuse, OK, so am I understanding in think this is orthogonal?
-21:22:30 <scarabeus>	also i would maybe prefer votes to be anonymous and displayed after we voted, so we cant theoreticaly affect each other :] at least most governments does it that way... :]
-21:22:43 <Betelgeuse>	scarabeus: the web application can do that
-21:23:11 <Calchan>	I still need an answetr for the ballot from Betelgeuse solar and leio
-21:23:42 <Betelgeuse>	Calchan: put everything suggested there
-21:23:51 <Calchan>	Betelgeuse, ok
-21:23:59 <Calchan>	so we have a majority for keeping them all
-21:24:02 <Calchan>	next
-21:24:11 <solar>	what answer do you need from me?
-21:24:14 <leio>	Is the ballot going to be condorcet of each of these, so developers can put a preference list of all these?
-21:24:31 <Calchan>	leio, most probably yes, but we'll discuss that inthe second part
-21:24:46 <Calchan>	second topic: http://archives.gentoo.org/gentoo-project/msg_76311b25ccb18fff4764955db55ad0ea.xml
-21:25:20 <leio>	I don't think any of the options present allow to replace e-mail with webapp, but that's also somewhat covered next in regards to who and how the rules can be changed later
-21:25:33 <leio>	(re: first topic)
-21:25:44 <Betelgeuse>	I wouldn't hardcode any media.
-21:26:20 <Calchan>	so there's 3 main ideas here
-21:27:13 <ulm>	Calchan: can you add a point without any glep?
-21:27:16 <Calchan>	keep the text as a glep, make it as some sort of consitution to make it clear that council can't change it (unlike gleps), or split it so that it's easy for us to update practical aspects of how council works
-21:27:23 <scarabeus>	ulm: there is, the last one
-21:27:35 <Calchan>	ulm, right I forgot that one
-21:27:40 <ulm>	scarabeus: not really
-21:27:48 <scarabeus>	ulm: disregard that, i now read it once again
-21:28:22 <ulm>	IMO this vote is beyond the scope of a glep, and I don't konw why it was a glep before
-21:28:26 <Calchan>	indeed, thare should be one item which says (or something along this): The new text should be a "constitution"
-21:28:27 <ulm>	*know
-21:28:29 <Calchan>	(anybody feel free to propose a better word here) which can only be
-21:28:34 <Calchan>	updated with an all developer vote
-21:28:56 <Calchan>	I'll add that, thanks ulm
-21:29:09 <Calchan>	anybody else with a comment about this ballot?
-21:29:48 <Calchan>	let's switch to the next one then: http://archives.gentoo.org/gentoo-project/msg_6009db554b00ae9de67047206c7698be.xml
-21:30:36 <Calchan>	depending on how people interpret glep 39 the current situation is either 1 or 3, and I comment in the summary that I'm not sure 3 makes sense
-21:30:52 <Calchan>	that's one of those I'm particularly intersted in your opinion
-21:31:10 <ulm>	it's all very vague
-21:31:45 <scarabeus>	we should be 2 or 4 if we have time :P, but its all really not well worded
-21:31:55 <scarabeus>	it does not state exact powers and capabilities
-21:32:00 <Calchan>	ulm, indeed, but unfortunately it's hard to draw the line for this kind of matter, any better idea?
-21:32:25 <Calchan>	scarabeus, again it's not about what the result should be but about the choices we suggest to devs for the vote
-21:32:55 <ulm>	"the council only reacts to requests from developers" doesn't make much sense, because council members are developers too ;)
-21:32:55 <scarabeus>	thats why i put the smiley there, second part of my sentence is important :]
-21:32:59 <Calchan>	does it make sense to have on the ballot the possibility of a council responsible for being proactive but with rather limited powers?
-21:33:24 <dertobi123>	if people want it that way ...
-21:33:37 <Betelgeuse>	Calchan: possible new option: Each council should set its mode of operation after being elected.
-21:34:11 <Calchan>	Betelgeuse, I'll add that to the list
-21:34:19 -->	chithead (~chithead@gentoo/developer/chithanh) has joined #gentoo-council
-21:34:20 <Calchan>	if nobody is against it
-21:34:29 <solar>	no objections
-21:34:55 <Calchan>	Betelgeuse, do we want it with and without the trustees thing? I'd say yes to both
-21:35:24 <Betelgeuse>	Calchan: The trustee option could be a separate vote
-21:35:45 <Calchan>	Betelgeuse, indeed, with this many choices it would make it simple, let's do that
-21:35:56 <Calchan>	I'll update the ballot on the list
-21:36:16 <Calchan>	are we ok with this one? any more comments?
-21:37:09 <Calchan>	ok, next one then: http://archives.gentoo.org/gentoo-project/msg_3806fe4e42dc8ce013e247a081e3d4a0.xml
-21:37:29 <Calchan>	I know solar might have things to say about this one
-21:38:17 <Calchan>	so, anybody objects to any of this?
-21:38:35 <scarabeus>	it corners all cases for devs to vote upon
-21:39:09 <Calchan>	scarabeus, ok, so at least from this point of view we should be covered
-21:39:11 <--	comprookie2000 has quit (Quit: Heading home)
-21:39:47 <Calchan>	solar and I discussed yesterday about some like number not being pertinent, does anybody else think this way?
-21:40:02 <solar>	- Unlike other projects the council does not need a lead.
-21:40:11 <solar>	that is what I agree with.
-21:40:14 <scarabeus>	expect i think it is bad idea having the 3rd option, really that one should not be even thinked upon
-21:41:12 <Calchan>	scarabeus, it's similar the way devrel operates for example, the lead can break ties which avoids the possibility of procrastinating on decisions
-21:41:46 <scarabeus>	well that is why there is 7 of us
-21:41:52 <scarabeus>	not 6 or 8
-21:41:53 <scarabeus>	:]
-21:42:03 <Calchan>	scarabeus, but someone could be missing
-21:42:27 <Calchan>	or we could be in the process of re-electing a new member, which happened
-21:42:44 <scarabeus>	ok
-21:43:34 <Calchan>	so, apart from solar who (it seems) would like to remove all but number one, anybody else wnats to remove any of these propositions?
-21:44:03 <ulm>	I agree with solar on this one
-21:44:33 <dertobi123>	i agree with solar, too ... but again, every proposed item should be added to the ballot
-21:45:05 <Calchan>	ulm, dertobi123, so are you against having those on the ballot? please be explicit
-21:45:26 <scarabeus>	we dont like idea of having lead, yet we respect devs that they want to vote about it themselves
-21:45:30 <solar>	dertobi123 was pretty explicit
-21:46:13 <Calchan>	solar, actually no, he says he doens't want them in the ballot and that he does want them in the ballot in the same sentence
-21:46:22 <Calchan>	Betelgeuse, scarabeus ?
-21:46:46 <Betelgeuse>	Calchan: anything goes, the more options the better
-21:47:00 <dertobi123>	Calchan: jesus ..... i agree with solar, that the council doesn't need a lead. but once again, every proposed item should be added to the ballot.
-21:47:06 <dertobi123>	that's explicit enough?
-21:47:13 <Calchan>	Betelgeuse, dertobi123, ok thanks
-21:47:43 <Calchan>	and I'm for leaving those options to devs too so we have a majority
-21:48:02 <Calchan>	anybody with anyhting to add before we switch to the second part?
-21:48:05 <leio>	same as Calchan for me
-21:48:54 <Calchan>	ok, then: 3. Scheduling and voting issues (20 minutes)
-21:49:11 <Calchan>	so here's the issue
-21:49:29 <Calchan>	devs will likely want to vote on the final text so that leaves us with 2 votes
-21:49:32 <leio>	nothing regarding the second part (how lead is elected if a lead is chosen in the vote)?
-21:49:45 <Calchan>	leio, oh sorry
-21:49:54 <Calchan>	so guys go ahead with that
-21:50:14 <leio>	I have nothing (like objections or whatnot) on it though
-21:50:19 <Calchan>	obviously that question applies only if some for of lead is decided to the previous question
-21:50:31 <solar>	this is a waste of my time
-21:50:40 <dertobi123>	solar++
-21:51:01 <Calchan>	solar, dertobi123 feel free to leave the meeting now, you don't have to stay
-21:51:18 <solar>	I'm looking for a proxy for the rest of the council.
-21:51:45 <solar>	my term. If any dev plans to run next year and you don't suck. let me know so I can make you my proxy
-21:52:17 <Calchan>	ok, back to 3. Scheduling and voting issues (20 minutes)
-21:52:35 <Calchan>	devs will likely want to vote on the final text so that leaves us with 2 votes
-21:52:48 <Calchan>	and that the schedule will be tight for that before the next election
-21:53:24 <Calchan>	so one question is: do we want to do everything possible to be done before the next election, or we want to take whatever time it takes to do it
-21:53:44 <dertobi123>	well, what solar said ... basically the same for me, especially the "if you don't suck" part ...
-21:54:19 <scarabeus>	we should not rush things before the end of our "time"
-21:54:28 <ulm>	scarabeus++
-21:54:35 <ulm>	we're not in such a hurry
-21:54:36 <dertobi123>	Calchan: such important things shouldn't be waived through in about some weeks or so ... so it's not practically doable to do "the right way" when rushing things through
-21:54:46 <dertobi123>	+it
-21:54:58 <Calchan>	scarabeus, at first I though it would have been nice to finish before the end of our term, but I think more and more it will be impossible without rushing it
-21:55:14 <Calchan>	dertobi123, agreed here
-21:55:45 <ulm>	Calchan: there should be enough time for discussion on MLs
-21:55:47 <scarabeus>	i think it will be impossible. and we should not push through something half baked on such important topic
-21:56:17 <leio>	has the discussion in mailing lists been going on for enough and is quieting down?
-21:56:26 <Calchan>	so we have dertobi123 scarabeus ulm and me for doing it right and not rushing it
-21:56:38 <Betelgeuse>	no hurry for me either
-21:56:38 <leio>	I'm with not rushing too
-21:56:42 <scarabeus>	come on, everyone will say that
-21:56:47 <Betelgeuse>	the current GLEP doesn't really impede that much
-21:56:51 <Calchan>	leio, yes, no progress in like a couple weeks, but not a good neough reason to stop it there
-21:57:45 <leio>	I think if we get somewhere with this from a well timed vote, then after this is in effect we don't need to wait for the whole year of the next term
-21:57:59 <Calchan>	another point raised on the ml is we could vote on that (and I'm guessing it's only for the first part, i.e. voting on all the propositions) on the forums instead
-21:58:04 -->	darkside_ (~darkside@gentoo/developer/darkside) has joined #gentoo-council
-21:58:19 <Calchan>	and frankly I don't like that much
-21:58:37 <leio>	and I have not been participating in any discussion as I didn't even notice any was going on, as I admit to not having been subscribed to gentoo-project. I imagine many other developers aren't as well (there was a dev-announce starter though).
-21:58:56 <scarabeus>	maybe migrate to -core
-21:58:59 <scarabeus>	everyone will get the mail
-21:59:03 <Calchan>	leio, I sent a tracker to dev-announce
-21:59:23 <Calchan>	scarabeus, no point to hide that in core, not what it's intended for
-21:59:42 <scarabeus>	well i didnt want to hide it
-21:59:48 <Betelgeuse>	If someone doesn't read -dev-announce that's their problem
-21:59:49 <scarabeus>	that is only list every dev is getting
-21:59:50 <Calchan>	leio, but that's ok, it's always time to jump in the discussions
-21:59:57 <scarabeus>	but yea Peteri is right
-22:00:01 <Calchan>	scarabeus, no
-22:00:01 <scarabeus>	people should read d-a
-22:00:10 <--	blueness has quit (Quit: Ex-Chat)
-22:00:17 <Calchan>	scarabeus, devs *have* to be subscribed to -dev-announce
-22:00:42 <Betelgeuse>	scarabeus: you're better off with Betelgeuse (it's Petteri)
-22:00:53 <Calchan>	so, about voting on forums?
-22:01:13 <Betelgeuse>	It's easier to write with tab too :)
-22:01:14 <ulm>	Calchan: forums would imply voting by non-devs?
-22:01:21 <Calchan>	ulm, indeed
-22:01:22 <leio>	yeah, we'll just assume the discussion will be happening in a mailing list that we aren't subscribed to, instead of thinking there's silence, based on the To and Reply-To being something and we look closely at that to know that we are missing a subscription :)
-22:01:32 <ulm>	Calchan: doesn't make sense to me
-22:01:41 <scarabeus>	Betelgeuse: i tried, somehow quassel didnt complete so Petteri is shorter if you write it out :P
-22:01:49 <dertobi123>	can we please get proposals for topic #3 for the next meeting? or on the council mailinglist ... that's kinda pointless do start a discussion now and here
-22:02:31 <Calchan>	dertobi123, ok, no emergency on that
-22:02:58 <dertobi123>	ulm: btw. there's a forum restricted to developers, but i guess not every developer has an account on f.g.o
-22:03:15 <Betelgeuse>	I think forums have any added benefit.
-22:03:21 <Betelgeuse>	+don't
-22:03:36 <Calchan>	anything else to add to this before we move on?
-22:03:54 -->	jsbronder (~jsbronder@gentoo/developer/jsbronder) has joined #gentoo-council
-22:04:22 <Calchan>	ok then
-22:04:24 <--	billie has quit (Remote host closed the connection)
-22:04:29 <Calchan>	4.1 Action list. Who does what and when?
-22:04:53 <Calchan>	I will update the propositions and prepare the ballot list
-22:05:31 <Calchan>	4.2 Who takes care of the summary and log for this meeting? When?
-22:05:46 <Betelgeuse>	I have exams for this week so rather not.
-22:06:04 <Calchan>	I can do it, or maybe we can ask tanderson
-22:06:16 <leio>	raw log, me as usual, before next sleep
-22:06:24 <Calchan>	anybody opposed to him doing the summaries btw?
-22:06:34 -->	ABCD (~abcd@gentoo/developer/abcd) has joined #gentoo-council
-22:06:59 <Calchan>	ok, so I'll see with him whetehr he wants to do it, if not I'll do it
-22:07:03 <Calchan>	4.3 Next meeting date/time.
-22:07:28 <Calchan>	how's june 14th for what should be our last meeting?
-22:07:32 <leio>	when is our term ending exactly?
-22:07:57 <Betelgeuse>	should work for me
-22:07:59 <Calchan>	leio, I'd say late june early july
-22:08:02 <jmbsvicetto>	According to http://archives.gentoo.org/gentoo-dev-announce/msg_20ba6ea38ae349fc57470bd8a78f4b5f.xml it should end at the end of June / early July
-22:08:26 <NeddySeagoon>	jmbsvicetto, so the election process shuold have started
-22:08:48 <Calchan>	NeddySeagoon, or soon will, are we late already?
-22:08:53 <jmbsvicetto>	NeddySeagoon: no
-22:08:55 <dertobi123>	NeddySeagoon: election process should start in early in june
-22:09:02 <jmbsvicetto>	It should start around June 1st
-22:09:20 <jmbsvicetto>	2 weeks nomination + 2 weeks voting
-22:09:28 <NeddySeagoon>	ok
-22:09:47 <dertobi123>	anyways, june 14th should work for my last council meeting, just in case i don't find a proxy
-22:09:49 <jmbsvicetto>	with 1 or 2 days in between - depends on how much time the infra contact require to setup the election
-22:10:15 <Calchan>	Betelgeuse, dertobi123 and I are available on june 14th, how about the others?
-22:10:20 <leio>	fine
-22:10:30 <Calchan>	dertobi123, not much usually happens on the last meeting though
-22:10:45 <ulm>	fine with me too
-22:10:57 <scarabeus>	works ok
-22:11:10 <dertobi123>	Calchan: we'll see ... already today and for quite some time nothing happened ... so that's quite ok for me.
-22:11:51 <Calchan>	ok, for the 14th then
-22:12:01 <Calchan>	who does the agenda?
-22:12:05 <Calchan>	any volunteers?
-22:13:17 <Calchan>	sigh, I'll do it then
-22:13:28 <Calchan>	5. Open floor
-22:13:33 <jmbsvicetto>	Calchan / dertobi123: We'll be ready for any ideas about a "Coup d'état" ;-)
-22:13:38 <Calchan>	thanks all for your participation
-22:13:56 <Calchan>	jmbsvicetto, meh?
-22:13:58 <jmbsvicetto>	We shouldn't be trying to rush a voting about GLEP39 "reform"
-22:14:08 <dertobi123>	jmbsvicetto: lol ;)
-22:14:13 <jmbsvicetto>	Calchan: about the "quiet" last meeting ;)
-22:14:57 <dertobi123>	all glep39 stuff should be voted on by all developers, so they should've the options they want - nothing to rush a vote on in the next meeting
-22:15:26 <Calchan>	jmbsvicetto, the "quiet" last meeting wsn't organized by me so I'll abstain from criticizing (in the goold old "do it or shut up" fashion)
-22:15:31 <leio>	we weren't creating ballots for our next meeting vote, but for a vote to be done by all developers
-22:15:48 <jmbsvicetto>	yes, but we should first establish some agreements
-22:16:17 <jmbsvicetto>	leio: yes, but that's too early
-22:16:39 <leio>	jmbsvicetto: I don't necessarily disagree that, clarifying dertobi123
-22:16:44 <leio>	with that*
-22:16:45 <jmbsvicetto>	there haven't been concrete proposals yet. People were talking about general concepts before Calchan did the summaries
-22:16:51 <jmbsvicetto>	ok
-22:18:05 <jmbsvicetto>	Calchan: I was joking about your (council members) expectation that the last meeting of your term would be "quiet"
-22:21:14 -->	billie (~billie@gentoo/developer/billie) has joined #gentoo-council
-22:24:59 <leio>	anything else for the open floor?
-22:25:19 <--	darkside_ (~darkside@gentoo/developer/darkside) has left #gentoo-council
-22:25:28 <dertobi123>	guess not
-22:25:34 <leio>	I hope that developers will comment on the summaries too with further stuff then
-22:31:04 <jmbsvicetto>	leio: I'll take further comments to the project ml
-22:32:40 <leio>	ok, I'll consider this the cut point for raw log then, meeting done unless todays chair says otherwise and I cut from later :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100614-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100614-summary.txt
deleted file mode 100644
index e2f6bdcaef..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100614-summary.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Gentoo Council 2010-06-14 meeting agenda / summary:
-
-role call:
- ferringb proxying for solar
- wired proxying for scarabeus
- ulm was missing
-
-No agenda set
-
-REQUIRED_USE eapi addition:
- - http://dev.gentoo.org/~ferringb/required-use.html
- - voting delayed till next council to ensure everyone knew the details
-
-attempted post mortem discussion for the outgoing council's term:
- - primarily discussion, no real recommendations/resolutions
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100614.txt b/xml/htdocs/proj/en/council/meeting-logs/20100614.txt
deleted file mode 100644
index 67da66f5d4..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100614.txt
+++ /dev/null
@@ -1,185 +0,0 @@
-21:01:07 <Betelgeuse> let's start
-21:01:10 <dertobi123> so, let's go
-21:01:13 <dertobi123> who's around?
-21:01:25 <Calchan> I am
-21:01:35 -*- dertobi123 is, obviously
-21:01:47 -*- wired here, proxying for scarabeus 
-21:02:15 <dertobi123> wired: funny, scarabeus didn't sent an email about you being his proxy for today
-21:02:30 <wired> he said so here a while back
-21:03:40 <Betelgeuse> 15:19  * scarabeus not sure if i will make it here, asked wired to proxy me
-21:03:44 <wired> [18:19:47] * scarabeus not sure if i will make it here, asked wired to proxy me
-21:04:29 <dertobi123> whatever, it doesn't matter for todays non-meeting
-21:05:44 <ferringb> so... no one assembling an agenda/request for err.. requests, means nothing happens, or...
-21:06:15 <Calchan> I spent a lot of time and effort last month putting together an agenda and a meeting that some of you said was a waste of your time
-21:06:15 <Betelgeuse> ferringb: we can still vote on issues but members might be vary on voting on something they know little about
-21:06:23 <Calchan> so I certainly wasn't going to waste any more of your time again this month
-21:06:45 <Calchan> and it demonstrates yet again that if I don't do it then nothing happens
-21:07:09 -*- dertobi123 sighs
-21:07:14 <ferringb> Calchan: don't suppose you've been maintaining a list of things that didn't make it into a specific council meeting?
-21:07:15 <Betelgeuse> so missing leio, ulm ?
-21:07:18 <ferringb> aka, a backlog?
-21:07:29 <leio> I'm here
-21:09:23 <Betelgeuse> was this our last meeting?
-21:10:06 <dertobi123> this is our last one, yes
-21:10:51 <Betelgeuse> Not having an agenda is quite fitting for the year.
-21:11:12 -*- ferringb sighs
-21:11:20 <Betelgeuse> Hopefully the webapp helps the next council
-21:11:20 <tove> you can meet again in two weeks
-21:11:24 <ferringb> yep
-21:11:27 <Betelgeuse> tove: true
-21:11:30 -*- ferringb notes there are two things still outstanding
-21:11:43 <ferringb> one is Arfrever's request, although I've indicated my views why it's not ready
-21:12:05 <ferringb> there is also REQUIRED_USE that's been sitting for a few months now
-21:12:35 <dertobi123> well, none of these items has been submitted to the council
-21:12:47 <Betelgeuse> dertobi123: that latter has
-21:12:49 <ferringb> dertobi123: check your logs.  REQUIRED_USE sure as hell was.
-21:13:01 -*- ferringb notes that discussing something shouldn't require red tape either
-21:13:11 <Betelgeuse> It's been our failure that it wasn't in the last meeting
-21:13:28 <dertobi123> ferringb: sorry
-21:13:44 <Betelgeuse> For Arfrever's request I propose we vote on whether it requires more work:
-21:13:47 <Betelgeuse> I vote yes
-21:13:54 <dertobi123> yes, too ... (of course)
-21:14:14 <leio> uh, abstain
-21:14:29 <Betelgeuse> leio: ?
-21:14:36 <ferringb> spoke my views.  not opposed to the change (there are other USE syntax changes I'd like for example), but this needs to be done in a way that doesn't cause PMS compliant managers to go boom.  Needs work.
-21:15:01 <leio> from voting on that, I don't know if it requires more work or not.
-21:15:01 <Betelgeuse> leio: did you read the logs little before the meeting?
-21:15:21 <leio> I think so
-21:16:21 <Betelgeuse> wired, Calchan ?
-21:18:42 <ferringb> additional item that likely is worth discussing; since this is the last meeting, a post mortem of the last year is likely wise, in terms of what worked, what didn't.
-21:19:22 <leio> everyone expecting someone else from the council to do certain council work tasks does not work
-21:20:07 <wired> abstain, but from a quick read of the bug this does seem to need more work
-21:21:30 <Betelgeuse> ferringb: reading your GLEP again what comes to mind is it shouldn't it reserve a cache key?
-21:21:47 <ferringb> should, yes
-21:22:00 <ferringb> s/should/must/ realistically, from a performance standpoint
-21:22:17 <ferringb> http://dev.gentoo.org/~ferringb/required-use.html <-- for people who've not read it.  think we've demonstrated we have time, so go read it if you've not
-21:23:32 <ferringb> Betelgeuse: good question though, hadn't thought to clarify in there.  currently there is still space left in the flat_list format, so that's not an issue to expand into one of the slots
-21:24:06 <Betelgeuse> ferringb: yes but ideally the GLEP would specify the slot number
-21:24:24 <ferringb> Betelgeuse: ideally PMS would, but yes
-21:25:06 <ferringb> Betelgeuse: to nail down the exact slot for it requires rechecking what portage jammed in there.  PROPERTIES iirc got slapped in there (without PMS updating afaik), so the enumeration in the spec needs updating either way
-21:25:30 <ferringb> tbh, I consider that something of an implementation detail, but yes, for the resultant PMS patch the slotting should be explicitly locked.
-21:27:50 <ferringb> leio: wired: comments?
-21:27:56 <ferringb> dertobi123: Calchan: y'all?
-21:28:19 <leio> ferringb: nope, but I'll take a portage patch :)
-21:28:32 <ferringb> read the glep.  a patch already exists.
-21:28:47 <leio> stop referring to it as a glep :)
-21:28:49 <ferringb> under the implementation section specifically, sebastian luther implemented it
-21:29:01 <ferringb> s/glep/text/ whatever.  point is, the doc covers this already
-21:29:40 <dertobi123> ferringb: no comments, looks good to me.
-21:29:49 <dertobi123> though ^^ looks rather funny
-21:29:58 <dertobi123> but that's just a detail
-21:30:04 <ferringb> ^.^ was my first preference.
-21:30:08 <dertobi123> heh
-21:30:11 <wired> ferringb: id like to see that in portage asap :)
-21:30:19 <ferringb> switching it to voting specifically
-21:30:28 <leio> while we don't have this, pkg_pretend had issues doing this in a temporary fashion?
-21:31:12 <Betelgeuse> leio: see motivation?
-21:31:19 <ferringb> already covered.
-21:32:12 <ferringb> expounding a bit... there is no 'temporary' in EAPI.  once it's there, it's there till we start stating xyz EAPI's are no longer supported (I don't expect that for at least a half decade either, if that).  once it's in, it screws up doing this properly long term
-21:32:17 <leio> yeah, wish Calchan made an agenda as volunteered in lack of others :)
-21:33:28 <Betelgeuse> ferringb: well that's not obsoleting pkg_pretend
-21:33:29 <leio> so not optimal, but temporarily possible to achieve something better than current with pkg_pretend too
-21:34:13 <ferringb> leio: no... pkg_pretend is added in eapi4.  this doc modifies eapi4 (which isn't released so we can pull this) to fix a flaw in using pkg_pretend for use validation like this.
-21:34:21 <leio> I'm hoping for some markup to express that a USE flag takes effect only in case some other one is enabled
-21:34:37 <ferringb> no REQUIRED_USE, you have to use pkg_pretend, and you suffer the issues laid out in motiviation.  this is why it needs fixing before eapi4 goes live.
-21:34:44 <leio> would this fit in the syntax style somewhere too? :P
-21:35:43 <ferringb> currently it's limited to just this new metadata key.  if someone wants to use ^^ elsewhere, they need to put forth a proposal (solar has some notions, but nothing concrete last I knew)
-21:36:16 <leio> same syntax like that but in IUSE could be expressing what I have in mind?
-21:36:51 <ferringb> no
-21:37:27 <leio> anyway, lets discuss this additional feature later in private perhaps.
-21:37:27 <ferringb> IUSE is an enumeration.  you'd have to combine effectively a tree syntax in w/ an enumeration... it's not pretty to even try it (have, hence the seperate key)
-21:38:04 <leio> just hoping that once all these new syntax features get added, that they all fit in consistently
-21:38:19 <ferringb> wired: dertobi123: fine with this, and moving on to post mortem?
-21:38:33 <ferringb> Calchan: your thoughts?  you've been fairly quiet
-21:40:05 <wired> ferringb: yeah
-21:40:34 -*- dertobi123 nods
-21:41:16 <ferringb> good enough.  at this point since there is logging, might as well start laying out the perceived/outstanding issues w/ the council over the last year... what went wrong, what can be improved, what went right, etc.
-21:41:35 <ferringb> standard post mortem (if you've not participated in one of these just pm and I'll go through details)
-21:41:40 <ferringb> sound good?
-21:42:43 <Betelgeuse> yes
-21:44:00 <Betelgeuse> I think this council suffered from the usual lack of "drive"
-21:44:20 <Betelgeuse> People do show up but effective work would require plenty of hours outside meetings
-21:44:21 <ferringb> Betelgeuse: lack of drive, or burnout?
-21:45:21 <Betelgeuse> It tells quite a lot that our last to summaries are "To be completed"
-21:45:26 <ferringb> yep
-21:45:28 <Betelgeuse> s/to/two/
-21:45:35 <dertobi123> well, from my pov ... this council was way too passive. we merely just discussed some eapi/pms stuff and became tired while doing so. personally i somehow lost interessed in gentoo and several other things became much more important for me. i should've stepped back from the council half a year ago or so - but seeing who'd take my seat i decided to fullfill my term.
-21:45:49 <ferringb> Betelgeuse: think making the council's term 6 months would be good?
-21:46:13 <ferringb> dertobi123: your thoughts on 6 months?
-21:46:28 <wired> id like to see the council be more decisive
-21:46:59 <Betelgeuse> ferringb: if there's a big shift in membership it might be hard to get things done
-21:47:08 -*- ferringb notes the purpose of a post mortem, while including wishes/desires for going forward, should also be looking at specific failures in the past to identify/ensure they don't occur again
-21:47:12 <dertobi123> ferringb: ambivalent ... might help, but it might be useful to shorten nomination and election periods then, too
-21:47:18 <ferringb> Betelgeuse: things aren't really getting done however.
-21:47:19 <dertobi123> we should give it a try
-21:47:32 <ferringb> Betelgeuse: faster cycle at least means that if people want out, they can bow out quicker.
-21:47:47 <Betelgeuse> ferringb: I would hope if people loose interest that they drop out voluntarily
-21:48:07 <ferringb> Betelgeuse: not guranteed.  as mentioned by dertobi123, knowing the competition, sometimes they hold on.
-21:48:08 <Betelgeuse> Current rules still state that the council has to approve the next one in line
-21:48:42 <ferringb> dertobi123: with respect mind you, but my stance is if there isn't interest, then one needs to let the next dude in line handle it... even if they're a schmuck (someone has to do the work one way or another)
-21:49:03 <ferringb> Betelgeuse: re: disruption, staggered seat elections comes to mind btw to combat that.
-21:49:24 <Betelgeuse> ferringb: we do keep those if council doesn't approve and it has already happened
-21:49:32 <Betelgeuse> happened this term already I think
-21:50:06 -*- ferringb means that 2/7 memebers have their terms for feb->feb, 2/7 have it for sept->sept, and the 7th lands wherever (under a year term)
-21:50:11 <ferringb> *members, pardon.
-21:50:28 <ferringb> either way... other failings/issues from the past year?
-21:50:55 <ferringb> wired: "be more decisive" is a bit vague.  specifics/examples would be useful here- post mortem should be specific failings rather than "I'd like us to be more xyz" if at all possible
-21:52:32 <dertobi123> ferringb: there was interest, i just didn't worked an hour or two a day on gentoo - just like i did a year or two ago. that's what i tried to express with "lost interest".
-21:53:08 <ferringb> dertobi123: fair enough.  as said, wasn't trying to pick at you specifically, more looking at the general problem that can arise there
-21:54:40 <ferringb> dertobi123: any thoughts on how to help w/ that?  realistically the council does have a semi-hefty req on one's time
-21:54:52 <wired> ferringb: a few months back i proxied for leio at a meeting where nothing was decided, no-one had read the agenta items enough and everything was postponed. i don't blame people for not having enough time to spend for the council, but in my eyes the council should be a swift body, quickly resolving things devs can't
-21:55:09 <ferringb> similar views for myself
-21:55:34 <ferringb> so why is it slow?  ignoring people not reading shit (can't do anything about that aside from come election time)
-21:55:54 <dertobi123> well, i was prepared (i.e. reading the agenda and related topics/gleps) every meeting i attended
-21:56:05 <dertobi123> but that doesn't matter at all now
-21:56:22 <ferringb> "doesn't matter at all now" howso?
-21:56:58 <wired> im not pointing fingers here and my experience doesn't mean that you hadn't done your studing, but the result was the same, a month went by without anything getting done
-21:57:32 -*- ferringb notes the point of a post mortem here is to not care about who did what.  it's to ensure that next time around, these issues don't re-occur
-21:58:08 <dertobi123> ferringb: as in "it doesn't matter if i was prepared, if in the end the result was to just postpone things"
-21:58:14 <ferringb> ah, right
-21:58:32 <ferringb> dertobi123: any thoughts on how to keep the council body from continually postponing things?
-21:58:48 <wired> i also feel that the council is kind-of afraid to take big decisions
-21:58:51 <Betelgeuse> ferringb: you need a member actively pushing things to avote
-21:58:53 <NeddySeagoon> council meetings should mostly be a dog and pony show - making decisions public and explaining the reasoning. There should be very little discussion.  Its an opportunity for the council to be held to account by the voters
-21:59:25 <Betelgeuse> ferringb: I get annoyed many times when actual votes don't happen in meetings
-21:59:37 <Betelgeuse> ferringb: We could try a no major discussion rule
-21:59:48 <Betelgeuse> ferringb: Get together every two weeks
-21:59:49 <NeddySeagoon> Betelgeuse, votes can happen before meetings
-21:59:56 <wired> i'd like to see members just vote for things as they see fit, instead of postponing.
-21:59:56 <Betelgeuse> discuss and vote separately
-22:00:04 <dertobi123> ferringb: there two importants points ... having a secretary tracking things and looking for things to get done. the other one is people who submitted things to actively ask what the status is and remember to add things to the agenda if something got lost
-22:00:07 <ferringb> Betelgeuse: every two weeks is something I've been after for a while, although the "no major discussion rule" I don't totally agree with.
-22:00:17 <wired> perhaps there should be a rule that when something is brought up for voting, it must be resolved
-22:00:38 <ferringb> wired: "postponed" is a resolved
-22:01:17 <dertobi123> not only the council was quite passive, also requests from the developer body were quite rare ... if you want to get things done and/or decieded by the council, mailing them via council@g.o is the way to go atm - but not that many people used that. i'm pretty sure lots of interesting stuff got lost on gentoo-dev@g.o
-22:01:38 <leio> I typically don't see any outside meeting discussions initiated either, in some cases there are gentoo-dev threads, which die
-22:02:14 <dertobi123> and having items where discussions start within a meeting lead to people looking unprepared and not being able to decide something
-22:02:56 <ferringb> from my perspective, there were dev requests
-22:03:06 <dertobi123> so in the end it's not the council who failed somehow, but also our developer body
-22:03:18 <ferringb> just very, very rarely did the council pick them up and run with them.  if it occured at all, it was typically either ulm or calchan proxying it into their realm of awareness
-22:03:35 <ferringb> dertobi123: my personal view, but the council should be actively engaging the dev body
-22:03:54 <ferringb> I'm not sure if others agree with that however
-22:04:26 <dertobi123> ferringb: probably none (or just a few) of the devs did mail those requests to council@g.o
-22:04:30 <ferringb> point is, from my view the council should be doing more than just "it's that time of the month" emails and sifting through the results- actively tracking what was requested, notifying why it was punted, etc.
-22:04:47 <ferringb> well, if the request for discussion goes to *dev*, it's not particularly surprising, no?
-22:04:48 <dertobi123> discussing things on irc or via mail doesn't automatically put this things on the council's agenda
-22:05:36 <ferringb> dertobi123: actually, it should.
-22:05:54 <ferringb> not even should, it kind of must considering the emails sent to dev.  one second.
-22:06:25 <ferringb> http://www.gossamer-threads.com/lists/gentoo/dev/210446#210446
-22:06:29 <wired> i agree with ferringb here, council members are devs, i'd like to see them filter through the dev mail and take decisions without someone explicitly requesting it when devs cant reach a decision themselves
-22:07:05 <ferringb> emails of that sort have been going to dev since day one, and very, very little of what people request on those threads ever makes it into the council's purview.  if those email threads won't be watched by the folk requesting discussion topics, the emails need to stop.
-22:07:31 <ferringb> explicit requests need addressing (even if it's a statement of "piss off you wanker").  implicit would be nice, but explicit isn't even working.
-22:07:41 <wired> i also think that the 6 month term is a nice idea, with meetings closer to each other
-22:08:28 <ferringb> any council members got other issues they'd like to bring up?
-22:08:36 -*- ferringb notes right now it's mostly the proxies speaking
-22:08:50 <dertobi123> we don't have different opinions here - i described how the council worked until now, it's your chance to make the council more active
-22:09:10 <ferringb> yeah, pardon- you're right.
-22:09:17 <ferringb> dertobi123: other issues/comments?
-22:10:12 <ferringb> brb
-22:11:36 <Betelgeuse> ferringb: nope
-22:11:48 <Betelgeuse> the webapp back log is open for ideas as usual
-22:12:14 <dertobi123> no ... just one thing, i'd like to see a more (pro-)active council being elected and from my pov it would help to get a fresh council started with new and fresh people. no offense, but imho everyone should be able to be member of two councils and then have take a break.
-22:12:33 *** Mode #gentoo-council -o dertobi123 by dertobi123
-22:14:04 <-> dabbott|afk is now known as dabbott
-22:14:05 <leio> I think for the whole council to be (pro-)active all individual members need to be proactive and proactively discuss things in this channel and elsewhere with others, so that there isn't one or a couple doing that, others missing drive, and then remaining getting a burnout
-22:17:28 <Betelgeuse> I need to go. Thanks for the year and let's see who show up next month.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100714-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100714-summary.txt
deleted file mode 100644
index c7a3b5f907..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100714-summary.txt
+++ /dev/null
@@ -1,99 +0,0 @@
-Gentoo Council 20100714 meeting goals:
-
-      * have the first public meeting of the new council
-      * set some base rules for the operation of the new council
-      * allow council members to present issues to work on this term
-      * listen to the community to check whether there are any issues it wants to bring to the attention of the council
-      * continue discussion about required-use and --as-needed to prepare a vote in the 26/7 meeting
-
-
-Gentoo Council 20100714 meeting agenda:
-
-      * allow all members to show up (5 min)
-      * select the probable date for the monthly meetings (5 min)
-      * discuss desired model of operation (15 min)
-        - using bugs to track issues
-        - have a section on all meetings to check the bugs status
-        - ability to have 2nd monthly / impromptu meetings when required
-        - secretary / meeting chair
-      * allow council members to present issues to be addressed in this term (15 min)
-      * listen to the community to see if there are any issues it would like to see the council address in this term (10 min)
-      * require-use discussion (10 min)
-      * --as-needed discussion (10 min)
-      * Any Other Business (5 min)
-
-
-Roll call:
-      * betelgeuse   here
-      * chainsaw     here
-      * ferringb     late (30 minutes)
-      * halcy0n      here
-      * jmbsvicetto  here
-      * scarabeus    here
-      * wired        here
-
-
-Gentoo Council 20100714 meeting summary:
-
-      * allow all members to show up (5 min)
-        Brian (ferringb) arrived 30 minutes late.
-
-
-      * select the probable date for the monthly meetings (5 min)
-        1900 UTC, 2nd Monday of each month
-
-
-      * discuss desired model of operation (15 min)
-
-        - using bugs to track issues
-        bugs for now (without any restrictions, fully visible and editable by any registered user)
-        rails project for council management is under development, will check that when finished
-
-        - have a section on all meetings to check the bugs status
-        discussion about bug progress should happen on each meeting.
-        each bug will have an assigned named council member that should be responsible for its tracking
-        we may use bugzilla voting capabilities if deemed useful
-
-        - ability to have 2nd monthly / impromptu meetings when required
-        there can be any number of meetings during the month, with the requirement of a minimal 1 week advance notice
-
-        - secretary / meeting chair
-        council members will replace a secretary by using google wave to create meeting summaries on the fly
-        the chair of a meeting is going to be decided at the end of the previous meeting. scarabeus volunteers to be default fallback
-        the selected chair is responsible for the initial email and the upcoming meeting agenda, as well as committing the summary of the meeting he chairs.
-
-
-      * allow council members to present issues to be addressed in this term (15 min)
-
-        Chainsaw - to kill (the official status of) overlays ; to review package maintenance policy
-        jmbsvicetto - to continue the work to review GLEP39 and Gentoo's metastructure ; to study and promote ways to allow more involvement from community
-        scarabeus - increase QA of the tree (be more strict with developers) and revive GWN
-        ferringb - make council less involved in day-to-day matters and more focused on bigger picture
-        wired - decisive and effective council
-        halcy0n - bigger QA hammer, easier and more straight rules for joining or helping out in our community
-        betelgeuse - putting GSoC results to some good use ; mostly PM stuff
-
-
-      * listen to the community to see if there are any issues it would like to see the council address in this term (10 min)
-
-        tanderson - have the council decide on proposals solely on their merit and not on the person who submits them
-
-
-      * require-use discussion (10 min)
-
-        skipped
-
-
-      * --as-needed discussion (10 min)
-
-        skipped - this issue is going to be discussed over mail and voted on next meeting. Note the word VOTE, so please raise your concerns on ML if required.
-
-
-      * chair for next meeting (will write initial email, propose agenda and commit summary)
-
-        wired
-
-
-      * Any Other Business (5 min)
-
-        none
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100714.txt b/xml/htdocs/proj/en/council/meeting-logs/20100714.txt
deleted file mode 100644
index 3d81c4c54b..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100714.txt
+++ /dev/null
@@ -1,437 +0,0 @@
-18:59 <@jmbsvicetto> ok, for reference here are 3 links about the issues to discuss:
-18:59 <@jmbsvicetto> 1. - ferringb's proposal - http://dev.gentoo.org/~ferringb/required-use.html
-19:00 <+tanderson> please make them (semi-)permament.
-19:00 <@jmbsvicetto> 2. - ferrings's initial discussion about it - http://archives.gentoo.org/gentoo-dev/msg_b0e868626019f497eba47194c34e5421.xml
-19:00 <@jmbsvicetto> 3. - last round of --as-needed discussion - http://archives.gentoo.org/gentoo-dev/msg_4d877108b67a4161eeaa5722aee7a297.xml
-19:01 <@jmbsvicetto> tanderson: we'll add them to the agenda / summary / etc
-19:01 <@jmbsvicetto> so, it's time
-19:01 <+tanderson> okay.
-19:01 <@jmbsvicetto> who are we missing?
-19:01 <@jmbsvicetto> ferringb: ping
-19:02 <@Chainsaw> Are phone numbers for ferringb available? If so, can they be used?
-19:02 <+tanderson> Chainsaw: you need a warrant :p
-19:02 <@jmbsvicetto> Gentoo warrant?
-19:02 <@jmbsvicetto> ;)
-19:02 <@Betelgeuse> jmbsvicetto: I am here.
-19:02 <@Chainsaw> jmbsvicetto: As am I.
-19:03  * scarabeus smiles around
-19:03 <@jmbsvicetto> Do we give 3 minutes for Brian to show up?
-19:03 <@wired> yeah
-19:03 < ssuominen> jmbsvicetto: since that last round of asneeded talking, we fixed last of the bugs with Xarthisius regarding having -Wl,--as-needed in LDFLAGS, 0 open bugs for that, and only 5-6 for forced asneeded
-19:04 <@jmbsvicetto> ssuominen: ok
-19:04 <@jmbsvicetto> thanks for the update
-19:04 -!- jmbsvicetto changed the topic of #gentoo-council to: congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting: 14/7 19H00 UTC - now || next meeting 26/7 19H00 UTC
-19:06 -!- jmbsvicetto changed the topic of #gentoo-council to: congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting: 14/7 19H00 UTC - now / agenda - http://dpaste.com/217481/ || next meeting 26/7 19H00 UTC
-19:06 -!- wired changed the topic of #gentoo-council to: congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting: 14/7 19H00 UTC - now - http://bit.ly/bALQMi || next meeting 26/7 19H00 UTC
-19:06 <@wired> lmao :D
-19:06 <@wired> your's is better :)
-19:06 <@jmbsvicetto> ok, we'll use yours ;)
-19:06 <@jmbsvicetto> ok
-19:06 -!- jmbsvicetto changed the topic of #gentoo-council to: congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting: 14/7 19H00 UTC - now / agenda - http://dpaste.com/217481/ || next meeting 26/7 19H00 UTC
-19:07 <@jmbsvicetto> so, if someone can reach Brian, please recall him of the meeting
-19:07 <@jmbsvicetto> shall we proceed?
-19:07 <@Betelgeuse> yes
-19:07 <@wired> yes
-19:07 <@Chainsaw> Agreed.
-19:07 <@scarabeus> yes
-19:07 <@jmbsvicetto> probable date for council meetings?
-19:08 <@jmbsvicetto> per our alias discussion, seems the best option are Mondays 19H00 UTC
-19:08 <@Chainsaw> The time works well for me.
-19:08 <@scarabeus> every 2nd monday 19H00 UTC?
-19:08 <@Chainsaw> And indeed, any weekday except Tuesday is good.
-19:08 <@jmbsvicetto> scarabeus: I like that
-19:08 <@Halcy0n> scarabeus: works for me
-19:09 <@wired> sounds good
-19:09 <@jmbsvicetto> shall we vote for it?
-19:09 <@scarabeus> jmbsvicetto: it looks like most people already said aye :]
-19:09 < dleverton> Does that change to 20H00 when DST ends?
-19:09 <@Betelgeuse> jmbsvicetto: I would rather try to find a time that suits everyone.
-19:10 <@Chainsaw> dleverton: UTC does not respect DST.
-19:10 <@jmbsvicetto> Betelgeuse: sure
-19:10 <@Chainsaw> dleverton: So yes, for most people the meeting time will shift by an hour.
-19:10 < dleverton> Yeah, but I think there's been some confusion in the past about that
-19:10 <@wired> Betelgeuse: i thought 1900 suits everyone?
-19:10 <@Betelgeuse> wired: Voting implies going by a majority.
-19:11 <@jmbsvicetto> Betelgeuse: I see there were no updates to the page :\
-19:11 <@wired> Betelgeuse: ah, you're referring to the vote suggestion :)
-19:11 <@Betelgeuse> jmbsvicetto: which page?
-19:11 <@scarabeus> the doodle page i guess
-19:11 <@jmbsvicetto> The one with the time availability
-19:11 <@jmbsvicetto> yes
-19:11 <@Betelgeuse> missed that
-19:12 <@scarabeus> i didnt update it because i can organise my time to fit anything you guys think up
-19:12 <@Betelgeuse> Any way I prefer the meeting staying the same local time (- if we have a meeting where US And Europe are not in DST sync)
-19:12 <@jmbsvicetto> so, does anyone have a problem with 2nd Monday of the month at 19H00 UTC ?
-19:12 <@Chainsaw> jmbsvicetto: That works very well for me, thank you.
-19:13 <@jmbsvicetto> Betelgeuse: so it would become 18H00 UTC when time changes?
-19:13 <@Betelgeuse> jmbsvicetto: 20UTC
-19:13 <@Chainsaw> jmbsvicetto: UTC does not respect DST. So the time would stay the same.
-19:13 <@scarabeus> yeah we can shift it to +1to fit even non sumer time
-19:13 <@Chainsaw> jmbsvicetto: Did you mean CEST?
-19:13 <@jmbsvicetto> Betelgeuse: thanks for correcting that
-19:14 <@jmbsvicetto> Chainsaw: 19H00 UTC until DST kicks in and 20H00 UTC from then on
-19:14 <@Betelgeuse> jmbsvicetto: 19UTC/BST
-19:14 <@jmbsvicetto> iirc, the problem is DST kicks in at different times in US and Europe
-19:14 <@Betelgeuse> hmm no
-19:14 <@wired> 1 week differene iirc
-19:14 <@jmbsvicetto> right
-19:14 <@Betelgeuse> 20BST 19UTC
-19:14 <@Chainsaw> So what you meant was 19:00 GMT.
-19:15 <@scarabeus> KILL MEEE
-19:15 <@wired> lol
-19:15 <@scarabeus> we will meet at this time
-19:15 <@jmbsvicetto> iirc, it changes in the last Saturday of September in Europe
-19:15 <@scarabeus> and when the summer time is over we add one hour
-19:15 <@wired> lets just stick to 1900
-19:15 <@wired> one meeting before dst change we can talk abou this
-19:15 <@Halcy0n> WFM
-19:15 <@Betelgeuse> Chainsaw: GMT == UTC for practical purposes
-19:15 <@Chainsaw> Indeed, let's shelve this discussion.
-19:15 <@jmbsvicetto> ok, let's defer that to the September meeting
-19:16 <@Chainsaw> jmbsvicetto: Agreed. Next item?
-19:16 <@Halcy0n> We've gone over our 5 minutes, so lets move on.
-19:16 <@jmbsvicetto> sure
-19:16 <@jmbsvicetto> So do we want to use bugs to track issues submitted to the council?
-19:17 <@Chainsaw> It seems a good way, yes.
-19:17 <@wired> i like the idea
-19:17 <@Betelgeuse> jmbsvicetto: the web app once GSoC is over
-19:17 <@Chainsaw> As long as there is some control over who can submit bugs to that category.
-19:17 <@Halcy0n> Betelgeuse: which web app is this?
-19:17 <@scarabeus> council web app to manage our workflow
-19:17 <@Betelgeuse> Halcy0n: We have a rails project to do anything that I can think of for the council.
-19:18 <@jmbsvicetto> so bugs for now and the webapp later?
-19:18 <@Chainsaw> jmbsvicetto: Okay. Can you make sure that the ability to file & comment bugs in the Council category is restricted?
-19:18 <@Halcy0n> Bugs for now, and lets see how the webapp works out.
-19:19 <@scarabeus> WFM
-19:19 <@wired> +1
-19:19 <@Chainsaw> Yes, agreed.
-19:19 <@jmbsvicetto> Chainsaw: I don't think infra cand do that now, but we can apply the same rules for abuse in bugzilla
-19:19 <@jmbsvicetto> s/cand/can/
-19:19 <@Chainsaw> jmbsvicetto: Restricting the filing might be difficult, but restricting the ability to comment sounds realistic.
-19:19 <@Halcy0n> We can restrict commenting, like devrel, but do we really want to do that?
-19:19 <@Chainsaw> jmbsvicetto: And should probably be done. My mailbox will thank you if we ever vote on a contentious issue.
-19:20 <@jmbsvicetto> Chainsaw: let's ask infra and wait for their reply, ok?
-19:20 <@Halcy0n> I'm not certain why we are restricting the bugs...nor do I agree with that.
-19:20 <@jmbsvicetto> idl0r: if you can comment, please do
-19:20 < a3li> if I may, there is no option to make a bug 'read-only' only for certain people by default
-19:20 <@Halcy0n> If people abuse bugzilla, we can deal with that, but we shouldn't be making the bugs hidden.
-19:21 <@Chainsaw> Halcy0n: Because seas of "No, this is a stupid idea" "I disagree it is great, please vote yes" are tiresome.
-19:21 <@Chainsaw> Halcy0n: I don't mean to restrict viewing.
-19:21 <@Chainsaw> Halcy0n: Just commenting.
-19:21 <@jmbsvicetto> Halcy0n: I assume the goal is to restrict access to people in the reporter, assigned and cc fields
-19:21 <@Betelgeuse> No discussion should happen in bugzilla.
-19:21 <@Betelgeuse> Even by us.
-19:21 <@Halcy0n> Bugzilla shouldn't be used as a discussion medium anyway.
-19:21 <@Chainsaw> Indeed. But people will if you give them the chance. So restrict comments please, nip it in the bud.
-19:21 <@jmbsvicetto> I agree in principle with Halcy0n and Betelgeuse 
-19:21 <@Halcy0n> Keep them open, if people don't use the tools correctly, we deal with it.  I don't want to deal with a possible non-issue before we even encounter it.
-19:22 <@jmbsvicetto> there are already tools to deal with people that abuse bugzilla
-19:22 <@Chainsaw> As you wish.
-19:22 <@wired> I think we should leave them open as well. if people misbehave continously we can revisit restricting them
-19:22 <@Chainsaw> Move on, next item?
-19:22 <@Halcy0n> Well, did we reach consensus before moving on?
-19:22 < idl0r> jmbsvicetto: what's up?
-19:23 <@Chainsaw> Halcy0n: Yes, the majority was against my idea of restricting bugs in any way.
-19:23 <@jmbsvicetto> So, the idea is to use bugs and check the webapp when it's ready
-19:23 <@Halcy0n> We will use bugzilla for tracking council issues (no restrictions), and will look at the webapp when it is declared complete?
-19:23 <@Betelgeuse> idl0r: Can we hide products?
-19:23 <@Betelgeuse> I wouldn't open a new product for Council and use it for a month if it would stay there indefinetely.
-19:24 <@jmbsvicetto> can we move forward?
-19:24 <@Chainsaw> jmbsvicetto: I would like that.
-19:25 <@jmbsvicetto> so should we have a section on all meetings to check the status of open bugs?
-19:25 <@jmbsvicetto> So that we can keep track of issues assigned to council and what is happening on them?
-19:25 <@Chainsaw> jmbsvicetto: Yes.
-19:25 <@scarabeus> of course we should check our work
-19:25 < idl0r> Betelgeuse: no, at least not in bugzilla-2. in bugzilla-3 dunno
-19:25 <@scarabeus> we could also use voting there
-19:25 < idl0r> Betelgeuse: but restricting bugs is possible
-19:25 <@jmbsvicetto> this would obviously be done in the future for the webapp (if / when we get it)
-19:26 <@Halcy0n> I don't know if we would want to check them every time, perhaps setting deadlines and revisiting those issues when the deadline has been reached?
-19:26 <@jmbsvicetto> Halcy0n: if something is still inside a deadline, we can lose 30 seconds just stating that ;)
-19:26 <@Chainsaw> It's good to have the reminder.
-19:27 <@jmbsvicetto> Should we try to have one council member directly responsible for each bug? So there's an individual responsibility beyond the team collective responsibility?
-19:27 <@wired> sounds good
-19:27 <@Chainsaw> Yes, that makes sense.
-19:28 <@scarabeus> but we should not force it, maybe voting in bugzilla, people can use popular bugs that we could take
-19:28 <@ferringb> holy backlog ;)
-19:28 <@scarabeus> people might open bugs but there might be even more important ones (by the voting it can be determined)
-19:28 <@jmbsvicetto> Hi Brian
-19:28 <@wired> ferringb! :)
-19:29 <@ferringb> sorry, in the midst of a release
-19:29  * ferringb goes back to catching up
-19:30  * wired fetches some water
-19:31 <@scarabeus> ok i think both are good ideas
-19:31 <@scarabeus> anyone against
-19:31 <@scarabeus> discussion about bug progress should happen on each meeting.
-19:31 <@scarabeus> each bug will have assigned named council member that should be responsible for its implementation.
-19:31 <@scarabeus> this can also utilize bugzilla voting metod, if used by developers.
-19:31 <@scarabeus> from summary
-19:31 <@Halcy0n> sounds good to me
-19:31 <@wired> +1
-19:31 <@jmbsvicetto> +1
-19:32 <@Chainsaw> Summary agreed, next item?
-19:32 <@wired> > ability to have 2nd monthly / impromptu meetings when required
-19:32 <@jmbsvicetto> are we willing to have a 2nd meeting per month or an improptu meeting when required?
-19:32 <@jmbsvicetto> Do we need to state that or is that a given?
-19:32 <@Betelgeuse> Ddin't we agree to meet every second week already?
-19:33 <@jmbsvicetto> We said we would meet at the 2nd Monday of the onth
-19:33 <@jmbsvicetto> month*
-19:33 <@scarabeus> we can have any  meeting during the month
-19:33 <@Chainsaw> And anything extra can be agreed at one of those meetings.
-19:33 <@scarabeus> but i would like at least week headsup
-19:33 <@Chainsaw> Yes, a week notice is the minimum I would need.
-19:33 <@scarabeus> like 8.8. -> announce meeting for 15.8. due to nuclear holocaust
-19:34 <@ferringb> week headup is a requirement for me
-19:34 <@Halcy0n> Same
-19:34  * ferringb notes he can swing impromptu's, but that's an exception, not a rule
-19:34 <@jmbsvicetto> Do we want to make any statement about this or just discuss it if / when it becomes needed?
-19:34 <@Chainsaw> Okay, we meet every second Monday at 19:00 UTC until further notice. 1 week notice required for any changes.
-19:34 <@Betelgeuse> I don't have other duties at these hours.
-19:35 <@ferringb> if/when works for me personally
-19:35 <@Chainsaw> All in favour?
-19:35 <@Halcy0n> fine by me
-19:35 <@Betelgeuse> sure
-19:35 <@scarabeus> aye
-19:35 <@jmbsvicetto> ok
-19:35 <@wired> 1 week notice is fine by me
-19:35 <@jmbsvicetto> next?
-19:36 <@scarabeus> secretary/chair
-19:36 <@jmbsvicetto> Do we want a secretary?
-19:36  * jmbsvicetto looks at tanderson 
-19:36 <@scarabeus> we need chair, i am willing to do it, but we might want to rotate so all of us will have the fun?
-19:36 -!- rokybid [~foolio@67.220.166.250] has joined #gentoo-council
-19:36  * tanderson is expected to give some form of answer
-19:36 <@wired> i think the wave thing is working for summaries
-19:36 <@scarabeus> quite well isn't it?
-19:37 <+tanderson> whatever you decide, don't make a non-council member the chair
-19:37 <@wired> i think chairing can be decided per-meeting
-19:37 <+tanderson> what wave thing?
-19:37 <@Halcy0n> Rotating amongst ourselves (those that want to), should work fine.  Using wave for the summaries is working nicely.
-19:37 <@Chainsaw> tanderson: That overhyped google wiki.
-19:37 <@Halcy0n> tanderson: Google Wave
-19:37 <+tanderson> yeah, how are you using it?
-19:37 <@wired> tanderson: we are using google wave to interactively create the summary
-19:37 <@scarabeus> right now we are writting summary
-19:37 <@jmbsvicetto> The wave thing is working, but if we want to use it to all meetings, we should assure all council members are either willing to use it or to have it used
-19:38 <@wired> during this meeting
-19:38 <+tanderson> ooh, but with that, you don't need a secretary doing stuff, correct?
-19:38 <@wired> jmbsvicetto: wave does *not* require a google account now, that should make things easier
-19:38 <@Betelgeuse> jmbsvicetto: We don't need all council members there.
-19:39 <@Halcy0n> Really we only need a few of us to ensure it gets done.
-19:39 <@jmbsvicetto> Betelgeuse: sure, but we must check if someone objects to its use, no?
-19:39 <@Betelgeuse> jmbsvicetto: Whatever gets the job done.
-19:39 <@ferringb> same from my stance.
-19:39 <@Betelgeuse> jmbsvicetto: It's better to not have everyone there so discussion doesn't spill there.
-19:39 <@jmbsvicetto> I'm fine with using wave
-19:39 <@Halcy0n> same
-19:40 -!- rokybid [~foolio@67.220.166.250] has quit [Read error: Connection reset by peer]
-19:40 <@wired> great
-19:40 <@jmbsvicetto> If we're ok with wave, that takes care of summaries. What about agendas and initial email warning about a meeting?
-19:40 <@Chainsaw> I'm not opposed to wave, but I'm unlikely to participate.
-19:40 <@wired> we just need to make sure that someone will commit the summaries each time :P
-19:41 <@scarabeus> that should be done by last months chair
-19:41 <@scarabeus> jmbsvicetto: ^
-19:41 <@Betelgeuse> wired: we could end the meeting officially with that
-19:41 <@jmbsvicetto> I think the person being chair for a meeting should take care of the agenda and initial email - which means the chair should be chosen before a meeting
-19:41 <@scarabeus> the agenda for next meeting + commiting current stuff we have
-19:42 <@wired> i like scarabeus' recommendation. he who chairs is responsible for next time
-19:42 <@jmbsvicetto> I'm willing to be chair on a rotating basis
-19:42  * wired too
-19:42 < NeddySeagoon> choose the chair for the next meeting at the end of the current one or on the ml
-19:42 <@Halcy0n> Same, to both
-19:42 <@ferringb> duck duck goose?
-19:43 <@Chainsaw> Selecting at the end of the meeting makes a lot of sense.
-19:43 <@scarabeus> but end meeting selection makes really lots of sense
-19:43 <@Chainsaw> And yes, I too share an ambition to one day be a rotating chair.
-19:43 <@jmbsvicetto> so the chair for a meeting will be chosen at the end of the previous meeting. Does everyone accept?
-19:43 <@Betelgeuse> yes
-19:43 <@wired> yeah
-19:43 <@Chainsaw> jmbsvicetto: Agreed.
-19:43 <@Halcy0n> +1
-19:44 <@jmbsvicetto> and the chair will be responsible for sending the initial email and setting up the agenda
-19:44 <@jmbsvicetto> can we move to the next point: allowing council members to present issues they'd like to see addressed this term?
-19:44 <@wired> great
-19:45 <@jmbsvicetto> anyone wants to start?
-19:45 <@Chainsaw> Yes. Death to (the official status of) overlays.
-19:45 <@Chainsaw> Development happens in the tree where everyone can QA it.
-19:46 <@Chainsaw> If it is "not done yet", you mask it.
-19:46 <@scarabeus> Chainsaw: it cant happen, imagine kde-base +600 weirdly broken ebuilds...
-19:46 <@scarabeus> but we can move to unofficial
-19:46 <@jmbsvicetto> Chainsaw: you're going to face some opposition about that
-19:46 <@Chainsaw> jmbsvicetto: I know.
-19:47 <@wired> it could happen
-19:47 <@wired> but not with cvs :p
-19:47 <@Chainsaw> scarabeus: I'm not saying don't use overlays. I'm saying don't have official overlays. Only take bugs about what is in the tree.
-19:47 <@Chainsaw> scarabeus: Using them for staging and then moving your ebuilds to the tree in good time makes sense.
-19:47 <@scarabeus> Chainsaw: so you probably dont like gnome approach
-19:47 <@scarabeus> we do mostly 0days
-19:47 <@Chainsaw> scarabeus: Having official overlays with bugs in the tracker and ebuilds that never make it to the tree are not.
-19:48 <@jmbsvicetto> Chainsaw: I suggest we leave discussions for future meetings ;)
-19:48 <@scarabeus> yeah lets not argue now, just show our visions :]
-19:48 <@jmbsvicetto> Chainsaw: Any other issue you'd like us to address in this term?
-19:48 <@Chainsaw> jmbsvicetto: Unmaintained packages.
-19:48 <@jmbsvicetto> what about them?
-19:48 <@Chainsaw> jmbsvicetto: I'd like a documented procedure to take an unloved package over with a set limit.
-19:49 <@jmbsvicetto> So discuss rules (policy) about unmaintained packages?
-19:49 <@Chainsaw> jmbsvicetto: If the maintainer fails to respond in say... 1 week, you take it over and there is no song & dance about it later. </example>
-19:49 <@Chainsaw> jmbsvicetto: And you use a bug for this, so there is an official record.
-19:50 <@scarabeus> oh not taking mn packages
-19:50 <@scarabeus> but overtaking from someone else
-19:50 <@Chainsaw> From a maintainer that has apparently lost interest, should be retired but isn't yet, etc.
-19:50 <@scarabeus> oka
-19:50 <@scarabeus> anything else?
-19:50 <@Chainsaw> Packages in limbo that under the current rules, you can't really touch. But that you rely on for business. Asterisk comes to mind.
-19:50 <@jmbsvicetto> in that case you want to review the current policy about package maintainance
-19:50 <@Chainsaw> No, that's my two super-controversial proposals out.
-19:51 <@Chainsaw> Someone else can have a go now.
-19:51 <@scarabeus> jmbsvicetto: how about you
-19:51 <@jmbsvicetto> ok, I want to continue the work to review GLEP39 and Gentoo's metastructure
-19:52 <@scarabeus> ok everyone knows whats that :]
-19:52 <@scarabeus> anything else?
-19:52 <@jmbsvicetto> and to study and promote ways to allow more involvement from community
-19:52 <@jmbsvicetto> I don't have any particular issues for now
-19:53 <@jmbsvicetto> scarabeus: you?
-19:53 <@scarabeus> ok so lets talk about my shiny hat:
-19:53 <@scarabeus> 1) qa and its involvement (that is probably on marks hat too, i want to bash people more for commiting crap simply put)
-19:53 <@scarabeus> 2) PR reviwe GWN
-19:54 <@scarabeus> with the hard push on the W, because it is manageable in few people
-19:54 <@scarabeus> We desperately need PR and global knowledge
-19:54 <@scarabeus> people really think we are dead if i go on few confs and stuff :]
-19:54 <@Chainsaw> I'm on-board with the QA proposal.
-19:54 <@Chainsaw> PR is not my thing, but I won't be in your way.
-19:54 <@Chainsaw> (Although I can probably help if you want to publish an article in our HotLINX newsletter)
-19:55 <@scarabeus> i actualy already have people that will translate it to cze and probably publish it on largest linux emagazine in cze, so at least in cze we are covered :P
-19:55 <@scarabeus> i just need to really organise what will be on it
-19:56 <@Chainsaw> The magazine we publish goes to people in the ISP industry.
-19:56 <@scarabeus> Chainsaw: sweet
-19:56 <@Chainsaw> It's a completely different audience that you might want to touch on.
-19:56 <@scarabeus> well isp is one of those guys who have large pc infrastructures so they are target :]
-19:56 <@scarabeus> but anyway that is not for this summary show, so who is next
-19:56 <@ferringb> re: pkg takeover, it should be more ability to do work on it... takeover being a bit longer imo
-19:57 <@scarabeus> ferringb: so what are your plans, since you talks
-19:57 <@scarabeus> s//
-19:57 <@Halcy0n> I just want to point out that we are about to run out of time. :)
-19:58 <@scarabeus> yeah
-19:58 <@Chainsaw> So, next item please?
-19:59 <@Halcy0n> I don't think we are finishing anything in 2 minutes. :)  I have my boss waiting to talk to me :)
-19:59 <@ferringb> scarabeus: plans re: takeover... basically I'd leave that to tree policy, aka QA to some degree.  let the community sort it out ;)
-19:59 <@ferringb> Halcy0n: same
-19:59 <@scarabeus> ferringb: not thoughts about those plans :P your plans :P
-19:59 <@scarabeus> i guess jorge want us to say : i want to do a and hopefully b
-19:59 <@scarabeus> thats it
-19:59 <@scarabeus> one sentence to put to summary
-20:00 <@ferringb> scarabeus: long term plans council wise, I'd like to have the council slightly less involved day/day community wise- light touch approach basically.  cardoe does have a point in my opinion- we don't need to be involved in every little thing
-20:01 <@scarabeus> Halcy0n: you?
-20:01 <@ferringb> scarabeus: technical side of it, PMS will be a bit of a focus obviously for me ;)
-20:01 <@jmbsvicetto> sorry, I lost my internet connection for the past 5 minutes
-20:01 <@wired> I want to make sure we as a council are decisive and effective throughout our term, making good decisions :)
-20:01 <@Chainsaw> Halcy0n: A bigger QA banhammer, yes?
-20:02 <@Halcy0n> Yes, and work on making it easier for people to know how to join/help out.  Basically involving the community more.
-20:02 <@Betelgeuse> Halcy0n: What would be needed beyond current powers?
-20:03 <@Halcy0n> I don't really have time right now to discuss it, but I have some ideas that would drastically change recruitment that I would like to propose to the dev community as a whole.
-20:03 <@Betelgeuse> Halcy0n: There's a GSoC project for that too.
-20:03 <@jmbsvicetto> Do we want to continue the meeting or do we need to finish it in a few minutes?
-20:04 <@Chainsaw> I have a need to vacate this building in roughly 15 minutes.
-20:04 <@Chainsaw> So if we could not start anything that will take a long time to complete, I'd appreciate it.
-20:04 <@scarabeus> Betelgeuse: and your plans? if not secrit?
-20:04 <@jmbsvicetto> I would like to give a chance for the community to present any ideas it has - next point
-20:05 <@jmbsvicetto> I can leave the discussion about --as-needed and required-use for the next meeting
-20:05 <@scarabeus> jmbsvicetto: no discussion, i want vote
-20:05 <@Betelgeuse> scarabeus: I'll probably be busy with putting the GSoC results to use for most part of the year.
-20:05 <@scarabeus> there is nothingreally to discuss about as needed
-20:05 <@Betelgeuse> scarabeus: Then mostly PM stuff.
-20:05 <@jmbsvicetto> I don't need to leave for anything, so I can be around for a long while if someone wants to continue the meeting
-20:05 <@scarabeus> Betelgeuse: oky
-20:06 <@Chainsaw> scarabeus: I am fully in favour of as-needed being introduced into profiles. As a demonstration of my commitment to your cause: https://issues.asterisk.org/view.php?id=14671
-20:06  * ferringb really needs to get back to work
-20:06 <@ferringb> jmbsvicetto: leaving them to the next meeting makes the most sense imo anyways
-20:07 <@jmbsvicetto> ok. Anyone else wants to present his ideas for this term?
-20:07 <@jmbsvicetto> are we missing anyone?
-20:07 <@scarabeus> jmbsvicetto: we have everyone
-20:07 <@jmbsvicetto> ok
-20:07 <@Betelgeuse> I want to stop global warming.
-20:07 <@scarabeus> so community what do you want? :]
-20:07 <@jmbsvicetto> If someone is willing to stay a few more minutes, I'd like to give a chance for the community to present their requests (next agenda itme)
-20:08 <@jmbsvicetto> item*
-20:08 <@Chainsaw> I can stay a few more minutes.
-20:08 <@wired> lets decide who's chairing the next one first
-20:08 <@Chainsaw> But not very long. So please proceed.
-20:08 <@Chainsaw> wired: You are.
-20:08  * scarabeus rises hand
-20:08 <@scarabeus> if nobody else wants
-20:08 <@wired> Chainsaw: really? I thought it was you! heheh :p
-20:09 <+tanderson> I'd like to get a guarantee from the council that decisions will be made based solely on the merit of proposals, not based in any way on anything to do with the person making the proposal.
-20:09 <@jmbsvicetto> as this was a special meeting and I did send the original email, I'll commit the summary for the meeting
-20:09 <@scarabeus> tanderson: i listen even to ciaran, if it makes sense
-20:10 <@scarabeus> jmbsvicetto: for NEXT meeting ;]
-20:10 <@Chainsaw> Yes, wired chairs the next meeting.
-20:10 <@Chainsaw> So, was there anything else?
-20:10 <+tanderson> my question.
-20:10 <@ferringb> open it up to the community imo
-20:10 <@scarabeus> nope most of you can disappear if needed, we will sit around and wait for the comunity to talk with us :]
-20:11 <@wired> lmao :) alright
-20:11 <@Chainsaw> tanderson: All I care about is the proposal itself. Even if you submitted it, I'd still look at seriously. Okay?
-20:11 <+tanderson> I'm not talking about me, but point taken.
-20:12 <@jmbsvicetto> scarabeus: I'll submit the summary for this meeting.
-20:12 <@scarabeus> okay
-20:12 <@jmbsvicetto> So who's going to be next meeting's chair? wired or scarabeus ?
-20:12 <@Chainsaw> jmbsvicetto: wired.
-20:12 <@wired> i'll do it
-20:12 <@scarabeus> ok
-20:12 <@Chainsaw> tanderson: I know you aren't. But I'm glad you understand :)
-20:14 <@jmbsvicetto> So if someone else has anything to suggest to the council, feel free to do so
-20:14 <@Chainsaw> We will listen!
-20:14 <@scarabeus> isn't mute on?
-20:14 <@Chainsaw> Please speak...
-20:14 <@Chainsaw> scarabeus: I don't see a +m, no. They've just been very well behaved.
-20:14 <@scarabeus> we feel lonely
-20:14 <+tanderson> scarabeus: no.
-20:14 <@jmbsvicetto> I suggest we give 30 minutes before closing the summary
-20:14 <@scarabeus> tell us something
-20:14 < dleverton> "wired chairs the next meeting" sounds like you're going to bring in electric chairs for all the council members
-20:14 <@scarabeus> i will show you my friendly face if you will talk :]
-20:14 < dleverton> Does that count?
-20:15 <@jmbsvicetto> In the meanwhile, is there any other business?
-20:15 <@Chainsaw> scarabeus: Or they have all been watching amusing pictures of cats on the internet. Who knows.
-20:15 <@scarabeus> dleverton: ok, my friendly look http://hlukotvor.blesmrt.net/~scarab/fotky/IMAG0017.jpg :D
-20:16 <@jmbsvicetto> If not, let's consider the meeting over, but consider any suggestions in the next 30 minutes in the summary
-20:16 -!- thrice` [thrice@unaffiliated/thrice/x-000000001] has left #gentoo-council []
-20:16 <@Chainsaw> I have to alarm this building in 4 minutes.
-20:16 <@Chainsaw> So I shall leave now.
-20:17 <@scarabeus> Chainsaw: cya
-20:17 <@Chainsaw> Thank you all for a productive meeting, and I look forward to seeing you again next week.
-20:17 <@wired> cya Chainsaw
-20:17 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has quit [Remote host closed the connection]
-20:20 <@scarabeus> so guys, is it so hot at your places too?
-20:20 <@scarabeus> 37 degrees in shade today
-20:20 <@scarabeus> :]
-20:20 <@scarabeus> (maybe someone will start talking)
-20:22 < dleverton> Was pretty dreary here
-20:22 <@ferringb> heat finally broke for us on the weekend... 70F, down from near 100F last week
-20:22 < dleverton> Didn't go out today though
-20:22 < dleverton> Actually a nice change from the heat
-20:22 < dleverton> O
-20:23 < dleverton> *(Probably never counted as "heat" by your standards in the first place)
-20:23 -!- Halcy0n [~halcy0n@gentoo/developer/halcyon] has quit [Quit: leaving]
-20:23 <@scarabeus> that is quite nice :]
-20:23 <@scarabeus> also note i speak in Celsius of course :P
-20:23 <+tanderson> thunderstorms here, 29 :)
-20:24 <@scarabeus> dleverton: apropos, i look friendly dont i? :]
-20:24 < dleverton> Hard to tell behind the face-paint :-P
-20:24 <@wired> the new council meeting time is now reflected on google gentoo calendar :)
-20:25 <@scarabeus> sweet i should start using google calendar :D
-20:25 <@wired> scarabeus: you have android, you should be using it already :p
-20:25 <@scarabeus> wired: stop doing that for me
-20:25 <@scarabeus> i disabled it
-20:25 <@scarabeus> :D
-20:25 <@wired> scarabeus: re-enable it :P
-20:26 <@scarabeus> jmbsvicetto: btw i think that open  30 minutes are useless, it is 20 now and nobody spoke up, it wont change...
-20:26 <@wired> scarabeus: also install the "Android Agenda Widget", it rocks :)
-20:26 <@wired> indeed, lets end this here
-20:26 <@jmbsvicetto> ok
-20:26 <@jmbsvicetto> http://dpaste.com/218207/ <- proposed summary
-20:27 <@jmbsvicetto> we had another clear day here
-20:27 <@scarabeus> aye aye sir
-20:28 <@wired> looks good
-20:28 <@jmbsvicetto> ok, I'm going to commit that, right after I have my dinner
-20:28 <@jmbsvicetto> So let's call the meeting closed
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100726-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100726-summary.txt
deleted file mode 100644
index cb5c966791..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100726-summary.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Gentoo Council 2010-07-26 meeting agenda / summary:
-
-*** meeting outcome marked with "->" ***
-
-* allow all members to show up (5 min)
-	-> betelgeuse   here
-	-> chainsaw     missing (1st absence)
-	-> ferringb     here, left after an hour (before ML discussion)
-	-> halcy0n      missing (1st absence)
-	-> jmbsvicetto  here
-	-> scarabeus    here
-	-> wired        here
-
-** vote **
-	add --as-needed to default profile's LDFLAGS
-		-> passed (unanimous vote)
-			scarabeus will create a news item,
-			ssuominen already pushed the actual change :D
-
-** discuss / vote **
-	* required-use: http://dev.gentoo.org/~ferringb/required-use.html
-		-> accepted by all members
-
-	* review eclass removal policy
-		should it be 2 years since portage 2.1.4.4 went stable?
-			-> all members agreed on removing the 2 year policy
-			-> QA will write a devmanual patch with a 30+ minimum lastrite period for eclass removals
-
-	* should there a policy about eclass API changes?
-		-> we didn't reach a decision here, talk will continue in the mailing lists
-
-	* use of invalid DEPEND atom "EAPI_TOO_OLD" instead of calling die in global scope on eclasses
-		http://archives.gentoo.org/gentoo-dev/msg_dee3aab5e8c840ed3fa4add9c7d74b97.xml and replies
-			-> the council opted for calling die instead of using the invalid DEPEND and required
-				a patch to devmanual and PMS (ferring will do the devmanual patch)
-
-	* mailing lists
-		should we post council agenda to -council? -dev? -project?
-		Some devs suggest we should cross-post to -dev and -council
-			but not everyone likes cross-posting as it can lead to fragmentation.
-		Petteri suggested punting -council and using -project instead
-			-> there was a vote on punting -council that ended in a 2-2 tie (ferringb had left)
-				jmbsvicetto and wired voted against, betelgeuse and scarabeus voted in favor
-			-> discussion will be continued in the mailing lists
-
-* go through bugs assigned to council@g.o
-	http://bugs.gentoo.org/buglist.cgi?quicksearch=assignedto,cc:council@gentoo.org
-
-	bug #234706
-		-> ask Halcy0n if he wants to resume work on this bug
-	bug #256451
-		-> ask ferringb if he still wants to do it
-	bug #256453
-		-> wired will take care of this
-	bug #237381
-		-> jmbsvicetto will take care of this
-
-* open floor: listen to developers
-	-> no input...
-
--> scarabeus will chair the next meeting
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100726.txt b/xml/htdocs/proj/en/council/meeting-logs/20100726.txt
deleted file mode 100644
index 5755ea4752..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100726.txt
+++ /dev/null
@@ -1,473 +0,0 @@
-[21:52:12] <jmbsvicetto> Hello
-[21:52:57] <wired> Hey
-[21:58:45] <jmbsvicetto> wired: so you'll run this meeting, right?
-[21:58:49] <wired> yeah
-[21:59:00] <wired> in roughly one minute
-[21:59:01] <wired> :p
-[21:59:04] <jmbsvicetto> wired: if you need I have logs
-[21:59:05] *** Joins: Betelgeuse (~betelgeus@gentoo/developer/Betelgeuse)
-[21:59:19] <wired> jmbsvicetto: thanks, I log too
-[21:59:53] <wired> jmbsvicetto: i've switched the wave to summary mode (and created a stupid copy as well that i trashed :p)
-[22:00:00] <ferringb> e'yo.
-[22:00:07] * ferringb has a meeting at 1pm on a sidenote
-[22:00:13] <ferringb> aka, hour from now
-[22:00:21] <wired> and its time :)
-[22:00:22] * scarabeus here
-[22:00:28] <Betelgeuse> yes
-[22:00:37] * scarabeus can use only one hand, so he will be really quiet man today :]
-[22:00:49] <jmbsvicetto> here
-[22:00:52] *** Joins: NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon)
-[22:01:30] <wired> lets wait the standard 5m for halcy0n and chainsaw 
-[22:01:43] <wired> agenda: http://archives.gentoo.org/gentoo-council/msg_620cb09e78b4e7d9997c45eb204f7fd7.xml
-[22:02:42] *** wired changes topic to 'congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting now - agenda: "save" => Array(20100726 19:00.00 UTC - http://dev.gentoo.org/~wired/localtime.php?time=1900 || following 20100809 19:00.00 UTC'
-[22:02:46] <wired> 			"type" => 9,
-[22:02:49] <wired> 			"reset" => true
-[22:02:51] <wired> 		)
-[22:02:54] <wired> bah
-[22:02:58] <scarabeus> interesting :D
-[22:03:24] *** wired changes topic to 'congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting now - agenda: http://bit.ly/dmARrD || following 20100809 19:00.00 UTC'
-[22:03:25] <ferringb> anyone got the wave for this time around?
-[22:03:35] <wired> ferringb: sure, want an invite?
-[22:03:44] <wired> its the old agenda one
-[22:03:45] <ferringb> might as well try the new hawtness
-[22:03:59] * ferringb only has the summary
-[22:04:01] <wired> ferringb: which mail should i invite?
-[22:04:06] <ferringb> @gmail
-[22:04:15] <ferringb> @gentoo just fwds to that account
-[22:04:23] <wired> done
-[22:04:38] * ferringb only uses @gentoo when needing to sound official while being a pompous ass, rest of the time he just uses @gmail when being a pompous ass
-[22:04:39] <wired> ah your gentoo was already invited :p
-[22:04:53] <jmbsvicetto> wired: if you're using the same, I sent an invite to ferringb
-[22:05:07] <wired> jmbsvicetto: we sent to both mails hehe
-[22:05:16] <NeddySeagoon> is five of you a quorum ?
-[22:06:15] <wired> it should be fine. not optimal, but oh well
-[22:06:48] <jmbsvicetto> NeddySeagoon: iirc, the quorum is 50% + 1
-[22:06:50] <scarabeus> well we should be, more than 50% of us is around
-[22:06:54] <wired> so...
-[22:06:58] <wired> shall we begin?
-[22:07:06] <scarabeus> yy
-[22:07:20] <NeddySeagoon> jmbsvicetto, tha depends on the rules.  if its not in glep-39, its whatever you want
-[22:07:35] <jmbsvicetto> wired: let's go
-[22:07:43] <wired> lets begin with --as-needed
-[22:07:55] <wired> * add --as-needed to default profile's LDFLAGS
-[22:08:13] <Betelgeuse> NeddySeagoon: GLEP 39: Council decisions are by majority vote of those who show up (or their proxies).
-[22:08:36] <jmbsvicetto> NeddySeagoon: ok, I see two rules:
-[22:08:37] <jmbsvicetto> Council decisions are by majority vote of those who show up (or their proxies).
-[22:08:40] <Betelgeuse> And at least 50& must be here.
-[22:08:46] <jmbsvicetto> f any meeting has less than 50% attendance by council members, a new election for all places must be held within a month. The 'one year' is then reset from that point.
-[22:08:47] <scarabeus> and if less 50% is around then we are all scrapped
-[22:08:53] <jmbsvicetto> so > 50%
-[22:08:55] <wired> so we are fine
-[22:09:05] * ferringb notes we might want to look at a different day of the week down the line btw... can take that discussion offline, but monday at noon is proving to be murder for myself (suspect I'm not the only usian hit b that)
-[22:09:10] <jmbsvicetto> Betelgeuse: sorry for repeating you
-[22:09:13] <ferringb> *by.  that said... lets get the show on the road. ;)
-[22:09:20] <wired> ferringb: we can talk about that later
-[22:09:35] <Betelgeuse> ferringb: I am waiting to get to bed :)
-[22:09:50] <wired> lets begin by voting on adding --as-needed to default profile
-[22:10:00] * scarabeus says aye captain'
-[22:10:04] <ferringb> yay to getting to voting, and yay for --as-needed in default profile.
-[22:10:09] <scarabeus> which means, yes for as-needed
-[22:10:10] <wired> I vote yes :)
-[22:10:48] <wired> Betelgeuse / jmbsvicetto ?
-[22:11:05] <jmbsvicetto> wired: let's go
-[22:11:29] <jmbsvicetto> I vote yes for adding --as-needed in default profile
-[22:11:41] <ssuominen> Want me to implent it right now? :)
-[22:11:44] <Betelgeuse> I don't have anything against adding it. I didn't check if anyone ever did sanity checks with it.
-[22:11:53] <scarabeus> Betelgeuse: we in qa do them :]
-[22:11:55] <wired> Betelgeuse: a lot of people did
-[22:12:05] <scarabeus> Betelgeuse: well mostly ssuominen ;]
-[22:12:15] <wired> ok
-[22:12:20] <wired> its approved
-[22:12:24] <wired> ssuominen: go ahead :)
-[22:12:44] <wired> next item
-[22:12:48] <Betelgeuse> Should we write a GLEP 42 news item?
-[22:13:04] <ferringb> yes
-[22:13:12] <jmbsvicetto> Betelgeuse: To match what? ;)
-[22:13:12] <wired> Betelgeuse: good idea
-[22:13:22] <scarabeus> but what should trgger it :]
-[22:13:27] <Betelgeuse> scarabeus: everything
-[22:13:28] <wired> everything
-[22:13:29] <Betelgeuse> or everyone
-[22:13:36] <jmbsvicetto> Betelgeuse: I'd say an annoucement through the usual ways, would work
-[22:13:38] <scarabeus> but quite few people have asneeded already
-[22:13:51] <jmbsvicetto> scarabeus: I have
-[22:13:56] <Betelgeuse> scarabeus: it's not a big burden to read it.
-[22:14:03] <Betelgeuse> scarabeus: or just skip based on the name
-[22:14:14] <scarabeus> i am not against it
-[22:14:41] <Betelgeuse> I propose the news item should be approved and in circulation before profiles are changed.
-[22:14:41] <scarabeus> but it can go even after it is enabled in portage, because it does not change anything for the user pov in first time until he does -e :]
-[22:14:59] <Betelgeuse> Mainly to ensure it gets done.
-[22:15:09] <scarabeus> oh that is good reason
-[22:15:21] <wired> who wants to prepare the news item?
-[22:15:28] <scarabeus> ok sounds sane, its 72 hours right?
-[22:15:46] <scarabeus> ssuominen: i think we will manage to write up something, rite?
-[22:16:15] <scarabeus> he he :D
-[22:16:23] <wired> ok scarabeus it is
-[22:16:25] <Betelgeuse> scarabeus: yes
-[22:16:32] <wired> i'll help too
-[22:16:47] <scarabeus> you guys really dont track commits huh? :]
-[22:17:09] <jmbsvicetto> ssuominen was too quick
-[22:17:16] <ssuominen> hu...
-[22:17:18] <scarabeus> he got approval
-[22:17:25] <wired> lol
-[22:17:26] <scarabeus> anyway lets implement the message  then
-[22:17:27] <ssuominen> I hit commit about when wired said go for it :)
-[22:17:28] <scarabeus> and just add it
-[22:17:31] <wired> thats fine, we'll write the message today
-[22:17:34] <wired> so its cool
-[22:17:51] <scarabeus> so lets move for next topic, i will ensure this will happen ok :]
-[22:17:54] <wired> great
-[22:18:08] <wired> * required-use: http://dev.gentoo.org/~ferringb/required-use.html
-[22:19:03] <jmbsvicetto> ferringb: few already implemented the code for portage, right?
-[22:19:07] <ferringb> yep
-[22:19:16] <ferringb> reasonably quick for me to do in pkgcore
-[22:19:28] <jmbsvicetto> dleverton_: Has anyone worked on it for paludis?
-[22:19:30] <ferringb> paludis should have rough machinery for this already via exheres MYOPTIONS
-[22:19:37] * scarabeus likes the idea
-[22:19:44] <wired> it loosk good
-[22:19:49] <wired> and will solve many current problems
-[22:19:50] <dleverton_> jmbsvicetto: don't think so
-[22:19:53] <jmbsvicetto> I like the idea
-[22:19:55] <Betelgeuse> We would approve final EAPI 4 text any way before it goes official.
-[22:20:02] <Betelgeuse> so I guess we are voting on the idea any way.
-[22:20:08] <ferringb> pretty much.
-[22:20:11] <wired> Betelgeuse: yeah
-[22:20:22] <jmbsvicetto> ok, +1 from me on using it
-[22:20:23] <ferringb> note between now and eapi 4 final, if someone has a better name... might be worth considering.
-[22:20:29] <ferringb> that caveat stated, +1 from me obviously.
-[22:20:30] <jmbsvicetto> ferringb: yes
-[22:20:44] <wired> +1
-[22:21:02] <Betelgeuse> ferringb: also the exact cache slot is not there yet but not a problem
-[22:21:03] <Betelgeuse> yes
-[22:21:13] <Betelgeuse> or +1
-[22:21:29] <wired> great
-[22:21:48] <wired> anyone want to say something else on this before we move on?
-[22:22:05] * ferringb cracks the whip; got 40 minutes left before I'm locked in a meeting ;)
-[22:22:11] <wired> moving on then
-[22:22:21] <wired> eclass removal policy
-[22:22:31] <wired> currently devs have to wait for 2 years before removing an eclass
-[22:22:57] <wired> this is not needed anymore since portage-2.1.4.4
-[22:23:30] <scarabeus> for eclass added after 2.1.4.4 got stable they can be purged
-[22:23:40] <wired> i think a 30day lastrite would be enough
-[22:23:45] <scarabeus> for old eclasses i would keep the way
-[22:23:56] <scarabeus> it does not hurt us to have empty files there
-[22:24:01] <ferringb> wired: 60 is my vote, although this number should be worked out w/ overlay consumers...
-[22:24:16] <Betelgeuse> I would vote on a devmanual patch.
-[22:24:22] <ferringb> scarabeus: there is no reason to do that offhand
-[22:24:28] <Betelgeuse> That's been discussed on gentoo-dev.
-[22:24:37] <ferringb> scarabeus: the env saving/restoration machinery works from the stored env dump, regardless of which version of PM that generated it
-[22:24:57] <scarabeus> ferringb: and old portage did store the env dump?
-[22:25:01] <scarabeus> ferringb: that i didnt know :]
-[22:25:05] <ferringb> scarabeus: always has
-[22:25:10] <ferringb> that's what environment.bz2 is
-[22:25:27] <scarabeus> i know what file it was, i just thought it wasnt stored before
-[22:25:39] <wired> Betelgeuse: +1 on the devmanual patch, this needs to be documented
-[22:25:40] <scarabeus> in that case it can be nuked and prepared as devmanual patch and discussed on -dev
-[22:26:27] <ferringb> +1 from me, although I'd rather the council not set the time frame instead leaving it to QA to find the best value
-[22:26:47] <wired> ferringb: agreed, 30/60 days are just recommendations
-[22:27:13] <wired> who'll take care of the devmanual patch?
-[22:27:21] <Betelgeuse> I think they should be an enforced minimum.
-[22:27:24] <jmbsvicetto> +1 for me with the devmanual patch
-[22:27:30] <Betelgeuse> Or we will always have people who find it oke to nuke without delay.
-[22:27:45] <wired> Betelgeuse: i meant recommendations for the QA team
-[22:28:09] <Betelgeuse> wired: sure
-[22:28:49] <wired> so QA will write the patch?
-[22:28:56] <wired> since they have to decide on the timeframe
-[22:28:56] <scarabeus> wired: we can
-[22:29:13] <scarabeus> </qa hat>
-[22:29:21] <wired> ok
-[22:29:46] <jmbsvicetto> so, next point?
-[22:29:49] <wired> 1sec
-[22:29:51] <wired> (summary)
-[22:29:59] <ferringb> eclass api change policy
-[22:30:23] <wired> ok
-[22:30:29] *** Quits: Cardoe (~Cardoe@gentoo/developer/Cardoe) (Remote host closed the connection)
-[22:30:35] <jmbsvicetto> I don't think we need to create one
-[22:30:44] * ferringb notes that this particular point is trying to legislate common sense in effect
-[22:31:13] <Betelgeuse> jmbsvicetto: Ass in don't allow it?
-[22:31:29] <wired> i don't see why we should prevent eclass api changes
-[22:31:33] <jmbsvicetto> no, as in let it at the discretion of the developers
-[22:31:43] <wired> as long as the teams ensure the tree doesn't break
-[22:31:47] <ferringb> I'd frankly punt it back to dev/QA and vote on specific requirements, rather than an open ended question like this.  thus a -1 from me in the current form.
-[22:32:03] <Betelgeuse> jmbsvicetto: If we decide to not care about overlays.
-[22:32:08] <wired> and they update everyone else, we are not needed
-[22:32:48] <jmbsvicetto> Betelgeuse: I think we should care about overlays
-[22:33:23] <jmbsvicetto> Betelgeuse: My only "requirement" is that any major changes are announced with some advanced warning
-[22:33:37] <scarabeus> i think the api should not be changed the much like python does for example
-[22:33:47] <scarabeus> it is better to roll out new eclass with additional stuff/functions
-[22:33:48] <jmbsvicetto> Betelgeuse: so that maintainers of overlays get a warning before the change is implemented
-[22:33:50] <scarabeus> and then migrate the things
-[22:34:08] <scarabeus> i just dont like packages in stable imploding to my face
-[22:34:13] <Betelgeuse> any way devmanual patch again
-[22:34:37] <jmbsvicetto> Betelgeuse: but instead of having a new policy just for this, I think we can address abuses here with the regular policies from QA and devrel
-[22:35:01] <Betelgeuse> DevRel should not deal with this.
-[22:35:10] <Betelgeuse> Unless it has to do with bans.
-[22:35:11] <jmbsvicetto> we may just make it mandatory the warning email
-[22:35:28] <Betelgeuse> let's move on if we want to handle more points
-[22:35:39] <Betelgeuse> We can come back to the discussion if there's time left.
-[22:35:41] <jmbsvicetto> This is mostly QA, until it become a repetitive and abusive behaviour of a developer
-[22:35:52] <wired> we're doing good
-[22:35:58] <jmbsvicetto> Betelgeuse: let's move the discussion back to the mls
-[22:36:20] <ferringb> scarabeus: agree: re: python, although that's realistically QA's role to crack the whip
-[22:36:57] <jmbsvicetto> wired: next point?
-[22:36:58] <wired> how about we don't enforce any policy, but allow QA to restrain teams when they go... too far?
-[22:37:30] <Betelgeuse> Don't like letting systems break and then picking up the peaces.
-[22:37:51] <jmbsvicetto> wired: such a policy is already in place
-[22:38:08] <ferringb> win 23
-[22:38:11] <jmbsvicetto> QA can already deal with developers that break the tree
-[22:38:11] <ferringb> merde. :)
-[22:38:22] <wired> jmbsvicetto: but is it enforced?
-[22:38:40] <scarabeus> i would say we look pretty undecided, so go for not-decided this time
-[22:38:43] <jmbsvicetto> QA has expressed a desire to enforce such policy
-[22:38:56] <scarabeus> i will try to sent some mailies
-[22:38:57] <wired> ok this is not going anywhere, so lets put it back to the MLs
-[22:39:09] <ferringb> agreed.
-[22:39:12] <wired> moving on:
-[22:39:19] <wired> - use of invalid DEPEND atom "EAPI_TOO_OLD" instead of calling die in global scope on eclasses
-[22:39:23] *** Joins: nirbheek (~nirbheek@gentoo/developer/nirbheek)
-[22:39:30] * ferringb twitches
-[22:39:39] <wired> ferringb: go ahead :p
-[22:39:41] <ferringb> +1 on die, -infinity on EAPI_TOO_OLD
-[22:39:41] <jmbsvicetto> dleverton_: Does ciaranm recall any reason for using it?
-[22:39:54] <scarabeus> that die works better
-[22:39:58] <scarabeus> from ebuild writter
-[22:40:02] <Betelgeuse> die will not stop anything
-[22:40:04] <scarabeus> if he uses repoman it gets caught
-[22:40:08] <Betelgeuse> EAPI_TOO_OLD does
-[22:40:17] <Betelgeuse> at least used to be that way
-[22:40:18] <jmbsvicetto> I like the idea of the depend
-[22:40:18] <scarabeus> with depend it gets broken in emerge
-[22:40:28] <scarabeus> i showed you guys the test
-[22:40:30] <ferringb> Betelgeuse: die will stop it from being used (and/or cached) in at least 2 out of the 3 managers
-[22:40:31] <scarabeus> with depend it dies on emerge
-[22:40:34] <jmbsvicetto> I wouldn't mind using a propper dep, though
-[22:40:38] <scarabeus> with die it dies on creating manifest
-[22:40:51] <Betelgeuse> ferringb: I remember Portage allowing emerge to continue
-[22:40:54] <ferringb> up until a recent paludis merge, it would also make paludis go rather cranky too during metadata
-[22:40:56] <Betelgeuse> ferringb: Might have changed since
-[22:41:11] <scarabeus> so first you catch if you emerge the thing, second cant be manifested and commited
-[22:41:15] <scarabeus> + we have --nodeps
-[22:41:16] <jmbsvicetto> virtual/invalid or something similar
-[22:41:22] <ferringb> Betelgeuse: equivalent to EAPI masking; it will roll past it but not use it last I'd tried it.
-[22:41:36] <ferringb> then yell that somethings went boom while it was trying to do it's thing.
-[22:41:37] <scarabeus> which technically should allow emerging stuff with forbidden eapi
-[22:42:14] <Betelgeuse> If we go the die route I would like to see a PMS patch specifying what it does in global scope.
-[22:42:16] <dleverton_> 20:41 < ciaranm> die in global scope used to be considered utterly illegal
-[22:42:19] <dleverton_> 20:41 < ciaranm> unfortunately it got left out of pms by accident, along with the ban on global scope output...
-[22:42:29] * ferringb notes that's opinion, not fact
-[22:42:38] <wired> die'ing at the repoman level sounds much better, this is something that should be caught by the dev
-[22:42:57] <jmbsvicetto> dleverton_: My understanding was that was the reason we moved from the die to the depend
-[22:43:24] <scarabeus> jmbsvicetto: i never seen reason with portage implementation
-[22:43:26] <jmbsvicetto> about repoman, why?
-[22:43:44] <ferringb> basically... die can be very ugly, but it blocks any potential invalid usages.  The con of such protection is that it reinforces that devs need to do checking of consuming ebuilds when doing changes of this sort (which quite frankly they should be double checking anyways)
-[22:44:51] <ferringb> the flaws with depend level is that the rest of the metadata is treated as valid, including the cache validation that goes with it
-[22:44:59] <jmbsvicetto> ferringb: Were do we expect the issue with the old EAPI showing up? I assume it's with the overlays
-[22:45:30] <jmbsvicetto> and probably a reasonable number of them don't run repoman
-[22:45:39] <scarabeus> jmbsvicetto: we speak about manifest
-[22:45:44] <scarabeus> repoman manifest does not work
-[22:45:48] <scarabeus> if it has the die
-[22:45:54] <scarabeus> the must create manifests :D
-[22:45:55] <jmbsvicetto> yes, but does it also fail on emerge manifest ?
-[22:46:04] <jmbsvicetto> emerge digest*
-[22:46:05] <ferringb> grr.  crappy connection.
-[22:46:25] <ferringb> jmbsvicetto: rephrase the question please
-[22:46:28] <jmbsvicetto> scarabeus: Are you sure people are using repoman manifest?
-[22:46:41] <jmbsvicetto> perhaps they're using ebuild digest
-[22:46:53] <scarabeus> http://paste.pocoo.org/show/241953/
-[22:47:03] <scarabeus> scarab@ugly-elf: ~/gentoo-x86/kde-base/ark $ ebuild ark-4.4.5.ebuild manifest
-[22:47:09] <scarabeus> repoman and ebuild do the same
-[22:47:10] <scarabeus> it bails out
-[22:47:21] <scarabeus> nothing else is really supported for creating manifests
-[22:47:23] <scarabeus> so tadada
-[22:47:28] <jmbsvicetto> scarabeus: ok
-[22:47:46] <jmbsvicetto> Do we want to vote on this?
-[22:47:48] <wired> so, shall we vote on this?
-[22:47:56] <ferringb> frankly, even if current tools didn't quite get it perfect... this is the route that should be taken, since injecting special values into DEPEND like that screws up the cache validation logic pretty heavily (and isn't friendly towards existing cache validation bits)
-[22:48:03] <ferringb> +1 on die as said, -infinity on depend.
-[22:48:15] <scarabeus> i would like to go with die
-[22:48:19] <wired> im with die as well
-[22:48:20] <wired> cleaner
-[22:48:43] <scarabeus> ok 4 for vote, so lets vote
-[22:48:46] <scarabeus> aye by me
-[22:49:04] <Betelgeuse> I would like it written down what die does in global scope.
-[22:49:32] <jmbsvicetto> I can live with both, although I don't like the concept of dieing on eclasses
-[22:49:59] <jmbsvicetto> I'd prefer us to find a way to "raise an exception"
-[22:50:08] <ferringb> jmbsvicetto: die is "raise an exception"
-[22:50:22] <ferringb> if you want literal raise/try/catch semantics... well.  you patch bash :P
-[22:50:23] <jmbsvicetto> I see it more as an call to exit
-[22:50:35] <ferringb> the manager supplies die
-[22:50:41] <ferringb> it's up to the manager what to do in that case
-[22:50:50] <jmbsvicetto> ferringb: The depend to me sounded a "softer approach"
-[22:50:51] <wired> dieing for this specific issue seems ok to me - not saying we should allow general die'ing in eclasses
-[22:51:12] <wired> so its over 10 minutes
-[22:51:17] <wired> on this topic
-[22:51:21] <ferringb> jmbsvicetto: the problem is that if the eclass cannot work with that eapi, the metadata it generates during that mismatch just isn't usable, period.
-[22:51:37] <jmbsvicetto> I agree with Betelgeuse that we should clear the consequences of the call to die on global scope
-[22:51:41] *** Joins: ABCD (~abcd@gentoo/developer/abcd)
-[22:52:02] <ferringb> fine by me.  I'd prefer it's usage be heavily limited to instances such as this also
-[22:52:08] <jmbsvicetto> ferringb: it's the manager tha generates the metadata, not the eclass
-[22:52:19] <ferringb> jmbsvicetto: both.  eclass sets the raw values
-[22:52:34] <jmbsvicetto> ok, I'll defer to you on this subject
-[22:52:36] <ferringb> jmbsvicetto: manager just grabs those values and records them (not arguable, recall I've written this sort of code twice now :P)
-[22:53:05] <wired> can we vote on this and move on? or do you want to look into it more?
-[22:53:30] * ferringb listens to the crickets
-[22:54:03] <Betelgeuse> wired: If you count the votes you already got a majority.
-[22:54:12] <Betelgeuse> But I don't know if ferringb changed since then.
-[22:54:34] <wired> lets clear this out then. who's in favor of die'ing?
-[22:54:39] <scarabeus> yes
-[22:54:44] <Betelgeuse> documentation first
-[22:55:22] <jmbsvicetto> I'll accept with propper documentation
-[22:55:33] <jmbsvicetto> +it
-[22:55:40] *** Joins: billie80 (~billie@gentoo/developer/billie)
-[22:56:12] <ferringb> Betelgeuse: "changed since then" ?
-[22:56:15] * wired is favor
-[22:56:31] <scarabeus> so patch to pms it is :]
-[22:56:33] <Betelgeuse> ferringb: I mean is it a yes without documentation
-[22:56:47] *** Quits: billie (~billie@gentoo/developer/billie) (Read error: Operation timed out)
-[22:57:25] <wired> ok, passed then, 3 to 2.
-[22:57:42] * ferringb stretches
-[22:57:47] <ferringb> sorry, meeting time.
-[22:57:53] <jmbsvicetto> Do we require the documentation or not?
-[22:57:55] <ferringb> will see if I can do both, but no gurantees
-[22:58:01] <wired> ferringb: we're almost done
-[22:58:01] <ferringb> devmanual should be updated for this
-[22:58:13] <Betelgeuse> so 3 for documentation and 2 without
-[22:58:14] <scarabeus> wired: its still over 50% :]
-[22:58:15] <jmbsvicetto> ok, then we have 4 votes for documentation?
-[22:58:23] <wired> jmbsvicetto: we do need documentation
-[22:59:01] * ferringb will do the devmanul patch if no one else does
-[22:59:05] <wired> ferringb: great, thanks
-[22:59:09] <ferringb> sorry, have to bail.  they pay my bills and such ;)
-[22:59:20] <wired> hehe, ok
-[22:59:21] <jmbsvicetto> see you later
-[22:59:23] <scarabeus> cya
-[22:59:23] <wired> ferringb: thanks, c ya
-[22:59:27] <Betelgeuse> PMS too if we wan't consistency.
-[22:59:28] <ferringb> may be back in about a bit, but we'll see
-[22:59:45] <wired> next point
-[22:59:47] <wired> mailing lists
-[22:59:48] <Betelgeuse> wired: We can try seeing if we get a majority on the rest of the points without ferringb
-[22:59:59] <wired> Betelgeuse: yeah
-[23:00:05] <wired> we only have mailing lists left anyway
-[23:00:21] <scarabeus> the cross posting is evil :]
-[23:00:23] <wired> so
-[23:00:25] <wired> first of all
-[23:00:34] <wired> petteri suggested punting -council
-[23:00:46] <wired> i personally think it has its place, so I don't agree :)
-[23:00:55] <jmbsvicetto> I'd like to have it around
-[23:01:16] <jmbsvicetto> and would like council topics being discussed there to make it easier to find previous discussions
-[23:01:38] <Betelgeuse> How do you know what is a council topic?
-[23:01:54] <Betelgeuse> Before being brought for council they should be discussed generically.
-[23:02:01] <Betelgeuse> jmbsvicetto: So you are in fact making it hard to find stuff.
-[23:02:21] <jmbsvicetto> I agree issues should be discussed before being brought to the council
-[23:02:32] *** Quits: Zorry (~zorry@gentoo/developer/zorry) (Read error: Connection reset by peer)
-[23:02:33] <wired> Betelgeuse: council agendas and discussion on the agendas fit in -council. issues themselves should have their own -dev threads
-[23:02:40] <scarabeus> i would be ok with having it on -project
-[23:02:49] <jmbsvicetto> I meant the agenda emails and any discussions about topics in an agenda
-[23:02:52] <scarabeus> what for we need quiet list
-[23:03:26] <Betelgeuse> If we want to avoid fragmentation we should only discuss the contents of the agenda not the issues themselves.
-[23:03:40] <Betelgeuse> Both -project and -council are low traffic.
-[23:03:48] <Betelgeuse> I don't see why we want to fragment like that.
-[23:04:11] <wired> Betelgeuse: is that bad? having seperate lists makes them easier to filter
-[23:04:38] <scarabeus> i tend to agree with peteri
-[23:04:46] <scarabeus> having stuff on one place is quite convinient
-[23:05:10] <jmbsvicetto> hmm, 2 vs 2 ?
-[23:05:14] <Betelgeuse> I don't value being able to easily filter council agendas (the only frequent traffic to -council) over less lists.
-[23:05:21] <wired> so scarabeus you think we should move -council to -project? or to -dev?
-[23:05:32] <scarabeus> just project
-[23:05:49] <Betelgeuse> That also makes it clearer not to discuss technical issues.
-[23:06:02] *** Joins: Zorry (~zorry@gentoo/developer/zorry)
-[23:06:55] <wired> hmm
-[23:07:28] <wired> what about crossposting to -dev (that was requested by a few devs?)
-[23:08:05] <jmbsvicetto> wired: Betelgeuse already mailed project about that and opened a bug to infra to add a note forbidding it
-[23:08:05] <Betelgeuse> wired: http://archives.gentoo.org/gentoo-project/msg_4584599e3f2a5e8ebc590ae3c623e7eb.xml
-[23:08:28] <Betelgeuse> will be announced on gentoo-dev once we get documentation in place
-[23:08:41] <wired> ok
-[23:09:07] <jmbsvicetto> Do you think we can reach any decision here?
-[23:09:25] <Betelgeuse> We can put it on the table again next time if we still have 2-2
-[23:09:27] <jmbsvicetto> I don't think so, so would suggest sending this back to the mls again
-[23:10:16] *** Joins: c1pher|home (~smitdane@resnet75-219.resnet.buffalo.edu)
-[23:10:22] <Betelgeuse> I can see all threads on gentoo-council at once on my screen now btw
-[23:10:29] <Betelgeuse> from 2010
-[23:10:49] <jmbsvicetto> I just noticed there are 3 bugs assigned to council
-[23:11:01] <Betelgeuse> give the area a little more space and it extends over a year
-[23:12:20] <jmbsvicetto> shall we move this back to the mls and quickly go over the open bugs?
-[23:12:22] <wired> lets move the ml talk to ml
-[23:12:25] <wired> yeah
-[23:12:35] <jmbsvicetto> ok, 3 bugs:
-[23:12:37] <jmbsvicetto> bug 234706
-[23:12:39] <willikins> jmbsvicetto: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-[23:12:52] <jmbsvicetto> bug 256451
-[23:12:54] <willikins> jmbsvicetto: https://bugs.gentoo.org/256451 "Council meeting notes appear to be missing"; Doc Other, Other; NEW; gentoo-bugs@allenjb.me.uk:council@g.o
-[23:13:02] <wired> bug 256453
-[23:13:04] <willikins> wired: https://bugs.gentoo.org/256453 "Documentation on Gentoo Council meeting processes, particularly regarding agenda items"; Doc Other, Other; NEW; gentoo-bugs@allenjb.me.uk:council@g.o
-[23:13:30] <scarabeus> i see one more
-[23:13:37] <scarabeus> bug 234713
-[23:13:38] <jmbsvicetto> I suggest we ask Halcy0n if we wants to resume work on the first bug
-[23:13:39] <willikins> scarabeus: https://bugs.gentoo.org/234713 "GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)"; Gentoo Linux, Unspecified; RESO, LATE; dberkholz@g.o:council@g.o
-[23:13:47] <scarabeus> but it should just be remarked proprely i guess :]
-[23:14:33] <jmbsvicetto> about 2nd bug, we can ask ferringb if still wants to do it
-[23:14:49] <wired> i can take 256453
-[23:15:07] <jmbsvicetto> ok
-[23:15:18] <wired> that was fast
-[23:15:41] <jmbsvicetto> we should reassign bug 237381 back to us and I propose to take care of it
-[23:15:43] <willikins> jmbsvicetto: https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:dberkholz@g.o
-[23:15:54] <wired> great
-[23:15:58] * wired updates summary
-[23:16:20] <jmbsvicetto> For the record, the complete list of bugs we need to check is https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailcc1=1&emailtype1
-[23:16:40] <scarabeus> jmbsvicetto: i also check for resolved later status ;]
-[23:16:54] <scarabeus> also i think maybe mark will be interested in 234706 :]
-[23:16:54] <jmbsvicetto> scarabeus: yeah, let me check those as well
-[23:16:58] <scarabeus> i certainly am
-[23:17:09] <scarabeus> because we nowdays again see quite few archies lacking manpower
-[23:17:59] <jmbsvicetto> So, anything else?
-[23:18:17] <jmbsvicetto> I'm a bit tired and would like to get some dinner
-[23:18:17] <wired> jmbsvicetto: your link gives 5000 bugs?
-[23:18:25] <scarabeus> it got stripped :P
-[23:18:29] <scarabeus> wired:
-[23:18:32] <wired> explains it
-[23:18:39] <wired> ok
-[23:18:52] <wired> jmbsvicetto: yeah we're pretty much done
-[23:19:02] <wired> any dev want to add anything?
-[23:19:06] <scarabeus> so again lets see if community wants to talk with us
-[23:19:17] <jmbsvicetto> wired: wait, we're missing one very important detail
-[23:19:23] <wired> ofcourse
-[23:19:24] <jmbsvicetto> Who will chair next meeting?
-[23:19:25] <wired> next chair
-[23:19:36] <Betelgeuse> jmbsvicetto: we also need to approve the summary
-[23:19:49] <scarabeus> jmbsvicetto: well thats simple, since noone volunteered i am fallback :]
-[23:20:29] *** Quits: nirbheek (~nirbheek@gentoo/developer/nirbheek) (Ping timeout: 260 seconds)
-[23:20:35] <jmbsvicetto> scarabeus: ok, thanks
-[23:20:37] <jmbsvicetto> Betelgeuse: true
-[23:21:49] <scarabeus> and community is silent :P
-[23:21:53] <jmbsvicetto> wired: feel free to update the die summary ;)
-[23:21:56] <scarabeus> ok guys look on this:
-[23:21:56] <scarabeus> http://paste.pocoo.org/show/241957/
-[23:22:03] <jmbsvicetto> wired: looks good to me the current summary
-[23:22:43] <Betelgeuse> scarabeus: into final -> into the final
-[23:23:08] <Betelgeuse> the sentences don't flow well
-[23:23:30] <wired> jmbsvicetto: you missed! :P
-[23:23:40] <Betelgeuse> scarabeus: it's potentially
-[23:24:23] <Betelgeuse> scarabeus: But good start. Some native will probably contribute a better version once you put that up.
-[23:24:44] <scarabeus> ok i will sent it to the dev
-[23:24:55] <Betelgeuse> remember pr
-[23:25:29] <Betelgeuse> scarabeus: I would include instructions how to override it
-[23:25:32] <Betelgeuse> scarabeus: namely LDFLAGS=""
-[23:25:53] <jmbsvicetto> wired: ok from me for the current summary
-[23:26:08] <scarabeus> yeah summary looks fine after you polished it guys :]
-[23:26:13] <scarabeus> Betelgeuse: you see the wave? :]
-[23:26:23] <Betelgeuse> nope
-[23:26:56] <wired> Betelgeuse: pasting to dpaste fails (needs reformatting), so it'd be better if I invited you to the wave to approve
-[23:27:01] <jmbsvicetto> wired: I suggest you submit a link to the final version so others can express their view on it
-[23:27:20] <wired> jmbsvicetto: submit to...?
-[23:27:28] <wired> council@ ?
-[23:27:29] <jmbsvicetto> dpaste
-[23:27:31] <Betelgeuse> I am going to bed.
-[23:27:39] <Betelgeuse> It's fine if you three agree on it.
-[23:27:44] <jmbsvicetto> ok, I'm going to grab dinner
-[23:27:46] <jmbsvicetto> see you later
-[23:27:49] <Betelgeuse> I will just complain tomorrow if it's lousy.
-[23:27:53] <jmbsvicetto> hehe
-[23:28:04] *** Joins: nirbheek (~nirbheek@gentoo/developer/nirbheek)
-[23:28:10] <wired> Betelgeuse: http://dpaste.com/222131/
-[23:28:28] <wired> great, thanks everyone for being here, good work :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100809-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100809-summary.txt
deleted file mode 100644
index fd5abc5c51..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100809-summary.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Gentoo Council 2010/08/09 meeting agenda / summary:
-
-
-1) allow all members to show up (5 min)
-  Petteri (Betelgeuse) 12 min late
-  Mark (Halcy0n) 15 min late
-
-2) voting
-  2a) we have nothing to vote this time, nobody wanted anything YAY :)
-
-3) discussion
-  3a) from last council meeting: the mailing list situation
-    * merge -project and -council mls into one (-project)
-      ** for: scarabeus, betelgeuse, chainsaw, ferringb (as experiment first
-         that could be reverted), halcy0n 
-      ** against: jmbsvicetto, wired
-    Fill up bug for infra to do this. (scarabeus will fill the bug)
-
-  3b) from last council meeting: eclass API changes
-    * document better what PV means http://bugs.gentoo.org/331921
-    * make it easier for QA to take action when common sense is *not* used and
-      things are broken
-    * QA team will update its internal policies about the process to request the
-      suspension of commit rights from a developer. The revision might involve an
-      update to GLEP 48. (QA mailinglist) 
-
-  3Y) additional deviation: fallout and suspension policies (per ferringb
-    request)
-    * learn from the python breakage to promote the importance of current
-      policies and why developers should use them properly
-    * use this as an example of how not do things and how it should be dealt
-      with and start a discussion of how to recover from it and how to ensure we
-      can reach users in such cases
-    * continue discussion on -project ml (per 3a) 
-
-  3Z) council comment about the Portage breakage fallout
-    * jmbsvicetto argued that Gentoo needs to acknowledge the incident, ensure
-      affected users can find correct documentation on how to fix it and make it
-	  clear that the practices that lead to it are neither appropriate nor acceptable 
-
-  3c) EAPI 4 status (jmbsvicetto nominate this so we actualy do something new)
-    * ferringb will review the status, and try to find some minion to help him
-
- 4) Bugs assigned to council@ in bugzilla and their progress
-	http://bugs.gentoo.org/buglist.cgi?quicksearch=assignedto,cc:council@gentoo.org
-
-    234706
-      halcy0n will create new draft proposal soonish
-    256451
-      last summary tbd by betelgeuse
-    256453
-      wired wrote nice patch and it will be updated according to the comments on
-      -project mailinglist
-    237381
-      jmbsvicetto plans to have something to show next mont meeting
-
-5) select the chair for following meeting
-  chair: wired
-  date: 2010-08-23 
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100809.txt b/xml/htdocs/proj/en/council/meeting-logs/20100809.txt
deleted file mode 100644
index d7a17495ee..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100809.txt
+++ /dev/null
@@ -1,464 +0,0 @@
-[22:00:43] <wired> its about time
-[22:00:44] <scarabeus> well it is supposed to start now :]
-[22:00:55] <wired> scarabeus: ah you're here :p do the honors =]
-[22:01:32] *** scarabeus changes topic to 'Meeting in progress: http://archives.gentoo.org/gentoo-dev/msg_73124be313f6404c92a6ccc033970a6b.xml | http://dev.gentoo.org/~wired/localtime.php?time=1900'
-[22:01:52] <scarabeus> so lets start with rollcall
-[22:02:06] *** ferringb is now known as he-man
-[22:02:14] * scarabeus here :]
-[22:02:18] <jmbsvicetto> here
-[22:02:20] <he-man> yes, let's continue w/ rollcall ;)
-[22:02:22] *** Joins: NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon)
-[22:02:25] <Chainsaw> Chainsaw is present.
-[22:02:29] *** he-man is now known as ferringb
-[22:02:30] <Chainsaw> NeddySeagoon just appeared as well.
-[22:02:35] * wired here
-[22:02:37] <Chainsaw> Ah, and ferringb came out of hiding.
-[22:02:39] <Chainsaw> Halcy0n: ping
-[22:02:50] <ferringb> Chainsaw: I put the sword away you see.
-[22:03:10] <ferringb> anyone care to chair?
-[22:03:16] <wired> ferringb: scarabeus is chairing
-[22:03:21] <ferringb> 'k.
-[22:03:27] <scarabeus> yes i am chairing, i am just writting summary as we speak
-[22:03:35] <scarabeus> they killed our wave :(
-[22:03:53] <wired> scarabeus: wave works
-[22:03:56] <scarabeus> so we wait few more minutes for the last 2 people
-[22:04:04] <scarabeus> wired: i read blog it is going to be killed
-[22:04:08] <wired> scarabeus: end of year
-[22:04:11] <wired> so we have time to replace it
-[22:04:12] <wired> ;p
-[22:04:14] <scarabeus> wired: aha
-[22:04:22] <scarabeus> wired: erm, could you create the wave thingie then plz
-[22:04:25] <wired> yeah
-[22:04:36] <ferringb> halcy0n?
-[22:04:41] <scarabeus> so we will wait couple of minutes on Peteri and Mark anyone against?
-[22:05:14] <Chainsaw> Not a problem. Let me get some water.
-[22:06:00] * NeddySeagoon fetches beer
-[22:07:04] <wired> scarabeus: ready
-[22:07:16] <jmbsvicetto> who is missing?
-[22:07:25] <Chainsaw> jmbsvicetto: Halcy0n.
-[22:07:36] <scarabeus> and Peteri
-[22:07:37] <wired> and betelgeuse
-[22:07:48] <Chainsaw> Did we exchange phone numbers?
-[22:07:53] <Chainsaw> Because if we did, we can call them.
-[22:08:14] <Chainsaw> (I know I left mine, and nobody called me when I missed one...)
-[22:09:02] <scarabeus> i changed my quassel core, and i didnt print it before, so i lack them :/
-[22:09:21] * ferringb notes meetings should start at 19:00... roll call should start at 18:50
-[22:09:21] <wired> !seen betelgeuse
-[22:09:22] <willikins> wired: Betelgeuse was last seen 1 day, 2 hours, 6 minutes and 33 seconds ago, saying "zmedico, ferringb: #gentoo-libbash if around" in #gentoo-portage
-[22:09:37] <scarabeus> !seen Halcy0n
-[22:09:38] <willikins> scarabeus: Halcy0n was last seen 2 days, 3 hours, 2 minutes and 44 seconds ago, saying "NeddySeagoon: sure" in #gentoo-qa
-[22:09:58] <wired> Chainsaw: good point, it didn't cross our minds...
-[22:09:59] <ferringb> just a general comment, since council wise, the 'hourly' meeting has a good chunk of time consumed for waiting on folk to show... should lock down a 60 minute block
-[22:10:25] <scarabeus> well max vaiting is 10 minutes
-[22:10:32] <ferringb> and it be 10 minutes
-[22:10:36] * wired doesn't think we should be limited to an hour, unless you guys have to go
-[22:10:37] <Chainsaw> scarabeus: I agree, we have vaited long enough. Let's proceed.
-[22:10:49] <scarabeus> ok any remarks on agenda?
-[22:10:51] <scarabeus> in topic
-[22:10:56] <ferringb> Chainsaw: you realize this gets logged and than posted (normally) in full to the site, right?  ;)
-[22:11:04] <wired> we'll strip it
-[22:11:05] <wired> ;p
-[22:11:08] <ferringb> yeah, just saying
-[22:11:09] <Chainsaw> wired: Thank you.
-[22:11:22] <ferringb> well.  halcy0n's earned his slacker mark I guess
-[22:11:32] <scarabeus> Chainsaw: you need to talk with infra to strip it, and hope noone else will log it
-[22:11:45] <scarabeus> anyway i guess no remarks, nor voting proposals
-[22:11:55] <scarabeus> so lets get to the point 3a)
-[22:12:00] *** Joins: Betelgeuse (~betelgeus@gentoo/developer/Betelgeuse)
-[22:12:00] <scarabeus> the mailing lists situation
-[22:12:11] <Chainsaw> There he is! Hi :)
-[22:12:14] <Betelgeuse> hi
-[22:12:17] <scarabeus> cool
-[22:12:20] <Chainsaw> We are at point 3a in the agenda.
-[22:12:29] <Betelgeuse> I need to find out why autojoin here is not working
-[22:12:36] <ferringb> Betelgeuse: query if you want backlogs... nothing particularly pressing in it however
-[22:12:47] <wired> backlogs for what? roll call? :P
-[22:12:54] <scarabeus> so last time we tried to vote about it, and we ended up in tie
-[22:12:58] <scarabeus> wanna try it again?
-[22:13:09] <Chainsaw> scarabeus: What are we voting about?
-[22:13:16] <scarabeus> the proposal was to disband gentoo-council ml in favor of gentoo-project
-[22:13:34] <scarabeus> so there wont be so much cross mails
-[22:13:56] <Chainsaw> Both are so very quiet that I don't see any harm in combining them.
-[22:13:57] <Chainsaw> In favour.
-[22:14:03] <Betelgeuse> scarabeus: in favor
-[22:14:08] <scarabeus> in favor
-[22:14:09] * ferringb is more inclined to vote for the destruction of -project, rather than shifting council ml to -project
-[22:14:22] <Halcy0n> here now.
-[22:14:34] <jmbsvicetto> I'd like to keep both
-[22:14:55] <Chainsaw> Halcy0n: Move -council ML to -project, in favour or against?
-[22:15:01] <Halcy0n> Computer problems at work.
-[22:15:02] <Halcy0n> For.
-[22:15:17] <Chainsaw> ferringb: Is that for or against?
-[22:16:06] <ferringb> for, I guess, although I'd want this to be an experiment initially
-[22:16:29] * wired is against,
-[22:16:30] <Chainsaw> ferringb: Everything we do is an experiment, because anyone can put it up for a vote again.
-[22:16:37] <ferringb> I'm not convinced project, with it's flamey nature, is the best place, but having council off in it's own ml isn't particuarly useful.  frankly I'd shift it to -dev rather than -project.
-[22:17:34] <Halcy0n> ferringb: basically my thinking as well.  I don't like having so many lists.
-[22:17:36] <Chainsaw> scarabeus: Are we tied again or did that solve it?
-[22:17:43] <scarabeus> we are not tied
-[22:17:44] <ferringb> 4 yays == majority
-[22:17:48] <scarabeus> i was writting it
-[22:17:53] <ferringb> at least when all 7 folk are around
-[22:17:56] <scarabeus> 5 yays if we count mark
-[22:18:32] <scarabeus> ok so anyone knows how to do the merge?
-[22:18:44] <Betelgeuse> scarabeus: file bug to infra
-[22:18:45] <Chainsaw> Infra does! Can you ask them to strip my phone number as well?
-[22:19:00] <ferringb> Chainsaw: we commit the logs ourselves, so yeah, it'll get stripped
-[22:19:08] <Chainsaw> ferringb: Thank you.
-[22:19:10] <scarabeus> Chainsaw: are you sure you dont want to file own bug?, i would recommend something with high priority
-[22:19:45] <Chainsaw> scarabeus: It's alright, they don't like me anymore after that e-mail adventure.
-[22:19:52] <scarabeus> ah
-[22:19:57] <wired> lets move on :)
-[22:20:00] <scarabeus> ok 1 minute left on this topic
-[22:20:02] <scarabeus> or we move on
-[22:20:03] <scarabeus> :]
-[22:20:09] <Chainsaw> Yes, let's move on.
-[22:20:16] <ferringb> clarification of 3.b would be useful btw
-[22:20:22] <ferringb> phrasing there is a bit vague
-[22:20:44] <scarabeus> it is about arfrever changes in eclasses
-[22:20:59] <scarabeus> he essentialy changed complete eclass api and modified ebuilds in tree to suit this
-[22:21:05] <wired> 	* should there a policy about eclass API changes?
-[22:21:07] <wired> 		-> we didn't reach a decision here, talk will continue in the mailing lists
-[22:21:15] <wired> ^^ last agenda/summary
-[22:21:35] <scarabeus> i assume better would be to have quite static api and for such major rewrites new eclass should be deployed
-[22:21:41] * ferringb notes we're in shitty territory here- basically trying to legislate common sense
-[22:21:43] <scarabeus> see x-modular versus xorg-2
-[22:21:50] <Betelgeuse> scarabeus: that's already the rule
-[22:21:58] <Chainsaw> ferringb: Recent actions suggest we will have to.
-[22:22:06] <Betelgeuse> Chainsaw: dealt with
-[22:22:24] <wired> legislation won't change much in cases like this
-[22:22:58] <ferringb> Chainsaw: the issue there is more speeding up the devrel/qa feedback loop, rather than legislating the definition of sanity imo
-[22:23:22] <Chainsaw> ferringb: As long as something gets done. Recovering portage was not fun.
-[22:23:26] <ferringb> said loop has done it's job (a suspension is active) also, so the mechanism does work, albeit a bit slow
-[22:23:32] <scarabeus> how about leaving this one for QA, i guess we acted quite fast when he broke portage
-[22:23:35] <ferringb> Chainsaw: whiner.  you're not stuck cleaning up the python versions :P
-[22:23:41] <wired> imo we don't need a strict policy. these things can happen, policy or not
-[22:23:55] <Chainsaw> wired: I see that action has been taken, so I'm willing to back off now.
-[22:23:58] <scarabeus> we can do the stop/revert and then devrel do their vote, and if is against QA must explain stuff
-[22:24:09] <ferringb> scarabeus: rephrase that statement please
-[22:24:24] <Chainsaw> Yes, I was also unable to decode that.
-[22:24:53] <scarabeus> QA can do the stop access/revert commit and then devrel do their vote if it was fair (if dev complains), and if  devrel is against QA decision, QA must explain :]
-[22:25:22] <ferringb> scarabeus: in other words, leave it to the appropriate organ of gentoo to handle rather than the council sticking it's nose in?
-[22:25:28] <wired> +1
-[22:25:40] <Halcy0n> Agreed.
-[22:25:43] * ferringb notes by and large, that's his view of how the council should be operating in cases like this.
-[22:25:47] <scarabeus> yes but expect unhappy devs, because i wont let python happen again
-[22:26:00] <wired> unhappy devs > broken systems
-[22:26:02] <ferringb> when shit's screwed up or not getting done properly, step in and knock some heads and sort it out, but stay out of it the rest of the time ;)
-[22:26:14] <scarabeus> okay
-[22:26:23] <scarabeus> so any ideas how to summarise it?
-[22:26:25] <ferringb> scarabeus: python is in the process of being cleaned up.  this situation should not re-occur in that project.
-[22:26:34] <wired> > as in "preferred than"
-[22:26:47] <scarabeus> Betelgeuse: any objections to above, since you are devrel boss? :]
-[22:26:54] <ferringb> Halcy0n: can you clarify the policy documentation for this by chance?
-[22:27:05] <Betelgeuse> ferringb: GLEP 48
-[22:27:08] <ferringb> specifically "don't make 2.6.5 be in reality 2.6.6" ?
-[22:27:12] *** Joins: tanderson (tanderson@gentoo/developer/tanderson)
-[22:27:16] <Betelgeuse> ferringb: ah that
-[22:27:30] <Halcy0n> ferringb: We can make it more clear in devmanual.
-[22:27:33] <Betelgeuse> scarabeus: I agree with ferringb.
-[22:27:35] <ferringb> Halcy0n: would be helpful
-[22:27:43] <scarabeus> ook goodie
-[22:27:56] <ferringb> at the very least, it removes the wiggle room for people pulling shit like this and makes it easier for qa/devrel to smack 'em on the nose
-[22:28:12] <jmbsvicetto> scarabeus / Halcy0n: I think one thing we can change is the current rule about how QA can ask for access to be suspended
-[22:28:47] <ferringb> or QA needs to delegate the powers for that to more than just one person
-[22:28:56] <Halcy0n> You mean going to infra for suspension?  Or who can ask for it?
-[22:29:05] <Betelgeuse> bug 331921
-[22:29:07] <jmbsvicetto> at the moment it falls to the QA lead. In case he's absent, we can have at least 2 QA members ask for the suspension of access and later deal with that - full QA meeting, devrel review, etc
-[22:29:07] <willikins> Betelgeuse: https://bugs.gentoo.org/331921 "Clarify what PV represents in devmanual"; Doc Other, Devmanual; NEW; betelgeuse@g.o:qa@g.o
-[22:29:28] <Halcy0n> I can agree with that.
-[22:29:59] * ferringb notes that works
-[22:30:06] <Chainsaw> That looks sensible.
-[22:30:12] <Chainsaw> I don't believe that needs change.
-[22:30:21] <scarabeus> Halcy0n: ok will you sent
-[22:30:25] <ferringb> although a single QA dev asking for it should work still in my opinion- the simple fact is that if they abused that ability, they would very quickly have their ass in the sling
-[22:30:27] <scarabeus> Halcy0n: erm turncated
-[22:30:33] <ferringb> either way, the 2 qa members thing works ;)
-[22:30:38] <Halcy0n> It would mean modifying GLEP 48.  If you want, I can bring it up with the whole team and get everyone on board, or just make it the change?
-[22:30:41] <scarabeus> Halcy0n: will you sent mail to qa ml so we can have some discussion about it in team? :]
-[22:30:57] <Halcy0n> scarabeus: yup.
-[22:31:08] <Betelgeuse> Halcy0n: GLEP 48 is already: "If a particular developer persistently causes breakage, the QA team may request that devrel re-evaluates that developer's commit rights. "
-[22:31:17] <Betelgeuse> Halcy0n: So you are just clarifying what the QA team means
-[22:31:32] <jmbsvicetto> Betelgeuse: Do you think we need to talk about it inside devrel? If it's a change to GLEP48 I don't think we need to change anything else on devrel pocliy
-[22:31:34] <ferringb> Halcy0n: eitherw ay, the glep should be amended regardless of the process to get that point- really would be nice if we can keep that doc authorative. ;)
-[22:31:35] <jmbsvicetto> policy*
-[22:31:55] <Halcy0n> Betelgeuse, ferringb: I'll bring it up with the team and we'll come back with something.
-[22:32:18] <ferringb> works for me.
-[22:32:36] <ferringb> scarabeus: mind if we deviate for a second while we're on the topic of the suspension btw?
-[22:33:07] <scarabeus> go ahead
-[22:33:09] <ferringb> specifically, there doesn't seem to be a helluva lot of awareness of it... which makes sense, 'cept in doing cleanup python wise for example, folks who should know don't
-[22:33:12] <scarabeus> we have one topic left anyway :]
-[22:33:19] <scarabeus> if others are not against
-[22:33:31] <ferringb> which leaves people in a slightly dicey situation
-[22:33:34] <Betelgeuse> ferringb: We are not in the business of public humiliation.
-[22:33:42] <ferringb> Betelgeuse: agreed
-[22:34:11] <ferringb> Betelgeuse: problem is, the team members do need to know when it's a direct affect on the work/responsibilities
-[22:34:49] <ferringb> point is, and I'm well aware there is no right/wrong in this case, it's something that needs consideration next time around
-[22:35:10] <ferringb> could just leave it at that if desired
-[22:35:10] <Betelgeuse> ferringb: Not really anything council needs to address. Seems like an oversight on my part.
-[22:35:39] <ferringb> Betelgeuse: fair enough.  honestly the discussion got me thinking about that issue, and I brought it up- may not have been the best forum for it.
-[22:35:42] <jmbsvicetto> ferringb: My concern about this issue is from a different angle. We (Gentoo) should acknowledge this incident, we should ensure users are not hitting it without finding any info on how to fix it and make it clear that the practices that lead to it are not appropriate nor acceptable
-[22:36:05] <ferringb> jmbsvicetto: you're blurring a breakage/QA incident, vs the repercussions to the dev
-[22:36:25] <Chainsaw> On that subject, the planet post from Diego has a mangled patch URL.
-[22:36:36] <Chainsaw> (And is truncated!)
-[22:37:01] <ferringb> blar.  will get it sorted
-[22:37:02] <jmbsvicetto> I don't care about the specific dev. The concern here is about Gentoo, the users and practices that shouldn't exist - the particular dev that caused it is irreleavnt
-[22:37:06] <jmbsvicetto> irrelevant*
-[22:37:26] <Chainsaw> ferringb: Would a news item work? I believe affected users can still read those?
-[22:37:32] <wired> you're just talking about different things
-[22:37:36] <ferringb> Chainsaw: affected users couldn't even sync
-[22:37:42] <jmbsvicetto> Chainsaw: I'd prefer to see a full article in our homepage
-[22:37:43] <ferringb> Chainsaw: so a news item is pointless
-[22:37:45] <scarabeus> guys you are talking about 2 things now
-[22:37:49] <Chainsaw> Oh right. I could cvs up, so I never really noticed that.
-[22:37:51] <Chainsaw> jmbsvicetto: Agreed.
-[22:38:00] <scarabeus> 1) the breakage and its fixing
-[22:38:00] <scarabeus> 2) the policy around the situation
-[22:38:12] <Chainsaw> scarabeus: Yes, I am making a concerted effort to move away from a difficult subject. It was working.
-[22:38:23] <scarabeus> :P
-[22:38:23] <ferringb> #1 is sorted at this point, doesn't need discussion.  the python version issues are being worked on also (I'm tracking that right now)
-[22:38:33] <scarabeus> great
-[22:38:44] <ferringb> #2 was the main point I was curious about, although perhaps delaying it to the next meeting is wise
-[22:39:00] <scarabeus> ferringb: so i take it as "QA is over python now" :P
-[22:39:07] <scarabeus> and yes deffering might be good idea
-[22:39:14] <scarabeus> but fire up discussion on -project :]
-[22:39:21] <Betelgeuse> I think drafting a process how to handle bad breakages is in order.
-[22:39:22] <scarabeus> so we dont start empty handed discussion
-[22:39:29] <Betelgeuse> Someone needs to champion that.
-[22:39:33] <Betelgeuse> Any volunteers?
-[22:39:44] * ferringb can offer advice, but has enough on his plate already
-[22:39:52] <scarabeus> me with my english and social skills, bad idea
-[22:39:56] <jmbsvicetto> scarabeus: I think we already have policies for this. At this point I think all we need to do is to recall everyone this case shows why they're important
-[22:40:08] <ferringb> scarabeus: get a copy editor than... :P
-[22:40:16] <Betelgeuse> jmbsvicetto: We don't really have anything for the communication to users.
-[22:40:23] <scarabeus> jmbsvicetto: so you want to make this more of example how not to do things and how it should be delt with?
-[22:40:33] <jmbsvicetto> So it's not about assigning blame, but about having people understand the importance of some policies and practices
-[22:40:54] <wired> and how thousands of users depend on those
-[22:41:18] <jmbsvicetto> Betelgeuse: That is true. I meant about devs following certain policies
-[22:41:46] <jmbsvicetto> Betelgeuse: talking about how to ensure a safe / quick recovery and how to reach users in such cases might be productive
-[22:42:25] <scarabeus> ok guys so lets move it to the ml, we are on this stuff for 20 minutes
-[22:42:28] <jmbsvicetto> scarabeus: I'd start the discussion with that tone
-[22:42:38] <scarabeus> jmbsvicetto: oky :]
-[22:42:44] <scarabeus> jmbsvicetto: hope you are reading summary on wave
-[22:42:57] <Betelgeuse> I can put that on my list of things to do after GSoC is over if no-one else wants to take it now.
-[22:42:57] <scarabeus> jmbsvicetto: and feel free to adjust my wording there
-[22:43:35] <scarabeus> ok rest of this stuff -> ml
-[22:43:39] <scarabeus> so 3c
-[22:43:42] <scarabeus> eapi4 status
-[22:43:54] <scarabeus> jmbsvicetto: i have no idea what you ment by nominating this
-[22:43:56] <scarabeus> so amuse us :]
-[22:44:02] <jmbsvicetto> peper / zmedico: ping ?
-[22:44:14] <ferringb> jmbsvicetto: you trying to find out the state of eapi4 support in portage, or
-[22:44:19] <jmbsvicetto> scarabeus: I forgot to ask you to ping them about the status
-[22:44:44] <jmbsvicetto> ferringb: mostly that and what is still desired / relevant from the original EAPI-4 specification
-[22:44:52] <scarabeus> i had no idea what was to the topic, i was thinking a) status report b) what we want to merge into the specs
-[22:45:00] <jmbsvicetto> ferringb: given the recent proposals for a new EAPI
-[22:45:11] <jmbsvicetto> scarabeus: that too
-[22:45:22] <ferringb> yeah, it would be good to go through eapi4 with a fine toothed comb and spot exactly what is desired that's in it, versus what got shoved in without much review
-[22:45:32] <ferringb> (community/develop review specifically)
-[22:45:47] <scarabeus> ferringb: wanna do it?
-[22:45:53] <ferringb> not really, no
-[22:45:57] <ferringb> but I'm suited to do so I suppose
-[22:46:15] <jmbsvicetto> How about we use our powers to nominate a person / group to look at this for X weeks?
-[22:46:15] <scarabeus> i guess you have most skills for that
-[22:46:18] <Betelgeuse> What I would be interested in is if there's enough new stuff ready in Portage to get a new EAPI out.
-[22:46:22] <jmbsvicetto> and then report back
-[22:46:34] <jmbsvicetto> unless some of us want to deal directly with this
-[22:46:34] <peper> jmbsvicetto: ?
-[22:46:49] <ferringb> Betelgeuse: there is a fair amount of support in portage for eapi4 bits at this point- few is the main person to talk to in re: to the status of it (he was the one doing the work)
-[22:47:02] <Betelgeuse> few_: ping
-[22:47:07] <jmbsvicetto> peper: Is there anything you can tell us about the current status of EAPI-4 ?
-[22:47:29] <jmbsvicetto> peper: or about new features desired for a later EAPI that could possibly be added to the next EAPI
-[22:47:30] <peper> I think you are mistaking me for someone else ;)
-[22:47:33] <scarabeus> i would like eapi done otherwise a bit; new features developed into portage/paludis/anything else and documented with EAPI="in-move" or whatever for just testing (banned for in-tree usage of course) and when people want all the new shiny stuff they just ask for eapi bump.
-[22:47:45] * ferringb suggests this should be delayaed till next meeting- we can do a fast rev meeting in 2-3 weeks if needed
-[22:47:53] <Chainsaw> scarabeus: Please don't, EAPI is messy enough as it is.
-[22:47:54] <jmbsvicetto> peper: Weren't you in the PMS team?
-[22:47:58] <ferringb> namely, no one has dug into it, and the folk who can comment on it aren't around
-[22:48:02] <ferringb> jmbsvicetto: you're thinking of ulm
-[22:48:02] <jmbsvicetto> peper: If not, sorry
-[22:48:07] <jmbsvicetto> peper: sorry
-[22:48:17] <jmbsvicetto> ulm: ping ^^
-[22:48:17] <ferringb> peper is g55 guy
-[22:48:33] <jmbsvicetto> I thought he was leading the PMS team. Sorry
-[22:48:42] <tanderson> fauli is lead iirc
-[22:49:11] <peper> I can tell you that you should adopt g55 though
-[22:49:13] * peper hides
-[22:49:26] <jmbsvicetto> ferringb: we can talk about nominating someone to look at EAPI-4 status
-[22:49:28] <scarabeus> peper: its nominated for vote on next meeting :P
-[22:49:40] <tanderson> Since this is obviously a democracy, I vote for g55 too =P
-[22:49:41] <scarabeus> peper: if you as proposer will agree to that
-[22:49:43] <ferringb> any takers to do the eapi4 investigation?
-[22:50:02] * ferringb can do it if no one else will
-[22:50:24] <jmbsvicetto> anyone from the community interested in joining the "quest"?
-[22:50:30] <peper> scarabeus: I don't mind :)
-[22:50:58] <ferringb> how about we take the "find a minion" part offline.  if no one is found in a week, I'll do it.
-[22:51:04] <scarabeus> ook
-[22:51:05] * ferringb won't get to it for at least a week anyways
-[22:51:20] *** Quits: yporti (~yporti@hyadesinc/pub/yporti) (Quit: Leaving)
-[22:51:23] <ferringb> bugs being next?
-[22:51:26] <scarabeus> oky
-[22:51:29] <scarabeus> bugs on road
-[22:51:30] <jmbsvicetto> ok, works for me :)
-[22:51:42] <scarabeus> so Halcy0n first question on you, are you interested in that bug of yours?
-[22:52:04] <wired> bug 234706
-[22:52:07] <willikins> wired: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-[22:52:15] <Halcy0n> scarabeus: yes.  I started digging through all of the threads from way back.  I'll try to come up with another proposal to get people talking about it again.
-[22:52:22] <scarabeus> oka
-[22:52:40] <scarabeus> just FTR kde has now just arm, amd64, ppc, ppc64 and x86 keywords
-[22:53:16] *** Joins: tove (~tove@smtp.gentoo.org)
-[22:53:41] <scarabeus> next bug then, ferringb its yours
-[22:54:07] <ferringb> err. what's the bug #?
-[22:54:10] <wired> bug 256451
-[22:54:13] <willikins> wired: https://bugs.gentoo.org/256451 "Council meeting notes appear to be missing"; Doc Other, Other; NEW; gentoo-bugs@allenjb.me.uk:council@g.o
-[22:54:24] <ferringb> sorted, although october 2009 is missing
-[22:54:33] <ferringb> (just noticed it, it's the only summary that's not up there)
-[22:54:50] <scarabeus> i see
-[22:54:52] <ferringb> would be nice if someone else does it since frankly it's shitty work, but I'll kill it by next council meeting if no one steps up
-[22:55:09] <scarabeus> oka
-[22:55:15] <Betelgeuse> ferringb: I can write it.
-[22:55:19] <ferringb> Betelgeuse: really appreciate it
-[22:55:30] <ferringb> !@#*ing sucks writing those things months/years after the fact
-[22:55:57] <wired> next one is mine, bug #256453
-[22:55:58] <scarabeus> wired: your bug?
-[22:56:00] <willikins> wired: https://bugs.gentoo.org/256453 "Documentation on Gentoo Council meeting processes, particularly regarding agenda items"; Doc Other, Other; NEW; gentoo-bugs@allenjb.me.uk:council@g.o
-[22:56:12] <wired> i have a patch http://paste.pocoo.org/show/248114/
-[22:56:17] <scarabeus> ferringb: why do you think that i for kde and this do it on run time
-[22:56:23] <scarabeus> ferringb: later you always lack the motivation :D
-[22:56:31] <ferringb> scarabeus: yep.
-[22:56:59] <scarabeus> hmm that patch is not bad
-[22:57:27] <scarabeus> altho is there possibility to place php script into cvs not to have rely on wired's devspace
-[22:57:51] <scarabeus> ?
-[22:57:54] <Betelgeuse> yeah official documents should not rely on devspaces
-[22:57:56] <wired> no idea, i'll have to ask
-[22:58:32] <wired> any other comments?
-[22:58:42] <scarabeus> ok i agree with applying this patch, when the devspace uri is sorted out (taken out to be static 19:00 or placed into the proj folder in cvs)
-[22:59:03] <scarabeus> so your yays and nays plz :]
-[22:59:11] <jmbsvicetto> wired: I like your patch but have 2 or 3 suggestions: one is to include some notes about items to be included in the Agenda, including timelines for proposed GLEPs to be voted
-[22:59:54] <scarabeus> 2 weeks for announcement, 1 week for last nomination of vote item so we can all prepare
-[23:00:02] <jmbsvicetto> The other is to add a note in the beginning that the dates and times of the meeting are set by each council and that for the current council the preferred time/date is X
-[23:00:08] *** Quits: zmedico (~zmedico@gentoo/developer/zmedico) (Ping timeout: 258 seconds)
-[23:00:12] <wired> mm
-[23:00:12] <wired> ok
-[23:00:29] <wired> i'll improve it send it to -project for final comments and observations then
-[23:00:35] <wired> before committing
-[23:00:38] <scarabeus> yep sounds reasonable
-[23:00:45] <ferringb> wired: one nit- note we keep a higher frequency of meetings than once a month.  might want to incorporate that in some respect
-[23:00:59] <jmbsvicetto> scarabeus: the old rule is the GLEP must be submitted to the dev ml one week before the agenda is sent and that the agenda must be sent 1 week before the meeting
-[23:01:02] <wired> ferringb: noted
-[23:01:39] <scarabeus> hmm first you announce meeting and then people ask for stuff to be on it
-[23:01:47] <scarabeus> not that people ask for stuff and then you base meeting on it
-[23:01:47] <jmbsvicetto> ferringb: we have up until now, but our decision was for 1 monthly meeting unless certain conditions are met
-[23:01:54] <scarabeus> (just saying how people work)
-[23:02:18] <wired> announcement -> possible item submissions -> agenda -> more possible item submissions + discussion on existing items
-[23:02:28] *** Joins: zmedico (~zmedico@gentoo/developer/zmedico)
-[23:02:35] <scarabeus> wired: that sounds nices
-[23:02:43] <scarabeus> but lets move this discussion to list seriously
-[23:02:49] <wired> sure
-[23:02:57] <scarabeus> last bug is your jmbsvicetto, i guess it is bit long-term so no status update :]
-[23:03:16] <wired> bug 237381
-[23:03:19] <willikins> wired: https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:dberkholz@g.o
-[23:03:20] <jmbsvicetto> I didn't got to it yet, but I plan to present some proposal in the next meeting
-[23:03:25] <scarabeus> ook
-[23:03:27] <ferringb> curious, but how are you tracking who owns what?
-[23:03:37] <wired> ferringb: last agenda
-[23:03:39] <wired> :p
-[23:03:45] *** Joins: yporti (~yporti@hyadesinc/pub/yporti)
-[23:03:48] <jmbsvicetto> let me fix that on my bug ;)
-[23:03:49] <ferringb> wired: yeah, point is shift the owner into the bug itself
-[23:04:13] <wired> ferringb: mm that'll make it harder to track.. lets just add owners as CC?
-[23:04:29] <scarabeus> just cc, just for query purposes
-[23:04:35] <scarabeus> we should all care about this stuff somehow :D
-[23:04:39] <jmbsvicetto> ferringb: I was reassigning the bug to me :P
-[23:04:48] * ferringb would just reassign, and cc council
-[23:05:02] <jmbsvicetto> wired: you can also search bugs council is cc'ed to
-[23:05:03] <scarabeus> actualy you are right it does not really much matter :]
-[23:05:05] <ferringb> my search query I use as is pulls anything that has the council cc'd
-[23:05:18] <scarabeus> aaanyway back to topics, item 5, who wants the shiny chair :]
-[23:05:18] <jmbsvicetto> by the way the curent list includes 8 bugs
-[23:05:35] <wired> jmbsvicetto: yes, but thats just getting messy, council can be cc'd to bugs for various reasons
-[23:06:00] <jmbsvicetto> there are only 8 bugs assigned to council or where council is cc'ed
-[23:06:05] <ferringb> offline it... we don't need to bikeshed in person during a meeting ;)
-[23:06:11] <wired> :)
-[23:06:19] <jmbsvicetto> bug 234711 is probably coming back when discussing GLEP55
-[23:06:21] <ferringb> suspect whoever does the work can just enforce the standard...
-[23:06:22] <willikins> jmbsvicetto: https://bugs.gentoo.org/234711 "GLEP 54: scm package version suffix"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:lu_zero@g.o
-[23:06:33] <ferringb> actually, I do have a vote I'd like to request on that
-[23:06:42] <scarabeus> brm
-[23:06:48] <scarabeus> pumpkins, this is ml stuff :]
-[23:06:49] <ferringb> the last council basically bound g54 to auto-pass if g55 passes
-[23:07:16] <ferringb> I'd like to see g54 go through a vote again this time around- the situation has changed a bit in terms of what portage can do, potential of capabilities, etc.
-[23:07:25] <ferringb> decouple the suckers namely
-[23:07:31] <Halcy0n> We are just about done right, because I have to run, and don't want to miss anything :)
-[23:07:41] <scarabeus> yes
-[23:07:41] * ferringb can take it to the ml
-[23:07:48] <scarabeus> just decision about the next chair
-[23:07:56] <jmbsvicetto> just for record and so it gets logged there's also b. 316401, 316403 and 316405 - which iirc are all waiting on infra
-[23:07:59] <wired> next meeting in a month?
-[23:08:01] <scarabeus> (i am fallback, i dont mind doing so, just if anyone else wants to do it)
-[23:08:08] <ferringb> wired: actually... sooner gets my vote
-[23:08:22] <scarabeus> 23.
-[23:08:22] <ferringb> it may be not obvious, but we've got some EAPI shit that needs discussing
-[23:08:22] <scarabeus> ?
-[23:08:24] <wired> ferringb: two weeks?
-[23:08:28] <scarabeus> too soon
-[23:08:29] <scarabeus> 23.
-[23:08:42] <scarabeus> eh it is 2 weeks
-[23:08:43] <scarabeus> :D
-[23:08:45] <ferringb> scarabeus: two weeks is enough time imo.
-[23:08:57] <scarabeus> so others
-[23:08:59] <jmbsvicetto> I'm not likely to have much free time in the week of 23rd August
-[23:09:06] <ferringb> if the two weeks approaches and we're not ready, fine, we just cancel the meeting
-[23:09:18] <wired> +1 for 23rd here
-[23:09:22] <scarabeus> ferringb: not really, it needs to be announced right away
-[23:09:26] <Betelgeuse> 23 should be fine but I won't chair as GSoC is still running.
-[23:09:29] <scarabeus> so people would expect it
-[23:09:42] <jmbsvicetto> I was also getting back on my bug in 1 month, not 2 weeks
-[23:10:12] <scarabeus> jmbsvicetto: no worries i updated summary
-[23:10:18] <scarabeus> ok I chair
-[23:10:23] <scarabeus> date is fine and dandy?
-[23:10:26] <wired> so we're good for 23rd?
-[23:10:38] <wired> scarabeus: i'll chair, seems its just the two of us, lets rotate :)
-[23:10:39] <ferringb> option of the 30th as a fallback comes to mind, but yep
-[23:10:43] <jmbsvicetto> I'll let you know if I can make it, but at this time it doesn't sound too promising
-[23:10:44] <scarabeus> wired: ok
-[23:10:47] <scarabeus> wired: update summary
-[23:10:59] <ferringb> jmbsvicetto: afaik you're going to want to be there being EAPI related- any idea when you'll know if you can be there?  that's ignoring if you just sent a proxy
-[23:11:06] <Halcy0n> 23 works for me as well.
-[23:11:06] <jmbsvicetto> scarabeus: I plan to chair future meeting
-[23:11:09] <jmbsvicetto> +s
-[23:11:12] <scarabeus> jmbsvicetto: find good proxy if you are really gone :]
-[23:11:15] <ferringb> that said it's probably going to be more of a discussion
-[23:11:55] <scarabeus> ok, so lets proceed with more bikeshed + open floor
-[23:12:01] <scarabeus> and i am going to tuneup the summary
-[23:12:03] <scarabeus> ack?
-[23:12:10] <scarabeus> and go get cookies :P
-[23:12:13] <jmbsvicetto> ferringb: we're planning a domain migration in that week at work. It all depends at what hour we end the preparation meetings on Monday
-[23:13:01] <wired> we can also do something like early 28th (saturday) for our US friends
-[23:13:16] <ferringb> jmbsvicetto: ah... yeah, those weeks suck ass
-[23:13:32] <jmbsvicetto> I can do weekends if others are willing to do it
-[23:14:49] <Chainsaw> I can do weekends, yes. Not a problem.
-[23:15:30] <jmbsvicetto> wired: but I guess our US friends would prefer a late meeting ;)
-[23:15:36] <few_> Betelgeuse: pong
-[23:15:39] <wired> jmbsvicetto: late for them, early for us
-[23:15:41] <wired> ;p
-[23:15:57] <jmbsvicetto> wired: hmm, that would be a fun time for me :P
-[23:16:15] <wired> heheh
-[23:16:18] <scarabeus> http://paste.pocoo.org/show/248127/
-[23:16:21] <scarabeus> summary :]
-[23:16:27] <NeddySeagoon> jmbsvicetto, you and your tropical island
-[23:16:30] <scarabeus> also guys did someone log? i forgot to ask :/
-[23:16:34] <wired> i always log
-[23:16:34] <jmbsvicetto> NeddySeagoon: :)
-[23:16:39] <wired> i have like 3mil log lines
-[23:16:41] <wired> ;p
-[23:16:48] <jmbsvicetto> I also have log
-[23:16:48] <scarabeus> wired: could you commit the log plz, i will attach the above summary to it soonish
-[23:16:54] <wired> ok
-[23:16:56] <scarabeus> wired: and remove the phone number
-[23:17:01] <wired> ofcourse
-[23:17:05] <wired> did the meeting end? :p
-[23:17:16] <ferringb> wired: could substitute in a sex line instead of chainsaws...
-[23:17:20] <ferringb> that might be fun
-[23:17:21] <wired> lmao
-[23:17:21] <scarabeus> yes dismissed, community is silent
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100823-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100823-summary.txt
deleted file mode 100644
index 727d036d3f..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100823-summary.txt
+++ /dev/null
@@ -1,85 +0,0 @@
-Gentoo Council 2010/08/23 meeting agenda / summary:
-
-* roll call
-	here:
-		jmbsvicetto
-		halcy0n
-		betelgeuse
-		wired
-		chainsaw
-		ssuominen ( proxying scarabeus )
-	missing:
-		ferringb ( called him, no answer )
-
-** items for discussion / vote **
-    - EAPI 4 status
-	3 bugs left
-		#273642 #273625 #273633
-	repoman not updated yet
-	support for EAPI 4_pre1 not enabled yet
-
-    - GLEP 54 - http://www.gentoo.org/proj/en/glep/glep-0054.html
-	http://www.mail-archive.com/gentoo-council@lists.gentoo.org/msg00524.html
-	http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg34159.html
-
-	passed, 4 to 2
-	yes
-		jmbsvicetto
-		chainsaw
-		ssuominen
-		wired
-	no
-		halcy0n
-			because GLEP 55 was turned down
-		betelgeuse
-			because GLEP 55 was turned down
-				would vote yes if we waited for a year
-				or did something else reasonable to
-				avoid warnings
-
-    - GLEP 55 - http://www.gentoo.org/proj/en/glep/glep-0055.html
-	voted down 4 to 2
-	no
-		jmbsvicetto
-		chainsaw
-		ssuominen
-		wired
-	yes
-		halcy0n
-		betelgeuse
-
-	* per Betelgeuse's request, do we want to find a solution for the issues raised by glep 55
-	yes
-		betelguese
-		chainsaw
-		halcy0n
-		jmbsvicetto
-		wired
-	no
-		ssuominen
-
-	** we should focus on finding an acceptable implemention or just vote on all the proposed ones
-
-* go through bugs assigned to the Council
-	http://bugs.gentoo.org/buglist.cgi?quicksearch=assignedto,cc:council@gentoo.org
-
-	234706
-		no new info
-
-	256451
-		done
-
-	256453
-		done
-
-	237381
-		no new info
-
-* decide who's chairing the next meeting
-	jmbsvicetto
-
-* choose next meeting's date
-	20100913 19H00 UTC
-
-* open floor - listen to the community
-	* antarus wants an espresso machine
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100823.txt b/xml/htdocs/proj/en/council/meeting-logs/20100823.txt
deleted file mode 100644
index 92ebbee94d..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100823.txt
+++ /dev/null
@@ -1,387 +0,0 @@
-[21:59:59] <wired> i guess its about time
-[22:00:04] *** Joins: lavajoe (~joe@gentoo/developer/lavajoe)
-[22:00:09] <Chainsaw> Ready here :)
-[22:00:11] <wired> rollcall! Betelgeuse Chainsaw ferringb Halcy0n jmbsvicetto scarabeus ( ssuominen )
-[22:00:15] <Betelgeuse> wired: around
-[22:00:20] <jmbsvicetto> around
-[22:00:38] <Halcy0n> here
-[22:00:54] <Chainsaw> wired: Present.
-[22:01:14] <wired> great
-[22:01:16] <wired> ferringb?
-[22:01:51] <wired> lets give him a couple of minutes
-[22:04:57] <Halcy0n> Want me to call Brian?
-[22:05:12] <wired> could you please?
-[22:05:33] <wired> or I will
-[22:05:55] <Halcy0n> Its free for me to call if you want.  I just can't find his number.
-[22:06:34] <wired> problem solved
-[22:07:09] *** Quits: ali_bush (~alistair@gentoo/developer/alibush) (Read error: Connection reset by peer)
-[22:07:39] <jmbsvicetto> Did we poke anyone to get an EAPI-4 status update?
-[22:08:17] <Betelgeuse> jmbsvicetto: few_ said to look at the tracker bug
-[22:08:29] <wired> ok so brian is not answering
-[22:08:32] <wired> lets move on
-[22:08:32] <Betelgeuse> 08:45 < few_> Betelgeuse: just in case nobody shows up to report about the portage eapi 4 status in the council meeting: it's all in bug 273620. whatever is marked as fixed can be made usable in the next release.
-[22:08:34] <willikins> Betelgeuse: https://bugs.gentoo.org/273620 "[TRACKER] sys-apps/portage EAPI 4 implementation"; Portage Development, Core; NEW; SebastianLuther@gmx.de:dev-portage@g.o
-[22:08:46] <wired> Betelgeuse: thanks, was about to paste that myself
-[22:10:05] *** Joins: antarus (~antarus@gentoo/developer/antarus)
-[22:10:13] <wired> it seems that the only open bugs there are bug 273642
-[22:10:15] <willikins> wired: https://bugs.gentoo.org/273642 "USE is calculated differently (EAPI 4)"; Portage Development, Core; NEW; SebastianLuther@gmx.de:dev-portage@g.o
-[22:10:18] <wired> and bug 273625
-[22:10:20] <willikins> wired: https://bugs.gentoo.org/273625 "Slot operator dependencies (EAPI 4)"; Portage Development, Core; NEW; SebastianLuther@gmx.de:dev-portage@g.o
-[22:10:47] <jmbsvicetto> few_ is around. Anyone has any questions?
-[22:11:12] *** Quits: nirbheek (~nirbheek@gentoo/developer/flyingspaghettimonster/nirbheek) (Ping timeout: 240 seconds)
-[22:11:23] <few_> there is a third: bug 273633
-[22:11:25] <willikins> few_: https://bugs.gentoo.org/273633 "Controllable compression and docompress (EAPI 4)"; Portage Development, Core; NEW; SebastianLuther@gmx.de:dev-portage@g.o
-[22:11:55] <wired> few_: right i missed it thanks
-[22:11:56] <zmedico> all the stuff that's implemented should be listed in the tracker bug and here too: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob_plain;f=doc/package/ebuild/eapi/4.docbook;hb=HEAD
-[22:12:32] <Betelgeuse> I think we should roll that together with GLEP 55 if approved today and start getting EAPI 4 out.
-[22:12:40] <Betelgeuse> zmedico said GLEP 55 already has code
-[22:12:57] <Betelgeuse> zmedico: 54 does too?
-[22:14:28] <zmedico> well, glep 54 isn't implemented but it would affect all the same places as the glep 55 patch
-[22:15:01] <Betelgeuse> It would take some time to get PMS in order any way
-[22:16:16] <Betelgeuse> zmedico: Also how's repoman wrt EAPI 4?
-[22:17:16] <ssuominen> It would be nice to have special version string, called for example 'scm' or 'live' to replace 9999 a-like versioning. But .ebuild stops at .ebuild, extra suffix is just ugly and complicates workflow
-[22:17:47] <zmedico> Betelgeuse: it's hard to say about repoman because we haven't enabled support for EAPI 4_pre1 yet
-[22:18:12] <Betelgeuse> zmedico: I was thinking we might want to check some || die stuff but any way not really that relevant now
-[22:18:16] <Betelgeuse> wired: Shouldn't we move on?
-[22:18:19] <wired> yes
-[22:18:57] <zmedico> ssuominen: a possible alternative to the -scm would be just to add a _scm suffix that's similar to the existing version suffixes
-[22:19:07] <wired> lets talk about GLEP 54
-[22:19:34] <jmbsvicetto> zmedico: would it be possible to have just ${PN}_scm ?
-[22:19:39] <wired> zmedico: thats kind of what I was thinking
-[22:19:54] <Betelgeuse> wired: shouldn't talk have happened at mailing lists?
-[22:20:00] <zmedico> jmbsvicetto: we could allow that since we're changing version rules anyway
-[22:20:06] <jmbsvicetto> ok
-[22:20:28] <wired> Betelgeuse: well, it should, but i guess we can do some basic talk before we vote on it
-[22:20:37] <Betelgeuse> Also we have the option to bikeshed before EAPI 4 is offically approved.
-[22:20:46] <Betelgeuse> zmedico: I presume changing naming etc is quite trivial?
-[22:20:56] <Betelgeuse> Once the approach is in.
-[22:21:17] <ulm> Betelgeuse: the issue is about hyphen vs underscore, not live vs scm
-[22:21:25] <wired> Im all for GLEP 54, but I strongly prefer _ and live
-[22:21:33] <ulm> see http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg34159.html
-[22:21:47] <ulm> all this has been discussed ad nauseam one year ago
-[22:22:32] <Chainsaw> ulm: You have a point, even versionator relies on those hyphens.
-[22:22:33] <zmedico> Betelgeuse: changing naming of ebuilds? yeah pretty trivial, along the lines of the glep 55 patch.
-[22:23:17] *** Joins: Ford_Prefect (~arun@gentoo/developer/ford-prefect)
-[22:23:19] <ssuominen> GLEP-54, yes. GLEP-55, no.
-[22:23:29] <wired> ^^ im with ssuominen 
-[22:23:38] <Halcy0n> If its a well defined standard, it doesn't matter if its a - or a _.
-[22:23:42] <jmbsvicetto> GELP-54, yes. GLEP-55, no.
-[22:23:52] <jmbsvicetto> GLEP*
-[22:24:06] <Betelgeuse> And how do you guys propose doing 54 without 55?
-[22:24:12] <Halcy0n> That was my question :)
-[22:24:32] <zmedico> you just use a new regex
-[22:24:34] <Chainsaw> I don't believe 54 is workable without 55, and I don't like 55.
-[22:24:38] <Chainsaw> So no on both.
-[22:24:55] <zmedico> you scan the ebuild dir for valid ebuild names
-[22:25:03] <zmedico> using a different regex for each format
-[22:25:23] <Betelgeuse> Of course we can do it if we wait until people are expected to be on a new Portage version
-[22:25:24] <zmedico> ebuid extension is irrelevant
-[22:25:28] *** Joins: darkside_ (~darkside@gentoo/developer/darkside)
-[22:25:36] <Chainsaw> Halcy0n: I'd prefer mandating the underscore though, to avoid violating any assumptions in current code.
-[22:25:38] <Betelgeuse> Meaning the standard year and screw earlier versions.
-[22:25:47] <jmbsvicetto> I'm open for a onetime change of the extension (.eb ?), if we use it to put up rules to ensure we can get changes in the future without requiring extension changes
-[22:25:55] <Halcy0n> The standard year sucks.
-[22:26:02] <Betelgeuse> Halcy0n: indeed
-[22:26:33] <wired> zmedico: how would reasonably old (1yo) portage react to foo-live or foo-1_live?
-[22:27:10] <zmedico> wired: it would just give a short warning message during dep calc and move on
-[22:27:14] <jmbsvicetto> about the EAPI argument, I don't agree with the claims on GLEP-55, including the "limitation" in forcing EAPI to be set on a clear position of the file
-[22:27:26] <wired> @council ^^ i don't see an issue with that
-[22:27:45] <jmbsvicetto> s/of/in/
-[22:27:57] <Chainsaw> Okay, so it seems we can do 54 without 55. What's the opinion on mandating the underscore?
-[22:28:02] <wired> zmedico: for every {-,_}live ebuild in tree?
-[22:28:17] <jmbsvicetto> wired: I'd rather see a new discussion taking the time to address the issue of supported features of a repo.
-[22:28:33] <zmedico> wired: well, every one that's pulled into the dependency graph for whatever reason
-[22:28:56] <wired> jmbsvicetto: sorry?
-[22:28:59] <Chainsaw> zmedico: The main concern is that it wouldn't abort so that a newer python/portage can be merged.
-[22:29:00] <Halcy0n> We really should have had these discussions on the mailing lists if you guys felt this way :)
-[22:29:10] <zmedico> wired: one warning for each .ebuild file with unrecognized version part
-[22:29:11] <jmbsvicetto> There have been talks about adding a file to every repo to specify features supported by the repo. It could be just at the root level, or it could also be used at the category or package level
-[22:29:13] <Chainsaw> zmedico: Which I believe you've addressed :)
-[22:29:25] <zmedico> Chainsaw: yeah, won't abort
-[22:29:33] <Chainsaw> jmbsvicetto: That sounds as invasive as GLEP55, I'd like to have that punted back to the mailing list.
-[22:30:00] <jmbsvicetto> Chainsaw: I'm not proposing to move forward with that. I'm proposing we take the time to discuss that (on mls)
-[22:30:05] *** Joins: nirbheek (~nirbheek@gentoo/developer/flyingspaghettimonster/nirbheek)
-[22:30:31] <wired> zmedico: that sounds good then, we could have GLEP 54 without severe consequences 
-[22:30:45] <Chainsaw> wired: Agreed, revising my vote. GLEP 54 yes, GLEP 55 no.
-[22:30:53] <zmedico> wired: sure
-[22:30:55] <jmbsvicetto> Chainsaw: if we decide to do a major change in the file format (including a file extension change), we might take the chance to address as many issues as possible
-[22:30:56] <Chainsaw> wired: Point about the underscores remains, but nobody seems willing to answer that.
-[22:31:14] <wired> Chainsaw: +1 for underscore here
-[22:31:22] <Betelgeuse> I voted yes to both previously and don't think anything has been presented since then.
-[22:31:22] <jmbsvicetto> Chainsaw: I'm ok with forcing it to be '_'
-[22:31:34] <wired> hyphen seems to make it harder for no apparent reason
-[22:31:52] <Chainsaw> wired: Indeed. Principle of least astonishment.
-[22:31:54] <Halcy0n> wired: _ has the same reprecussions anyway, since its a valid part of the version string right now as well.
-[22:32:23] <wired> Halcy0n: true, but it doesn't split PN from PV
-[22:32:35] <Betelgeuse> wired: I propose we vote on if this council thinks the problem of changing global scope should be addressed?
-[22:32:45] <Halcy0n> Either way, I approve of GLEP 54, with my own minor bikeshedding of it be "live" vs "scm" which was brought up in one of the previous discussions.
-[22:33:07] <jmbsvicetto> Betelgeuse: yes from me on both - we should vote and we should address it
-[22:33:36] <jmbsvicetto> Halcy0n: no objection from me on live and no preference between live or scm
-[22:33:38] *** Quits: nirbheek (~nirbheek@gentoo/developer/flyingspaghettimonster/nirbheek) (Excess Flood)
-[22:33:54] <Halcy0n> Also, I like GLEP55, but I don't like the proposed solution, but like the second one with a static extension with the eapi as part of the version.
-[22:34:07] <wired> Betelgeuse: can you be more specific, what issue are you refering to?
-[22:34:19] <Betelgeuse> wired: The problem that GLEP 55 aims to solve.
-[22:34:29] <Chainsaw> Halcy0n: I like the principle, but I don't like the implementation.
-[22:34:38] <Betelgeuse> wired: As people vote no I want to know if they want to just ignore it for now.
-[22:34:44] <wired> ah
-[22:34:51] <jmbsvicetto> Betelgeuse: iirc, ferringb has disputed the claim in the GLEP
-[22:35:18] <Betelgeuse> jmbsvicetto: The parsing EAPI part or the performance?
-[22:35:49] <Betelgeuse> jmbsvicetto: I haven't heard there being anything wrong with the Problem statement in the GLEP (of course it's been a while)
-[22:35:54] <wired> lets clear things out for a minute here
-[22:35:54] <jmbsvicetto> Betelgeuse: and it has been discussed before that we can (should) split the ebuild sourcing from a "pre-processing" step
-[22:35:59] <wired> hold your GLEP 55 thoughts
-[22:36:16] <wired> GLEP 54, can I have yes/no votes please
-[22:36:22] <jmbsvicetto> yes
-[22:36:27] <Betelgeuse> wired: It really makes sense to do 55 first
-[22:36:34] <jmbsvicetto> + '-' restriction
-[22:36:42] <jmbsvicetto> bah, '_'
-[22:36:42] <Chainsaw> wired: GLEP 54: yes.
-[22:36:59] <Halcy0n> Doing 54 without 55 seems like we are just hoping to not have warnigns displayed to users.
-[22:37:04] <Chainsaw> wired: And indeed, underscore, not hyphen.
-[22:37:14] <Halcy0n> I'm not willing to vote on 54 until 55 is decided.
-[22:37:29] <jmbsvicetto> 55 then?
-[22:37:34] <wired> ok then
-[22:38:40] <wired> i really don't like suffix
-[22:38:55] <jmbsvicetto> 55: no - I don't agree with the premises nor with the proposed solution
-[22:39:12] <Chainsaw> wired: GLEP 55: no.
-[22:39:23] <ssuominen> 55: no
-[22:39:24] <wired> GLEP 55: no.
-[22:39:58] <wired> Halcy0n / Betelgeuse?
-[22:40:21] <Betelgeuse> yes (and I don't have particular ties to any of the proposed naming schemes in the GLEP)
-[22:40:49] <Halcy0n> Yes (and I prefer the second naming scheme)
-[22:41:01] <wired> okay
-[22:41:15] <wired> glep 55 was voted down 4 to 2
-[22:41:31] <Halcy0n> glep 54 is a no for me then
-[22:41:41] <Betelgeuse> If performance doesn't really matter (would need some numbers) it could also be a subdirectory if people are tied to .ebuild
-[22:42:03] <Halcy0n> Betelgeuse: if we stick with .ebuild, we are tied to waiting and can't use it immediately.
-[22:42:19] <Betelgeuse> Halcy0n: Not if the new EAPIs move to a pkg sub directory
-[22:42:27] <Halcy0n> Oh, I see what you mean now.
-[22:42:41] <Halcy0n> I personally don't like that solution, for reasons brought up in the glep.
-[22:42:56] <ssuominen> need to stick with .ebuild, anything else is just extra layer of complexity, the benefits from this certainly doesn't outweight the unconvinience
-[22:43:01] <wired> lets revisit our GLEP 54 vote now
-[22:43:05] <jmbsvicetto> glep54 - yes with '_' restriction
-[22:43:18] <Chainsaw> wired: GLEP54, yes, underscore not dash.
-[22:43:22] <wired> i vote yes with _ and preferably "live"
-[22:43:29] <Betelgeuse> I don't like showing warnings on users so no.
-[22:44:00] <Halcy0n> ssuominen: a one time change of the extension to "eb" shouldn't be anything that's another layer of complexity, but the conversation has moved on I guess.
-[22:44:03] <wired> i recommend voting between "live" and "scm" now so we can avoid bikeshedding later
-[22:44:04] <ssuominen> yes
-[22:44:07] <jmbsvicetto> ssuominen: I'd be willing to have a one time extension change (.eb?) if we use it to implement large changes
-[22:44:39] <jmbsvicetto> I can live with live or scm.
-[22:44:45] <Betelgeuse> wired: I would like that vote on if people are categorily against 55 or just the particular scheme it prefers
-[22:44:54] <Halcy0n> jmbsvicetto: you don't like one of the proposed solutions of having it be foo-1.2.3-eapi_4.eb?
-[22:45:07] <jmbsvicetto> no
-[22:45:14] <jmbsvicetto> I don't want the EAPI exposed in the file name
-[22:45:18] <ssuominen> me either
-[22:45:27] <Betelgeuse> Halcy0n: It doesn't have to be pkg/eapiX/ could be just pkg/new-apis/foo-1.ebuild
-[22:45:38] <ssuominen> btw, i'm fine with both live or scm, the naming doesn't really bother me, long as it's short and to the point
-[22:45:41] <wired> Betelgeuse: i don't like any of the proposed "solutions"
-[22:45:43] <Betelgeuse> Halcy0n: so only a single readdir more
-[22:45:56] <wired> personally I believe we can live with some old portage warnings
-[22:45:57] <Halcy0n> Even having it easily fetchable in the ebuild is fine.  I just don't see how you guys can go ahead with G54 when its clearly going to show warnings to users.
-[22:46:15] <ssuominen> {package}-${version}.ebuild, profit. where ${version} can be scm or live or ...
-[22:46:29] <wired> this thing has had so much bikeshedding its already pretty safe to apply glep 54 without breaking portage (when the glep was written it was not safe)
-[22:46:59] <Betelgeuse> Halcy0n: yeah a feature for ricers should not show warnings to stable users
-[22:47:29] <Chainsaw> There's a difference between warnings & breakage.
-[22:47:35] <Betelgeuse> wired: s/old/current/
-[22:47:53] <wired> Halcy0n: glep55 is about ebuild suffixes...
-[22:47:55] <Chainsaw> Obviously it should not be phased in until a portage supporting the feature is marked stable.
-[22:48:29] <Halcy0n> wired: g55 has other proposed solutions that we could talk about.
-[22:48:29] <Chainsaw> A portage that warns until it is upgraded is acceptable. A portage that falls over so the situation is unrecoverable is not.
-[22:48:52] <Chainsaw> (Ever tried upgrading an installation that is >6 months old? Warnings are the least of your problems)
-[22:49:10] <jmbsvicetto> Halcy0n: GLEP-54 should be implemented on a new EAPI version
-[22:49:42] <Betelgeuse> jmbsvicetto: o_O
-[22:49:51] <Halcy0n> Its not going to understand the version no matter what you do at this point.
-[22:50:03] <jmbsvicetto> Betelgeuse: ?
-[22:50:32] <Betelgeuse> jmbsvicetto: just venting fustration a little
-[22:50:41] <jmbsvicetto> ok
-[22:51:03] <Betelgeuse> jmbsvicetto: as Halcy0n said you can't change version rules with our current way of naming files
-[22:51:13] <Betelgeuse> Not tomorrow any way.
-[22:51:19] <jmbsvicetto> sure
-[22:51:26] <Chainsaw> You'd be about two months out before your first _live can go in, yes.
-[22:51:40] <Halcy0n> Which is quite a crappy way to try and make the distribution move fowards.
-[22:51:44] <Halcy0n> s/fowards/foward/
-[22:51:55] * jmbsvicetto borrows an r to Halcy0n 
-[22:51:57] <Betelgeuse> And what about the next feature like GLEP 54?
-[22:52:02] <Betelgeuse> The same thing again?
-[22:52:04] <Betelgeuse> And then again?
-[22:52:05] <Betelgeuse> And again?
-[22:52:28] <Chainsaw> 55 is down. If you feel 54 depends on 55, reflect it in your vote please.
-[22:52:31] <peper> Halcy0n: to be fair the gleps are from 2007
-[22:52:33] * peper hides
-[22:52:43] <Halcy0n> peper: yea, but I'm trying to be foward thinking here :)
-[22:52:44] <jmbsvicetto> Betelgeuse: That's why I want a new discussion including the idea of adding repo version files so that we can finally address the issue
-[22:53:02] <Betelgeuse> Chainsaw: Already did. But I wanted that vote if the problem should be solved.
-[22:53:09] <Betelgeuse> wired: I think you should control the meeting a little more.
-[22:53:24] <jmbsvicetto> Betelgeuse: I'm even willing to have a one time extension change for that - assuming the not having to wait 1 year to implement rule
-[22:53:41] <Betelgeuse> jmbsvicetto: That's an option in 55.
-[22:53:53] <wired> well we are having a civilized discussion here and these are all our topics :)
-[22:54:19] <jmbsvicetto> Betelgeuse: the problem is 55 dismisses the choice of having EAPI inside the file and has a few premisses I don't agree with
-[22:54:49] <Betelgeuse> wired: The point was voting to end the discussion :)
-[22:55:15] <peper> jmbsvicetto: dismisses? It just shows some weak points
-[22:55:20] <jmbsvicetto> wired: Did we get a full count on 54?
-[22:55:23] <wired> Betelgeuse: we voted on 55 but then you guys have objections on 54 cause of the 55 vote... so we talk :)
-[22:55:29] <Betelgeuse> jmbsvicetto: "Easily fetchable EAPI inside the ebuild and one-time extension change" is an option there?
-[22:55:41] <jmbsvicetto> peper: To get it to be considered took quite a large discussion in the mls ;)
-[22:55:56] <jmbsvicetto> peper: the initial drafts ignored that option
-[22:55:59] <Chainsaw> wired: They will vote no on 54 because 55 is down. Probably means 54 is down as well. Best take counts now.
-[22:56:33] <wired> true
-[22:57:07] <Betelgeuse> jmbsvicetto: We can consider the performance implications acceptable to get a solution that gets enough votes behind the GLEP but maybe not happening
-[22:57:22] <Halcy0n> As I said, no to 54 without 55.  I need to go to a meeting in 4 minutes, so lets please wrap this up.
-[22:57:32] <peper> jmbsvicetto: Yes, because I didn't thinkg it would cause such a reaction from some folks. The proposed solution seemed the best to me and I didn't see the point of considering other approaches at first
-[22:57:33] <wired> well 54 passes the vote, 4 to 2
-[22:57:58] <Chainsaw> I can make it a tie and let it die if that ends the meeting?
-[22:58:04] <Betelgeuse> Also the benefits of 55 are not really apparent now as it enables further development.
-[22:58:05] <wired> with the underscore instead of the hyphen
-[22:58:08] <jmbsvicetto> peper: ok, understood
-[22:58:27] <wired> Chainsaw: there's no need, it'll end anyway :)
-[22:58:34] <wired> do we have a preference between live and scm?
-[22:58:38] <Chainsaw> wired: live
-[22:58:42] <wired> live+1
-[22:59:03] <wired> jmbsvicetto: ssuominen (who voted for)?
-[22:59:21] <jmbsvicetto> I'll accept either
-[22:59:22] <Chainsaw> wired: No on 54. Then both fail.
-[22:59:36] <wired> Chainsaw: sorry?
-[22:59:38] <Chainsaw> wired: And we don't have a broken tree.
-[22:59:54] <jmbsvicetto> Chainsaw: 54 doesn't break the tree
-[23:00:20] <Halcy0n> Not if you wait the normal year, which is apparently our development cycle now O:)
-[23:00:20] <Betelgeuse> Depends on your definition of "broken"
-[23:00:50] <ssuominen> yes to 54, long as it can be implented without 55. waiting is fine.
-[23:00:59] <wired> Chainsaw: did you change your vote to no?
-[23:01:20] <Halcy0n> It doesn't matter since it passed anyway without him changing his vote.
-[23:01:33] <tanderson> Halcy0n++
-[23:01:53] <wired> thats not true, if he votes no we have a tie...
-[23:02:10] <Betelgeuse> The summary defenitely needs to list who voted what.
-[23:02:16] <Chainsaw> Playing devils advocate, it doesn't matter either way.
-[23:02:54] <peper> wired: a tie with 7 people? impressive ;p
-[23:03:02] <wired> peper: ferringb is not here
-[23:03:05] <Chainsaw> peper: One of whom is not present.
-[23:03:11] <Chainsaw> peper: You can do it with 6.
-[23:03:26] <wired> Chainsaw: please make clear what you voted so we can move on :)
-[23:03:29] *** Quits: lavajoe (~joe@gentoo/developer/lavajoe) (Ping timeout: 240 seconds)
-[23:03:48] <Chainsaw> wired: GLEP54: yes
-[23:03:54] <wired> thanks
-[23:03:56] <peper> I thought ssuominen is proxying for ferringb but now I see scarabeus is not here as well. nvm
-[23:04:20] <wired> peper: underscore, live, glep 54 is a go
-[23:05:08] <peper> wired: with foo_live or foo-live?
-[23:05:09] <jmbsvicetto> so, are we done with the votes?
-[23:05:25] <Chainsaw> peper: underscore, not dash.
-[23:05:31] <Chainsaw> jmbsvicetto: I believe so.
-[23:05:34] <wired> jmbsvicetto: yes
-[23:05:50] <jmbsvicetto> So, do we have any updates in the open bugs?
-[23:05:54] <wired> yes
-[23:05:55] <wired> bugs
-[23:06:01] <wired> bug 256451 is done
-[23:06:02] <peper> Chainsaw: well, no dash at all in PNV would be something new
-[23:06:03] <willikins> wired: https://bugs.gentoo.org/256451 "Council meeting notes appear to be missing"; Doc Other, Other; RESO, FIXE; gentoo-bugs@allenjb.me.uk:council@g.o
-[23:06:14] <wired> bug 256453 is done
-[23:06:15] <Betelgeuse> wired: So I don't get my vote in this meeting?
-[23:06:16] <willikins> wired: https://bugs.gentoo.org/256453 "Documentation on Gentoo Council meeting processes, particularly regarding agenda items"; Doc Other, Other; RESO, FIXE; gentoo-bugs@allenjb.me.uk:council@g.o
-[23:06:28] <wired> Betelgeuse: you voted no?!
-[23:06:46] <Betelgeuse> wired: The vote on if we want to solve the problems GLEP 55 was for.
-[23:06:57] <jmbsvicetto> Betelgeuse: sorry, my bad
-[23:07:07] <Betelgeuse> wired: I didn't ever see a clear vote count on that.
-[23:07:12] <jmbsvicetto> Betelgeuse: I forgot your request
-[23:07:14] <ulm> peper: foo_live doesn't make sense since you need to have ${PN}-${PV}
-[23:07:18] <wired> Betelgeuse: you're right
-[23:07:30] <peper> ulm: see scrollback..
-[23:07:41] <jmbsvicetto> ulm: we talked about getting that
-[23:07:57] <jmbsvicetto> ulm: having ${PN}_live
-[23:08:25] <jmbsvicetto> wired: Yes from me in that we want to solve the issues raised by GLEP 55
-[23:09:17] <wired> yes from me as well
-[23:09:26] <Betelgeuse> yes
-[23:09:26] <Halcy0n> yes
-[23:10:01] <wired> Chainsaw: ssuominen?
-[23:10:58] <Chainsaw> wired: I want to solve the issues in GLEP55, yes. Just not this way.
-[23:11:20] <wired> ok. ssuominen?
-[23:11:21] <Chainsaw> wired: Perhaps we should agree to shelve both, as it is unlikely we will agree on 54 now?
-[23:11:57] <ssuominen> GLEP55 is a big no long as it talks about changing .ebuild or adding extra suffixes to it
-[23:12:09] <Betelgeuse> ssuominen: That wasn't the question
-[23:12:16] <wired> ssuominen: we're talking about the issues raised
-[23:12:18] <wired> not the solution
-[23:12:32] <ssuominen> I don't like the underscore, _
-[23:12:50] <jmbsvicetto> ssuominen: please answer the question ;)
-[23:12:52] <wired> i don't understand ;p
-[23:12:54] <ssuominen> err wait
-[23:13:12] <jmbsvicetto> 20:06 <@Betelgeuse> wired: The vote on if we want to solve the problems GLEP 55 was for.
-[23:14:02] <ssuominen> no
-[23:14:06] <ssuominen> shelve it
-[23:14:18] <wired> ok
-[23:14:19] <wired> thanks
-[23:14:28] <jmbsvicetto> So, bugs again?
-[23:14:28] <Betelgeuse> Can those people who voted yes now and no to GLEP 55 tell their preferred solution(s).
-[23:15:00] <jmbsvicetto> Betelgeuse: That is something I'd like to talk in the mls. I don't have answers for now
-[23:15:30] <Chainsaw> I would like to say shelve both for further discussion. And my apologies for being disruptive.
-[23:16:03] <Chainsaw> (In the future my first vote is what goes, and nothing else. I am notoriously undecisive if I don't keep stop myself.)
-[23:16:20] <Chainsaw> s/stop/stopping/
-[23:16:56] <Betelgeuse> wired: your solution?
-[23:18:00] <wired> Chainsaw is not making this easy
-[23:18:07] <Chainsaw> I know.
-[23:18:15] <wired> does anyone else feel we should discuss glep54 for two more weeks?
-[23:18:23] <ssuominen> wired: o/
-[23:18:47] <Chainsaw> Yes, let's go back to discussions.
-[23:19:03] <Chainsaw> And we'll have a rule next meeting that I can't change my vote. Ever.
-[23:19:55] <jmbsvicetto> Chainsaw: never say never
-[23:20:19] <Chainsaw> jmbsvicetto: I certainly don't want a repeat of this.
-[23:20:29] <antarus> Its like a gaggle of school girls in here
-[23:20:36] <Chainsaw> Hi antarus.
-[23:20:55] <wired> Chainsaw: lets say that glep 54 passed, but we will give it 2 weeks to see if we can find a better way to implement it (through a new solution to glep55)
-[23:21:18] <peper> antarus: "A group of fat chicks; usually chit-chatting and usually snacking on fried foods.
-[23:21:22] <peper> what? :D
-[23:21:37] <Betelgeuse> wired: GLEP 54 should go in as part of an EAPI an ywa
-[23:21:41] <Betelgeuse> wired: And that takes some time.
-[23:21:54] <wired> Betelgeuse: shhh ;p
-[23:22:00] <antarus> peper: I think urban dictionary failed you there ;p
-[23:22:02] <wired> what im trying to say is
-[23:22:25] <wired> we all want glep54, lets not vote for it again, its passed, lets just focus on finding the best way to implement it
-[23:22:43] <Betelgeuse> wired: It was already passed before the meeting started :)
-[23:22:46] <jmbsvicetto> can we move on to bugs?
-[23:22:50] <wired> yes please
-[23:22:52] <jmbsvicetto> We're almost on 90 minutes
-[23:23:05] <wired> bug 234706
-[23:23:09] <willikins> wired: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-[23:23:13] <antarus> you guys need to learn how to cut the meeting short; its ok to delay items to the next one
-[23:23:25] <antarus> but ignore me and finish ;p
-[23:23:29] *** Joins: jbergstroem (~johan@bergstroem.nu)
-[23:23:30] <wired> antarus: the purpose here is not to "get done with it" :P
-[23:23:57] <jmbsvicetto> wired: anything worthy to discuss about bugs, besides the 2 closed bugs?
-[23:24:01] <wired> Halcy0n: ^^ bug, any progress?
-[23:24:10] <jmbsvicetto> I don't think there were any relevant updates to the others
-[23:24:11] <wired> jmbsvicetto: your bug, any progress?
-[23:24:39] <jmbsvicetto> no, I said I was going to address it in 1 month, not 2 weeks :P
-[23:24:45] <wired> you never know ;p
-[23:25:11] <wired> ok
-[23:25:21] <jmbsvicetto> next meeting?
-[23:25:31] <wired> next meeting date: 2010-09-13
-[23:25:36] <wired> jmbsvicetto: you'll chair? =]
-[23:25:53] <Chainsaw> wired: That works for me. 1900UTC as usual?
-[23:26:16] <wired> Chainsaw: yes
-[23:26:54] <Betelgeuse> ok for me
-[23:26:57] <jmbsvicetto> wired: I will
-[23:27:01] <wired> great
-[23:27:11] <wired> anyone from the community wants to discuss anything?
-[23:27:22] <antarus> sure
-[23:27:29] <antarus> when are we getting an expresso machine?
-[23:27:33] <antarus> cause my work has one
-[23:27:35] <antarus> and damn its good
-[23:27:39] * jmbsvicetto points to the foundation lounge
-[23:27:45] <peper> are you going to resurrect the g55 threads on the m/l?
-[23:27:46] <jmbsvicetto> antarus: they have the money ;)
-[23:27:52] <NeddySeagoon> antarus, the Foundation has one too
-[23:27:59] <wired> antarus: here are the keys, please don't lose them
-[23:28:04] <Philantrop> peper: 55 is dead.
-[23:28:34] <jmbsvicetto> peper: Seems a few of us want to discuss the issues GLEP 55 tried to address
-[23:28:38] <wired> peper: we'll be talking about a solution
-[23:28:46] <NeddySeagoon> Philantrop, I thought the principle of 55 was agreed but not the solutions
-[23:28:54] <jmbsvicetto> peper: tried as it wasn't approved - no other meaning
-[23:29:01] <peper> Philantrop: it's been dead for 3 years now. It just has this funny feature of coming back every now and again
-[23:29:47] <wired> tbh i voted no for ebuild naming changes but Im willing to discuss other options
-[23:29:54] <jmbsvicetto> peper: if needed, we can look for some silver bullets
-[23:30:25] <antarus> peper: like the herpes
-[23:30:28] <Betelgeuse> We should just vote on individual implementation options.
-[23:30:30] <jmbsvicetto> ok, if there's nothing else, I'm going to look around for dinner
-[23:30:49] <wired> Betelgeuse: maybe. we'll have a more detailed agenda on this next time :)
-[23:31:03] <wired> great
-[23:31:05] <Chainsaw> Something tells me both will be back in some form.
-[23:31:25] <wired> thanks everyone
-[23:31:30] <wired> meeting is now over
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100927-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20100927-summary.txt
deleted file mode 100644
index f5232e5dff..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100927-summary.txt
+++ /dev/null
@@ -1,68 +0,0 @@
-Gentoo Council 2010/09/27 meeting agenda / summary:
-
-* roll call
-
-	here:
-
-		Betelgeuse
-		chainsaw
-		ferringb (15 minutes late)
-		halcy0n
-		jmbsvicetto
-		scarabeus
-		wired
-
-
-* items for discussion / vote
-
-	There were no items submitted for the agenda of this meeting, so the following were presented during the meeting:
-
-	FOSDEM:
-		What council members plan to attend the 2011 edition?
-			Betelgeuse, jmbsvicetto and wired are set to go. scarabeus is a tentative maybe.
-		jmbsvicetto will try to arrange Saturday's dinner - with possible help from bonsaikitten.
-		Further discussion was pushed to the existing FOSDEM thread in the project ml.
-
-	meeting time:
-		The US council members (ferringb and halcy0n) have started a new discussion about the meeting time, as the current schedule doesn't work for them
-
-	livedvd:
-		scarabeus recalled that we should try to get a new livedvd (with new codename) out soon, so we can have a bug release before FOSDEM.
-
-
-* go through bugs assigned to the Council
-
-	http://bugs.gentoo.org/buglist.cgi?quicksearch=assignedto,cc:council@gentoo.org
-
-	234706
-		no new info. Halcy0n is very busy so would welcome any other member taking care of this bug.
-
-	234711
-		discussion about GLEP54 was done in the last meeting and there was a vote for _live. jmbsvicetto will take care of the bug.
-
-	237381
-		jmbsvicetto will start a thread in the project ml later today about this issue
-
-	316401
-		waiting for resolution by the bugzilla team
-
-	316405
-		waiting for resolution by the bugzilla team
-
-	331987
-		waiting on infra
-
-
-* decide who's chairing the next meeting
-
-	ferringb
-
-
-* choose next meeting's date
-
-	20101019 20H00 UTC
-
-
-* open floor - listen to the community
- 
-	No issue was brought to the attention of the council at this meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20100927.txt b/xml/htdocs/proj/en/council/meeting-logs/20100927.txt
deleted file mode 100644
index 81af746504..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20100927.txt
+++ /dev/null
@@ -1,262 +0,0 @@
-19:00 <@scarabeus> jmbsvicetto: if we dont have any topic, i would like to talk about livedvd, but for that i need only you :D
-19:00 <@jmbsvicetto> :)
-19:02 <@jmbsvicetto> alright, let's do the roll call
-19:02 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has joined #gentoo-council
-19:02 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
-19:03  * Halcy0n raises his hand.
-19:03 <@jmbsvicetto> so who's around here?
-19:03  * Chainsaw raises both hands, just to be different
-19:03  * scarabeus moves from the bar
-19:03 <@jmbsvicetto> wired: ping
-19:05 <@jmbsvicetto> can anyone ping / phone ferringb?
-19:05 < Philantrop> jmbsvicetto: Can't be that hard to find topics. After all, most of you had splendid manifestos. Chainsaw wanted to discourage the usage of overlays and find a solution for maintainer-needed packages. Then there's betelgeuse's webapp thing. Halcyon wanted "to get innovation starting in Gentoo again" so there should be lots to discuss. ferringb wanted to reform the council election process and the council itself. jmbsvicetto
-19:05 < Philantrop> wanted to re-work GLEP39 and lots of other things. wired wanted to be "swift, decisive, vigilant". So, guys, I'm sure you've all worked hard on your goals. Wouldn't it be time to discuss each of your progress?
-19:05 -!- [Enrico] [~chiccoroc@gentoo/contributor/Enrico] has joined #gentoo-council
-19:05 <@wired> I'm here
-19:06 <@jmbsvicetto> Philantrop: yes, I need to start the discussion about my goals. You are correct
-19:06 < mama> Philantrop, your 2nd last was cut on "itself. jmbsvicetto"
-19:08 <@scarabeus> jmbsvicetto: i dont have phone at my hand, actualy i really dunno where i put it; grm ; so i cant call anyone :)
-19:08 <@Halcy0n> I'm not sure where I put all of your numbers...looking now :)
-19:09 < NeddySeagoon> Just start - you have a quorum and its +8 min in
-19:10 <@wired> my goals are really off because real life has been dominating lately
-19:10 <@wired> I'm hoping to get some free time soon
-19:10 < NeddySeagoon> wired, planning or hoping ?  planning is good, leaving it to chance ...
-19:11 <@wired> yeah, planning is the right word ;)
-19:11 -!- Betelgeuse [~betelgeus@gentoo/developer/Betelgeuse] has joined #gentoo-council
-19:11 -!- mode/#gentoo-council [+o Betelgeuse] by ChanServ
-19:12 <@jmbsvicetto> ok, I caught Betelgeuse 
-19:12 <@jmbsvicetto> so, let's move on
-19:12 <@Betelgeuse> Hmm. Sorry about being late.
-19:12 <@jmbsvicetto> We have no item in our agenda
-19:12 <@Betelgeuse> Got burried in a debugging.
-19:12 <@jmbsvicetto> Any of you wants to discuss anything before moving to the bugs?
-19:13 <@Betelgeuse> jmbsvicetto: FOSDEM?
-19:13 <@Betelgeuse> How many of the council will be there?
-19:13 <@scarabeus> i am still not sure if i get the money to actualy get there :)
-19:13 <@wired> I'll be there
-19:13 <@jmbsvicetto> I'm going to book my plane from Lisbon to Brussels later tonight
-19:13 <@scarabeus> so for me it is "maybe"
-19:14 <@Betelgeuse> jmbsvicetto: We could consider organizing some kind of a QA session like there was some years back.
-19:14 <@jmbsvicetto> That sounds a great idea
-19:14 <@Halcy0n> I won't be there.
-19:14 <@jmbsvicetto> we could also have a special "bugday" on Saturday or something similar to involve the community
-19:15 < NeddySeagoon> Who is doing the organising now ?
-19:15 <@Betelgeuse> NeddySeagoon: There's no need for much organising if we don't get a booth
-19:15 <@Betelgeuse> Someone should organizer a dinner though
-19:16 <@jmbsvicetto> I wouldn't mind organizing it, but I'm too far away for that :\
-19:16 -!- anti[Enrico] [~chiccoroc@gentoo/contributor/Enrico] has joined #gentoo-council
-19:17 <@Betelgeuse> jmbsvicetto: bonsaikitten should be able to at least help you along
-19:17 <@Betelgeuse> bonsaikitten: Assuming you are willing of course.
-19:17 -!- ferringb [~ferringb@gentoo/developer/ferringb] has joined #gentoo-council
-19:17 -!- mode/#gentoo-council [+o ferringb] by ChanServ
-19:17 <@Halcy0n> ferringb is on his way, btw.
-19:17 <@Betelgeuse> jmbsvicetto: The hard part is collecting info on who will attend.
-19:17 <@Betelgeuse> jmbsvicetto: And then getting everyone there :)
-19:17 -!- [Enrico] [~chiccoroc@gentoo/contributor/Enrico] has quit [Disconnected by services]
-19:17 -!- anti[Enrico] is now known as [Enrico]
-19:18 < bonsaikitten> Betelgeuse: don't want to commit yet as I can't predict anything, but if I have the time ... yes, of course
-19:18 <@ferringb> Betelgeuse: hard part is attending on time
-19:18 <@Betelgeuse> ferringb: We were talking about FOSDEM
-19:18 <@scarabeus> ferringb: which for you as USan is not so amusing i guess :)
-19:19  * ferringb cracks the whip
-19:19 <@jmbsvicetto> I suggest we plan to have dinner closer to Brussels this year
-19:19 <@ferringb> Halcy0n: sorry, literally a mess atm- channel?
-19:19 <@jmbsvicetto> I wouldn't mind the Italian we went close to Grand Place
-19:20 <@ferringb> ahh right
-19:20 <@jmbsvicetto> ok, so I'll try to arrange the dinner - possibly with bonsaikitten's help
-19:21 < NeddySeagoon> jmbsvicetto, what night ?
-19:21 <@jmbsvicetto> Saturday
-19:21 <@scarabeus> friday is the event, so saturday as usuall
-19:21 <@jmbsvicetto> NeddySeagoon: we usually meet at Delirium on Friday and plan the dinner for Saturday
-19:21 <@scarabeus> jmbsvicetto: you might also poke sabayoners :)
-19:21 <@wired> is the booth a possibility?
-19:22 <@jmbsvicetto> Anyone planning to arrive earlier or to leave later this year?
-19:22 <@jmbsvicetto> wired: I don't think it'll be easy to get one, but in any case we should really, *really* get someone responsible for it before applying
-19:22 <@Betelgeuse> jmbsvicetto: Friday - Monday usually for me
-19:23 <@wired> Jorge: I'm probably doing the Friday-Monday thing again
-19:23 <@jmbsvicetto> yeah, I plan to arrive around 13H00 on Friday and leave around 14H00 on Monday
-19:23 <@jmbsvicetto> we can talk off channel about accomodation
-19:23 <@wired> indeed
-19:23 <@jmbsvicetto> I'll ask about it in the FOSDEM thread
-19:23 <@wired> sleep well ftw? hehe
-19:24 <@jmbsvicetto> I would prefer a better (free?) wi-fi, but wouldn't mind getting there again
-19:24 <@wired> ah yeah, the sad Internet story
-19:24 <@scarabeus> jmbsvicetto: there is no free wifi in brusell
-19:24 <@scarabeus> i told you
-19:24 <@scarabeus> move fosdem to prague :)
-19:24 <@jmbsvicetto> I'll take my extension cords again
-19:24 <@wired> :p
-19:25 <@Betelgeuse> jmbsvicetto: The hotel I have usually taken has had it included
-19:25 <@jmbsvicetto> scarabeus: want to bring that to the FOSDEM distributions ml? ;)
-19:25 <@scarabeus> :DDD
-19:25 <@scarabeus> i want to live :)
-19:25 <@ferringb> Halcy0n: side note, what hours works for you moving forward btw (that thread died off) ?
-19:25 <@jmbsvicetto> Betelgeuse: we'll have to talk about it ;)
-19:25 <@ferringb> afaik your hours are going to be even tighter than my own
-19:26 <@jmbsvicetto> ferringb / Halcy0n: I think the first issue is what day of the week
-19:26 <@Halcy0n> ferringb: I'm going to look at what people replied with and try to take it from there.
-19:26  * ferringb notes wired's suggested time really won't fly
-19:26 <@jmbsvicetto> scarabeus / wired / Betelgeuse: how flexible would you be about delaying the meeting hours on week days?
-19:26 <@ferringb> that's 6am till noon on sunday
-19:26 <@ferringb> or 3am till 6am on saturday, iirc
-19:27 <@Halcy0n> I have to see what happens in the coming weeks for me.  I've been extremely busy lately.
-19:27 <@scarabeus> jmbsvicetto: i would rather go over weekends maybe :)
-19:27 <@ferringb> pretty much for me, monday + noon is proving to be a serious killer
-19:27 <@Betelgeuse> jmbsvicetto: I could start an hour later
-19:28 <@Betelgeuse> jmbsvicetto: Or then it would have to be next morning
-19:28  * ferringb notes an hour later has a decent chance of being less of a mess for him
-19:28 <@jmbsvicetto> I can go up until 0000UTC on weedays and can go with weekends between 1100 UTC to 0100 / 0200 UTC
-19:29 <@jmbsvicetto> Betelgeuse: about FOSDEM, anything else we should talk about nwo?
-19:29 <@jmbsvicetto> now*
-19:29 <@Halcy0n> As I said, its still very much up in the air for me.  I have to see how certain things work out.
-19:29 <@ferringb> well
-19:29  * ferringb can keep trying it, but noon/monday isn't flying at this point for him
-19:29 <@ferringb> it was initially, but it's proving pretty hard to be timely
-19:31 <@ferringb> push back of an hour on monday at least would be appreciated... else another weekday perhaps
-19:31 <@wired> I'd be ok with that
-19:31 <@jmbsvicetto> If no one else takes care of it, I can make the funding request to the trustees. I'll have to know what we want to get to FOSDEM first, though
-19:31 <@Betelgeuse> jmbsvicetto: let's continue mls
-19:32 <@jmbsvicetto> So can we try to have the next meeting at 2000 UTC?
-19:32 <@Betelgeuse> jmbsvicetto: The booth dl is soon so we need to act on that if we want one
-19:32 <@ferringb> Halcy0n: guessing it still is a mess either way for you w/ the extra hour?
-19:32 <@jmbsvicetto> Betelgeuse: ok
-19:32 <@Halcy0n> I'll be fine for a couple more weeks.  I'll have to see what happens after that.
-19:32 <@jmbsvicetto> hmm, we need to check the day light time change for next meeting
-19:33 <@jmbsvicetto> scarabeus: Do you still want to talk about the livedvd?
-19:34 <@jmbsvicetto> scarabeus: is it related to FOSDEM and or a topic for this discussion or can / should we talk later about it?
-19:34 <@scarabeus> jmbsvicetto: well we should have it shipped rather soon, so we can release first bugfix for fosdem
-19:34 <@scarabeus> and we should have some codename for it
-19:34 <@scarabeus> cause 10.0 does not fit anymore ;)
-19:34 <@jmbsvicetto> I thought people didn't want rolling code names anymore
-19:34 < NeddySeagoon> 11.0 ?
-19:35 <@jmbsvicetto> also, iirc there was a proposal recently to the dev ml to change the profiles naming
-19:35 <@ferringb> infinity + 1
-19:35 <@scarabeus> nah no need for new profile
-19:35 <@wired> rolling is what we do
-19:35 <@scarabeus> just codename
-19:35 <@wired> :p
-19:35 <@scarabeus> profiles should be updated if needed
-19:35 <@scarabeus> not mandatory :)
-19:35 <@jmbsvicetto> so, anything else or should we go over the bugs?
-19:37 <@Halcy0n> I have no info for my bug as I haven't had much free time.  I also don't know how much of a problem it is since I haven't heard a lot of complaining lately about slacking arches.  If someone wants to take it over from me, since I'm going to be pretty busy the coming weeks, please do so, otherwise I'll look into it "soon".
-19:38 <@jmbsvicetto> ok, so going over our bug list: http://www.google.com/url?sa=D&q=http%3A%2F%2Fbugs.gentoo.org%2Fbuglist.cgi%3Fquicksearch%3Dassignedto%2Ccc%3Acouncil%40gentoo.org
-19:38 <@jmbsvicetto> bug 234706
-19:38 < willikins> jmbsvicetto: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-19:38 <@jmbsvicetto> no new info as Halcy0n reported
-19:38 <@jmbsvicetto> bug 234711
-19:38 < willikins> jmbsvicetto: https://bugs.gentoo.org/234711 "GLEP 54: scm package version suffix"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:lu_zero@g.o
-19:39 <@jmbsvicetto> as we talked about GLEP54 in last meeting, can we close this one?
-19:39  * ferringb notes there is a minor modifier to 54 btw
-19:40 <@jmbsvicetto> anyone?
-19:40 <@ferringb> would've mentioned it last time around if I'd been in meeting- while I think in the current tree it's a no go, I don't see any reason folk can't reopen it down the line if repository watermarking or a new repo layout is created
-19:40 <@ferringb> irreverent to the closing of the bug for the most part, just mentioning it to make my opinion known on that one
-19:41 -!- [Enrico] [~chiccoroc@gentoo/contributor/Enrico] has left #gentoo-council ["http://quassel-irc.org - Chat comfortably. Anywhere. [Enrico] was here"]
-19:42 <@jmbsvicetto> I see the summary doesn't list a decision, but iirc we made a choice about the suffix
-19:43 <@ferringb> suffix was passed 4x2 if memory serves
-19:43 <@ferringb> aka, close the ticket if there is nothing left to be done, else pass it off to affected folk
-19:44  * ferringb notes his commentary is primarily aimed at 55 on that, although personal opinion is that applies to 54 also... that said ;)
-19:45 <@wired> ftr, I have a new glep55 solution idea I have to write down
-19:45 <@ferringb> anyone actually want to track/own that ticket council wise?
-19:46 <@jmbsvicetto> sorry, was reading the log. From my reading we got a majority vote on _live
-19:46 <@ferringb> hmm?
-19:46 <@jmbsvicetto> the log for the last meeting
-19:46 <@jmbsvicetto> Anyone wants to take care of this bug?
-19:47 <@jmbsvicetto> for anyone distracted, bug 234711
-19:47 <@ferringb> bahh. me is inverting 'em, aren't I :/
-19:47 < willikins> jmbsvicetto: https://bugs.gentoo.org/234711 "GLEP 54: scm package version suffix"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:lu_zero@g.o
-19:47 <@jmbsvicetto> If no one wants to do it, I'll take care of this one
-19:47 <@ferringb> jmbsvicetto: chatting w/ zac is wise on that at the very least
-19:48 <@ferringb> jmbsvicetto: aka, in the loop and such
-19:48 <@jmbsvicetto> sure
-19:48 <@jmbsvicetto> ok, seems no one is stepping up, so I'll take care of this bug
-19:48 <@jmbsvicetto> next, bug 237381 
-19:48 < willikins> jmbsvicetto: https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:dberkholz@g.o
-19:48 <@jmbsvicetto> This one is mine. I'll start a thread in the project ml about it tonight
-19:48 <@jmbsvicetto> bug 316401 
-19:48 < willikins> jmbsvicetto: https://bugs.gentoo.org/316401 "Add resolution OBSOLETE"; Bugzilla, General Bugs; NEW; betelgeuse@g.o:bugzilla@g.o
-19:48 <@jmbsvicetto> bug 316405
-19:48 < willikins> jmbsvicetto: https://bugs.gentoo.org/316405 "Disable resolutions LATER and REMIND"; Bugzilla, General Bugs; NEW; betelgeuse@g.o:bugzilla@g.o
-19:49  * ferringb notes the next two are mostly infra
-19:49 <@jmbsvicetto>  these two bugs are in the bugzilla team hands
-19:49 <@jmbsvicetto> bug 331987
-19:49 <@jmbsvicetto>  
-19:49 < willikins> jmbsvicetto: https://bugs.gentoo.org/331987 "Merge -council and -project mailing lists"; Gentoo Infrastructure, Mailing Lists; NEW; scarabeus@g.o:infra-bugs@g.o
-19:49 <@jmbsvicetto> this one is on infra.
-19:49 <@jmbsvicetto> so, who wants to chair next meeting
-19:49 <@jmbsvicetto> ?
-19:49 <@ferringb> I'll do it if it's at 20 UTC :P
-19:50 <@scarabeus> also guys i have on manifesto one thing i didnt kick my ass to do yet, the gwn, i hope i will have something for next meeting :)
-19:50 <@ferringb> would definitely be interested in any notions for it
-19:51 <@jmbsvicetto> ferringb: Can you commit to it or would you prefer someone else volunteers for being chair of the meeting?
-19:52 <@ferringb> can commit to 20 utc
-19:52 <@jmbsvicetto> about the next date, do we want to have it on a Monday? (4, 11, 18, 25)
-19:52 <@jmbsvicetto> and does anyone know when daylight savings kick in?
-19:52 <@ferringb> tuesday perhaps?
-19:52 <@jmbsvicetto> 5 is an holliday here, so I'm free ;)
-19:53 <@ferringb> jmbsvicetto: 11/07 roughly for usian
-19:53 <@jmbsvicetto> so, first question: Monday or Tuesday?
-19:53 <@wired> last weekend of October in eu
-19:53 <@jmbsvicetto> I can do both
-19:53 <@wired> Jorge ^^
-19:53 <@jmbsvicetto> ferringb: ok, that doesn't affect next meeting
-19:53 <@jmbsvicetto> wired: yeah
-19:53 <@ferringb> jmbsvicetto: correction, 11/31
-19:53 <@ferringb> *10/31
-19:54 <@Halcy0n> I have no idea what my availability is yet, so just go ahead with whatever and I'll deal with it.
-19:54 <@jmbsvicetto> wired / Betelgeuse / scarabeus / Chainsaw: Monday or Tuesday?
-19:54 <@scarabeus> ok for me, both days
-19:54 <@Betelgeuse> jmbsvicetto: doesn't matter
-19:54 <@wired> either is fine
-19:54 <@jmbsvicetto> ok, Tuesday then
-19:54 <@jmbsvicetto> 2000 UTC?
-19:55 <@wired> ok
-19:55 <@Chainsaw> Tuesday 2000 UTC works for me, thank you.
-19:55 <@jmbsvicetto> Betelgeuse / scarabeus: 2000 UTC?
-19:55 <@scarabeus> can be
-19:56  * ferringb notes he appreciates it
-19:56 <@jmbsvicetto> oh and what day of the month?
-19:56 <@jmbsvicetto> 5, 12, 19 or 26?
-19:56 <@jmbsvicetto> I think 5 is too short
-19:56 <@jmbsvicetto> s/short/close/
-19:56 <@ferringb> 12 is 15 days out
-19:56 <@ferringb> 19th would get my vote, since I suspect there won't be much in the coming 3 weeks
-19:57 <@jmbsvicetto> ferringb: as you're going to chair it ;), what date do you suggest?
-19:57 <@jmbsvicetto> 19th is ok for me
-19:57 <@wired> fine for me too
-19:57 <@ferringb> hokay
-19:58 <@jmbsvicetto> scarabeus / Betelgeuse / Chainsaw / Halcy0n: 19th?
-19:58 <@scarabeus> okchay
-19:58 <@Betelgeuse> jmbsvicetto: ok
-19:58 <@jmbsvicetto> anyone following the wave summary?
-19:58 <@ferringb> 'ootay' would've been a better response :P
-19:59 <@jmbsvicetto> ok, so let's move to the open floor
-19:59 <@Chainsaw> Can't do 11-22
-19:59 <@Chainsaw> So 19th doesn't work for me, sorry.
-19:59 <@jmbsvicetto> Chainsaw: 26th?
-20:00 <@jmbsvicetto> ferringb: your suggestion
-20:00 <@Chainsaw> jmbsvicetto: Yeah, 26th is fine.
-20:00 <@jmbsvicetto> ?
-20:00 <@jmbsvicetto> ferringb / Halcy0n / Betelgeuse / wired / scarabeus: 26th?
-20:01 <@ferringb> works for me
-20:01 <@scarabeus> jmbsvicetto: too
-20:01 <@wired> a bit far away but I guess we can always reschedule if anything comes up
-20:01 <@wired> so ok :)
-20:01  * ferringb nods
-20:02 <@ferringb> worst case we make chainsaw get himself a proxy (don't think anyone has used that card yet either) ;)
-20:02 -!- jmbsvicetto changed the topic of #gentoo-council to: Next meeting 20101026 2000UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000
-20:02 <@jmbsvicetto> ferringb: ssuominem was proxy for scarabeus in last meeting
-20:02 <@ferringb> stand corrected
-20:03 <@jmbsvicetto> ferringb: Good luck and have fun with the next meeting ;)
-20:03  * ferringb nods
-20:03 <@scarabeus> jmbsvicetto: you forgot onto open floor
-20:03 <@jmbsvicetto> I'll give another 30 minutes for the open floor and will then close this meeting
-20:03 <@scarabeus> ah, hehe :D
-20:04 <@jmbsvicetto> scarabeus: I had typed to open it, but then Chainsaw said he couldn't do 19th and I was forgetting it now
-20:04 <@jmbsvicetto> 19:59 <@jmbsvicetto> ok, so let's move to the open floor 
-20:04 <@jmbsvicetto> Thanks guys for being around for our meeting
-20:05 <@jmbsvicetto> in case any of you can, please check the summary in the wave
-20:24 <@ferringb> doobie... doobie doo
-20:27 -!- miknix [~miknix@gentoo/developer/miknix] has joined #gentoo-council
-20:31 -!- miknix [~miknix@gentoo/developer/miknix] has quit [Client Quit]
-20:44 <@jmbsvicetto> ok, meeting closed then
-20:45 <@Chainsaw> Thank you.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20101026-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20101026-summary.txt
deleted file mode 100644
index d825254afe..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20101026-summary.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-2010-10-26 Council meeting summary
-==================================
-
-All members present:
-	betelgeuse, chainsaw, ferringb, jmbsvicetto, halcyon, scarabeus, wired
-
-Agenda:
-	ferringb forgot to send meeting related mail, so there was no
-	announced agenda.
-
-Topics discussed:
-
-	la files
-	--------
-
-	The council decided that removing la files is the right thing to do,
-	but the whole thing will be taken to the -dev ML to allow devs to
-	express their opinions/objections, if any. Jorge will handle this.
-
-	The removal will only happen after portage-2.1.9 or later is
-	stabilized, since this is the first version that can fix la files
-	automatically.
-
-	At that time, a news item will be released to inform users on how to
-	fix any issues that may arise from the removal.
-
-	EAPI 4
-	------
-
-	few_ suggested finalizing EAPI 4 with the features currently
-	implemented in portage (bug #273620).
-
-	we agreed that this is a good idea, as long as a spec list is built
-	and PMS patches are written for all the features.
-
-	ferringb will write documentation for REQUIRED_USE.
-
-	the council will finalize things in the next meeting. people
-	responsible for EAPI 4 should be pinged beforehand so they can attend
-	that meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20101026.txt b/xml/htdocs/proj/en/council/meeting-logs/20101026.txt
deleted file mode 100644
index dacd4bbc14..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20101026.txt
+++ /dev/null
@@ -1,280 +0,0 @@
-20:01  * ferringb bangs the gavel
-20:01 <@scarabeus> btw guys i am sick have fever and lot of pills in me, so if i disappear in middle of meeting plz excuse me for falling asleep ;)
-20:02 <@ferringb> heh
-20:02 <@wired> no excuses! :Pp
-20:02 <@ferringb> related, if I pop off for 5 minutes... pardon.  not a fever, imminent release and no proper cube space to keep people the hell out
-20:03 <@jmbsvicetto> brb
-20:03 <@ferringb> heh
-20:03  * ferringb is counting 6 folk atm
-20:04 <@scarabeus> Halcy0n: ping
-20:04 <@Halcy0n> Sorry, here :)
-20:04 <@jmbsvicetto> back
-20:04 <@ferringb> !seen chainsaw
-20:04 < willikins> ferringb: Chainsaw was last seen 1 day, 19 hours, 50 minutes and 25 seconds ago, quitting IRC (Quit: Leaving) and a moment before doing *Chainsaw leaves mr. Fire & mr. Viola to work this out amongst themselves* in
-20:05 <@ferringb> so... number?
-20:05 <@jmbsvicetto> Anyone willing to call?
-20:06  * ferringb is willing, but can't
-20:06 <@ferringb> better question is does anyone have the number
-20:06 <@jmbsvicetto> I have it
-20:07 <@jmbsvicetto> ok, I'll call him
-20:07 <@scarabeus> Jorge - The secretary - comming to theater near you really soon
-20:07 <@jmbsvicetto> :P
-20:08 <@scarabeus> is few_ around?
-20:08 <@scarabeus> for the future (about that eapi) :)
-20:08 <@wired> !seen few_
-20:08 < willikins> wired: few_ was last seen 1 hour, 15 minutes and 6 seconds ago, saying "good" in #gentoo-portage
-20:09 <@jmbsvicetto> He should be around soon
-20:09 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has joined #gentoo-council
-20:09 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
-20:09 <@Chainsaw> Sorry!
-20:09 <@scarabeus> hi man
-20:09 <@wired> ohai
-20:09 <@ferringb> Chainsaw: 10 lashes!
-20:09 <@Chainsaw> I know :(
-20:09 <@jmbsvicetto> Chainsaw: I'm sorry but you'll have pay ice-cream for all of us!!! ;)
-20:09 <@jmbsvicetto> +to
-20:10  * Chainsaw runs into the kitchen to make every coffee & tea
-20:10 <@wired> ice-cream? we have a machine for that, let him bring beer instead
-20:10 <@ferringb> Chainsaw: wouldn't worry.  you're 10 minuts- that's significantly better than my turn around when I'm still stuck in a meeting and someone has to call ;)
-20:10 <@wired> :P
-20:10 <@jmbsvicetto> wired: I think you'll prefer than for FOSDEM ;)
-20:11 <@jmbsvicetto> So, shall we start?
-20:11  * ferringb supposes
-20:11 <@Chainsaw> Yes, let us proceed.
-20:11 <@ferringb> first, sorry for the clusterfuck of me not sending out the agenda/2 week notice- works been mildly hellish
-20:12 <@ferringb> what we have on the schedule is namely .la files, and request by few/co. to look at eapi4 (approve what is implemented specifically)
-20:12 <@ferringb> so... .la first I suppose.
-20:12 <@scarabeus> yep
-20:12  * ferringb yields the floor to whoever wants to first fling poo on the matter
-20:13 <@scarabeus> jmbsvicetto: basically you nominated it so wanna start?
-20:15 <@scarabeus> so ok, everyone of us knows what lafiles are and what are their disandvantages i guess
-20:15 <@scarabeus> only thing we need to do is figure some global way how to get rid of them, because those @preserved-rebuild and lafilefixer runs are annoying :)
-20:15 <@scarabeus> if i get it right
-20:15 <@ferringb> and the given decision as to whether killing them off is even desired (presume yes, but it is a choice point)
-20:16 <@scarabeus> well most apps use pkgconfig anyway :)
-20:16 <@jmbsvicetto> ok
-20:17 <@wired> has anyone presented any really important reason not to kill them? afaik there haven't been any really important arguments
-20:17 <@jmbsvicetto> Does any of us (council) have any objections about killing la files (where appropriate) ?
-20:17 <@Chainsaw> I believe not installing .la files should be the default.
-20:17 <@Chainsaw> If you do install them, there should be a comment in your ebuild stating why.
-20:17 <@ferringb> Chainsaw: same for me.
-20:18 <@Chainsaw> Disagreement with comments can go through the usual commit reviews, which do happen.
-20:18  * ferringb nods
-20:18  * Chainsaw wouldn't want to say "Never! Thou shalt not install .la files under any circumstances"
-20:18 <@ferringb> exactly
-20:18 <@scarabeus> yes so agreed on their removal
-20:19 <@Chainsaw> But "default off" and "comments mandatory"
-20:19 <@ferringb> how to do the removal?
-20:19 <@scarabeus> problem is process
-20:19 <@ferringb> well, I see 2 issues
-20:19 <@jmbsvicetto> Just to be clear, there are cases where we can't just remove them
-20:19 <@ferringb> yep
-20:19 <@ferringb> 1) the pruning itself, doing it without breaking the shit out of things while transitioning
-20:19 <@jmbsvicetto> libtool and some particular packages
-20:20 <@jmbsvicetto> Then there's the issue that Diego has identified at least one package with .la files that are not libtool archives
-20:20 <@ferringb> 2) should the pruning be configurable?
-20:21 <@ferringb> so... views?
-20:21 <@Chainsaw> Can we make it part of the new EAPI? Have a dolafile?
-20:21 <@jmbsvicetto> Chainsaw: there's no need for a new EAPI for this
-20:21 <@jmbsvicetto> I like Diego's proposal:
-20:22 <@Chainsaw> jmbsvicetto: There isn't a need, but it's a way.
-20:22 <@Betelgeuse> jmbsvicetto: No but it could be useful down the road.
-20:22 <@Chainsaw> Ah, the flaming eyes. What did they say?
-20:22 <@Halcy0n> The problem is still the crap breaking as we get rid of them.  We need to have it automated so that things fix themselves.
-20:22 <@jmbsvicetto> let's add to eutils.eclass the following function:
-20:22 <@jmbsvicetto> delete_libtool_archives() { find "${@:$D}" -name '*.la' -delete
-20:22 <@jmbsvicetto> }
-20:22 <@jmbsvicetto> Halcy0n: In my view there's 2 issues
-20:22 <@Chainsaw> jmbsvicetto: That still relies on people calling it though.
-20:23 <@jmbsvicetto> 1. drop .la files from packages that don't need them
-20:23 <@jmbsvicetto> 2. fix required .la files to use propper -l<lib> -L<path> instead of hardcoding library references
-20:23 <@jmbsvicetto> The 2 is already being done on portage
-20:23 <@jmbsvicetto> Chainsaw: yes, but that's the whole point
-20:24 <@jmbsvicetto> Chainsaw: you can't just set a FEATURES="no-la-files" and have your system kill all .la files
-20:25 <@jmbsvicetto> The above function would fix 1
-20:25 <@jmbsvicetto> leio: around?
-20:25 < leio> a bit
-20:26 <@wired> can't we have FEATURES="keep-la-files" for those users who want them and another var that ebuilds can set to force la preservation if needed?
-20:26 <@jmbsvicetto> leio: If we wait to get a stable version of portage with support for 2 and make sure we get the news item warning about 1, do you still have any objection with going forward with this?
-20:26 <@jmbsvicetto> wired: that's what the static-libs use flag is being added for
-20:26 < leio> I don't know what "this" is, need to be preoccupied 5 minutes and then read up
-20:27 <@jmbsvicetto> The idea is that we're installing just shared libs by default and that anyone wanting to keep static libs enables the static-libs use flag
-20:28 <@jmbsvicetto> leio: adding to eutils a function to drop the la files (so we have the same function being used all over the tree). That function will remove all la files in ${D} or just the list of files/dirs specified in an ebuild
-20:29 <@jmbsvicetto> leio: The removal of la files in a package will still have to be discussed with the maintainers - I'm not suggesting someone jumps in the tree and touches all packages without talking to the maintainers
-20:30 <@ferringb> jmbsvicetto: but that's fun!
-20:31  * ferringb looks around; not much comments from folk
-20:31 <@jmbsvicetto> So, does anyone have any objections to going this route?
-20:32 <@Chainsaw> jmbsvicetto: Thinking about it, having a function in eutils makes it easier on maintainers.
-20:32 <@ferringb> and easier to flip it off if someone wants to
-20:32 <@ferringb> although I'm not convinced of a feature controlling that
-20:33 <@jmbsvicetto> I think user's control should be about whether to install static libs or not
-20:33 <@jmbsvicetto> That function should not be called if USE="static-libs"
-20:34 -!- darkside_ [~darkside@gentoo/developer/darkside] has joined #gentoo-council
-20:34  * ferringb nods
-20:35 -!- dilfridge [~quassel@gentoo/developer/dilfridge] has joined #gentoo-council
-20:35 <@jmbsvicetto> darkside_: you joined in a good time
-20:35 <@jmbsvicetto> darkside_: are there any concerns from prefix about removing the la files?
-20:35 <@jmbsvicetto> So, no objections, no agreement, no opinion? anyone?
-20:36 <@Halcy0n> I never cared, so long as it was done in a way that would not cause headaches for users :)
-20:36 <@wired> the function looks fine to me
-20:36 -!- Zorry [~zorry@gentoo/developer/zorry] has joined #gentoo-council
-20:36 < darkside_> jmbsvicetto: the only concern would be the archs that require static so a tunable param would be desired
-20:37 < darkside_> (minor)
-20:37 <@jmbsvicetto> darkside_: in those arches you could just force enable the static-libs use flag, right?
-20:37 < darkside_> i think so. i haven't dug into the implementation details yet
-20:37 < darkside_> grobian did reply to that thread on -dev and flameyees agreed while talking on irc
-20:38 <@jmbsvicetto> darkside_: Do you have an idea of what prefix supported arches require static building?
-20:39  * darkside_ looks abit
-20:39 -!- blackace [~blackace@gentoo/developer/blackace] has joined #gentoo-council
-20:40 < darkside_> http://archives.gentoo.org/gentoo-dev/msg_a39b16fbf70fd08a029c883d6e7f6aeb.xml <- grobian's comment on the thread
-20:41 < leio> One primary reason of existence of libtool is for supporting non-ELF platforms, where even shared libraries might not record dependencies within themselves. I don't know of any such systems that we care about though, as apparently it's not an issue on PE
-20:42 <@ferringb> adding an option when it's neeed isn't hard
-20:42 <@ferringb> *needed
-20:42 < darkside_> only one or two requires static and they are minor archs which i don't care about, but users do. apparantly there is this whole community has built up gentoo on atari (m68k-mint) =D
-20:42 < leio> basically the idea in my mind has always also been doing it via an eclass, so you can tune it in a global place. Like have a variable that needs to be defined in make.conf for any deletion to be done
-20:42  * ferringb nods
-20:43 < leio> darkside_: this isn't about just static libs. Some systems don't have DT_NEEDED in shared libraries
-20:43 <@jmbsvicetto> ok, my proposal is the following:
-20:43 <@wired> leio: or a variable to be defined for deletion _not_ to be done
-20:43 <@ferringb> point is, if the deletion is via an eutils func, wiping/overriding the .la removal is easy enough
-20:43 <@jmbsvicetto> 1. add the function to the eutils eclass so that we use a consistent function everywhere
-20:43 < leio> If it's a variable, then it could be set on new installs AND users have the possibility to opt-in to it at a point _they_ have time to actually deal with it
-20:44 <@jmbsvicetto> 2. add a static-libs use flag for packages where we want to drop static libs and call that function only if the use flag isn't set
-20:44 <@jmbsvicetto> 2.1. that means arches that don't support using just the shared lib use.force static-libs
-20:45 <@jmbsvicetto> 3. halt any more ebuild work until a portage version with the lafilefixer like script that fixes .la files is marked stable
-20:45 <@Halcy0n> How does this address the breakage during the transition period?....
-20:45 <@Halcy0n> nvm :)
-20:45 <@jmbsvicetto> 4. require the news item warning users about the chance and telling them how to fix any issues they face
-20:46 <@wired> jmbsvicetto: that doesn't cover systems without DT_NEEDED in shared libraries that leio pointed out
-20:46 <@jmbsvicetto> wired: just force static-libs on those systems
-20:46 < leio> (I also said I don't know of any such systems we care about)
-20:46 <@wired> ok
-20:46 <@jmbsvicetto> wired: static-libs doesn't remove shared libs, it just forces building static libs as well and include .la files
-20:46 < leio> (and they don't necessarily need static libraries, just listing of all shared libraries)
-20:46 <@jmbsvicetto> leio: does this seem reasonable to you?
-20:47 <@jmbsvicetto> leio: the best option for those would probably be .pc files, right?
-20:47 < leio> yes, just not all libraries provide them yet
-20:48 <@jmbsvicetto> so, do we want to have a vote on this subject or would it be best to take this proposal to the dev ml and if there aren't many objections have a council vote through mail in a few days?
-20:48 <@Halcy0n> Take it to the ML and just let everyone have their chance to say yay or nay, then we can decide.
-20:48 <@jmbsvicetto> ok, I agree
-20:49 < leio> that's the main issue with libtool files - they only list all dependencies - indirect and direct. While really it should be indirect and direct separately, so that on ELF systems it would only look at the direct ones if needed in case of shared libs, and only look at indirect in those other cases. Either way, I don't think we care about those systems, and I'm not opposed to any proper .la file dropping, once the process is painless to users
-20:49 <@Halcy0n> Do we have any timelines on when a version of portage will be going stable to fix the la-files?
-20:49 <@jmbsvicetto> unless any of you wants to do it, I offer to write an email about this to the dev ml today or tomorrow
-20:49 <@jmbsvicetto> Halcy0n: I think Zac was talking in around 1 month
-20:49 < leio> As other random comments of the discussion above
-20:50 < leio> * .la files are _required_ if they are for plugins or the like that are opened via libltdl
-20:50 < darkside_> Halcy0n: FEATURES=fixlafiles is in portage-2.1.9*
-20:51 < leio> * .la files should never be required for plugins and the like that are opened via dlopen, no need to not delete them really if user requested no deletion otherwise
-20:51 <@wired> lets say that unless serious -currently unknown- issues arise, we'll vote [if needed] and proceed with this as soon as portage 2.1.9 is stable
-20:52 -!- ssuominen [~ssuominen@gentoo/developer/ssuominen] has joined #gentoo-council
-20:52 <@jmbsvicetto> darkside_: that's tied to a FEATURE? Doesn't sound the best option. Something else to talk in the ml
-20:52 <@jmbsvicetto> wired: I agree
-20:52 <@Halcy0n> I was just going to say the same thing.  It should just happen if necessary.
-20:53 <@jmbsvicetto> ferringb: should we proceed?
-20:53 <@ferringb> thus far it's your topic/your show ;)
-20:53 <@Halcy0n> I also need to leave in about 5-10 minutes, so if we can wrap it up.... :)
-20:53 <@jmbsvicetto> but you're the "hammer guy" tonight ;)
-20:53 <@ferringb> my personal views is proceed
-20:53 < leio> * the transition pain is about the .la files of libraries that other things link against. If lafilefixer --justfixit is made sure to be ran by users just once with a news item and from thereon out portage-2.1.9 with always enabled fixlafiles is used to prevent any future merges, I don't see a problem with deleting of those problematic .la files _after_ users have done all that
-20:53 <@ferringb> if we're wrong, that's fine, we revisit (the council can be wrong and overrule itself after all)
-20:54 < leio> (any future merges from having libtool files depend on other libtool files)
-20:54 <@ferringb> so... vote?
-20:54 <@jmbsvicetto> I thought we were going to move this to the ml?
-20:54  * ferringb has the hammer :P
-20:54 <@jmbsvicetto> hehe
-20:55  * ferringb notes the ml suffices if folks want it, but it's not going to be a fast process
-20:55 <@wired> [dodges the hammer] +1 here ftr :)
-20:56 <@Halcy0n> I say just give it about 5 days to let people comment if we missed anything, and then we can just go ahead with it if nothing big is brought up.
-20:56 <@jmbsvicetto> If we want to vote, I vote yes. I'm ready to work with people to get an implementation plan that addresses all concerns raised during this discussion
-20:56 <@Halcy0n> We can do stuff on the mailing lists and not just in these meetings :)
-20:56  * ferringb nods
-20:56 <@jmbsvicetto> we've already decided we can vote through email at any time
-20:57 <@ferringb> basically I'd like to get it decided today, then leave it to the next council run for the exact details of transitition plan to be worked out by then
-20:57 <@jmbsvicetto> ok, in that case I vote yes
-20:57 <@wired> yes
-20:57 <@Betelgeuse> So we are voting on if we want to get rid of them?
-20:57 <@Betelgeuse> or what?
-20:57 <@ferringb> heh.
-20:57 <@ferringb> punting them, specifically the eutils approach.
-20:58 <@Betelgeuse> I have no desire or need for them so - yes
-20:58 <@jmbsvicetto> ferringb: let's find a wording to point to
-20:58 <@ferringb> jmbsvicetto: would be useful yes.
-20:58 <@Chainsaw> I am in favour of deleting LA files where it makes sense, yes.
-20:59 <@jmbsvicetto> The motion is to drop la files, when appropriate, through the use of a function in eutils that will only be called if the static-libs use flag is not set.
-20:59 < ssuominen> .la files don't make sense with static archives if the package comes with pkg-config file
-20:59 <@wired> la removal, handled by eutils function, added to ebuilds by their maintainers, controlled by static-libs
-20:59 < ssuominen> so it can't be tied only to USE=static-libs, it simply doesn't make sense
-21:00 <@jmbsvicetto> The motion also sets a halt on la file removal until a portage version with support to fix the la files is marked stable and a news item is published informing users on how to fix any issue arising from the transition
-21:00 <@jmbsvicetto> ssuominen: The ebuild maintainer will add the function call where appropriate.
-21:01 <@wired> ssuominen: perhaps we can have two functions, one that always removes the la files (your case) and a wrapper that only removes la files if ! use static-libs
-21:01 < ssuominen> ok.
-21:01 <@jmbsvicetto> ssuominen: the static-libs use flag just prevents the removal of .la files if set. Is that ok?
-21:02 <@wired> jmbsvicetto: he's pointing out that you can have static-libs and still not need la files
-21:02 < ssuominen> no, they should be removed if a working .pc file is provided
-21:02 <@jmbsvicetto> ssuominen: ok, then let's add that exception
-21:02 <@jmbsvicetto> new wording:
-21:02 < ssuominen> and for libs that don't link to other libs (except libc itself) (no pkg-config file, but still no .la files required)
-21:03 <@jmbsvicetto> The motion is to drop la files, when appropriate, through the use of a function in eutils that will only be called if the static-libs use flag is not set or unless the package relies on pkg-config.
-21:03 <@wired> the function could have a force parameter
-21:03 <@jmbsvicetto> ssuominen: better?
-21:03 < ssuominen> see my last msg
-21:04 < ssuominen> still doesn't cover all cases where they should be punted
-21:04 <@jmbsvicetto> ok, we'll improve the wording in the ml
-21:04 <@ferringb> yeah, time for the ml I suspect since halcy0n is likely gone by now.
-21:04 <@jmbsvicetto> ferringb: the above can be used as a first draft to be improved in the ml. ok?
-21:04  * ferringb nods
-21:04 <@wired> ok
-21:05 <@ferringb> jmbsvicetto: should just doc the thing up anyways, since the resulting doc folk will need to look at from a qa standpoint down the line
-21:05 <@ferringb> not sure if we want to add it to devmanual or what, but you get the idea
-21:05 <@jmbsvicetto> we should probably add to the QA project space - if QA wants it
-21:05  * ferringb nods
-21:05 <@jmbsvicetto> like the --as-needed doc
-21:06 <@ferringb> jmbsvicetto: either way- guessing you'll take on that responsibility?
-21:06 <@jmbsvicetto> yes
-21:06 < ssuominen> the should be a "overlinking" page from which .la files -page and asneeded -page is linked to
-21:06 < ssuominen> *there
-21:06 < ssuominen> opensuse has one.
-21:06 < ssuominen> :)
-21:06 <@ferringb> jmbsvicetto: ok.
-21:06 <@jmbsvicetto> ssuominen: seems we have an "inspiration source" ;)
-21:07 <@ferringb> anyone care to be the next chairman also?  because I suck at it, and next month is going to be just as nasty as this month for me work wise ;)
-21:07 <@wired> how about this first?
-21:07 <@wired> <few_> what do you guys think about finalizing EAPI 4 with the stuff that is currently implemented in portage? there hasn't been much activity on the EAPI front in portage lately and I don't think this is going to change soon.
-21:07 <@jmbsvicetto> ferringb: Do we still want to go over EAPI-4? I need to go check on my mother, so I'd prefer to leave in a bit
-21:08  * ferringb will answer your question with a question
-21:08 <@ferringb> sans <few_>, who hear can state exactly what is implemented in portage right now for eapi4?
-21:08 <@jmbsvicetto> if no one wants to be the chair for next meeting, I'll do it
-21:08 <@ferringb> preferably now, without going and asking or scraping through the source at the last minute ;)
-21:09 <@ferringb> my point is, if eapi-4 is to be what's in portage now, patches needed, list of exactly what's in it's eapi4, etc, is needed
-21:09 < ulm> ferringb: I think only "slot operator dependencies" and "profile defined IUSE injection" are missing. bug 273620 is the tracker for portage.
-21:09 < willikins> ulm: https://bugs.gentoo.org/273620 "[TRACKER] sys-apps/portage EAPI 4 implementation"; Portage Development, Core; NEW; SebastianLuther@gmx.de:dev-portage@g.o
-21:09 <@Betelgeuse> I support releasing everything that's both implemented and has PMS text ready as EAPI 4.
-21:09 <@jmbsvicetto> about EAPI-4, I'm fine with going with whatever is done already, although a little discussion about desired features and current implementation could be useful. In the least it might help to start defining goals for the next EAPI
-21:10  * ferringb generally does, but doesn't think we should be passing it last minute w/out folks going over it closely
-21:11 <@jmbsvicetto> I agree. I'm not ready to vote now for the official EAPI without a complete spec
-21:11 <@Betelgeuse> ferringb: the passing is done with a PMS tag any way
-21:11 <@Betelgeuse> I don't think there's such a thing.
-21:11 <@Betelgeuse> well commit to tag
-21:12  * ferringb notes he needs to be disappearing pretty quickly...
-21:13 <@jmbsvicetto> I also need to leave now
-21:13 <@ferringb> jmbsvicetto: looks as though you're chairing the next round... exact date we'll figure out on the ml
-21:13 <@jmbsvicetto> ok
-21:13 <@jmbsvicetto> I'll shoot an email to the alias later asking for a date
-21:13 <@jmbsvicetto> see you later
-21:13  * ferringb nods
-21:13 <@wired> sorry
-21:13 <@wired> my net went down
-21:14 <@ferringb> wired: mostly shifting over to the ml
-21:14 <@wired> alrighty
-21:14 <@ferringb> jmbsvicetto is chairing the next round, exact date will be figured out there
-21:15  * ferringb disappears... back to the imminent release
-21:16 <@wired> okie. ftr, the tracker has all the eapi 4 features implemented, only two bugs are open
-21:16 -!- darkside_ [~darkside@gentoo/developer/darkside] has left #gentoo-council []
-21:17 < ulm> wired: also we don't have PMS wording for all implemented features
-21:19 <@Betelgeuse> ulm: are there any blockers on that front?
-21:20 < ulm> Betelgeuse: would be nice if somebody provided a wording for REQUIRED_USE
-21:20 <@Betelgeuse> ferringb: ^
-21:26 -!- scarabeus [~quassel@gentoo/developer/flyingspaghettimonster/scarabeus] has quit [Quit: No Ping reply in 180 seconds.]
-21:26 -!- scarabeus [~quassel@gentoo/developer/flyingspaghettimonster/scarabeus] has joined #gentoo-council
-21:26 -!- mode/#gentoo-council [+o scarabeus] by ChanServ
-21:39 <@ferringb> ulm: yeah, I can do so
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20101130-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20101130-summary.txt
deleted file mode 100644
index 4f5337a6ba..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20101130-summary.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-2010-11-30 Council meeting summary
-==================================
-
-members present:
-	betelgeuse, chainsaw, ferringb, jmbsvicetto, scarabeus, wired
-member missing, no proxy announced:
-	halcy0n
-
-Agenda:
-	EAPI 4
-	la files removal status/progress
-	future meetings
-
-What happened:
-
-	future meetings
-	---------------
-
-	We've talked [on alias] about alternating between Tuesdays and
-	Saturdays, because Halcy0n can't do weekdays and Chainsaw couldn't do
-	weekends.
-	
-	In the meeting it turned out that Chainsaw can do Saturdays,
-	although the timing is really hard for ferringb.
-
-	We decided to have our next meeting on Saturday the 18th of December,
-	at 1500 UTC. jmbsvicetto will chair.
-
-	We'll keep switching between Tuesdays and Saturdays for the time
-	being to try and accomodate all members.
-
-	EAPI 4
-	------
-
-	The council agreed that the current EAPI-4_pre1 implementation is
-	pretty good. Ulm will work on a PMS patch for EAPI-4.  He will
-	create a final tag, that will also include one extra feature, a var
-	called MERGING_FROM, available in pkg_* phases, with the following
-	possible values: ["source","binary"].
-
-	The tag will then be approved by the council, either by email or in a
-	meeting, whatever is faster. Our goal is to have EAPI-4 before 2010
-	ends.
-
-	la files removal status/progress
-	--------------------------------
-
-	Nothing has happened since the last meeting. Jorge did start some ML
-	threads, but there was no interest in the subject.
-
-	This needs to be done:
-	1. write a doc (w/ Diego's blog as source)
-	2. publish news item
-	3. get portage 2.1.9 stable
-	4. let devs remove la files.
-
-	Since no-one volunteered to do 1, we'll push it to the ML.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20101130.txt b/xml/htdocs/proj/en/council/meeting-logs/20101130.txt
deleted file mode 100644
index dd7a90b2d9..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20101130.txt
+++ /dev/null
@@ -1,350 +0,0 @@
-[22:00:48] <wired> alrighty, it's meeting time
-[22:00:58] <Chainsaw> Roll call!
-[22:01:08] <wired> ^^
-[22:01:17] <Chainsaw> Chainsaw is here.
-[22:01:33] <wired> Betelgeuse, Chainsaw, ferringb, jmbsvicetto, scarabeus <--- ping
-[22:01:40] <Chainsaw> pong!
-[22:01:53] <ferringb> gnip
-[22:02:03] <jmbsvicetto> pong
-[22:03:25] <Chainsaw> Do we have phone numbers for Betelgeuse & scarabeus?
-[22:03:25] <wired> I guess Mark didn't assign a proxy for today?
-[22:03:47] <jmbsvicetto> I have both
-[22:03:59] * wired calling thomas
-[22:04:26] *** Quits: Tommy[D] (~TommyD]@gentoo/developer/tommy) (Remote host closed the connection)
-[22:04:29] <jmbsvicetto> Betelgeuse joined 5 minutes ago, so he should be around
-[22:04:44] <scarabeus> blaghr
-[22:04:44] <wired> i actually invited him, so it could be an auto-accept
-[22:04:47] <scarabeus> thnaks
-[22:04:50] <scarabeus> for cal
-[22:04:52] <wired> heheh
-[22:04:53] <wired> yw
-[22:05:10] *** Joins: Tommy[D] (~TommyD]@gentoo/developer/tommy)
-[22:05:21] <jmbsvicetto> wired: hmm, ok
-[22:05:25] <jmbsvicetto> I'll call him then
-[22:05:32] <wired> okie
-[22:06:48] <Betelgeuse> hmm
-[22:06:52] <jmbsvicetto> ^^
-[22:07:07] <Betelgeuse> Didn't have an alarm reminder
-[22:07:08] <wired> great
-[22:07:11] <Betelgeuse> sorry for being late
-[22:07:25] <wired> no worries
-[22:07:38] <Chainsaw> Is that everyone? :)
-[22:07:44] <wired> yeap
-[22:07:47] <wired> agenda: http://archives.gentoo.org/gentoo-dev-announce/msg_7890bad79264c057cbf503fbd0f6e5d8.xml
-[22:07:55] *** wired changes topic to 'Next meeting: Now | http://archives.gentoo.org/gentoo-dev-announce/msg_7890bad79264c057cbf503fbd0f6e5d8.xml'
-[22:08:06] <wired> I'd like us to start with the last item
-[22:08:27] <Chainsaw> Okay; can't do Friday/Saturday/Sunday. All other days fine.
-[22:08:34] <Chainsaw> (Any time of day)
-[22:08:36] <wired> ok
-[22:08:38] *** Quits: alexxy (~alexxy@gentoo/developer/alexxy) (Remote host closed the connection)
-[22:08:55] <wired> so is everyone ok with my proposed Tuesday/Saturday plan?
-[22:09:24] <wired> One tuesday for Tony, one saturday for Mark?
-[22:09:34] <Chainsaw> wired: Saturday I can possibly do if I know far in advance; past 1pm UTC.
-[22:09:45] <Chainsaw> wired: Friday or Sunday are definitely out.
-[22:10:21] <Chainsaw> It's not convenient, but I don't want to ruin it for others.
-[22:10:24] * ferringb notes we really need to find something that is friendlier to usian times if at all possible
-[22:10:31] <jmbsvicetto> I'm fine with it
-[22:10:37] <wired> oh Saturday 1300 UTC would be perfect
-[22:10:39] <Betelgeuse> ferringb: I don't consider this time overlay friendly either
-[22:10:42] <ferringb> fortunately, I aparently have no sane schedule so I'm reasonably flexible, but halcyon, not so much
-[22:10:43] <Chainsaw> ferringb: This is fairly friendly to US time already.
-[22:10:54] <Chainsaw> ferringb: Note that it is 8pm at night, in a dark office with only the light above my desk on.
-[22:11:15] <jmbsvicetto> wired: Saturday 1300 UTC is 0600 PDT, iirc
-[22:11:18] <ferringb> well, 1300 UTC is 5am my time
-[22:11:46] <jmbsvicetto> right
-[22:11:46] <ferringb> and halcy0n would be 3-5am for that
-[22:12:01] <wired> jmbsvicetto: yes but Mark said its good for him
-[22:12:26] <jmbsvicetto> we currently have people spreading a 10 hour time span, iirc
-[22:12:38] <wired> Weekend: 0700-1300 UTC-5, 1900-0000 UTC-5
-[22:12:41] <wired> ^^ thats what mark said
-[22:13:11] <ferringb> UTC -5, not UTC
-[22:13:39] <ferringb> atlantic/east coast times, basically
-[22:13:45] <jmbsvicetto> Betelgeuse: you're currently UTC+2, no?
-[22:13:46] <wired> yes, 0800 UTC-5 is 1300 UTC, right?
-[22:14:03] <Betelgeuse> jmbsvicetto: yes
-[22:14:22] <Chainsaw> I can do 1pm and later, as required.
-[22:14:52] <wired> ferringb: is that time acceptable for you at all?
-[22:15:46] <jmbsvicetto> ferringb: up until what time would you be available on Friday and from what time on Saturday?
-[22:17:00] <ferringb> sorry, interuptions
-[22:17:39] <ferringb> either it needs a +5 to it, or -2
-[22:18:02] * ferringb can swing it if needed for a couple of meetings, but 5am is not exactly a time I'm good at being conscious
-[22:18:55] <ferringb> just run with it for the time being
-[22:19:01] <wired> okay
-[22:19:05] <jmbsvicetto> ferringb: so up until what time would you be willing to stay up on Friday and from what time are willing to be awake on Saturday?
-[22:19:49] <ferringb> my times; 10->00 UTC-08 generally speaking
-[22:20:11] <ferringb> I can veer out of that within limits (I already have meetings on european time as is)
-[22:21:16] <wired> you think you could handle a 07 UTC-08?
-[22:21:42] <ferringb> sundays would be better for it, but yes.
-[22:21:49] <wired> or a 08
-[22:21:59] <ferringb> basically; if I'm the one with the weird time, I'll swing what I have to.
-[22:22:28] <wired> ok so guys, 1500 UTC Saturday, is that good for (just) our next meeting?
-[22:22:31] *** Joins: alexxy[home] (~alexxy@gentoo/developer/alexxy)
-[22:22:38] <Chainsaw> wired: I'll make that work, yes.
-[22:23:09] <ferringb> fine by me, but I strongly suggest you double check that with mark to make sure y'all are converting correctly (and that he intentionally aimed for 3-4am EST time)
-[22:23:33] * ferringb hates timezones on a related note
-[22:23:51] <wired> he could have made a mistake, we'll talk briefly on the alias
-[22:24:18] <wired> ok, thank you. I'll take everyone else's silence as a yes
-[22:24:56] <scarabeus> yep
-[22:25:08] <wired> lets move on to EAPI 4
-[22:26:15] <wired> in last meeting it was proposed (by few_) to finalize EAPI-4 now, in the state that's currently implemented in portage
-[22:26:23] <wired> zmedico: ping
-[22:26:39] <zmedico> wired: pong
-[22:26:43] *** Joins: Philantrop (~Philantro@exherbo/developer/philantrop)
-[22:26:45] <wired> there's a draft of EAPI-4 here: http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-4_pre1
-[22:27:24] <wired> zmedico: everything in eapi-4_pre1 is implemented, right?
-[22:27:26] <Chainsaw> I will repeat my objection;  REPLACING_VERSIONS & REPLACED_BY need clear examples.
-[22:27:36] <jmbsvicetto> ferringb: Any comments / concerns from your part about the above?
-[22:27:39] <zmedico> wired: right
-[22:27:43] <Chainsaw> Based on that document, it is not clear what the package manager expects of me in my ebuild.
-[22:28:44] <wired> Chainsaw: I understand those variables as helpers for you, not something you have to use
-[22:28:48] <Chainsaw> (And that worries me, because "shall" suggests I can't omit it)
-[22:29:00] <Betelgeuse> Chainsaw: The final approval is a PMS commit any way
-[22:29:08] * Chainsaw reads "shall" as defined in an RFC
-[22:29:13] <Betelgeuse> Chainsaw: So for drafting that text we can make it clearer
-[22:29:15] <Chainsaw> Which is "you MUST do this".
-[22:29:28] <ferringb> jmbsvicetto: controllable compression and symlinks for docs mostly
-[22:29:43] <Chainsaw> i.e. You MUST use these two variables that I have not described very well here.
-[22:29:45] <ferringb> jmbsvicetto: few others, but honestly, test ebuilds/pkgs are needed to really smoke out how well it works
-[22:29:56] <Chainsaw> Everything else looks very good though.
-[22:30:13] <wired> Chainsaw: I think shall here means "will be defined and available in these stages"
-[22:30:27] *** Quits: pchrist (~spirit@gentoo/developer/pchrist) (Quit: leaving)
-[22:30:32] <Chainsaw> wired: Please clarify that in some way or use a different word.
-[22:31:07] *** Joins: pchrist (~spirit@gentoo/developer/pchrist)
-[22:31:33] <wired> ok
-[22:31:36] <Chainsaw> wired: "shall be defined". "Helmets shall be worn" "Children shall be accompanied by an adult at all times". Nothing about is optional.
-[22:31:43] <wired> so we all have minor issues with the documentation
-[22:31:56] *** Quits: pchrist (~spirit@gentoo/developer/pchrist) (Client Quit)
-[22:32:01] <wired> do we all agree that the implemented featureset is good enough for a new eapi?
-[22:32:07] <ferringb> zmedico: what ebuilds out there exist using eapi4 for testing btw?
-[22:32:23] <ferringb> wired: yeah, hold up
-[22:32:27] * ferringb would like that question answered
-[22:32:35] <zmedico> ferringb: none that I know of
-[22:32:57] <ferringb> wired: I have no real issues with what's there doc wise
-[22:33:12] <Chainsaw> ferringb: You can't write ebuilds until you finalise the documentation.
-[22:33:15] <Chainsaw> ferringb: That seems a bit unfair.
-[22:33:20] <ferringb> Chainsaw: can too :P
-[22:33:26] * ferringb isn't asking for gentoo-x86 converted over
-[22:33:32] *** Joins: pchrist (~spirit@gentoo/developer/pchrist)
-[22:33:37] <jmbsvicetto> I may have misunderstood the purpose of the example for pkg_pretend. If I didn't, I'm worried as in my reading it seems we may be creating some issues for binary packages
-[22:33:38] <ferringb> sanity checking mainly
-[22:34:19] <Betelgeuse> wired: yes it's enough
-[22:34:31] <jmbsvicetto> we could ask for volunteers to test the spec in an overlay
-[22:34:35] <ferringb> either way, that's my only real concern
-[22:35:20] <Chainsaw> I'm happy with the feature set, and will vote "yes, with REPLACING_VERSION/REPLACED_BY_VERSION *not* mandatory".
-[22:35:22] * ferringb defers to the others however for their collective opinion
-[22:36:01] <jmbsvicetto> wired: This seems enough to create EAPI-4
-[22:36:17] <ferringb> Chainsaw: reason for not wanting it mandatory?
-[22:36:22] <wired> jmbsvicetto: yes, thats what I think as well
-[22:36:37] <jmbsvicetto> ferringb: can it be mandatory and empty?
-[22:36:49] <Chainsaw> ferringb: Because it is for all intents & purposes undocumented and the need is not apparent to me.
-[22:37:08] <jmbsvicetto> I need to re-read their purpose
-[22:37:23] <ferringb> Chainsaw: it's a corner case thing where it's useful
-[22:37:35] <wired> my understanding is those variables are useful if you need to perform specific actions when replacing specific versions
-[22:37:49] <ferringb> Chainsaw: documentation arguement I won't disagree with, it needs specifics, but it's purpose I strongly agree with
-[22:37:58] *** Quits: Tommy[D] (~TommyD]@gentoo/developer/tommy) (Remote host closed the connection)
-[22:38:06] <jmbsvicetto> can anyone address my concern about the use of pkg_pretend on binary packages? Mainly about the docs suggesting you could some "kernel checks"
-[22:38:15] <Chainsaw> ferringb: Without clear documentation it is not clear what I am voting in.
-[22:38:28] <ferringb> jmbsvicetto: pkg_pretend has known issues
-[22:38:37] *** Joins: Tommy[D] (~TommyD]@gentoo/developer/tommy)
-[22:38:37] <Betelgeuse> wired: it's useful to detect upgrade vs. reinstall etc too
-[22:38:40] <Chainsaw> ferringb: "Chainsaw, you said yes to this 3 months ago."
-[22:38:55] <ferringb> Chainsaw: well, you did.  I have logs :P
-[22:38:58] <Chainsaw> ferringb: If you want me to say yes, show me examples. How do I use it, why can't I omit it.
-[22:38:59] <Betelgeuse> wired: no need to show those "if you are upgrading" messages all the time
-[22:38:59] * ferringb groks
-[22:39:06] <wired> Betelgeuse: yeah, indeed
-[22:39:08] <ulm> Chainsaw: maybe this is good enough for REPLACING_VERSION/REPLACED_BY_VERSION: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=blob;f=ebuild-env-vars.tex;h=f96b2038a5ac7f3d5aaf767159e53fae924797e4;hb=HEAD
-[22:39:30] <Chainsaw> ulm: Do you have that in english please?
-[22:39:59] <ulm> Chainsaw: what?
-[22:40:20] <Chainsaw> \toenail &&
-[22:40:25] <zmedico> jmbsvicetto: just substitute "kernel checks" with "random checks that can be done earlier than pkg_setup, before deps are installed"
-[22:40:26] <Chainsaw> / (1) 23)
-[22:40:29] <Chainsaw> Hard to read.
-[22:40:49] <scarabeus> Chainsaw: REPLACED_VERSIONS= packages that i uninstall in order to have this package installed so lets say 7.0:0 8.1:1
-[22:40:49] <scarabeus> REPLACED_BY_VERSION= packages that removes me
-[22:41:01] <jmbsvicetto> zmedico: ok. It's just that to me that seems to be suggesting some actions that will break for binary packages
-[22:41:03] <scarabeus> s/packages that/package thatr/
-[22:41:14] <jmbsvicetto> zmedico: or better put, for people using a central build box
-[22:41:37] <ulm> Chainsaw: voila: http://dev.gentoo.org/~ulm/pms.pdf
-[22:41:48] <zmedico> jmbsvicetto: basically, it has similar caveats as pkg_setup checks
-[22:41:55] <Chainsaw> ulm: That I can read, thank you.
-[22:42:17] <ulm> Chainsaw: page 51
-[22:42:19] <ferringb> ulm: is there a specific statement of what the value will be?
-[22:42:23] <zmedico> jmbsvicetto: it allows to give earlier feedback to the user, that's all
-[22:42:24] <ferringb> specifically an atom, or
-[22:42:33] <ferringb> ah, versions.
-[22:43:16] <ferringb> ulm: zmedico: not quiet sure I see the purpose in "versions", instead of 'version' (plural vs singular) there
-[22:44:03] <Chainsaw> ulm: Text still reads as awkward to me, but yes, I can vote that in.
-[22:45:06] <ulm> Chainsaw: they are also described in the table on page 49
-[22:45:13] <ulm> maybe it's clearer there
-[22:45:25] <jmbsvicetto> ulm: thanks for the link
-[22:45:32] <zmedico> ferringb: yeah, portage never puts more than one version there as it is
-[22:45:32] <jmbsvicetto> so the variable can be defined as empty
-[22:45:46] <jmbsvicetto> Chainsaw: so if you don't have a need to use it, just define it as empty
-[22:46:07] <zmedico> ferringb: it's always 1 package per slot
-[22:46:15] * ferringb nods, hence my point ;)
-[22:46:40] <Chainsaw> Has been clarified privately by leio, I'm happy to vote in EAPI 4 as is.
-[22:46:53] <ferringb> ulm: was the use specification w/in PMS updated to ensure no trailing -/+ for use dep defaults btw?
-[22:46:58] <wired> excellent
-[22:47:25] <ferringb> if not, should be.  it's a minor naggle, but cross the t's, dot the i's, etc
-[22:47:42] <ulm> ferringb: I have to check
-[22:48:10] <ferringb> minus that naggle (which I presume no one has an issue if the spec is tweaked to cover it after the fact), I'm +1
-[22:48:22] <wired> jmbsvicetto: are your pkg_pretend concerns settled?
-[22:48:54] <Chainsaw> ferringb: Some sentences need rewriting, that is acceptable.
-[22:49:31] * ferringb still would like a var jammed into eapi to indicate if installing from source build or binary
-[22:49:37] <ferringb> having such a thing would address jmbsvicetto's concern.
-[22:49:50] <jmbsvicetto> wired: I see they're the same as the exiting ones for pkg_setup
-[22:50:07] *** Quits: ABCD (~abcd@gentoo/developer/abcd) (Ping timeout: 252 seconds)
-[22:50:08] <ferringb> jmbsvicetto: reduced via REQUIRED_USE also
-[22:50:29] <jmbsvicetto> wired: so instead of getting it fixed on the spec, we'll have to club ^W teach people about it ;)
-[22:50:34] <wired> jmbsvicetto: well in the end it's up to the devs to use it properly
-[22:50:37] <wired> yeah
-[22:50:59] <ulm> ferringb: USE flag syntax must be updated in PMS still, but that's a minor issue really
-[22:51:04] <wired> zmedico: would the var ferringb asked be hard to implement?
-[22:51:07] *** Joins: ABCD (~abcd@gentoo/developer/abcd)
-[22:51:16] <ferringb> wired: it's basically there already, it's just not standardized
-[22:51:23] <ferringb> it's 5 minutes in any manager
-[22:51:51] <zmedico> wired: implemented already: http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-4_pre1-metadata-required-use
-[22:52:18] <ferringb> zmedico: he's asking about a "we're installing from a binary" var
-[22:52:34] <zmedico> oh, that's easy
-[22:52:47] <zmedico> there's already EMERGE_FROM=binary
-[22:53:00] <ferringb> name sucks
-[22:53:00] <zmedico> can add another var like that
-[22:53:10] <wired> yeah, sounds easy too, so if it could be included in EAPI-4 it'd be nice
-[22:53:22] <ferringb> ulm: comments?
-[22:53:55] *** Quits: alexxy[home] (~alexxy@gentoo/developer/alexxy) (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
-[22:53:56] <Chainsaw> Flushing a boiler out for ~2 minutes. My vote on EAPI 4 is yes. Back soon.
-[22:54:07] <ferringb> -.^
-[22:54:12] <ulm> ferringb: EMERGE_FROM sucks indeed as a name
-[22:54:14] <jmbsvicetto> ferringb: I don't use it myself, but infra and people with large deployments might not be happy to have an ebuild fail to merge because someone wants to die on a certain kernel version or config when the package is built on a build server
-[22:54:26] <ferringb> jmbsvicetto: aware, but they already run into it
-[22:54:31] <jmbsvicetto> sure
-[22:54:36] <ferringb> jmbsvicetto: and a certain luddite dev has an override for that last I knew
-[22:55:23] <ferringb> ulm: MERGING_FROM perhaps?
-[22:55:45] <ferringb> specifically with two potential values; source, binary
-[22:56:06] * wired likes that better
-[22:56:10] <Betelgeuse> how about we flesh that out for EAPI 5
-[22:56:20] <Betelgeuse> and just make it happen in a reasonable timetable
-[22:56:26] <scarabeus> so MERGE_TYPE=[ 'binary', 'source' ]
-[22:56:32] <scarabeus> ah alread brian offered something :)
-[22:57:01] <wired> Betelgeuse: this is so minor we could just let them implement it after we pass EAPI-4 imo
-[22:57:20] <ferringb> Betelgeuse: just mentioning it now since we've been talking about this sort of var for a long while, and it *does* address the pkg_pretend/pkg_setup concerns
-[22:57:27] <Chainsaw> Back.
-[22:57:30] <ferringb> plus frankly, ebuild devs already are doing shit like this if you go looking ;)
-[22:57:46] *** Joins: alexxy[home] (~alexxy@gentoo/developer/alexxy)
-[22:58:50] <ferringb> how about this
-[22:59:16] <ferringb> if we all agree on eapi4, and we agree said var is needed... wording gets sorted in the next few days via email, and the puppy is stamped at that point.
-[22:59:25] <ferringb> if we all agree on 4, but not the var, well, you all suck
-[22:59:33] <ferringb> but we move on and discuss it in eapi5 timelines
-[22:59:40] <ferringb> that work for folks?
-[22:59:50] <wired> MERGING_FROM is good enough for me to accept it now
-[22:59:58] <jmbsvicetto> works for me
-[23:00:14] <ferringb> same for me, but I'd like to keep the option of tweaking it if absolutely needed for paludis needs
-[23:00:18] <jmbsvicetto> besides, the official stamp is put on a PMS tag / patch
-[23:00:24] * ferringb notes they're not represented here, primarily
-[23:00:34] <scarabeus> also with eapi4 stabilisation i have this idea of qa policy update, how about we would require use of latest eapi possible instead of least possible as is now since that would require new devs to be really in common only in few eapis also we are now having quite few ones so even i have to use cheatsheet to see what i can do :D
-[23:00:53] <jmbsvicetto> I hope that var can help fix current issues with binary packages
-[23:00:58] <ferringb> scarabeus: seperate discussion... and a very very heated one I'd expect
-[23:01:03] <wired> indeed
-[23:01:07] <ferringb> scarabeus: ml is the starting point for that imo
-[23:01:10] <wired> scarabeus: this should start on the ML
-[23:01:13] <scarabeus> ok
-[23:01:24] <wired> ok 
-[23:01:32] <jmbsvicetto> scarabeus: we should probably start a discussion about "deprecating" EAPIs too ;)
-[23:01:51] <wired> lets do an official vote about EAPI-4 approval then
-[23:02:04] <Betelgeuse> scarabeus: that's already accepted practise
-[23:02:11] <Betelgeuse> wired: there's nothing to vote on
-[23:02:11] <Chainsaw> wired: EAPI-4 with additional vars discussed: YES
-[23:02:19] <jmbsvicetto> scarabeus: oldest / newest debate is interesting, but as Patrick as been talking for a long time, we should think about limiting the number of EAPIs active at each point in time
-[23:02:32] <wired> Betelgeuse: i know, just for the record
-[23:02:43] <scarabeus> Betelgeuse: nope, accepted and qa enforced practise is to use oldest eapi around
-[23:02:47] <jmbsvicetto> wired: let's rephrase it
-[23:02:57] <Betelgeuse> scarabeus: weird, never seen that
-[23:03:03] <scarabeus> Betelgeuse: (with features your ebuild needs)
-[23:03:18] <jmbsvicetto> let's vote on asking PMS team to provide a patch to implement EAPI-4 with the linked spec and the discussed vars?
-[23:03:51] <ferringb> jmbsvicetto: that's a +1 from me.  I want that var, but if folks don't, I'm still +1 on eapi-4.
-[23:03:57] <jmbsvicetto> Betelgeuse: when PMS was approved, everyone was told to use the oldest EAPI that was good enough for the ebuild
-[23:03:59] <scarabeus> +1 from  me
-[23:04:04] <Chainsaw> Flushing boiler out second time; have 2 minutes to decide what we're voting on please.
-[23:04:15] <scarabeus> :D
-[23:04:20] <wired> jmbsvicetto: i don't think eapi4 needs to go through council again, we already have the specs
-[23:04:35] <Betelgeuse> jmbsvicetto: PMS as a whole has never been approved
-[23:05:03] * ferringb cracks the whip... voting?
-[23:05:08] <ferringb> still have .la
-[23:05:17] <wired> jmbsvicetto: I'd just approve eapi4 and give the respective portage/docs team the go to implement them
-[23:05:17] <Betelgeuse> I vote that I can vote when the commit to tag is ready.
-[23:05:27] <jmbsvicetto> Betelgeuse: yeah, sorry. I meant when EAPI-1 was approved
-[23:05:49] <jmbsvicetto> wired: as Betelgeuse as said, we can only vote on the tag
-[23:06:05] <ferringb> anyone have issues doing that via email?
-[23:06:19] <jmbsvicetto> That's why I'm suggesting we agree to vote on asking PMS team / any volunteers on writing the patch to get the EAPI-4 tag
-[23:06:32] <wired> ferringb: whatever makes it happen faster
-[23:06:46] <ferringb> that's basically my views
-[23:06:51] <Betelgeuse> email is fine
-[23:06:56] <wired> ok lets sum up.
-[23:06:58] * Chainsaw returns
-[23:07:03] <Chainsaw> So gents, what are we voting on?
-[23:07:14] <ferringb> Chainsaw: getting me my damn pony.
-[23:07:53] <wired> we agree we want a tag ready for eapi-4, including the extra var, so we can vote on it, by email or on a meeting (depending on the timing)
-[23:08:25] <jmbsvicetto> Do we want to task anyone (a council member) on getting this done?
-[23:08:44] <jmbsvicetto> bah, I missed a ? on (a council member?)
-[23:09:12] <ferringb> jmbsvicetto: unless ulm disagrees, I'd punt the req to him
-[23:09:25] *** Joins: hwoarang (~hwoarang@gentoo/developer/hwoarang)
-[23:09:25] <ferringb> non-council I realize, but logical choice
-[23:09:28] <ferringb> ulm: you mind?
-[23:09:46] <jmbsvicetto> ferringb: seems a good idea to me
-[23:11:40] <wired> ulm seems afk...
-[23:11:50] <wired> lets give him some time while we talk about la files
-[23:12:00] <ulm> yeah, fine with me
-[23:12:05] <Chainsaw> ulm agrees!
-[23:12:05] <wired> ah great :)
-[23:12:07] <wired> :D
-[23:12:12] <ferringb> ulm: sweet.  now you have to write that patch ;)
-[23:12:13] <Chainsaw> Well I'm glad that's sorted :)
-[23:12:20] <wired> excellent news
-[23:12:30] <wired> seems we're gonna have eapi-4 in 2010 after all :)
-[23:12:45] <jmbsvicetto> ulm: Thanks
-[23:12:50] <wired> ulm: thanks indeed
-[23:12:52] <ferringb> ulm: yeah, danke.
-[23:12:57] <ulm> np
-[23:13:00] * Chainsaw bows politely to ulm
-[23:13:08] <Chainsaw> wired: So, what else do you have on the agenda for today?
-[23:13:10] * ferringb needs to duck out for 5-10 minutes.  continue about your ways .la wise, will be back shortly
-[23:13:12] <wired> la files
-[23:13:20] <wired> last item
-[23:13:22] <wired> jmbsvicetto: your floor
-[23:13:33] <jmbsvicetto> wired: I'm sorry but I dropped the ball on this one :\
-[23:13:44] <jmbsvicetto> So, what's the status:
-[23:13:55] <Chainsaw> (Back in 2 minutes, will read scrollback)
-[23:14:28] <jmbsvicetto> 1. we need to write a doc, we can use Diego's blog post as sources - he agreed to license them under CC-SA and add it to the QA space - assuming there's no objection from the QA team
-[23:14:50] <jmbsvicetto> 2. then we need to publish the news item referencing the doc
-[23:14:59] <jmbsvicetto> 3. get the new portage version stable
-[23:15:23] <jmbsvicetto> zmedico: how soon can we get it?
-[23:15:51] <jmbsvicetto> 4. we can let ebuild devs remove la files as required
-[23:16:13] <wired> most recent 2.1.9 was committed 3 days ago
-[23:16:14] <jmbsvicetto> Is there anyone interested in helping out with 1?
-[23:16:56] <jmbsvicetto> wired: we don't need the most recent. iirc, the first usable version should be almost 4 weeks now
-[23:17:37] <wired> the first one still in tree is *portage-2.1.9.24 (31 Oct 2010)
-[23:17:38] <jmbsvicetto> but as I've said before, I don't think we need to wait the 30 days for this
-[23:17:51] <jmbsvicetto> so 1 month
-[23:18:12] <wired> but .25 seems to have some important fixes
-[23:18:35] <jmbsvicetto> unless anyone wants to volunteer for 1, I think we can and should take this for the mls
-[23:18:53] <ago> jmbsvicetto: I have not read the backlog, the documentation on what is it?
-[23:19:00] <jmbsvicetto> ssuominen: I'm sorry for not getting it sorted out by now
-[23:19:24] <ago> i'm just passing through :P
-[23:19:48] <wired> ago: la file removal
-[23:20:38] <wired> jmbsvicetto: well, lets push it to the ML then and hope we get more replies than last time
-[23:21:43] <wired> I have many things on my shoulders now, but I'll do my best to find some time to help as well
-[23:22:21] <Betelgeuse> I need to finish for today.
-[23:22:26] <Betelgeuse> Early start tomorrow.
-[23:22:35] <jmbsvicetto> wired: so are we done for today?
-[23:22:37] <wired> i think we're done
-[23:22:48] <jmbsvicetto> wired: Thanks for chairing today's meeting
-[23:22:54] <wired> thank you all for being here
-[23:23:15] *** Quits: alexxy[home] (~alexxy@gentoo/developer/alexxy) (Read error: Connection reset by peer)
-[23:23:22] <jmbsvicetto> wired: I can chair next meeting
-[23:23:29] <jmbsvicetto> wired: can you recall me the date?
-[23:23:42] <wired> yeah, hold on
-[23:24:18] <wired> Saturday, 18th of December, 1500 UTC
-[23:25:15] <Chainsaw> Thanks wired :)
-[23:26:10] <jmbsvicetto> wired: you may want to call the end of the meeting - for log's sake ;)
-[23:26:36] <wired> ---- meeting end ----
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20101218-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20101218-summary.txt
deleted file mode 100644
index e8dde43a03..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20101218-summary.txt
+++ /dev/null
@@ -1,143 +0,0 @@
-2010-12-18 Council meeting summary
-==================================
-
-members present:
-	betelgeuse, chainsaw, ferringb, jmbsvicetto, wired
-member missing:
-	halcy0n
-possible proxy announced but unable to attend:
-	scarabeus
-        
-Agenda:
-	roll call
-	slacking arches
-	la files removal status / progress
-	Arfrever's suggestions of new features for EAPI=4
-	open bugs with council involvement
-	next meeting date / chair
-	open floor - listen to the community
-
-Topics discussed:
-
-	slacking arches
-	---------------
-
-	This subject was proposed by scarabeus. As he wasn't around, the remaining council
-	members shifted the focus to making sure there is enough relevant hardware available
-	to developers to allow arch team work and questioned whether emulation could help
-	on this, at least for non core parts on a trial basis.
-
-	Roy (NeddySeagoon) asked what hardware is needed and whether there should be a
-	funding application to the Foundation. Tony mentioned some hardware that could
-	be used by the ppc64 team and Jorge noted that mainstream arches such as amd64
-	and x86 may also want to make a request.
-
-	Finally, there was a mention that if council cared about this issue, one member
-	could talk to arch teams to determine the hardware requirements and that we could
-	take this opportunity to consider automated test boxes and rethink the boxes for
-	the weekly builds. This issue was sent back to the ml for further debate.
-	
-
-	la files removal status / progress
-	----------------------------------
-
-	Jorge mentioned that portage-2.1.9* is now marked stable, but that he failed to
-	take care of the documentation and or submitting a news item proposal based on
-	the previous proposal made by Diego (flameeyes). He suggested the other council
-	members that the council could either set a deadline to get a news item submitted
-	for review in the dev ml after which the la files removal "embargo" would be
-	dropped or just drop the "embargo" immediately and deal with the consequences.
-
-	After some discussion there was a vote on "the council will drop the "embargo" on
-	la file removal if no one submits to the dev ml a news item proposal about this
-	issue before 2359 UTC next Wednesday". There were 3 yes votes and 2 no votes on
-	this proposal.
-
-
-	Arfrever's suggestions for EAPI-4
-	---------------------------------
-
-	After some confusion caused by Jorge introducing the pkg_required_use topic
-	during the discussion of this topic, the council members agreed to go over each
-	of the points in Arfrever's email[1]. Brian took the occasion to go over each of
-	the points to finally get the discussion about them on record.
-
-	 [1] - http://archives.gentoo.org/gentoo-dev/msg_bec5db8373fca0271fcadf0cd55724e8.xml
-
-	Problem #1: USE flags cannot contain "." characters.
-		
-		Brian argued that having "." on use flags is simply an aesthetic issue. Furthermore,
-		use flags are used all over the tree and this could cause backward compatibility
-		issues. Thus this would provide a minor gain, but would require much pain.
-
-		Even though the council members agree that it would be possible to find ways to allow
-		for the use of "." in use flags and that the change itself would be welcome, they
-		agreed that this should only be addressed as part of a major restructuring of use
-		flags, like the introduction of use groups. Petteri opened bug 349021 for this.
-		
-		The council voted against the proposed solution for this problem with 5 votes no.
-
-	Problem #2: Files in profiles cannot use features from newer EAPIs.
-
-		Brian argued that Arfrever's proposal for "-${EAPI}" extension files is a nightmare
-		and that it relied on developers to get things right across multiple eapi versions.
-		Jorge and Alex argued that this proposal is another variation of GLEP55 and that
-		they have expressed their dislike for it before.
-
-		The council voted against both proposed solutions for this problem with 5 votes no
-		for the 1st solution and 4 votes no and 1 defer to ml for the 2nd solution.
-
-		During this discussion there was a "detour" into the issue of migrating the EAPI of
-		the base profiles, moving trouble files like package.mask to real profiles and how
-		to ensure a clean upgrade path for old installs. Alex talked about an automated
-		incremental process with switches of rsync sources over time and Brian mentioned the
-		use of repository format markers. This discussion was pushed back to the ml.
-
-	Problem #3: repoman doesn't allow stable packages to have optional dependencies on unstable
-	packages (usually until these packages are stabilized).
-
-		Brian argued that both proposed solutions for this problem would cause a maintenance
-		"hell" and would have a noticeable repoman run-time impact. Petteri noted he saw a
-		problem needing a solution in here and Jorge argued that the solutions presented need
-		a debate but that they are not tied to the presented problem.
-
-		During the discussion Petteri asked about a 3rd option, unstable use flags, and Jorge
-		argued that the separate profiles for stable / unstable tree could make sense if we got
-		back to the idea of moving KEYWORDS out of ebuilds.
-		
-		In the end the council voted with 5 no votes for both solutions presented in point 3
-		to be part of the EAPI-4 specification.
-
-
-	pkg_required_use
-	----------------
-
-	After a first attempt to discuss this during the previous point, the council addressed this
-	issue after Ulrich (ulm) recalled he requested it to be added to the topic, which Jorge forgot
-	to do.
-	
-	Following some debate about this issue, including requested feedback from both Zac (zmedico)
-	and Brian, the council voted on having EAPI-4 introduce a pkg_required_use function to be
-	called by the PM when it can't fulfill the required_use constraints with 4 no votes and 1
-	yes vote. The council members accepted having an EAPI-4.1 with pkg_required_use if / when
-	there is a need for it in the tree.
-
-	The council also expressed the desire to get a final vote on EAPI-4 before the end of the
-	year. Petteri will propose a schedule to get EAPI-4 voted through email.
-
-
-	open bugs:
-	----------
-	
-	As the meeting lasted over 2 hours, the productivity was becoming low and Petteri had to
-	leave, the review of the open bugs was pushed for next meeting.
-
-
-Next meeting chair:
-	wired
-
-Next meeting's date:
-	20110111 20H00 UTC
-		
-Open floor - listen to the community
-	No issue was brought to the attention of the council at this meeting.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20101218.txt b/xml/htdocs/proj/en/council/meeting-logs/20101218.txt
deleted file mode 100644
index a71a6d927d..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20101218.txt
+++ /dev/null
@@ -1,695 +0,0 @@
-15:03 -!- jmbsvicetto changed the topic of #gentoo-council to: Next meeting: Saturday, 18th of December, 1500 UTC - agenda: http://archives.gentoo.org/gentoo-dev-announce/msg_a40b5e49c106a3a98656b2caf8e660a1.xml
-15:04 <@jmbsvicetto> ok, let's start this meeting
-15:05 <@jmbsvicetto> roll-call:
-15:05 <@jmbsvicetto> here
-15:05 <@Betelgeuse> here
-15:05 <@wired> here
-15:05 <@jmbsvicetto> Chainsaw: ^^
-15:06 <@Betelgeuse> Americans are still sleeping?
-15:06 <@wired> Chainsaw: lol
-15:06 <@jmbsvicetto> Anyone wants to poke them?
-15:07 <@Betelgeuse> let me see if I can find Mark's number
-15:07 <@jmbsvicetto> I'm calling ferringb
-15:07 <@Betelgeuse> I'll send Mark a SMS
-15:08 <@Chainsaw> Yes, present.
-15:08 <@jmbsvicetto> ferringb will be joining in a minute
-15:08 -!- ferringb [~ferringb@gentoo/developer/ferringb] has joined #gentoo-council
-15:08 -!- mode/#gentoo-council [+o ferringb] by ChanServ
-15:08  * ferringb mutters
-15:08 <@Chainsaw> Welcome ferringb :)
-15:09 <@jmbsvicetto> Betelgeuse: Did you caught halcy0n or want me to do it?
-15:09 <@ferringb> thanks whoever called, and pardon- I thought I was getting a call from the romanian team ;)
-15:09 <@jmbsvicetto> ferringb: it was me :P
-15:09 <@Betelgeuse> jmbsvicetto: I sent an SMS
-15:09 <@jmbsvicetto> ok
-15:09 <@ferringb> yeah, lost track of time this morning working on some work bits
-15:09 <@jmbsvicetto> so, we have 5 out of 7
-15:09 <@jmbsvicetto> let's start then
-15:09 <@ferringb> no halcy0n?
-15:10 <@Chainsaw> ferringb: I'm surprised too, this time was chosen specifically for him.
-15:10 <@Betelgeuse> ferringb: I sent him an SMS
-15:10 <@Betelgeuse> ferringb: I can try calling if he doesn't show u
-15:10  * ferringb notes this time is 5am his time
-15:10 <@ferringb> correction, 4am
-15:10 <@jmbsvicetto> slacking arches was the first topic. scarabeus asked for it and he won't be around. Anyone wants to address this point or should it be postponned?
-15:10 <@ferringb> ugh
-15:10 <@ferringb> ignore me.  I'm being very, very special- 10am his time.
-15:11 <@Chainsaw> jmbsvicetto: I would rather concentrate on getting relevant hardware distributed among devs.
-15:11 <@Chainsaw> jmbsvicetto: As in, instead of trying to punish arch teams that are doing the best they can with very little actual hardware.
-15:11 <@Betelgeuse> What's the status of emulation?
-15:11 <@ferringb> yeah, I was wondering the same
-15:11 <@Betelgeuse> I wonder if we could accept non core parts tested with emulation.
-15:11 <@Chainsaw> Betelgeuse: Slow & horrible as always.
-15:11 <@jmbsvicetto> qemu?
-15:12 <@ferringb> bit racey
-15:13 <@ferringb> that said, I actually think the emulation thing should be poked at if folks haven't... very least there are a fair number of tricks that can be done to build either proper cross-compile, or in a mixed emulation mode; end result is faster builds at least
-15:13 <@Chainsaw> ferringb: Actually I make it 8am Mark's time.
-15:13 <@Chainsaw> ferringb: 7am even. Definitely not 10am. It's 3pm here.
-15:13 <@ferringb> Chainsaw: east coast last I knew, so +3 from mine.  doubt he's in mountain time (ain't nothing in that timezone)
-15:13 <@Chainsaw> ferringb: Ah yeah. Wrong coast as always :)
-15:13 <@ferringb> if he's west coast/PDT (my timezone), it's 7am
-15:14  * Chainsaw 's only ever been to California, so "US" == "California" in my limited view
-15:14 <@Betelgeuse> The number I have is from 2008
-15:14 <@Betelgeuse> i can try calling that
-15:14 <@ferringb> more on topic... personally I have no issues w/ emulation where possible for testing at least on a trial basis
-15:15 <@wired> ok reached the rest area and the much needed gas station
-15:16 <@Chainsaw> ferringb: Sure, armin76 is into that.
-15:16 <@wired> most basic things should be safe to test with emulation IMO
-15:16 <@Chainsaw> ferringb: Emulation & SSH accounts on dev machines.
-15:17 < NeddySeagoon> Chainsaw, what hardware is needed - should there be a funding application to to Foundation ?
-15:17 <@jmbsvicetto> If we want to go down that route, then we could suggest existing arch teams with low man power to test it
-15:17 <@ferringb> straight to voicemail for Mark, so he's not going to be reachable (phone's likely off)
-15:17 <@Chainsaw> NeddySeagoon: Reliable dual G5s could help out PPC64. The machines are on eBay, but the prices are high.
-15:18 <@ferringb> define high
-15:18 <@ferringb> don't suppose one could clarify the reliable angle also?  Guessing g5's haven't aged well?
-15:19 < NeddySeagoon> Chainsaw, thats just something for arch teams and council (if needed) to consider.  No need to spend meeting time on it now
-15:19 <@Chainsaw> ~200GBP at least.
-15:19 <@Chainsaw> ferringb: Reliable means not the quad 2.5GHz and not the dual 2.7GHz, these are liquid cooled will fail.
-15:19 <@jmbsvicetto> let me just point out that if we start looking for hardware for arch teams, even mainstream arches like amd64 are likely to make a request
-15:19 <@ferringb> given
-15:19 <@ferringb> that said, arch teams *should* have a wish list handy, and we should have it available publically
-15:20 < NeddySeagoon> jmbsvicetto, anyone can ask
-15:20 <@Chainsaw> You can designate an arch as in need of protection. AMD64/X86 are not.
-15:20 <@jmbsvicetto> NeddySeagoon: sure
-15:20  * ferringb reiterates that point for x86 included; there is *zero* harm in making known folks could make use of hardware
-15:20 <@jmbsvicetto> any council member wants to take the task of talking to arch teams and try to find out what hardware is needed?
-15:20 <@Chainsaw> I've just listed what you'd need to kickstart PPC64.
-15:21 <@Chainsaw> (PowerStation is not reliable, ask Halcy0n for the gory details)
-15:21 < NeddySeagoon> Chainsaw, we also need to know where its needed.  No point in shipping hardware all over the world
-15:21 <@jmbsvicetto> if the council wants to get involved on this, than perhaps we should also take the chance to think about automated testing boxes
-15:22 <@ferringb> jmbsvicetto: thinking tinderbox?
-15:22 <@jmbsvicetto> including it as well
-15:22 <@wired> autobox :)
-15:22 <@Chainsaw> NeddySeagoon: *nod* You can purchase close to the dev though.
-15:22 <@jmbsvicetto> ferringb: the weekly builds are an "automated testing platform" ;)
-15:22 < NeddySeagoon> Chainsaw, yep, that would be ideal
-15:22 <@jmbsvicetto> ferringb: and I have an interest on that
-15:22 <@ferringb> similar, although not much time
-15:23 <@wired> jmbsvicetto: barely, considering how often it fails :P
-15:23  * ferringb has been dealing w/ crap like that for work for the last year or so though
-15:23 <@ferringb> won't own the issue, but I'm willing to help
-15:23 <@jmbsvicetto> wired: sorry, that only means it's catching problems in the tree :P
-15:23 <@wired> I'd be interested in an autobox system as well
-15:23 <@wired> jmbsvicetto: heh
-15:23 <@jmbsvicetto> so, let's take this to the ml
-15:24 <@jmbsvicetto> la files removal / progress
-15:24 <@jmbsvicetto> portage-2.1.9* is marked stable now, but we (me) didn't wrote any doc about the la files, nor was I able to send the news item for review
-15:25 <@jmbsvicetto> This one is my fault
-15:25 <@jmbsvicetto> at this point I see 2 options:
-15:25 <@jmbsvicetto> 1. give a deadline to send a news item for review and get the news out before letting people remove the la files (dbus is still waiting for this)
-15:26 <@jmbsvicetto> 2. just drop the "embargo" and deal with it
-15:26 <@jmbsvicetto> I'd prefer for 1 and would be grateful if anyone else would be willing to help
-15:26 <@jmbsvicetto> -for
-15:26 <@Betelgeuse> jmbsvicetto: Wasn't there a suggestion for news item wording already?
-15:26 <@jmbsvicetto> yes
-15:26 <@Betelgeuse> It shouldn't be that much trouble then to get one out.
-15:26 <@jmbsvicetto> It shouldn't, I just didn't had the time
-15:27 <@Betelgeuse> jmbsvicetto: Can you send an email at the end of this meeting saying it will be committed in 3 days if nothing comes up?
-15:27 <@jmbsvicetto> sure
-15:27 <@jmbsvicetto> The old news item? It needs some rewording
-15:27 <@jmbsvicetto> iirc
-15:28 <@jmbsvicetto> I was going to suggest we give until Monday 2359 UTC for someone to put a proposal for a news item or the "embargo" would be dropped
-15:29 <@jmbsvicetto> Betelgeuse: ^^ would that work for you?
-15:29 <@wired> well if we have a draft ready, let's fix and publish it
-15:29 <@jmbsvicetto> can we have a vote on this issue?
-15:29 <@jmbsvicetto> wired: yes, but *who*? I failed on this
-15:30 <@Betelgeuse> jmbsvicetto: You're not able to redeem yourself? :)
-15:30 <@Betelgeuse> If someone else has more time on their hands that's of course better too.
-15:30 <@jmbsvicetto> I'll be very busy the next few days
-15:31 <@Betelgeuse> Ok. Any takers? I have exams Monday
-15:31 <@jmbsvicetto> ok, let's please vote in the following:
-15:31 <@wired> same here, but i could try and take a look at the news item midweek
-15:32 <@jmbsvicetto> The council will drop the "embargo" on la file removal if no one submits to the dev ml a news item proposal about this issue before 2359 UTC next Monday.
-15:32 <@jmbsvicetto> How do you vote?
-15:32 <@jmbsvicetto> I agree
-15:32 <@wired> Monday is too soon, make it Wednesday
-15:33 <@Betelgeuse> Wednesday is ok. It's not a matter of days at this point.
-15:33 <@wired> although I don't like the idea of skipping it altogether just because noones does it
-15:34 <@jmbsvicetto> ok, Wednesday then and a disagree vote means the "embargo" will remain until the news item is published
-15:34 <@jmbsvicetto> How do you vote?
-15:34 <@ferringb> randomly
-15:35 <@Chainsaw> News item is a necessity. Disagree. Don't try and push it through before the documentation is ready.
-15:35 <@Betelgeuse> agree (I would make sure something gets posted though)
-15:35  * ferringb seconds betelgeuese/chainsaw
-15:36 <@wired> yeah I'm with Chainsaw, we shouldnt encourage skipping steps :)
-15:36 <@ferringb> could attempt to draft diego for proper docs also
-15:36 <@jmbsvicetto> ferringb: you need to vote to break the tie
-15:36 <@Betelgeuse> voting empty is allowed
-15:36 <@ferringb> yeah, 'cept that was a joke
-15:37 <@jmbsvicetto> sure, but at this point we don't have a decision
-15:37 <@Betelgeuse> ferringb: well you also seconded both options :)
-15:37 <@ferringb> Betelgeuse: shhh.
-15:37 <@jmbsvicetto> So let's push this back to next meeting again?
-15:37 <@ferringb> here's the thing
-15:37 <@ferringb> yes, docs are needed.  people don't write docs.  thus this delays further and further.
-15:37 <@ferringb> well, not so much needed, as very desirable
-15:38 <@ferringb> I'd rather not see this keep getting kicked further and further back
-15:38 <@ferringb> agree.  not sure wednesday is the best date, but we need to move it forward
-15:38 <@jmbsvicetto> so, 3 agree and 2 disagree
-15:38 <@jmbsvicetto> Anyone is welcome to help with this task
-15:39  * wired will try to
-15:39 <@Chainsaw> The only thing worse than blowing up a users system and telling them why is blowing their system up and leaving *them* to figure out what just happened.
-15:39 <@jmbsvicetto> s/anyone/everyone/
-15:39 <@jmbsvicetto> Chainsaw: I agree, but we've delayed this enough as is
-15:39 <@Chainsaw> It's a good change to delete .la files. But you need to tell users why you're doing it and a quick "if you see X, do Y".
-15:39 <@jmbsvicetto> so, arfrever's suggestions to EAPI-4
-15:40 <@Chainsaw> It is ludicrous do proceed without that.
-15:40 <@Betelgeuse> If we fail to get a single email out it's a clear sign things would be just delayed and delayed
-15:40 <@Chainsaw> s/do proceed/to proceed/
-15:40 <@jmbsvicetto> ferringb: Do you want to talk about required_use before or after this?
-15:40 <@Chainsaw> Betelgeuse: If you can't document it appropriately, you're not ready to proceed.
-15:40 <@ferringb> jmbsvicetto: what specifically do you wish to discuss?
-15:40 <@Betelgeuse> Chainsaw: The vote was to lift the restrictions only if no action is taken
-15:41 <@ferringb> ongoing 3sat/sky-will-fall, or
-15:41 <@Betelgeuse> Chainsaw: It will still be there even if the news item is not ready by Wednesday as long as the work is on going
-15:41 <@jmbsvicetto> ferringb: the patch submitted by ulm and the effect that ongoing discussion has on it
-15:42 <@ferringb> someone *really* should talk to flameeyes about .la doc also- he's been after this a while, and is likely available to help ignoring this weekend
-15:42 <@ferringb> ulm's already pushed the patch in
-15:42 <@jmbsvicetto> ferringb: He's willing to help and he already agreed to release his posts as CC-SA, but he's not willing to write the doc
-15:43 <@ferringb> jmbsvicetto: the ongoing discussion isn't discussion.  it's "the sky will fall".  I'm not having those discussions anymore.
-15:43 <@jmbsvicetto> ok
-15:43 <@jmbsvicetto> So you don't want the proposed function, correct?
-15:43 <@Chainsaw> jmbsvicetto: Hardened has a very enthusiastic young jedi, eh, docs writer going by the nickname of klondike.
-15:43 <@Chainsaw> jmbsvicetto: Have a word with him if that's what it takes to move this forward.
-15:44 <@ferringb> jmbsvicetto: function is pointless.
-15:44 <@ferringb> well, backing down slightly... the function should be added *after* if it proves needed
-15:45 <@ferringb> everything I laid out in that bug in terms of binding together the various information already available (particularly local use flag info from metadata.xml) makes me think the function isn't needed
-15:45 <@jmbsvicetto> so it should be left out of EAPI-4 and, if needed, be discussed for next EAPI version?
-15:45 <@ferringb> exactly
-15:45 <@jmbsvicetto> ok
-15:45 <@ferringb> hell, a 4.1 would be fine by me
-15:45 <@Chainsaw> The only conclusion I can draw on REQUIRED_USE is that it is a punch thrown in Arfrever vs repoman.
-15:45 <@Chainsaw> EAPI 4 looks sane, leave this out of it so it can be voted in.
-15:45 <@jmbsvicetto> Do we want to vote the patch or will we leave this for a final vote on EAPI-4 ?
-15:46 <@ferringb> "punch thrown in arfrever vs repoman" ?
-15:46 < Arfrever> Chainsaw: REQUIRED_USE isn't related to me at all.
-15:46 <@Chainsaw> ferringb: It's a way for Arfrever to bypass repoman in a crazy python dependency nightmare.
-15:46 <@jmbsvicetto> Chainsaw: You're mixing proposals
-15:46 <@Chainsaw> ferringb: I don't see any clean way to implement it.
-15:46 <@ferringb> crazy python dep issue is orthogonal to required_use
-15:46 <@Chainsaw> jmbsvicetto: So be clear about what you're discussing, because REQUIRED_USE is on my agenda.
-15:47 <@jmbsvicetto> Chainsaw: my fault, sorry
-15:47 <@jmbsvicetto> Chainsaw: I was asking ferringb if he wanted to talk about required_use before or after arfrever's proposals for EAPI-4
-15:47 <@Chainsaw> Right. I shall shut up until later then.
-15:47 <@wired> Chainsaw: we are talking about pkg_required_use()
-15:48 <@ferringb> ok, I'm confused
-15:48 <@jmbsvicetto> So, do we want to have a vote or make any comments about ulm's patch or do we leave this until we're ready to have a final vote for EAPI-4?
-15:49 <@Betelgeuse> The final vote is tagging a commit so it should at least be easy to get what we will tag
-15:50 <@Betelgeuse> guess we could have two branches but I wonder how convenient that is
-15:51 <@jmbsvicetto> So everyone knows what were talking about, required_use is bug 347353 and arfrever's proposal is http://archives.gentoo.org/gentoo-dev/msg_bec5db8373fca0271fcadf0cd55724e8.xml
-15:51 < willikins> jmbsvicetto: https://bugs.gentoo.org/347353 "[Future EAPI] REQUIRED_USE USE state constraints"; Gentoo Hosted Projects, PMS/EAPI; NEW; ulm@g.o:pms-bugs@g.o
-15:52 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has quit [Disconnected by services]
-15:52  * ferringb mutters
-15:52 <@Betelgeuse> jmbsvicetto: The former wasn't on the agenda so at least I am not really that prepared on it
-15:52 <@ferringb> seriously, if that '.' thing comes up once more I'm wedgieing folk
-15:52 <@jmbsvicetto> Betelgeuse: sorry, that was also my fault
-15:53 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has joined #gentoo-council
-15:53 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
-15:53 <@jmbsvicetto> in that case, let's take care of the bug later
-15:53 <@Chainsaw> Well that was most annoying.
-15:53 <@Chainsaw>  <wired> Chainsaw: we are talking about pkg_required_use()
-15:53 <@Chainsaw>  <Chainsaw> wired: You need that. There's no way the package manager can create a useful error message by itself.
-15:53 <@Chainsaw> What'd I miss?
-15:53 <@ferringb> jmbsvicetto: basically, everything on that list he's been told no.  repeatedly.
-15:53 <@jmbsvicetto> so let's discuss arfrever's request
-15:53 < Arfrever> jmbsvicetto: In case of my suggestions, please discuss each of them separately.
-15:53 <@ferringb> trying to bypass me pointing out issues (repeatedly) via going to the council (which I'm a part of) seems nonsensical
-15:53 <@jmbsvicetto> Chainsaw: http://archives.gentoo.org/gentoo-dev/msg_bec5db8373fca0271fcadf0cd55724e8.xml - link to arfrever's proposal
-15:54 <@ferringb> fine, we'll put it on the record this time
-15:54 <@wired> Chainsaw: I agree :)
-15:54 <@ferringb> anyone mind if I work through the points?
-15:54 <@jmbsvicetto> please do
-15:54 <@jmbsvicetto> I'm ready to vote on this if anyone else wants to
-15:54 <@Betelgeuse> I strong dislike how dots in USE flags is presented as some kind of a mandatory feature.
-15:54 <@Betelgeuse> but ferringb feel free
-15:54 <@ferringb> yeah, just let me address the points
-15:54 <@jmbsvicetto> I vote against . in USE flags for the reasons ferringb has stated before
-15:55 < Arfrever> Dots were requested also by Tommy[D].
-15:55 <@ferringb> among other things, I'm putting this in the fucking record so it stops coming up
-15:55 <@wired> let ferringb analyze everything then we talk
-15:55 <@wired> then I can start driving again :)
-15:55 <@ferringb> #1; doing so is a minor, stupid gain.  Yes it's aesthetically lovely, the problem is that use flags go *everywhere*.  Consider that python would shortly have a flag 'python2.6', that flag would than be able to show up in multiple places in the profiles with ease
-15:56 <@ferringb> this isn't equivalent to usage of slot deps in profiles- you can technically convert a slot dep down to a set of ranged deps to keep the eapi as low as possible in profiles (which you have to do anyways for compatibility)
-15:57 < Tommy[D]> Arfrever: while i asked for it, it is not a requirement for me, besides the detail, that i talked with ferringb and he has a point about using such USE flags in the profiles
-15:57 <@ferringb> change use flags, everywhere that flag can show up (which is a *lot* of places) winds up getting it's eapi bumped to the version allowing thos versions
-15:57 <@ferringb> in other words, pain, potentially at the base nodes of the profiles themselves, for a freaking period.  It ain't worth it.
-15:57 <@Chainsaw> Seconded, I don't want it either.
-15:58 <@jmbsvicetto> no, from me as well
-15:58 <@ferringb> -infinity against it, and a +1 on a permenant ban from it ever reaching my ears again ;)
-15:58 < Arfrever> ferringb: What's wrong in using the newest EAPI in non-deprecated profiles?
-15:58 <@Betelgeuse> If all languages like php and ruby also moved to using dots then it would be fine
-15:58 <@ferringb> Betelgeuse: even then, it wouldn't be.  consider those flags making their way into the default use flag configuration for a profile
-15:58 <@ferringb> that's the thing
-15:58 <@jmbsvicetto> ferringb: there's also the issue that current tools will break if a . is used on use flags, right?
-15:58 <@ferringb> think through base/make.defaults in the profiles- it specifies use flags
-15:59 <@Betelgeuse> ferringb: It would be a major coordinated effort any way but yeah.
-15:59 <@ferringb> now if you ever want php5.4 or whatever the hell as a default, the base becomes EAPI=4; locking out basically the entire upgrade path
-15:59 <@Betelgeuse> ferringb: multiple inheritance would allow creating a EAPI 4 base
-15:59 < Tommy[D]> Arfrever: backward compactibility, think about users with older installs, which do a sync, then want to select a new profile as suggested and then wont get anywhere because their portage does not support the profile
-16:00 <@ferringb> you'd have to shadow the entire profile tree
-16:00 <@ferringb> Betelgeuse: there are ways, I don't deny it, but you must acknowledge they're generally all involving large amounts of pain, and zero lube ;)
-16:00 <@Betelgeuse> ferringb: I know. I was basically agreeing with you in different words.
-16:00 <@ferringb> pardon ;)
-16:00 <@Betelgeuse> ferringb: Basically with added gains it could be worth the trouble later down the road.
-16:01 <@ferringb> if it's ever to be done, it should be deployed during a wholescale restructuring of use flags
-16:01 <@ferringb> introduction of use groups (proper use groups) for example.
-16:01 <@jmbsvicetto> Does anyone else want to vote on this point? we already have 3 no votes
-16:01 <@Chainsaw> You'd probably have to switch to a "profile2" directory.
-16:01 < Arfrever> *-${EAPI} files would avoid duplication of profiles.
-16:01 <@Chainsaw> I don't see another way.
-16:01 <@wired> I vote no for now
-16:01 <@Chainsaw> wired: Not until the end of time?
-16:01 <@ferringb> Arfrever: in favor of duplication of data.  great solution.
-16:01 <@wired> lol
-16:02 <@Chainsaw> wired: My vote is unlikely to change.
-16:02 <@ferringb> anyone really want me to tear at #2?
-16:02 <@Betelgeuse> Chainsaw: We can't tie the next council any way :)
-16:02 <@wired> I think this can happen when/if we figure out a way to ensure upgrade paths for users
-16:02 <@jmbsvicetto> So this point was voted no with 4 votes: ferringb, chainsaw, me and wired 
-16:02 <@Betelgeuse> jmbsvicetto: I voted no too
-16:02 <@jmbsvicetto> Betelgeuse: ok, I missed it
-16:02 <@Betelgeuse> Probably too unclearly
-16:02 <@wired> I have something in mind i need to write down someday
-16:03 <@ferringb> I suggest adding it to a bug of "these are the things we'd like to do if we ever can break use flags"- it should be tracked
-16:03 <@jmbsvicetto> ferringb: talk about point 2 please
-16:03 <@ferringb> not much to say.  it's equivalent to pointing a shotgun on your foot
-16:04 <@ferringb> it's relying on humans to get things right across multiple eapi versions
-16:04 <@jmbsvicetto> to me it's another GLEP55 variation and I already expressed my dislike for that. I vote no
-16:04 <@wired> jmbsvicetto: exactly
-16:04 <@ferringb> it doesn't address later versions (how does EAPI=5 fit into a profile that has 2, and 4 for a file?), and generally, it's a freaking hack trying to prop up #1
-16:05 <@Betelgeuse> bug 349021
-16:05 < willikins> Betelgeuse: https://bugs.gentoo.org/349021 "Tracker: Use flag restructuring"; Gentoo Hosted Projects, PMS/EAPI; NEW; betelgeuse@g.o:pms-bugs@g.o
-16:05 <@ferringb> Betelgeuse: thanks
-16:05 <@jmbsvicetto> Betelgeuse: thanks
-16:05 < Arfrever> ferringb: EAPI specified in filename is used only for syntax inside given files.
-16:05 <@ferringb> Arfrever: trust me, I understand the profiles and what you're trying to do here
-16:06 <@wired> it'll be maintenance nightmare...
-16:06 <@ferringb> yep
-16:06 <@ferringb> in light of that, what's the gain?
-16:06 <@jmbsvicetto> Arfrever: Instead of going down that route, I want us to review the profiles so we can move the trouble files inside real profiles that can have an eapi file
-16:06 < Arfrever> wired: What exactly would be maintenance nightmare? My suggestion actually avoids/decreases maintenance nightmare.
-16:07 <@ferringb> Arfrever: your suggestion compounds it massively
-16:07 <@Betelgeuse> u
-16:07 <@Betelgeuse> sorry
-16:07 <@wired> again, what we really need here is a way to ensure users have their pm up to date
-16:07 <@Betelgeuse> willikins: WE already do
-16:07 <@Betelgeuse> wired: ^
-16:08 <@jmbsvicetto> wired: there are issues with the package.mask file and the base profile
-16:08 <@wired> I've been thinking of a solution that includes switching our rsync repo's name on big updates
-16:08 <@jmbsvicetto> wired: is that like Patrick's proposal?
-16:08 <@wired> similar
-16:08 <@ferringb> not sure if others have been throw equivalent, but when you try doing massive swaps like wired is talking about, with hard cut off's and manual transitions... you bleed users off
-16:08 <@ferringb> *through
-16:09 <@wired> but more automated
-16:09 <@Betelgeuse> When a new EAPI is introduced putting latest EAPI for central packages but without breaking Portage upgrade path makes it quite likely that people are on new versions.
-16:09 <@Betelgeuse> Of course this probably doesn't solve profile problems here.
-16:09 <@ferringb> wired: what, like having EAPI markers in the profiles, or an EAPI marker in the repository? ;)
-16:09 <@jmbsvicetto> Betelgeuse: but that only works for a certain timeframe
-16:10 < Arfrever> Both solutions to problem #2 allow to implement solution to problem #1 in profiles.
-16:10 <@ferringb> #1 isn't a fucking issue
-16:10 <@ferringb> it's a period
-16:10 <@jmbsvicetto> Betelgeuse: after 3 or 4 EAPI bumps, you would need to do 3 or 4 jumps to specific snapshots of the tree and then you would need to find the distfiles for the packages and run the merging for the 3 or 4 updates
-16:10 <@ferringb> seriously.  use a dash.  backwards compatibility sucks, but we do have to do it
-16:10 <@wired> ferringb: cutting off all updates to current rsync except from portage, then when portage gets updated it switched the make.confirm rsync line to the new repo automatically
-16:10 <@wired> switches*
-16:11 <@ferringb> wired: there are other ways; repository format markers
-16:11 <@wired> sure
-16:11 <@ferringb> think it was ulm I was last talked w/ about it; it's reasonably clean
-16:11 <@jmbsvicetto> anyway, I suggest we take this discussion to the ml as it wasn't in our agenda and at this rate we won't end this meeting
-16:11 <@ferringb> eh, let's vote on #2
-16:12 <@jmbsvicetto> right
-16:12 <@ferringb> if folks have time, I'd like to finish this list off in full
-16:12 <@jmbsvicetto> I vote no
-16:12 <@wired> ferringb: yeah just working on a basic idea
-16:12 <@ferringb> -1, +infinity for never hearing it again
-16:12 <@Chainsaw> I vote no, until the end of time.
-16:12 <@wired> I vote no
-16:12 <@jmbsvicetto> I meant moving to the ml the talk about how to review Gentoo upgrade paths, not arfrever's email
-16:12 <@wired> I hate suffixes
-16:12 < Arfrever> jmbsvicetto: Please clarify on what is this voting.
-16:12 <@jmbsvicetto> Arfrever: we're voting about point 2 of your email
-16:13 <@jmbsvicetto> Betelgeuse: how do you vote?
-16:13 < Arfrever> jmbsvicetto: Problem #2 has 2 suggested solutions. Is it voting on the first or second solution.
-16:13 < Arfrever> s/\.$/?/
-16:13 <@jmbsvicetto> Arfrever: sorry, I missed that
-16:13 <@ferringb> Arfrever: there is no reason to create those profiles, exempting for if you actually managed to get #1 implemented; it was killed
-16:14 <@jmbsvicetto> ferringb / Chainsaw / wired: Do you vote no to both proposals or just to the first?
-16:14  * ferringb isn't against profile restructuring if needed for an eapi
-16:14 <@ferringb> -infinity no on the first part (.$EAPI), and no on the second since right now, there ain't any reason to do it
-16:14 <@Chainsaw> jmbsvicetto: No on both.
-16:15 <@wired> no on both
-16:15 <@Betelgeuse> No on both.
-16:15 <@ferringb> that 4, or 5?
-16:15 <@jmbsvicetto> I vote no on the first and push back the 2nd to a larger discussion in the mls
-16:15 <@Betelgeuse> But I don't mean that profile restructuring is not allowed.
-16:15 <@Betelgeuse> But I don't want to mandate any such thing currently.
-16:15 <@ferringb> I doubt anyone is against profile restructuring
-16:15 <@jmbsvicetto> 5 no votes for the 1st solution, and 4 no votes and 1 back to the ml for the second solution
-16:15 <@ferringb> there just has to be a _reason_ to do it
-16:16 <@ferringb> folks feel like finishing the list?  point #3?
-16:16 <@Chainsaw> ferringb: Go for it.
-16:16 <@jmbsvicetto> yes
-16:16 <@ferringb> in reading the text... want my "the sky will fall" explanation, or can you see the QA mess that will unleash w/out it?
-16:17  * ferringb is refering in this case to both proposed solutions
-16:17 <@jmbsvicetto> ferringb: The "solutions" presented on this case deserve some debate, imho. But not in relation to the proposed problem
-16:18 <@Betelgeuse> I can see a problem needing a solution here.
-16:18 <@ferringb> to some degree, I agree
-16:18 <@Betelgeuse> Ruby should have similar problems with differently stability of VMs
-16:18 <@ferringb> I just very strongly think doing what is proposed there is going to lead to maintenance hell
-16:18 <@Betelgeuse> like jruby vs. mri
-16:19 <@Betelgeuse> maybe 3) unstable use flags?
-16:19 <@ferringb> hmm
-16:19 <@Betelgeuse> so users with default stable keywords would have to unmask them
-16:19 <@jmbsvicetto> ferringb: the "unsatisfiable" idea reminds me of the special repo in paludis for packages that don't exist in the tree. That is something I think we might want to talk about sometime, but I don't see how that has anything to do with python
-16:19 <@ferringb> Betelgeuse: how would that work across profiles though?  that's more a repository level thing
-16:19 <@Betelgeuse> ferringb: repo global support could be enough
-16:19 <@ferringb> jmbsvicetto: unsatisifable in exherbo is a seperate beast, and worthwhile rip off also.
-16:19 <@Betelgeuse> ferringb: for at least for these use cases
-16:20 <@jmbsvicetto> the separate unstable / stable profile idea is also something that we can talk about, in particular if we get back to the idea of moving KEYWORDS out of ebuilds, but I also don't see how this is tied to python
-16:20 < Arfrever> Betelgeuse: Some flags would have to be unstable on some architectures.
-16:20 < Arfrever> s/on/only on/
-16:20 <@Betelgeuse> Then it could stack like all other stuff?
-16:21  * ferringb notes that has the potential to screw repoman run times over pretty hardcore
-16:21 <@ferringb> well... that's assuming repoman is doing the same optimizations pcheck does for profile collapsing
-16:21 <@ferringb> either way, QA scanning runtime implications
-16:21 <@Betelgeuse> In general I think it's too late for EAPI 4
-16:21 <@ferringb> agreed
-16:22 <@ferringb> the unsatisfiable angling also I very strongly disagree with
-16:22 <@wired> agreed, we should discuss this a bit more
-16:22 <@ferringb> unstable/stable classification (as a whole) isn't something I'd thought about, but that is a discussion point
-16:22 <@jmbsvicetto> Betelgeuse: I know in the past we had KDE packages bumps that added optional support for new features (new deps) that lead to this issue - how to mark the package stable and have the new use flag which pulled an unstable package masked just for stable users
-16:23 <@Betelgeuse> jmbsvicetto: So basically the stability attributes for use flags
-16:23 <@jmbsvicetto> I do agree it's to late to discuss this for EAPI-4
-16:24 <@jmbsvicetto> Betelgeuse: yes
-16:24 < Arfrever> Bug #348087 contains example problem. dev-python/numexpr should be stabilized, but its optional dependency (sci-libs/mkl) cannot be stabilized.
-16:24 < willikins> Arfrever: https://bugs.gentoo.org/348087 "Stabilize dev-python/pytables-2.2.1"; Gentoo Linux, Applications; RESO, LATE; arfrever@g.o:python@g.o
-16:24 <@wired> something like ~use to define unstable use flags maybe?
-16:24 <@ferringb> it's not about unstable flags
-16:24 <@jmbsvicetto> so, shall we have a vote for 3?
-16:24 <@ferringb> it's about optional deps, enhancements
-16:25 <@ferringb> wired: imo at least.  if you think about it in that context, stable/unstable lose their meaning and it's more of an annotation
-16:25 <@Betelgeuse> On first thought ~use seems a good idea
-16:25 <@jmbsvicetto> Betelgeuse: hmm, reading your comment and ferringb's again, it's not about adding "unstable flags" but about optional deps hidden behind use flags that are not yet ready to be marked stable
-16:26  * ferringb reiterates; forget stable/unstable
-16:26 <@jmbsvicetto> sure
-16:26 <@wired> ferringb: then this whole thing could fall under the general use flag redesign umbrella
-16:26 <@ferringb> the real issue is that at a dep level, it's strongly refed, *always*.  most of the real issues where it's a pain in the ass (say enabling real support for mplayer- *that* is a good example) are optional deps
-16:26 <@Betelgeuse> jmbsvicetto: yes but unstable use flags would cause the optional deps to not be able to be enabled
-16:27 <@Betelgeuse> jmbsvicetto: as such solving the problem
-16:27 <@ferringb> Betelgeuse: and what does it do to the ability to scan unstable pkgs?
-16:27 < Arfrever> Please note that any solution needs to be per-profile, so it cannot require any changes inside ebuilds.
-16:27 <@ferringb> see my point about reorientating the discussion?
-16:27 <@jmbsvicetto> Betelgeuse: in this case I'd prefer Zac's idea of optional deps
-16:27 <@ferringb> Arfrever: the proper place for this is *in* ebuilds themselves
-16:27 <@ferringb> profiles shouldn't be involved
-16:27 <@ferringb> well, not directly at least
-16:28 <@wired> this clearly needs a discussion, and I think it belongs in the ebuild
-16:28 <@Betelgeuse> Profile should have as little as possible package specific stuff
-16:28 <@Betelgeuse> Package specific stuff belongs to the package directory
-16:29 < Arfrever> ferringb: After stabilization of Python 2.7 or 3.2 on given architecture, it should be sufficient to change 1 file in a profile of this architecture instead of changing hundreds ebuilds.
-16:29 <@ferringb> Arfrever: eclass
-16:29 <@ferringb> nice try though
-16:29 <@jmbsvicetto> my vote on point 3 is that something related to the solutions presented should be discussed in the mls, not to be included in EAPI-4, but that the problem raised is another source of concern for the current status of python in Gentoo
-16:30 <@ferringb> framing the vote; is this eapi-4 material?
-16:30 <@ferringb> my vote is no
-16:30 <@Betelgeuse> no
-16:30 <@jmbsvicetto> no
-16:30 <@wired> I vote no for EAPI 4
-16:30 <@wired> would like to talk more about it
-16:30 <@Chainsaw> I vote no.
-16:30 <@ferringb> wired: ml's make perfect sense
-16:30 <@wired> heap
-16:30 <@jmbsvicetto> so 5 no votes for the solutions presented in point 3 to be part of EAPI-4
-16:30 <@wired> yeap*
-16:31 <@ferringb> jmbsvicetto: yeah, exactly that phrasing
-16:31 <@ferringb> my personal views for >4, the solution presented would get a -1 still (should be in the ebuild, profiles are a maintenance nightmare)
-16:31 <@ferringb> but that vote doesn't need to occur here/now
-16:31 <@jmbsvicetto> let's move to the bugs then?
-16:32  * ferringb shuts up and lets whoever was chairing this beast run it
-16:32  * wired this has to be my most bizarre meeting yet, in my car, on an iPhone, in the middle of nowhere
-16:32 <@ferringb> wired: you're cribbing dr. seuss there ;)
-16:32 <@jmbsvicetto> How much time do you want / can spend on the meeting? (Should we try to finish the meeting or can we prolong it)
-16:33 <@jmbsvicetto> wired: photos or it didn't happen ;)
-16:33 <@wired> meh
-16:33 <@ferringb> I'd personally like to go get some coffee before continuing, but I've got basically all morning as needed for council
-16:33 <@jmbsvicetto> we've gone over slacking arches - bug 234706
-16:33 < willikins> jmbsvicetto: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-16:34 <@ferringb> if we're continuing, any complaints if I duck out for ~10 minutes or so?
-16:34 <@ferringb> or think we'll be finished in 10 ;)
-16:34  * Chainsaw shouts RECESS and steps aside to dodge the stampede
-16:34 <@jmbsvicetto> Betelgeuse / Chainsaw / wired: ^^
-16:34 <@jmbsvicetto> ok
-16:34 <@jmbsvicetto> 10 minute break then
-16:34 -!- DrEeevil is now known as bonsaikitten
-16:34 <@ferringb> back in 10ish
-16:34 <@wired> oh nice
-16:34 <@wired> I'll start driving then
-16:34 <@ferringb> wired: just enough time for you to get pictures
-16:34 <@ferringb> heh
-16:34 <@wired> heheh
-16:34 <@jmbsvicetto> :)
-16:36 <@wired> k got a few photos and screenshots of this client :)
-16:38 <@jmbsvicetto> hehe
-16:40 < ulm> hm, what have you decided on pkg_required_use()?
-16:40 < ulm> it's not clear to me from the log
-16:41 <@Chainsaw> ulm: That if REQUIRED_USE were somehow accepted, it is a necessity.
-16:41 <@Betelgeuse> Did we decide?
-16:42 <@Betelgeuse> I don't even remember voting
-16:42 <@Chainsaw> Betelgeuse: I believe that since we voted out REQUIRED_USE, pkg_required_use dies with it.
-16:42 <@Betelgeuse> Chainsaw: Isn't REQUIRED_USE already accepted?
-16:42 <@Betelgeuse> Then there were complications
-16:42 <@Betelgeuse> And now it's an open question how to deal with them.
-16:43 <@Betelgeuse> Unless we got a decision today
-16:43 < ulm> REQUIRED_USE was accepted in the November meeting
-16:43 <@Chainsaw> ulm: Ah.
-16:43 < ulm> only open point in the pkg_required_use function
-16:43 < ulm> then EAPI 4 can be tagged
-16:44 <@Chainsaw> jmbsvicetto: ulm has a point, we need to vote on pkg_required_use. I vote yes.
-16:44  * ferringb looks up
-16:45 <@ferringb> thought we had
-16:45 <@ferringb> I vote no on the function
-16:46 <@jmbsvicetto> ulm: we pushed it for next meeting
-16:46 < ulm> oh well...
-16:46 <@jmbsvicetto> Chainsaw: Betelgeuse reminded I forgot to include it in the agenda for this meeting
-16:47 <@Chainsaw> jmbsvicetto: Ah, okay. I must have missed that in the disconnection.
-16:47 <@jmbsvicetto> everyone back? can we go over the bugs?
-16:47 <@ferringb> ahh right, we didn't vote on that
-16:47 <@jmbsvicetto> so
-16:47 <@jmbsvicetto> bug 234706 - slacker arches (we've gone over this issue in the meeting)
-16:47  * ulm wonders why jmbsvicetto then asked for topics in his announcement
-16:47 < willikins> jmbsvicetto: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o
-16:48 <@jmbsvicetto> ulm: Did you ask for it? If so, I missed your email. I'm sorry
-16:48 < ulm> jmbsvicetto: http://archives.gentoo.org/gentoo-project/msg_3463900fd31abf9894c4c07e1a4a9978.xml
-16:48 <@Betelgeuse> I think we can vote on it today if people think they have enough info
-16:49 <@jmbsvicetto> Betelgeuse / ferringb: As it was I who missed it and we seem to have some time, do you want to talk about required_use?
-16:49 <@ferringb> pkg_required_use to be clear
-16:49 <@jmbsvicetto> zmedico: ping ?
-16:49 <@jmbsvicetto> yes, pkg_required_use
-16:49 <@Chainsaw> I am happy to vote pkg_required_use in at this point.
-16:49 < zmedico> jmbsvicetto: pong
-16:50 <@wired> yes please
-16:50 <@Chainsaw> Because I don't see how a package manager could produce a sane error message without it.
-16:50 <@jmbsvicetto> zmedico: Do you want to say anything about pkg_required_use?
-16:50 <@ferringb> Chainsaw: give me an example asserition
-16:50 <@ferringb> *assertion
-16:50 < zmedico> jmbsvicetto: this sums up my feelings: https://bugs.gentoo.org/show_bug.cgi?id=347353#c26
-16:51 <@jmbsvicetto> zmedico: ferringb proposes that pkg_required_use be left out of EAPI-4 and be considered for a next revision if it is showed a need for it
-16:51 <@jmbsvicetto> ferringb: right?
-16:51 <@ferringb> basically
-16:51 <@ferringb> I'm mostly waiting for examples that disprove my earlier comments about the PM being able to hit 90% of the req itself w/ a bit of work
-16:51 < zmedico> as long as we don't have to call pkg_pretend when REQUIRED_USE is unsatisfied, it's fine with me
-16:52 <@Betelgeuse> ferringb: How will an ebuild write know he's hitting the 10%?
-16:52 <@ferringb> Betelgeuse: by someone giving me an example right here/now so we have something concrete to discuss
-16:52 <@jmbsvicetto> ferringb: you don't want the PM to call pkg_pretend because of require_use, do you?
-16:52 <@ferringb> pkg_pretend isn't involved in required_use
-16:52 <@ferringb> required_use is prior to pkg_pretend
-16:52 <@Betelgeuse> jmbsvicetto: one proposal was for pkg_pretend to do a double duty
-16:53  * ferringb is -1 on such a proposal
-16:53 <@jmbsvicetto> yes, but I just want to clarify that PMS should be clear that it's not acceptable for the PM to call pkg_pretend
-16:53 <@ferringb> different stages
-16:53 <@jmbsvicetto> ferringb: right, that's what I wanted to confirm
-16:53 <@jmbsvicetto> your -1 vote
-16:53 <@Betelgeuse> Well PMS shouldn't document all kinds of false behavior.
-16:54 <@jmbsvicetto> I'm now ready to vote. Does anyone want to discuss this further?
-16:54 <@Betelgeuse> zmedico, ferringb: Would auto detection in PM prove to be complex to implement and as such prone to bugs?
-16:54 <@ferringb> ok; and zmedico presumably will back me up on this, but under eapi-4, it's basically 1) do resolution; notify users about flat out broken deps, 2) required_use validation; notify user about conflicts, 3) pkg_pretend invocations as necessary, notify users about those failures, 4) nofetch validations, invoke as needed for fetchs unable to be completely
-16:54 <@ferringb> that's the *current* state of REQUIRED_USE/eapi-4
-16:55 <@ferringb> folks grok that?
-16:55 <@Betelgeuse> ferringb: Can't we have pkg_required_use in eclasses?
-16:55 <@Betelgeuse> ferringb: Then it can be upgraded on the fly as needed.
-16:55 <@Betelgeuse> ferringb: Then the logic would be same for all PMs
-16:55 <@ferringb> stick to the resolution/current state first
-16:55 <@Betelgeuse> ferringb: And you would not have to reinvent the wheel
-16:55 <@ferringb> folks get that that is how the PM actually does it's thing?  note that 3/4 could be varied in ordering, but that's the rough steps
-16:56 < ulm> Betelgeuse: you might have the function in an eclass, but the PM must still call it
-16:56 <@Betelgeuse> ulm: yes
-16:57 <@jmbsvicetto> Betelgeuse: my reading is that the issue is not where the function is defined, but whether one should open the door for execution of code or stick to metadata resolution
-16:57  * ferringb notes execution of code is duplication
-16:57 <@ferringb> ok, consider ( mysql sqlite ), right?
-16:57 <@ferringb> one or the other
-16:58 <@ferringb> err
-16:58 <@ferringb> ok, consider || ( mysql sqlite ), right?
-16:58 <@ferringb> *cough*
-16:58 < zmedico> it's conceivable that you could add a REQUIRED_USE_EXPLANATION variable, and avoid executing code that way
-16:58 <@ferringb> the PM, presuming it's not written by monkeys (descendants of monkeys are fine though), knows that that's an OR; so if neither is satisfied, it can tell the user "you must choose one or the other of the following"- then it can pull the local use for that pkg for mysql/sqlite
-16:59 <@ferringb> zmedico: ugh.  annotate REQUIRED_USE itself rather than a parallel tree please
-16:59 < zmedico> sure
-16:59 <@jmbsvicetto> annotations seem to make more sense here
-16:59  * ferringb notes you already have them in local use flags
-17:00 <@ferringb> the only context missing is annotating the group operator- the 'or', the 'and', the 'exactly one of', which the PM _already_ knows about since it's the one enforcing the constraint
-17:00 <@jmbsvicetto> ferringb: not arguing against that
-17:00 <@ferringb> so... considering those points, that the data is already there, what's the point of the function?
-17:00 <@ferringb> beyond each ebuild/eclass author working around PMs not implementing such a UI design I mentioned?
-17:01  * ferringb notes that's his point, through and through; the PM can do this on it's own, doesn't require ebuild/eclass authors writing it
-17:01 <@jmbsvicetto> ferringb: I think ciaranm objection was about more complex cases
-17:01 <@ferringb> aware
-17:01 <@ferringb> again, I wanted examples
-17:02 <@ferringb> *real world examples*
-17:02 <@jmbsvicetto> ferringb: something like ^ ( mysql sqlite postgres) on package A, ( mysql ) on package B, ( sqlite ) on package C and ( mysql postgres  ) on package D
-17:03 <@ferringb> jmbsvicetto: easy counter; explain to me how a pkg level pkg_required_use could explain the conflicts there any better than the manager could?
-17:03 <@jmbsvicetto> ferringb: I understand and I don't have any particular world examples that would break your proposal
-17:03 <@ferringb> because the *manager* is the one that knows the depgraph, and the use configuration it's choosen
-17:03 <@jmbsvicetto> ferringb: btw, I agree with your proposal
-17:03 <@ferringb> the ebuild itself doesn't know that info
-17:04 <@jmbsvicetto> anyone wants to continue this discussion or are we ready to vote?
-17:05 <@jmbsvicetto> Betelgeuse / Chainsaw / wired: ^^
-17:05 <@Chainsaw> Ready to vote.
-17:05 <@Betelgeuse> Do PMs have the REQUIRED_USE error handlers ready?
-17:05 <@Chainsaw> My opinion hasn't changed.
-17:05 <@Betelgeuse> zmedico, ferringb: ^
-17:05 <@ferringb> Betelgeuse: no, but the infrastructure for REQUIRED_USE is easily extended for this
-17:05 <@ferringb> if it's implemented as a CSP, it's available
-17:05 <@wired> I'm ready
-17:06 <@jmbsvicetto> ok, let's vote then
-17:06 <@ferringb> Betelgeuse: that said, zac may've coded something when I wasn't looking ;)
-17:06 <@jmbsvicetto> Should EAPI-4 introduce a pkg_required_use flag to be called if the PM isn't able to fulfill required_use constraints?
-17:07 <@ferringb> no
-17:07 <@Chainsaw> jmbsvicetto: I vote yes.
-17:07 <@jmbsvicetto> s/flag/function/
-17:07 <@jmbsvicetto> no
-17:08 <@jmbsvicetto> wired / Betelgeuse: ^^
-17:08 < zmedico> Betelgeuse: this is what portage uses for user feedback: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=pym/portage/dep/__init__.py;hb=master#l1984
-17:09 < zmedico> required_use.replace("^^", "only-one-of").replace("||", "any-of")
-17:09 <@wired> 1 sec
-17:09 <@ferringb> zmedico: yeah, that can be extended a fair bit also
-17:09 <@Betelgeuse> zmedico: What is your preference on the question under vote?
-17:10 < zmedico> Betelgeuse: it doesn't matter to me. I'm only opposed to calling pkg_pretend when REQUIRED_USE is unsatisfied
-17:10 <@ferringb> zmedico: alternative question; is the function needed, or can the PM do it itself?
-17:10 <@wired> I vote no, unless proven needed. even then, the internal function should be disabled by a flag in the ebuild when the external function is required
-17:11 <@Betelgeuse> A tertiary option is calling it if the function is defined and otherwise falling back on the PM default.
-17:11 <@wired> or that
-17:11 <@Betelgeuse> This way people can just start writing pkg_required_use when things start falling apart.
-17:11 < zmedico> ferringb: I don't know, I think maintainers of ebuilds that would need REQUIRED_USE would be more qualified to speculate
-17:11 <@ferringb> well, as is it's 3 nos, 1 yes, 1 undecided
-17:11 <@Betelgeuse> Of course this sounds a little bit future proofing.
-17:12 <@ferringb> I'm generally opposed to optional's like Betelgeuse is suggesting, but it's a compromise
-17:12 <@Betelgeuse> no now and fast 4.1 with pkg_required_use as I described as soon as there's a need in main tree
-17:12 <@ferringb> my main concern is that it allowed PM authors to skimp on it, thus forcing it to become the default
-17:12 <@ferringb> *allows
-17:13 <@ferringb> well, moreso forcing ebuild devs to define it to work around shitty package managers
-17:14 <@jmbsvicetto> are everyone votes final? Can I count them?
-17:14 <@wired> brb in 2' on a normal keyboard
-17:14 <@ferringb> 2 feet?
-17:14 <@wired> 2 minutes :P
-17:14 <@ferringb> feet's funnier
-17:15 <@Betelgeuse> jmbsvicetto: yes
-17:15 <@jmbsvicetto> ok, I think this meeting productivity is going down hill, so let's try to wrap this issue and finish the meeting, please?
-17:16 <@Betelgeuse> jmbsvicetto: yes
-17:16 <@Chainsaw> jmbsvicetto: I vote yes!
-17:16  * ferringb votes yes, quickly before wired makes it the 2 feet
-17:16 <@ferringb> yes to finishing up that is.  still -1 on pkg_required_use
-17:17 <@wired> hehe
-17:17 <@jmbsvicetto> So, we have 3 votes no, 1 vote yes and 1 undecided vote on having EAPI-4 introduce a pkg_required_use function to be called by the PMs when they can't fulfill the requird_use constraints
-17:17 <@wired> back
-17:18 <@wired> -1 on the function from me as well
-17:18 <@jmbsvicetto> I suggest we leave the bug for next meeting
-17:18 <@wired> for eapi 4[.0] anyway
-17:18 <@jmbsvicetto> the remaining bugs*
-17:18 <@Betelgeuse> jmbsvicetto: who's undecided?
-17:18 <@ferringb> jmbsvicetto: "<@Betelgeuse> no now and fast 4.1 with pkg_required_use as I described as soon as there's a need in main tree"
-17:18 <@ferringb> so -4, +1; with myself/betelgeuse advocating a hedged 4.1 if needed (others possibly also)
-17:18 <@jmbsvicetto> ok, then the votes weren't final :P
-17:19 <@jmbsvicetto> So, 4 votes no and 1 vote yes on ...
-17:19 <@Betelgeuse> jmbsvicetto: I said that before you asked if stuff is final
-17:19 <@wired> ferringb: me 2 :)
-17:19 <@jmbsvicetto> I also advocate 4.1 if needed
-17:19 <@Betelgeuse> ulm: Presumably there's text to approve for next meeting then?
-17:20 <@Betelgeuse> or just via email
-17:20 < ulm> Betelgeuse: you could approve http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=9d2b8ee57bf3be941cfdfe13650952d91b9edfdc now, if you want
-17:20 <@jmbsvicetto> so can we leave the remaining bugs for next meeting or do you have any you want to go over now?
-17:20 <@Betelgeuse> jmbsvicetto: I need to leave soon so later please
-17:21 <@jmbsvicetto> sure
-17:21 <@Betelgeuse> I suggest we all take a look at that commit and aim to approve it before end of year :)
-17:21 <@ferringb> agreed
-17:21 <@Betelgeuse> but let's handle the remaining agenda first
-17:21 <@jmbsvicetto> so when should we have our next meeting and who wants to chair it?
-17:22 <@wired> what about the 28th?
-17:22 <@jmbsvicetto> wired: ? So soon?
-17:22 <@jmbsvicetto> If we try to do it on a Tuesday again, what about 11th or 18th of January?
-17:22 <@Betelgeuse> We need to have a meeting in January any way
-17:22 <@wired> either that or agree on a voting day for eapi-4 via email
-17:22 <@wired> then we can do it on january
-17:23 <@jmbsvicetto> I say we vote on EAPI-4 by email
-17:23 <@wired> the 11th sounds good
-17:23 <@Betelgeuse> wired: I'll make sure we get input from everyone in time before the end of year
-17:23 <@wired> Betelgeuse: a deadline (say, this friday, or the 27th) would be nice
-17:23 <@jmbsvicetto> oh and here's an idea, what about a meeting on February 5th? ;)
-17:24 <@jmbsvicetto> (after the next one)
-17:24 < NeddySeagoon> heh
-17:24 <@wired> ;p
-17:24 <@Betelgeuse> jmbsvicetto: let's get the next one nailed first
-17:24 <@jmbsvicetto> sure
-17:24 <@wired> so, how's the 11th?
-17:25 <@jmbsvicetto> +1 from me
-17:25 <@wired> (tuesday)
-17:25 <@Betelgeuse> ok for me (evening UTC+2)
-17:25 <@Betelgeuse> wired: I'll come up with a schedule
-17:25 <@jmbsvicetto> what time did we meet last time? 2000 UTC?
-17:25 <@Betelgeuse> wired: (for approval)
-17:26 <@wired> 2000 UTC yeah, lets stick to that for now
-17:26 <@wired> Betelgeuse: great, thanks
-17:26 <@Chainsaw> Tuesday the 11th; 2000 UTC works well for me.
-17:26 <@Chainsaw> In favour *raises hand*
-17:26 <@jmbsvicetto> ferringb: what about you?
-17:26  * ferringb can swing 20utc
-17:26 <@jmbsvicetto> So, who wants to chair the meeting?
-17:27 <@ferringb> we'll have words if someone proposes another 15:00utc though ;)
-17:27 <@wired> heh
-17:27 <@wired> well
-17:27 <@wired> today's meeting had one advantage
-17:27 <@wired> noone had to leave
-17:27 <@wired> :)
-17:28 <@jmbsvicetto> and we had a first-time - a "car" meeting ;)
-17:28 <@wired> :P
-17:28 <@wired> oh yeah the photos
-17:28  * wired scps
-17:28 <@jmbsvicetto> no one is willing to volunteer to chair the meeting?
-17:28 <@wired> if noone else wants to
-17:28 <@wired> (beside's jmbsvicetto who just chaired)
-17:28 <@wired> i'll do it
-17:29 <@jmbsvicetto> I'd prefer not to do it next time
-17:29  * ferringb notes saturday seems to work a bit better actually
-17:29 <@Betelgeuse> I can take one too if no-one is voluntary
-17:29 <@ferringb> per wired's comments
-17:29 <@Betelgeuse> I need to go now.
-17:29 <@jmbsvicetto> So, who is going to chair it?
-17:30 <@Betelgeuse> wired: want to do it or will I?
-17:30  * NeddySeagoon notices everyone looking at jmbsvicetto 
-17:30 <@jmbsvicetto> NeddySeagoon: :P
-17:30 <@wired> Betelgeuse: i don't mind, you decide :)
-17:30 <@Betelgeuse> Ok. I'll let you :)
-17:31 <@jmbsvicetto> so, wired will chair next meeting
-17:31 <@Betelgeuse> So you can take whatever comes after I'll leave now into account :)
-17:31 <@Betelgeuse> Bye and thanks
-17:31 <@wired> heh
-17:31 <@wired> thanks, c ya
-17:31 <@jmbsvicetto> Thanks everyone. Brian thanks for taking all this at 700 AM and Alex for doing it in your car
-17:32 <@jmbsvicetto> The floor is now open. Does anyone have anything for the council?
-17:32 -!- leio_ [~leio@gentoo/developer/leio] has joined #gentoo-council
-17:33  * wired uploading proof.. err pictures :)
-17:34 <@ferringb> jmbsvicetto: 7am ain't too bad for me, it's just not always guranteed
-17:34 -!- leio [~leio@gentoo/developer/leio] has quit [Ping timeout: 272 seconds]
-17:34  * ferringb was up since 5am anyways
-17:35 <@jmbsvicetto> ok, the meeting is closed then
-17:35 <@jmbsvicetto> if anyone in the community has anything to say, just leave us a message
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110111-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20110111-summary.txt
deleted file mode 100644
index 8f14b4af1c..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110111-summary.txt
+++ /dev/null
@@ -1,99 +0,0 @@
-2011-01-11 Council meeting summary
-==================================
-
-members present:
-
-	Betelgeuse
-	bonsaikitten
-	chainsaw
-	ferringb
-	jmbsvicetto
-	scarabeus
-	wired
-
-
-Agenda:
-
-	Bugs assigned/ccd to the council, including
-		#211529 [Future EAPI] have econf run ./configure with
-			--disable-dependency-tracking and --enable-fast-install
-		#322049 use_with 3 arg specification differs in portage for $3='' 
-	EAPI 4 tree usage approval
-	Slacking arches
-
-
-New Council Member:
-	
-	Halcy0n stepped down from the council a few days before this meeting.
-	The council unanimously accepted patrick, the next in line, to fill
-	the empty seat, with this being his first meeting.
-
-
-What happened:
-
-#211529 [Future EAPI] have econf run ./configure with
-	--disable-dependency-tracking and --enable-fast-install
----------------------------------------------------------------
-
-	As summarized in the bug by Ulrich:
-
-	So, looks like the possible options are:
-	1) Only filter the warning for now, and reiterate for EAPI 5,
-		as suggested by Petteri in comment #12.
-	2) Change the spec as in attached patch.
-	3) Call ./configure --help | grep disable-dependency-tracking to
-		determine if the option is available (another idea from Diego).
-	4) Remove --disable-dependency-tracking from EAPI 4 entirely.
-
-	Petteri expressed some concern about option 3 as it would mean
-	changing an approved EAPI version. Brian and Jorge expressed the view
-	that the council can just issue a new tag and that EAPI-4 hasn't been
-	approved for use yet. No council member supported option 4. Brian and
-	Tony noted that option 2 only partially addresses the issue.
-
-	The vote turned out 6 votes for option 3 and 1 [Betelgeuse]
-	for option 1.
-
-
-#322049 use_with 3 arg specification differs in portage for $3='' 
------------------------------------------------------------------
-
-	Jorge asked for a clarification about the proposal to address this
-	bug. Brian explained that the purpose is to change EAPI 0 to 3
-	definition to state that use_with arg1 arg2 '' can't be  relied upon.
-	For EAPI 4 it can be relied on. So in EAPI 0-3, use_with arg1 arg2 ''
-	is treated as if there were two args, whilst in EAPI 4 it's treated as
-	if there were 3 arguments.
-
-	All council members approved the proposal.
-
-
-EAPI 4 tree usage approval
---------------------------
-
-	The council members decided to wait for a new portage release that
-	will include the above modifications before approving EAPI-4 for tree
-	use. Some members expressed the desire to hold the aprroval until said
-	portage release is marked stable, but no decision was made. The issue
-	will be resolved and approval will be granted via email or at the next
-	meeting.
-
-
-Slacking arches
----------------
-
-	There was some discussion about this issue, but the council members
-	decided this needs to be discussed in the -dev ml before the council
-	can decide anything about this topic.
-
-
-Next Meeting Chair
-------------------
-
-	jmbsvicetto
-
-
-Next Meeting Date
------------------
-
-	20110201 2000 UTC 
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110111.txt b/xml/htdocs/proj/en/council/meeting-logs/20110111.txt
deleted file mode 100644
index ec17c35734..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110111.txt
+++ /dev/null
@@ -1,375 +0,0 @@
-[22:01:04] *** wired changes topic to 'Meeting now | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | Agenda: http://archives.gentoo.org/gentoo-project/msg_046560a972cd72dc5b4911f07007e973.xml'
-[22:01:20] * bonsaikitten reports for duty
-[22:01:24] <wired> Betelgeuse, bonsaikitten ferringb jmbsvicetto scarabeus: ping!
-[22:01:30] <Betelgeuse> wired: pong
-[22:01:35] * scarabeus around
-[22:01:41] <jmbsvicetto> ping
-[22:02:08] <jmbsvicetto> s/ping/pong/
-[22:02:17] <ferringb> the mooning wasn't enough?
-[22:02:18] *** Joins: Chainsaw (~chainsaw@gentoo/developer/atheme.member.chainsaw)
-[22:02:31] *** Parts: bonsaikitten (~quassel@gentoo/developer/bonsaikitten)
-[22:02:33] *** Joins: bonsaikitten (~quassel@gentoo/developer/bonsaikitten)
-[22:02:38] <wired> heheh
-[22:02:51] * bonsaikitten feels the level up to level 73 wizard
-[22:03:00] <wired> great, we're all here
-[22:03:27] <wired> Let's begin. Agenda: http://archives.gentoo.org/gentoo-project/msg_046560a972cd72dc5b4911f07007e973.xml
-[22:04:11] <wired> members, please welcome bonsaikitten :D
-[22:04:25] <ferringb> slacking arches is a new one
-[22:04:29] * bonsaikitten bows
-[22:04:34] <bonsaikitten> thanks  :)
-[22:05:09] <scarabeus> bonsaikitten: enjoy your slacking ;)
-[22:05:25] <bonsaikitten> scarabeus: oh be quiet ;)
-[22:05:46] <wired> heheh
-[22:06:09] <jmbsvicetto> welcome Patrick
-[22:06:31] <scarabeus> whom is willing to update council page wrt Patrick?
-[22:06:38] <jmbsvicetto> I can do it
-[22:06:40] * ferringb points at patrick
-[22:06:51] <ferringb> he's got the least seniority now, so we should make him do the grunt work. :)
-[22:06:57] <bonsaikitten> I claim incompetence!
-[22:07:01] * wired agrees with ferringb 
-[22:07:03] <bonsaikitten> wait, no, the other thing ...
-[22:07:06] <ferringb> bonsaikitten: we all claimed that long ago ;)
-[22:07:47] <wired> so, first and primary topic for this meeting is the EAPI 4 usage approval, held back by those two bugs where we need to make a decision.
-[22:08:19] <wired> bug 211529
-[22:08:21] <willikins> wired: https://bugs.gentoo.org/211529 "[Future EAPI] have econf run ./configure with --disable-dependency-tracking and --enable-fast-install"; Gentoo Hosted Projects, PMS/EAPI; NEW; nyhm@g.o:pms-bugs@g.o
-[22:09:38] <jmbsvicetto> I'm trying to write the summary through wave (council members should have got the "invite")
-[22:09:48] <ferringb> tbh, I prefer diego's notion of just doing ./configure --help | grep the bugger
-[22:09:54] <wired> thanks jmbsvicetto 
-[22:09:58] <scarabeus> yeah i like that grep too
-[22:10:18] <wired> ferringb, that grep is a nice idea yeah
-[22:10:23] <ferringb> avoids a lot of the dodgier bits that are proposed... error filtering for example, I do *not* like
-[22:10:30] <ssuominen> --disable-dependency-tracking has been available since Automake 1.4_p3 or so.  packages generated with older automake than that, would get a QA notice of unrecognized flag.
-[22:11:30] <scarabeus> ssuominen: you can have packages that use configure but not automake
-[22:11:30] <ferringb> ssuominen: yes, automake.  we're invoking autoconf bits
-[22:11:33] <ferringb> they're seperate
-[22:11:40] <ferringb> albeit not common, but common enough
-[22:12:03] <jmbsvicetto> are we talking about comment 9 in the bug?
-[22:12:29] <scarabeus> jmbsvicetto: in last comment it is summarised quite well
-[22:13:35] <ferringb> Betelgeuse: your views?  guessing you're anti-mangle the spec?
-[22:13:36] <Betelgeuse> Option 1 allows fastest tree use.
-[22:13:36] <jmbsvicetto> so are we talking about option 3 in ulm's comment (comment 24) ?
-[22:14:13] <ferringb> Betelgeuse: option 1, 2, and 3, all are bloody quick mods to the pm; only option 1 allows the pm to avoid a release
-[22:14:18] * ferringb isn't too concerned about a release
-[22:14:42] <scarabeus> jmbsvicetto: yep
-[22:14:47] <Betelgeuse> ferringb: And option 1 isn't confusing about what EAPI 4 is.
-[22:15:04] <ferringb> eapi4 is whatever the hell we say it is before people start using it ;)
-[22:15:16] <ferringb> each eapi has had a naggle period right after it's release
-[22:15:26] <Betelgeuse> ferringb: but they have stayed the same
-[22:15:49] <jmbsvicetto> my order of preference is 2 or 3, 1. I don't want 4
-[22:15:50] <ferringb> would have to dig through history, but memory says that's not true- subtle tweaks
-[22:15:56] <Betelgeuse> ferringb: We can't revoke the tag from git.
-[22:16:09] <jmbsvicetto> Betelgeuse: nope, but we can do a new tag
-[22:16:14] <ferringb> jmbsvicetto: exactly
-[22:16:32] <jmbsvicetto> and the other bug might (will?) require us to do a new tag for EAPIs 1, 2 and 3
-[22:16:46] <Betelgeuse> I would rather focus on EAPI 5 being out in reasonable time.
-[22:17:08] <ferringb> I'd like to see 5 out in 6 months, but I know well enough it won't happen
-[22:17:09] <scarabeus> one eapi per year is quite reasonable
-[22:17:09] <Betelgeuse> Then really there's not much benefit in meddling with tags.
-[22:17:18] <ferringb> and if it does, it won't have much worth using most likely ;)
-[22:17:29] <ferringb> see eapi1, and it's level of usage for example
-[22:17:46] <wired> ferringb, thats a different topic of conversation
-[22:18:03] <ferringb> aware
-[22:18:07] <ferringb> relevant however ;)
-[22:18:13] <wired> we will need to address it at some point too :)
-[22:18:39] <jmbsvicetto> another point is "cleaning up" old EAPI versions
-[22:18:52] <ferringb> my personal views, #3, #1; #2 will only partially work
-[22:18:55] <jmbsvicetto> s/cleaning up/depreacting/
-[22:18:55] <bonsaikitten> let's focus on one issue at a time :)
-[22:19:00] <wired> indeed
-[22:19:27] <scarabeus> so someone is against #3 to be implemented?
-[22:19:33] <wired> so I think 4 is pretty much out of the question
-[22:19:33] <jmbsvicetto> ferringb: you mean 2 will only partially work?
-[22:19:58] <jmbsvicetto> ferringb: I was confused by your punctuation
-[22:20:05] <ferringb> jmbsvicetto: yes, #2 will only work
-[22:20:16] <jmbsvicetto> partially?
-[22:20:55] <ferringb> mmm.
-[22:21:20] <ferringb> don't have the scenario in front of me, diego had mentioned a failure case for it though
-[22:21:36] <ferringb> well, "spit warnings" scenario, still would work (same as the current status)
-[22:21:37] <jmbsvicetto> ok, I'm just trying to parse your comment.
-[22:21:57] <ferringb> occasionally a hard task, especially when work IRQs are occuring ;)
-[22:22:43] <wired> 3. looks like the best option to me, but 1. would work equally well since configure won't die
-[22:22:44] <jmbsvicetto> ok, after reading your point, I'd vote in order of preference 3, 2 and 1.
-[22:23:16] <jmbsvicetto> I don't think 3 should be "shot" just because it will lead to a new tag
-[22:23:17] <scarabeus> so we have 4 people in favor of option 3
-[22:23:40] <jmbsvicetto> Chainsaw: any thoughts?
-[22:24:43] <bonsaikitten> I have no strong preference, but #3 appears the sanest to me
-[22:25:48] <Chainsaw> 3 is a bit of a round-about way, but it's better than downright filtering.
-[22:26:04] <Chainsaw> 1 is a band-aid, 2 & 4 re-neg on what we've said.
-[22:26:10] <Chainsaw> 3 please.
-[22:26:36] <jmbsvicetto> wired: are we missing any "votes"?
-[22:27:05] <wired> Betelgeuse?
-[22:27:43] <Betelgeuse> wired: I prefer 1
-[22:28:01] <wired> ok
-[22:28:17] <wired> so 6 in favor of 3, 1 in favor of 1.
-[22:28:22] <wired> 3. it is
-[22:28:35] <wired> who wants to update the bug and get things going?
-[22:29:05] * ferringb reiterates the seniority thing earlier, and points at patrick >:)
-[22:29:36] <scarabeus> ferringb: you really enjoy it :P
-[22:29:43] <ferringb> yes, I'm a bastard
-[22:29:44] * wired lold
-[22:29:51] <ferringb> but damn it, it's fun ;)
-[22:30:09] <wired> bonsaikitten, you on it? :)
-[22:30:25] <ferringb> plus there is some serious humour in the seniority claim considering we all get voted in at the same time (some just have been around longer) ;)
-[22:30:26] <bonsaikitten> ferringb: I'm older than you afair ;)
-[22:30:42] <bonsaikitten> at least I have more grey hairs. sigh.
-[22:31:19] <ferringb> topic #2...
-[22:31:30] <ferringb> bug 322049
-[22:31:31] <jmbsvicetto> ferringb: actually Betelgeuse has higher seniority than us ;)
-[22:31:33] <willikins> https://bugs.gentoo.org/322049 "use_with 3 arg specification differs in portage for $3=''"; Portage Development, Core - Ebuild Support; NEW; ferringb@g.o:dev-portage@g.o
-[22:31:43] <ferringb> jmbsvicetto: yes, 'cept the question was who had lowest ;)
-[22:33:16] <scarabeus> so someone against the patch attached to the bug?
-[22:33:46] <ferringb> +1 from me
-[22:34:05] <wired> imo we could safely backport the $3 fix to all EAPIs and avoid all this, unless Im missing something
-[22:34:38] <ferringb> wired: not really
-[22:35:00] <ferringb> sure you can fix current package managers
-[22:35:34] <ferringb> the problem is that there are *old* installations out there- I can think of a couple of well maintained installs, but also a year behind gentoo-x86 for example
-[22:36:06] <jmbsvicetto> I haven't quite understood yet what is the proposal for this bug
-[22:36:16] <ferringb> textual change to eapi0-3
-[22:36:25] <ferringb> specifically stating use_with arg1 arg2 '' # can't be relied on
-[22:36:32] <ferringb> but in eapi4, it can be
-[22:36:35] <jmbsvicetto> right, so we would be "changing" EAPI 0 to 3
-[22:36:40] <ferringb> clarifying
-[22:36:50] <ferringb> implementation never matched the spec
-[22:36:59] <ferringb> grok?
-[22:37:02] <jmbsvicetto> ferringb: I thought you didn't want the "uncertainty" :P
-[22:37:10] <ferringb> this isn't uncertainty
-[22:37:20] <ferringb> it's bloody clear- you can't rely on that behaviour in eapi0-3 :)
-[22:37:37] <jmbsvicetto> ok
-[22:38:10] <ferringb> so... +1 from me at least.
-[22:38:12] <ferringb> others comments?
-[22:38:25] <jmbsvicetto> so all that we want to for EAPI 0 - 3 is to add that "use_with arg1 arg2 '' # can't be relied on", right?
-[22:38:41] <ferringb> basically.  and explicitly stating that in 4, it can be
-[22:38:46] <jmbsvicetto> for EAPI-4 '' is to be treated as the empty string?
-[22:38:52] <ferringb> es
-[22:38:54] <ferringb> *yes
-[22:39:00] <jmbsvicetto> +1 from me as well
-[22:39:04] <wired> ferringb, I see your point, agreed
-[22:39:11] <ferringb> 0-3, use_with arg1 arg2 '' # is treated as "there were two args".  in eapi4, "there were 3"
-[22:39:28] <bonsaikitten> sounds reasonable, +1 from me
-[22:39:42] * ferringb notes it's *just* for the empty string case also.  basically is a corner case oddity that slipped passed
-[22:39:58] *** Quits: apostrophe (ohnobinki@binki.ohnopublishing.net) (*.net *.split)
-[22:39:58] *** Quits: willikins (~rbot@gentoo/bot/Willikins) (*.net *.split)
-[22:39:59] *** Quits: a3li (~alex@gentoo/developer/a3li) (*.net *.split)
-[22:39:59] *** Quits: zlin (~bo@exherbo/developer/zlin) (*.net *.split)
-[22:39:59] *** Quits: [Arfrever] (~Arfrever@gentoo/developer/Arfrever) (*.net *.split)
-[22:40:14] <Betelgeuse> +1
-[22:40:38] <wired> Chainsaw, scarabeus ?
-[22:41:40] <Chainsaw> Add the caveat to the existing spec for EAPI < 3, yes.
-[22:41:42] <scarabeus> i already agreed to it
-[22:41:43] <scarabeus> :)
-[22:42:16] <wired> great
-[22:42:38] <wired> we all agree then
-[22:42:44] *** Joins: apostrophe (ohnobinki@binki.ohnopublishing.net)
-[22:42:44] *** Joins: willikins (~rbot@gentoo/bot/Willikins)
-[22:42:44] *** Joins: a3li (~alex@gentoo/developer/a3li)
-[22:42:44] *** Joins: zlin (~bo@exherbo/developer/zlin)
-[22:42:44] *** Joins: [Arfrever] (~Arfrever@gentoo/developer/Arfrever)
-[22:43:20] <Chainsaw> wired: That's a first :)
-[22:43:21] <ferringb> so... eapi4 first, or do we want to bich about mips^Wslacking arches? ;)
-[22:43:25] <ferringb> *bitch
-[22:43:30] *** Quits: a3li (~alex@gentoo/developer/a3li) (Quit: jumpin' jumpin')
-[22:43:31] <bonsaikitten> eapi4 I say
-[22:43:50] *** Joins: a3li (~alex@gentoo/developer/a3li)
-[22:43:59] <wired> bonsaikitten, are you taking care of both bugs? :)
-[22:44:19] <bonsaikitten> wired: if that makes you shut up ;)
-[22:44:21] <jmbsvicetto> bonsaikitten: no slacking for you ;)
-[22:44:47] <wired> bonsaikitten, you're so kind, I think Im gonna let you chair the next meeting too 
-[22:44:49] <wired> :D
-[22:45:05] <bonsaikitten>  \o/
-[22:45:10] <bonsaikitten> never give +o to austrians ;)
-[22:45:35] * ferringb points at california
-[22:45:47] *** Quits: willikins (~rbot@gentoo/bot/Willikins) (Ping timeout: 260 seconds)
-[22:46:09] <ferringb> ...for a more recent example
-[22:46:11] <wired> so, eapi4
-[22:46:12] <ferringb> meanwhile... eapi4?
-[22:46:47] <Betelgeuse> we need to wait for a new Portage release
-[22:46:48] <scarabeus> i would go with fixing those two bugs and having the portage stable is enough for me to feel it nice to be widely used in main tree
-[22:47:25] * ferringb honestly would give it 2 weeks or so
-[22:47:27] <wired> I don't think we need to have it stable
-[22:47:36] <ferringb> portage release yes, but I'm mainly wondering about any new last minute issues
-[22:47:46] <Betelgeuse> I would vote by email when it's out
-[22:47:50] <ferringb> exactly
-[22:49:12] <jmbsvicetto> if we don't get it sorted out until next meeting, we can quickly vote then
-[22:49:25] <wired> fix bugs, get new portage version out, if no bugs are around allow ~ usage -> the best way to iron things out
-[22:50:37] <wired> getting an eapi4 supporting portage to stable will need a month anyway
-[22:50:53] <bonsaikitten> so we'll see any issues by next meeting - sounds reasonable
-[22:50:55] <ferringb> thoughts on allowing masked usage for experimentation/exposure?
-[22:51:23] <jmbsvicetto> ferringb: it can be used on overlays for that, no?
-[22:51:23] <ferringb> masked, lacking keywords, or similar.  realistically people should just grab from an overlay/repo, but that's not how it goes
-[22:51:42] <ferringb> jmbsvicetto: could, but I'm not hugely confident it would be in the time frame I'm thinking
-[22:51:48] <Chainsaw> ferringb: Out of tree is out of sight. Hardmasked is better.
-[22:51:49] <wired> ferringb, does it really need all that screening/testing?
-[22:51:53] <bonsaikitten> lacking keywords should be enough
-[22:51:55] <jmbsvicetto> I don't think there's anything in particular that KDE could use, if not we could test it there
-[22:52:05] <ferringb> wired: imo, yes
-[22:52:09] <bonsaikitten> I think hardmasking is overkill
-[22:52:20] <ferringb> wired: fuck ups in the implementation wind up making fun situations for the spec
-[22:52:41] <jmbsvicetto> The issue with allowing in tree masked use is that some unexpected issue might affect tree parsing
-[22:52:42] <ferringb> usually since it's portage that slightly differs, which means the others have to choose between PMS compliance, or doing what portage does ;)
-[22:52:55] <ferringb> either way, it was just a thought
-[22:53:19] <bonsaikitten> jmbsvicetto: all involved package manager versions should be able to grok EAPI, so I see no issues
-[22:53:25] <wired> ferringb, we can just agree to quickly fix any implementation bugs right away, we have a clean spec for eapi4
-[22:54:04] <wired> but i can see why you're worried :)
-[22:54:08] <jmbsvicetto> bonsaikitten: after we get a stable portage version
-[22:54:36] <bonsaikitten> jmbsvicetto: why?
-[22:55:03] <jmbsvicetto> how about the cvs -> rsync box?
-[22:55:07] <bonsaikitten> the only problem I can think of is that devs with an older package manager won't be able to create manifests
-[22:55:24] <jmbsvicetto> That's the one that generates the metadata for rsync tree
-[22:55:30] <wired> jmbsvicetto, there's no requirement for a stable portage afaik
-[22:55:54] <wired> eapi3 was used in tree for a while iirc without stable support
-[22:56:03] <bonsaikitten> jmbsvicetto: so we may have to make that path a conditional for in-tree use - once it is fixed there is no reason to not allow not-keyworded ebuilds imo
-[22:56:04] <jmbsvicetto> wired: hmm, I can' recall if it wasn't required for EAPI-2
-[22:56:29] <wired> jmbsvicetto, i remember this because I wanted to stable an eapi3 ebuild (again, iirc)
-[22:56:49] <scarabeus> we should wait for portage in stable to support it
-[22:56:58] <scarabeus> so people dont whine about it
-[22:57:01] <wired> scarabeus, well
-[22:57:07] <wired> if you wait for it to go to stable
-[22:57:09] <wired> to use it
-[22:57:13] <wired> you lose a big testing phase
-[22:57:18] <Betelgeuse> indeed
-[22:57:24] <wired> do you really want to find that NASTY bug in stable?
-[22:57:27] <Betelgeuse> Portage is not really known for its QA.
-[22:57:42] <jmbsvicetto> we're talking about tree use
-[22:57:51] <jmbsvicetto> that's why in the past the testing was initially done in overlays
-[22:58:36] <jmbsvicetto> Anything else about EAPI-4 or should we move forward?
-[22:58:49] * ferringb wants his pony
-[22:58:54] <ferringb> eapi4 pony, specifically
-[22:58:58] <ferringb> (move forward)
-[22:59:05] <wired> no, lets wrap this up. bugs are fixed, new portage goes in tree, we talk over email about allowing usage
-[22:59:13] <ferringb> yep
-[22:59:16] <wired> great
-[22:59:25] <wired> final topic: slacking arches
-[23:00:15] <jmbsvicetto> who wanted to talk about it?
-[23:00:18] <scarabeus> I
-[23:00:24] <wired> this was initially requested by scarabeus, then dilfridge
-[23:00:28] <scarabeus> i would like arches to react in timely manner
-[23:00:28] <wired> so scarabeus, your floor
-[23:00:45] <scarabeus> so we have some softlimit where we can start dropping their stable keywords
-[23:00:54] <scarabeus> cause some bugs are open for around 1 year
-[23:01:00] <scarabeus> which is not particulary good
-[23:01:27] <scarabeus> so my idea would be that arch teams should stabilise OR write out reason why they cant to stable bug in 90 days
-[23:01:30] <bonsaikitten> that's actually two issues - how we can get these bugs managed, and how to get these arches up to a sane level
-[23:01:42] <scarabeus> after that it is up to maintainer whether he wants to drop the stable or not
-[23:02:42] <ssuominen> be sure to write something about 'you can't drop stable keyword from base-system, or toolchain pkgs even after 90 days is up'
-[23:03:01] <ssuominen> so it'll be clear to new devs they don't kill the whole arch :)
-[23:03:24] <scarabeus> new devs dont have access to base-system bugs
-[23:03:27] <scarabeus> usually
-[23:03:32] <ferringb> scarabeus: been a busy few weeks, but where was the ml discussion on this?
-[23:03:39] <ferringb> possible I missed it
-[23:03:50] <wired> scarabeus, you could just stop filing stable bugs for the slacking arches
-[23:04:07] <jmbsvicetto> ferringb: no discussion
-[23:04:10] <scarabeus> wired: still you have then the packages with their stable keywords to handle
-[23:04:12] <scarabeus> over irc
-[23:04:13] <wired> then, when time comes to remove the old version, you send a warning a few days earlier,
-[23:04:20] <jmbsvicetto> ferringb: slacking discussion ;)
-[23:04:26] <wired> saying your last stable version will go bye bye soon, act or lose it
-[23:05:12] <jmbsvicetto> scarabeus / wired: judging from past history I don't expect things to change much
-[23:05:26] <wired> jmbsvicetto, well, pressure works sometimes
-[23:05:34] * ferringb notes punting stable versions gets into some qa territory also, in terms of the breakage to the depgraph it can induce
-[23:05:42] <wired> jmbsvicetto, I managed to get some arches working by mailing them
-[23:05:48] <scarabeus> well basic approach is that arch should a) stable the stuff b) or loose the possibility to sable
-[23:06:02] <bonsaikitten> ferringb: that's why package plus reverse deps gets downgraded, if at all
-[23:06:09] <ferringb> lot of work
-[23:06:10] <Arfrever> scarabeus: Small suggestion: Please count days since filing of the first ignored bug. Sometimes stabilization request bug for version A after less than 90 days is replaced by bug for version B, which after less than 90 days is replaced by bug for version C... Some architecture ignores all these bugs.
-[23:06:11] <jmbsvicetto> scarabeus: that's an improvement over the old debate
-[23:06:27] <ferringb> curious, is there any specific reqs laid out to be an arch?
-[23:06:35] * ferringb isn't looking for "bugs must be dealt with in n days"
-[23:06:50] <scarabeus> there is now no specific requirement
-[23:06:52] <ferringb> but part of this problem seems to come from adhoc bits at times being added
-[23:07:06] <ssuominen> it's qa's territory in sense that we can trust people in qa to know the impact for the dropping of stable keywords for the said package
-[23:07:27] <Betelgeuse> Maybe we could automate dropping keywords for maintained arches?
-[23:07:31] <Betelgeuse> For old ebuilds.
-[23:07:47] <ferringb> Betelgeuse: signing
-[23:07:54] <Betelgeuse> eobsolete foo-1.ebuild
-[23:07:54] <ferringb> doable, just has problems there
-[23:08:00] <jmbsvicetto> ssuominen: I don't think most arches necessarily agree with the idea QA knows
-[23:08:30] <scarabeus> yes, but the problem is still around, if arch dont like loosing keywords they can find more ATs
-[23:08:48] <scarabeus> after AT test some package then any dev can stabilise it...
-[23:09:00] * ferringb needs to bail pretty quickly
-[23:09:26] <jmbsvicetto> one argument that I've seen before about this is that when this comes up people started pointing at mips or some other "minor" arch. However when one checked the bugs, amd64 could quickly come up as one of the "latest" arches to react
-[23:09:35] <ferringb> personal views, the involved parties should be discussing this on the ml, rather than it hitting our level; specifically I'd harass vapier/qa (diego?), and the folks pushing the change and try to sort out some agreement
-[23:10:07] * ferringb assumes folks understand his views on that one
-[23:10:10] <jmbsvicetto> scarabeus: if amd64 can't get enough ATs to do stable keywords itself, why do you want to require others to do that?
-[23:10:18] <ferringb> so... you've got about a minute before I'm out of here :)
-[23:10:42] <wired> next meeting, february 1st? 
-[23:10:44] <scarabeus> jmbsvicetto: amd64 is capable of fitting into that 90 days limit
-[23:11:06] <wired> ^^ lets take care of it now that we're all still here
-[23:11:08] <jmbsvicetto> scarabeus: you mean random dev doing it can get it under the 90 days? :P
-[23:11:29] <jmbsvicetto> wired: I'd suggest February 5th :P
-[23:11:36] <jmbsvicetto> wired: a FOSDEM gentoo meeting ;)
-[23:11:38] <wired> that would be a different kind of meeting
-[23:11:39] <scarabeus> we can havemeeting IRL at fosdem :D
-[23:11:46] <bonsaikitten> so I guess we postpone the "deprecate older eapis" discussion to next meeting
-[23:11:47] <jmbsvicetto> I also volunteer to be chair for next meeting
-[23:11:47] <wired> ;p
-[23:11:49] <scarabeus> technicaly most of us will be there :D
-[23:11:55] <bonsaikitten> jmbsvicetto: I'll sit on you then ;)
-[23:12:00] <scarabeus> :D
-[23:12:08] <jmbsvicetto> bonsaikitten: :P
-[23:12:24] <jmbsvicetto> we'll have 5 out of 7 council members at FOSDEM, right?
-[23:12:27] * jmbsvicetto is one
-[23:12:29] <wired> bonsaikitten, next time would be better, it wasn't on the agenda
-[23:12:32] * wired is two
-[23:12:35] <wired> ;p
-[23:12:38] * bonsaikitten is pi
-[23:12:59] * jmbsvicetto cuts bonsaikitten until it fits an integer
-[23:13:08] <jmbsvicetto> s/it/he/
-[23:13:17] * bonsaikitten feels the irrationality fading away ... darn, I wanted to use that part :(
-[23:13:26] <wired> so I'll ask again, february 1st?
-[23:13:33] <wired> (tuesday)
-[23:13:53] <jmbsvicetto> hmm, shouldn't the next meeting be on a Saturday?
-[23:14:02] <wired> not necessary
-[23:14:11] <wired> saturdays were chosen for mark
-[23:14:11] <jmbsvicetto> ferringb: 7AM? :P
-[23:14:17] <ferringb> y'all make me get up at 7am on a saturday again, I'll be at fosdem, but you won't like it.
-[23:14:25] <jmbsvicetto> hehe
-[23:14:27] <wired> hahahah
-[23:14:29] * ferringb keeps the weird hours right now for the meetings, would be nice to have something sane for a change
-[23:14:39] <ferringb> meanwhile, out of here, got a meeting in a bit
-[23:14:40] <ferringb> *poof*
-[23:14:50] <jmbsvicetto> ok, so February 1st?
-[23:14:52] <wired> no objections
-[23:15:02] <wired> so I guess yeah
-[23:15:09] <scarabeus> ook
-[23:15:11] <jmbsvicetto> scarabeus / Chainsaw / Betelgeuse  ^^
-[23:15:25] <wired> scarabeus, I think we need an ML discussion for the arches thingy
-[23:15:27] <jmbsvicetto> bonsaikitten ^^
-[23:15:37] <Betelgeuse> ok
-[23:15:44] <scarabeus> qa-mailing list?
-[23:15:46] <Betelgeuse> jmbsvicetto: 20UTC?
-[23:15:50] <jmbsvicetto> sure
-[23:15:56] <bonsaikitten> grml
-[23:16:01] <bonsaikitten> you make me subscribe to too many MLs
-[23:16:02] <bonsaikitten> :D
-[23:16:07] <wired> scarabeus, Id do it on -project or -dev
-[23:16:07] <jmbsvicetto> scarabeus: dev ml
-[23:16:21] <jmbsvicetto> scarabeus: that topic needs to be discussed on -dev
-[23:16:25] <scarabeus> ook
-[23:16:32] <scarabeus> dev it be
-[23:17:00] *** jmbsvicetto changes topic to 'Meeting now | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | Agenda: http://archives.gentoo.org/gentoo-project/msg_046560a972cd72dc5b4911f07007e973.xml | next meeting 20110101 2000UTC'
-[23:17:23] <wired> um
-[23:17:43] *** wired changes topic to 'Next meeting: 2010-02-01 2000UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | Agenda: http://archives.gentoo.org/gentoo-project/msg_046560a972cd72dc5b4911f07007e973.xml'
-[23:17:54] <wired> has to be next month :P
-[23:18:01] <jmbsvicetto> wired: oops
-[23:18:05] <wired> and next year
-[23:18:06] <wired> hahah
-[23:18:09] *** wired changes topic to 'Next meeting: 2011-02-01 2000UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | Agenda: http://archives.gentoo.org/gentoo-project/msg_046560a972cd72dc5b4911f07007e973.xml'
-[23:18:23] <wired> that was me though, Im still in 2010
-[23:18:26] <wired> :)
-[23:19:02] <jmbsvicetto> wired: so who's going to be chair? You or me? I'll do it unless you really want to do it
-[23:19:05] *** Quits: Philantrop (~Philantro@exherbo/developer/philantrop) (Quit: Philantrop)
-[23:19:37] <wired> jmbsvicetto, go ahead
-[23:19:42] <jmbsvicetto> ok
-[23:19:50] <jmbsvicetto> wired: want to open the floor?
-[23:20:00] <wired> yeah i think we're done for today
-[23:20:07] <jmbsvicetto> wired: please check the wave summary and update as you feel
-[23:20:15] <wired> yeah Im on it
-[23:20:31] <Chainsaw> Feb 1st works for me.
-[23:20:39] <Chainsaw> Sorry for my lack of reply.
-[23:21:27] <wired> no worries
-[23:21:58] <wired> We're done :)
-[23:22:03] <wired> thank you all for being here
-[23:22:14] <Chainsaw> And thanks for running the show :)
-[23:22:17] <Chainsaw> Back later.
-[23:22:29] *** Quits: Chainsaw (~chainsaw@gentoo/developer/atheme.member.chainsaw) (Remote host closed the connection)
-[23:25:40] <jmbsvicetto> Thanks wired for chairing the meeting
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110201-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20110201-summary.txt
deleted file mode 100644
index f1b30dec34..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110201-summary.txt
+++ /dev/null
@@ -1,80 +0,0 @@
-Council 2011/02/01 meeting summary
-==================================
-
-
-Agenda
-------
-
-* roll call
-
-* slacking arches
-* EAPI-4 use in the tree
-* GLEP 48 (QA)
-
-* open bugs with council involvement
-* next meeting date / chair
-* open floor - listen to the community
-
-
-Meeting
--------
-
-* roll call
-
-    here:
-
-        Betelgeuse
-        bonsaikitten
-        chainsaw
-        ferringb
-        jmbsvicetto
-        scarabeus
-        wired
-
-
-* items for discussion / vote
-
-    slacker arches
-
-        After a brief discussion about the ml thread, Jorge raised a few concerns
-        about the proposed policy increasing arch teams work and not addressing
-        the issue of lacking hardware.
-        It was decided that Tomas will write a proposal based on the ml thread
-        and that Jorge will try to talk to the arch teams and trustees to see
-        if there is or not a hardware issue and if so will try to address it.
-
-
-    EAPI-4
-
-        The council already approved and published the use of EAPI-4 for testing
-        ebuilds in the tree - mail sent by Alex.
-        While mentioning this point, Tomas recalled his question about changing
-        policy to have developers use the latest EAPI whenever possible, which
-        lead to a long discussion about deprecating EAPI versions and upgrade
-        paths, to be continued in the MLs.
-
-
-    GLEP48
-
-        There was a very long discussion about "authority" and "powers" and whether
-        QA should or not have be able to suspend developer's commit privileges.
-        No consensus was reached and as proposed in the agenda, the GLEP was sent
-        back to be updated with current requests and for further discussion on MLs.
-
-
-    Bugs assigned/cc'd to the council were pushed to the next meeting
-
-
-
-* Next meeting chair
-
-    Tomas
-
-* Next meeting date
-
-    Tuesday, 20110301 2000 UTC
-
-
-* Open floor - listen to the community
-
-    No issue was brought forward to the council
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
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110308-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20110308-summary.txt
deleted file mode 100644
index 423c79c912..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110308-summary.txt
+++ /dev/null
@@ -1,56 +0,0 @@
-Council 2011/03/08 meeting summary
-==================================
-
-Roll Call
----------
-	betelgeuse
-	patrick (dropped after first 30 mins due to connection issues, no mark)
-	chainsaw (proxied by a3li)
-	ferringb
-	jmbsvicetto
-	scarabeus (proxied for first 5 minutes by ssuominen)
-	wired
-
-Agenda
-------
-
-* Preferring latest EAPI in ebuilds
-This change should encourage developers to migrate their ebuilds to latest EAPI
-version rather than sticking to old EAPIs.
-Devmanual EAPI section will be updated so the new text reads:
-"When writing new ebuilds developers can choose whathever EAPI they think is the
-best. Using the features of the latest EAPI is encouraged."
-- Accepted by 6 ack votes (patrick, did not vote).
-
-* slacking arches
-The ongoing discussion with arch teams has already provided some good feedback.
-As we now have a better knowledge of the issues affecting arch teams, some of
-the points raised will be moved to the -project ml to expose them to a wider
-audience and to try to find solutions from the community.
-Common issues identified so far are developer burnout and lack of hardware.
-Jorge (jmbsvicetto) is now coordinating between foundation /infra /arch teams
-to see if we can define some hardware specs and get the required resources.
-
-* GLEP 48 (QA)
-After a long discussion and a review of the final proposal text, the result is
-the following:
-- vote:
-	in favor: scarabeus, ferringb, wired, jmbsvicetto
-	didn't state (abstain): betelgeuse, patrick, a3li
-Given the result, the GLEP update is accepted and can proceed, albeit Peteri
-raised a question how Devrel is going to work out the resolution after the process
-is handled over from QA. It was agreed that the part of the text (last sentence of
-the diff) will be updated with string based on what those two teams agree with
-without more council involvment (unless required otherwise).
-
-* open bugs with council involvement
-Only relevant bug is https://bugs.gentoo.org/344479.
-Brian (ferringb) is going to look to it and resolve it (given the fact the bug
-is about him so he should do it :))
-
-* next meeting date / chair
-Date to be decided on mail, Alex (wired) will send an e-mail about it.
-Chair will be Jorge (jmbsvicetto)
-
-* open floor - listen to the community
-They were really really quiet. Nobody wanted icecream.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110308.txt b/xml/htdocs/proj/en/council/meeting-logs/20110308.txt
deleted file mode 100644
index 2c27cf060f..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110308.txt
+++ /dev/null
@@ -1,546 +0,0 @@
-[21:02:53] <ssuominen> scarabeus asked me to proxy if he's too much late
-[21:03:04] * jmbsvicetto has changed topic for #gentoo-council to: "Next meeting: 20110308 2000 UTC - NOW | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | 20110201 Log and Summary now available | http://www.gentoo.org/proj/en/council/"
-[21:03:07] <ssuominen> should be here in 15 mins or so
-[21:03:15] <jmbsvicetto> So, who's here?
-[21:03:20] <Betelgeuse> I
-[21:03:21] -*- jmbsvicetto is present
-[21:03:24] <a3li> <- for chainsaw
-[21:03:24] -*- wired here
-[21:03:34] -*- ssuominen in form of scarabeus I guess :P
-[21:03:43] <ferringb> tempted to use my he-man nick for this meeting
-[21:03:50] <ferringb> and yes, present obviously
-[21:04:15] <jmbsvicetto> bonsaikitten: you're around, right?
-[21:05:40] -*- wired hums
-[21:05:42] <jmbsvicetto> so shall we start?
-[21:05:49] <wired> please
-[21:05:52] <jmbsvicetto> I'll chair the meeting until scarabeus shows up
-[21:07:44] <scarabeus> ok guys
-[21:07:47] <scarabeus> i was bit fater
-[21:07:51] <jmbsvicetto> Did Tomas send the proposed text for using the latest EAPI when comitting to the tree?
-[21:07:54] <jmbsvicetto> I can't find it
-[21:07:57] <scarabeus> no i didnt sent it
-[21:08:02] <scarabeus> i spent my time in that hospital
-[21:08:05] <jmbsvicetto> scarabeus: ok, I'll leave it for you then
-[21:08:06] <scarabeus> so nope
-[21:08:19] <scarabeus> so we will skip that step with explanation : scarabeus slacked :
-[21:08:24] <scarabeus> let me find agenda list :)
-[21:09:01] <wired> http://archives.gentoo.org/gentoo-dev-announce/msg_cc43b3abbe1d56e7b1408c226a8820e9.xml
-[21:09:05] <wired> scarabeus: ^^
-[21:09:10] <scarabeus> yep
-[21:09:11] <scarabeus> i have it
-[21:09:14] <scarabeus> in bookmarks
-[21:09:15] <scarabeus> :)
-[21:09:17] <scarabeus> ok
-[21:09:24] <Betelgeuse> Do we need anything more to vote on besides: When writing ebuilds that don't effect Portage upgrades for old machines, use the latest EAPI?
-[21:09:43] <scarabeus> Betelgeuse: no just voting it on and updating devmanual so it is policy
-[21:09:58] <scarabeus> i just didnt have time to write it in proper english
-[21:10:13] <jmbsvicetto> Betelgeuse: do we want to make it a bit more clear? Something along, "unless the package in question is part of the system set"?
-[21:10:23] <wired> + repoman warning if new version or new package?
-[21:10:47] <ferringb> alternative line of questioning
-[21:10:56] <ferringb> very, very simply phrased: why?
-[21:11:10] <ferringb> someone answer that before we proceed with voting/devmanual
-[21:11:22] <Betelgeuse> jmbsvicetto: not all of system set is needed for the upgrades to work
-[21:11:44] <Betelgeuse> ferringb: makes it easier for new developers
-[21:11:47] <ferringb> system set has a surprising tendrils.
-[21:12:07] <ferringb> *surprising.  specifically, it can wind up pulling in/referencing a large amount of stuff
-[21:12:19] <Arfrever> jmbsvicetto wanted to upgrade Python 2.6.6-r2 to EAPI="3" :) .
-[21:12:29] <jmbsvicetto> Betelgeuse: sure, but that was an exception for a "mandate", so it doesn't prevent anyone from working on packages within the system set to choose the latest EAPI if they think it's appropriate - it just "lifts" the requirement
-[21:12:39] <ferringb> as such trying to say "unless it's part of system set" is a bit daft- does this include the full graph w/ all flag permutations for system set (and it's deps) ?
-[21:13:23] <jmbsvicetto> Arfrever: I wasn't thinking about that at this point.
-[21:13:46] <jmbsvicetto> ferringb: ok, point taken. I drop my suggestion
-[21:14:18] <jmbsvicetto> I'll leave it to someone who knows how to do it to find a repoman rule that applies when it "makes sense"
-[21:14:20] <ferringb> Betelgeuse: your turn.  clarify to me how this makes it easier for new developers.
-[21:14:38] <ferringb> because with the nature of the tree, they're going to have to work with all eapi's (exempting 1, which is probably going to die in the next 6 months)
-[21:14:40] <scarabeus> ferringb: it clarifies my life when deprecating old eapis and support in eclasses for them :)
-[21:14:44] <jmbsvicetto> ferringb: In my view it goes the same lines as being able to "deprecate" EAPI versions
-[21:14:51] <ferringb> scarabeus: we're not talking about deprecating here
-[21:15:21] <ferringb> scarabeus: presuming that all new ebuilds will automatically be upgraded to version foo of eapi isn't likely in light of revbumps and other such also
-[21:15:27] <ferringb> and in light of eclasses.
-[21:15:29] <Betelgeuse> ferringb: If we require people to use the lowest EAPI that has all the features new developers use then recruiting should be much more strict about knowing the differences between EAPIs
-[21:15:43] <Betelgeuse> ferringb: If they can learn on a need to know basis it's somewhat easier.
-[21:15:48] <ferringb> Betelgeuse: if they're working in the tree, especially if they touch eclasses, they have to know eapi differences
-[21:15:54] -*- ferringb disagrees
-[21:16:03] <ferringb> it might be easier for them, but it's more dangerous to the tree's QA
-[21:16:18] <Betelgeuse> ferringb: big eclass changes should be peer reviewed
-[21:16:26] <ferringb> drop the big
-[21:16:27] <scarabeus> ferringb: even now it is mess
-[21:16:39] <Betelgeuse> ferringb: depends on how you define big of course
-[21:16:40] <ferringb> minor eclass changes can still slip by that are eapi sensitive
-[21:16:41] <scarabeus> people use eapi2/3 cases in ebuilds wiht eapi1
-[21:16:42] <scarabeus> and stuff
-[21:16:48] <scarabeus> so it is problem even now
-[21:16:53] <scarabeus> and this problem will grow
-[21:16:58] <scarabeus> with numbers of eapis we introduce
-[21:17:11] <bonsaikitten> jmbsvicetto: yes (lag ...)
-[21:17:12] <ferringb> scarabeus: not denying controlling it is an issue
-[21:17:31] <ferringb> scarabeus: what I'm specifically picking at is the justification for this "all new ebuilds must be eapi foo" as a supposed fix for that issue
-[21:17:52] <jmbsvicetto> ferringb: I wouldn't worded it as "must" but instead as "should"
-[21:17:59] <ferringb> think I pointed out fairly well that the logic that it's easier for new devs is wrong; they still need to know the eapi's that are in the tree else frankly we shouldn't be trusting their asses
-[21:18:08] <wired> ferringb: any reasons people shouldn't use latest eapi then?
-[21:18:21] <ferringb> jmbsvicetto: should becomes must in the hands of a few folk who want it that way ;)
-[21:18:25] <jmbsvicetto> ferringb: so instead of making it "mandatory", I think we should make it a "suggestion"
-[21:18:31] <scarabeus> ferringb: they can bump eapi when changing stuff
-[21:18:49] <ferringb> wired: use what's appropriate to the eclass, appropriate to the dep chain's importance, and in relation to the stability of the eapi
-[21:19:07] <ferringb> new != better for all cases, new == different
-[21:19:14] <wired> ferringb: all those are obvious exceptions, but they dont cancel the generic suggestion
-[21:19:29] <jmbsvicetto> ferringb: true, but if we approve it as "should" instead of "must", whenever someone tries to force it, they can be pointed to the policy and demonstrate it's "should" and not "must" ;)
-[21:19:29] <ferringb> wired: I reiterate; what's the actual gain of it
-[21:19:44] <ferringb> jmbsvicetto: doesn't work that way.  had a couple of wars with QA to that effect even ;)
-[21:19:51] <Betelgeuse> ferringb: I don't think we should set the bar that high for people who don't work on anything core. We should rather recruit people who are aware of their skill limits than people who think they know it all.
-[21:20:32] <ferringb> Betelgeuse: "think they know it all" is not what I said.  I expect them to know the formats they're dealing in.
-[21:20:39] <ferringb> these are users systems that get impacted after all
-[21:20:43] <ferringb> and we don't peer review every change
-[21:20:51] <ferringb> thus they should know the basics of what they're touching at the very least.
-[21:21:12] <scarabeus> ahem i sent for peer review or at least other team members review every eclass merge into main tree...
-[21:21:12] <ferringb> it's a seperate discussion to this one
-[21:21:18] <scarabeus> and it is separate issue :)
-[21:21:24] <ferringb> scarabeus: ebuilds vastly outnumber eclasses in commit count
-[21:21:51] <ferringb> even if you account for the portage "double tap" for manifest recommits ;)
-[21:21:54] <ferringb> either way
-[21:21:55] <jmbsvicetto> ferringb: I understand, but those cases can be brought to council
-[21:22:01] <Betelgeuse> ferringb: I don't think it's important when EAPI 6 is out for all developers to know 1-5
-[21:22:17] <scarabeus> yep i agree with Peteri
-[21:22:43] <Betelgeuse> 0-5 but any way
-[21:22:45] <ferringb> I rather strongly disagree
-[21:22:53] <jmbsvicetto> I agree with ferringb that this falls into the "deprecate" EAPI discussion
-[21:22:55] <ferringb> I'm not saying I expect people to know 8 different eapis
-[21:23:10] <ferringb> as jmbsvicetto just mentioned, deprecate/remove eapi's from the tree if you want to keep the count down
-[21:23:17] <jmbsvicetto> developers will have to know all EAPI versions in use at the tree at that time. I really hope there won't be 6, though
-[21:23:38] <ferringb> but frankly, I expect new devs to know the eapi's that are in use in the tree- this is basic litmus test of the dev's knowledge before we let them near the tree
-[21:23:41] <Betelgeuse> ferringb: So you want to rules for selecting an EAPI when writing ebuilds?
-[21:23:59] <Betelgeuse> ferringb: Any rule that can result in any of the in use EAPIs requires developers to know all EAPIs.
-[21:24:00] <ferringb> no ammount of arguement will convince me otherwise on the new dev angle btw, so just assume I'm being a stubborn ass on that one ;)
-[21:24:16] <scarabeus> ferringb: but people opposing ot this always say "hey dont touch my eapi i am perfectly fine with eapi1 because it has all features my ebuild currently needs"
-[21:24:18] <ferringb> Betelgeuse: what I'm trying to point out here is that the ruling that's being pushed is based on non-existant reasons
-[21:24:27] <scarabeus> this way we wont ever deprecate anything
-[21:24:46] <jmbsvicetto> ferringb: in any case, I still think we should drop the current policy that states that developers should use the lowest possible EAPI version that works and replace it with "developers are strongly urged to use the most recent EAPI version at the moment they commit that makes sense for the ebuild"
-[21:24:46] <ferringb> scarabeus: frankly, we've not had need, and no one has actually been tracking the usage up until recently
-[21:24:51] <scarabeus> with enforcing latest version it would somehow propagate itself quite conviniently and also you can see which stuff actually is updated
-[21:25:03] <scarabeus> ferringb: ahwell we did it for quite long since eapi2
-[21:25:07] <scarabeus> at least in x11 team
-[21:25:25] <scarabeus> why do you think i had so much scripts around that i just bit adjusted to work with faster pkgcore ;)
-[21:25:27] <wired> both sides have merit here, it is easier for the new dev to only know one EAPI, it is better for the tree (and possible the dev's future) if he knows all active EAPIs beforehand - otherwise he'll have to learn it later (hopefully)
-[21:25:28] <Betelgeuse> ferringb: Also nudging people to bump things hopefully makes them think if there's something how the ebuild could be improved.
-[21:25:29] <scarabeus> erm s/x11/kde/
-[21:25:30] <scarabeus> \
-[21:25:34] <Betelgeuse> ferringb: Instead of copying verbatim.
-[21:25:52] <NeddySeagoon> jmbsvicetto, careful ... thats how we got the portage/python issue on old systems
-[21:26:31] <ferringb> Betelgeuse: I could be wrong, but I suspect most devs are busy dev'ing then to be looking around for ways to polish their existing stable of ebuilds
-[21:26:31] <Betelgeuse> jmbsvicetto: What I am not really sure if that's really codified anywhere or just an opinion of some people.
-[21:26:33] <jmbsvicetto> NeddySeagoon: "that makes sense" - doing that to packages that pervent system's update, doesn't make sense to me
-[21:27:00] <Betelgeuse> ferringb: This rule is not meant to apply to existing ebuilds.
-[21:27:00] <jmbsvicetto> Betelgeuse: I recall at one point that was written in devmanual. I haven't looked in some time, though
-[21:27:12] <wired> i think we should suggest using the latest eapi whenever possible to try and move forward, but the "what new developers have to learn" issue should be handled with eapi deprecation, not this suggestion
-[21:27:21] <ferringb> Betelgeuse: heh, just the -r1 that appears to add a patch :P
-[21:27:28] <ferringb> splitting a rather fin hair there
-[21:27:37] <Betelgeuse> ferringb: that -r1 is not going directly to stable
-[21:27:38] <ferringb> *fine.  sorry, keyboard's nearing time for a replacement again
-[21:27:45] <jmbsvicetto> I think we have 3 issues going around:
-[21:27:50] <jmbsvicetto> 1. deprecating "old" eapis
-[21:27:50] <NeddySeagoon> jmbsvicetto, can you always tell?  Its one package today, something else next month and suddenly the update path has gone
-[21:28:04] <jmbsvicetto> 2. setting a suggestion or rule about the EAPI version to use when commiting an ebuild
-[21:28:28] <jmbsvicetto> 3. whether a non-maintainer might push an EAPI bump during a commit
-[21:28:41] <ferringb> strike #3
-[21:28:52] <jmbsvicetto> I think some people are worried about 3. In my view, we already have a general rule about 3 and shouldn't make special rules for EAPI
-[21:29:01] <ferringb> non-maintainer pulling that without asking the maintainer is already across the line
-[21:29:08] <Betelgeuse> indeed
-[21:29:22] <scarabeus> #3 is banned
-[21:29:32] <Amynka> hi
-[21:29:34] <scarabeus> expect if council asks qa to deprecate some eapi as whole :)
-[21:29:58] <ferringb> scarabeus: if deprecation of an eapi is desired... 1) gentoo-dev ml, 2) then council.
-[21:30:01] <Betelgeuse> scarabeus: mass actions also have working policies already
-[21:30:04] <ferringb> I'm not opposed to deprecating eapis also
-[21:30:16] <ferringb> either way; potential compromise
-[21:30:30] <ferringb> the "lowest version available" thing, punt it as far as I'm concerned
-[21:30:38] <jmbsvicetto> NeddySeagoon: yes, but that raises another issue that has we've been circling around and have yet to make a decision. How strongly do we want to allow for long term system updates and what timeline do we want to set for it? The rule still in effect is 1 year, but I don't think anyone is making sure that is actually real
-[21:30:45] <ferringb> controlling the population count of which eapi's are in use, leave it up to maintainers
-[21:30:59] <ferringb> they know when it makes sense for their particular area to migrate forward to a new eapi
-[21:31:21] <ferringb> and from a PM standpoint, we're not really that hard pressed to support the variations
-[21:31:40] <NeddySeagoon> jmbsvicetto, its a related issue.  Sorry for the disruption
-[21:32:06] <wired> ferringb: not necessarilly true, new eapi features dont ensure that devs will use them even if they are useful :)
-[21:32:13] <jmbsvicetto> NeddySeagoon: no disruption and you're right. I just meant it's a separate issue, but it's tied to EAPI usage in tree
-[21:32:16] <ferringb> wired: when the features are useful, yes
-[21:32:30] <ferringb> wired: other times we're formalizing things or adding some bit that someone in particular needs
-[21:32:34] <ferringb> eapi1 is a good example of that
-[21:32:41] <jmbsvicetto> wired: I'd argue that if an EAPI is useful, people will want to use it.
-[21:32:51] <ferringb> it was dead on arrival, and buried when eapi2 landed
-[21:33:03] <ferringb> jmbsvicetto: that's kind of my view
-[21:33:07] <jmbsvicetto> wired: Just because an EAPI as "whistles and bells" doesn't mean it's "useful" for particular developers and or teams
-[21:33:15] <ferringb> arbitrary nudging people to go to latest presumes it's greatest
-[21:33:26] <scarabeus> well it should be
-[21:33:29] <ferringb> I presume not all EAPI's are created equal, let alone the PM support. ;)
-[21:33:39] <ferringb> scarabeus: yeah, reality is a whole other thing however
-[21:34:03] <jmbsvicetto> ferringb: up to this point I'd say 1 and 2 were the most useful
-[21:34:05] <scarabeus> i am 8n ebuilds away from dropping support for eapi1 in cmake-utils :)
-[21:34:13] <Betelgeuse> "When writing new ebuilds developers can choose whathever EAPI they think is the best. Using the features of the latest EAPI is encouraged."?
-[21:34:13] <ferringb> either way, I'm fine w/ striking the "must be lowest that can do what they need", but I oppose changing it to the opposite end of the spectrum "should use latest it can"
-[21:34:25] <jmbsvicetto> Betelgeuse: that sounds good to me
-[21:34:28] <ferringb> jmbsvicetto: I'd like to see folk on 3 for prefix reasons, but that's a seperate discussion
-[21:34:40] <jmbsvicetto> Betelgeuse: perhaps just adding "when it makes sense"
-[21:35:08] <ferringb> Betelgeuse: += "... except for EAPI1.  it's the ginger child of the bunch."
-[21:35:23] <ferringb> pardon to any redheads for that joke.
-[21:35:35] <jmbsvicetto> ferringb: sure. 3 is very useful for prefix, but ignoring prefix, it didn't provide many useful features for me as an individual developer
-[21:35:42] <ferringb> Betelgeuse: encouraged, but not required
-[21:36:04] <scarabeus> ok lads
-[21:36:07] <scarabeus> 30 mins passed
-[21:36:12] <scarabeus> so lets move to next topic
-[21:36:27] <scarabeus> but lets agree with dropping the deprecating that lowest preffered
-[21:36:34] <scarabeus> and adding something among what peteri sent
-[21:36:44] <ferringb> +1 for dropping lowest, +1 for text mentioned.
-[21:36:46] <jmbsvicetto> I agree with both
-[21:36:46] <ferringb> others?
-[21:36:47] <wired> +1 on Peteri's wording
-[21:37:06] <jmbsvicetto> wired: and droppping any mention to "oldest preferred"?
-[21:37:25] <scarabeus> bonsaikitten: ^
-[21:37:28] <wired> jmbsvicetto: yes
-[21:37:37] <Betelgeuse> yes to both
-[21:37:47] <ferringb> hm.  20m idle on bonsai...
-[21:38:04] <jmbsvicetto> ferringb: he seems to be on a very slow link
-[21:38:16] <jmbsvicetto> a3li: ^^
-[21:38:17] <a3li> I'd say dropping the 'oldest' is fine as long as noone is forced to update just for the sake of updating. so betelguese's text sounds good
-[21:38:24] <ferringb> jmbsvicetto: what, moon and back? ;)
-[21:38:30] <jmbsvicetto> :)
-[21:38:42] <wired> ferringb: mars
-[21:38:55] <ferringb> wired: something like an hour, but I was thinking that route initially ;)
-[21:38:59] <jmbsvicetto> scarabeus: you haven't expressed your vote yet
-[21:39:07] <scarabeus> ah +1 on both
-[21:39:30] <scarabeus> we can say then unanimous acceptance?
-[21:39:36] <jmbsvicetto> so, 6 votes for both and we're just missing bonsaikitten?
-[21:39:41] <scarabeus> oh patrick lacking
-[21:39:57] <ferringb> bonsai is irrelevant at this point vote count wise
-[21:40:02] <jmbsvicetto> scarabeus: let's move on. He can express his vote until the end of the meeting
-[21:40:08] <ferringb> extract his +1/-1 later for official total
-[21:40:17] <scarabeus> ok
-[21:40:27] <scarabeus> step two will be Jorge doing lot of talk
-[21:40:38] <scarabeus> as he is the mastermind for the stable arches discussions :)
-[21:40:45] <jmbsvicetto> scarabeus: my talking won't be about that policy but about the discussion ;)
-[21:40:49] <scarabeus> :DD
-[21:40:53] <scarabeus> eeexcuses
-[21:40:57] <jmbsvicetto> :)
-[21:41:01] <jmbsvicetto> want me to start?
-[21:41:17] <ferringb> just a thought... do we have the various arch leads available?
-[21:41:37] <scarabeus> jmbsvicetto: sure go ahead
-[21:41:45] <jmbsvicetto> ferringb: that would lead me to the following question: how many arches have been electing their leads as they should?
-[21:41:54] <scarabeus> ferringb: i think some teams dont have lead or keep honorary one :)
-[21:42:11] <ferringb> s/arch lead/arch sacrifical lamb/
-[21:42:27] <jmbsvicetto> I think you must have noticed all the "flodding" I did to your inboxes
-[21:42:29] <ferringb> meant moreso, someone who is active in an arch and can speak for it formally or informally
-[21:42:32] <ferringb> yeah
-[21:42:49] <wired> jmbsvicetto: you're being modest now :P
-[21:43:02] <jmbsvicetto> I think the discussion has brought forward a few good points that I'll try to pursue until next meeting
-[21:43:10] <jmbsvicetto> wired: ;)
-[21:44:32] <jmbsvicetto> I think the council needs to discuss with arch teams, infra and trustees if we want new hardware, hardware specs and see what we can get
-[21:45:29] <jmbsvicetto> There's also the issue of statistics and how to recruit, motivate and keep people working on arch teams
-[21:45:55] <jmbsvicetto> I don't know if you're interested in the rest of the dicussion or if it should be left for arch teams, infra, trustees and interested developers
-[21:46:29] <scarabeus> i dont think all of us needs to be in loop, i honestly tried to read all those mails tho :)
-[21:46:35] <jmbsvicetto> Before we can discuss hardware, we must complete the discussion about hardware requirements
-[21:46:51] <ferringb> jmbsvicetto: soft ice cream machine is desperatly needed
-[21:46:53] <ferringb> (it's hardware)
-[21:47:04] <jmbsvicetto> I don't mind reporting back conclusions of that discussion. In any case, you're CC'ed so you can be in the loop if you want
-[21:47:13] <jmbsvicetto> ferringb: :)
-[21:47:57] <ferringb> fine by me
-[21:48:00] <jmbsvicetto> scarabeus: about the arches policies, given the current status of the discussion, I don't know if you want to hold it off a bit more, or if you want to set a few general rules that can be reviewed depending how the discussion turns out
-[21:48:23] <jmbsvicetto> s/arches policies/slacking arches policy/
-[21:49:08] <jmbsvicetto> Does any of you want to get involved in the statistics and or developer burnout points?
-[21:49:23] <scarabeus> jmbsvicetto: those things are quite interesting
-[21:49:30] <ferringb> what, to provide ourselves as examples of burnouts? ;)
-[21:49:32] <scarabeus> so -project should be hit with those numbers
-[21:49:55] <jmbsvicetto> we don't have numbers yet. The discussion is about how to get those numbers
-[21:50:14] <jmbsvicetto> in any case, I think we should move some of those discussions to project to see what comes out of them
-[21:50:20] <ferringb> yep
-[21:50:47] <jmbsvicetto> unless you want any more details, I think that's what I have to say at this point about the ongoing discussion
-[21:51:05] <wired> jmbsvicetto: Id like to get involved with that
-[21:51:33] <scarabeus> wired: whats preventing you? (sorry this just hit my mind first when you wrote that)
-[21:51:50] <wired> hahah
-[21:52:00] <jmbsvicetto> wired: what part? all of it?
-[21:52:01] <wired> (lack of) time with most of the things id like to do
-[21:52:28] <wired> jmbsvicetto: ideally everything, but I was referring to the statistics
-[21:52:36] <jmbsvicetto> wired: Feel free to step in at any time
-[21:52:42] <jmbsvicetto> wired: great :)
-[21:53:14] <jmbsvicetto> Oh, I forgot one point which is the testing platform / framework / whatever
-[21:53:38] <wired> jmbsvicetto: thats what we need the most /me thinks
-[21:53:44] <jmbsvicetto> I'll try to start a discussion from releng with infra, QA and interested developers (grobian I didn't forgot you) and then move it to the mls
-[21:54:09] <jmbsvicetto> That's something I really want to be involved in
-[21:54:21] <ferringb> have at it as far as I'm concerned.
-[21:54:32] <wired> +automated
-[21:54:35] <jmbsvicetto> yes
-[21:54:40] <jmbsvicetto> *automated*
-[21:54:57] <scarabeus> so alles?
-[21:55:00] <wired> ideally every commit would have to go through that system
-[21:55:02] <wired> :p
-[21:55:19] <scarabeus> ha-ha
-[21:55:24] <scarabeus> stable tinderbox would be cool :)
-[21:55:29] <ferringb> next point?
-[21:55:33] <jmbsvicetto> stable and testing ;)
-[21:55:34] <scarabeus> yep
-[21:55:40] <ferringb> thanks.  work and such.
-[21:55:56] <scarabeus> yeah jorge writes hell lot of mails nowdays :P
-[21:55:59] <scarabeus> thanks for that :D
-[21:56:07] <jmbsvicetto> hehe
-[21:56:16] <scarabeus> so QA glepie update
-[21:56:23] <scarabeus> thats probably me talkking
-[21:56:27] <scarabeus> so the diff: http://dev.gentoo.org/~scarabeus/glep-0048.diff
-[21:56:40] <scarabeus> and ignore the whitespace, it is not part of it
-[21:56:57] <scarabeus> wording was updated at fosdem to please many
-[21:57:15] <ferringb> wordings fine.
-[21:57:20] <ferringb> anyone have issues with it?
-[21:57:21] <scarabeus> so some really oppsing voices against this, or can we vote on it
-[21:57:34] <scarabeus> *opposing
-[21:57:47] <scarabeus> (i need new keyboard, someone wants to donate me one? :))
-[21:58:07] <ferringb> scarabeus: you can have my (soon to be) old laptop keyboard.  have fun w/ the l, g, and h key.
-[21:58:27] <jmbsvicetto> scarabeus: I'm fine with that wording
-[21:58:31] <ferringb> +1 from me.
-[21:58:48] <scarabeus> +1 from me obviously
-[21:59:00] <scarabeus> bonsaikitten, Betelgeuse, wired
-[21:59:10] <a3li> why was that 4-month rule removed? because the new recruiting rules imply the lead will enforce that anway?
-[21:59:26] <ferringb> because someone got bitchy about a candidate who was 3.75 months showing up.
-[21:59:26] <wired> the deputy thingie sounds weird and I still think the whole thing could use some rethinking, but +1 for now
-[21:59:32] <ferringb> and 4 months is an arbitrary period.
-[22:00:11] -*- ferringb notes the 4 months isn't going to stop someone from behaving as QA anyways
-[22:00:11] <jmbsvicetto> a3li: the idea was to drop the "time" requirement and replace it with the "knowledge" requirement
-[22:00:19] <ferringb> it just means that an actual QA member has to follow them around and back them up
-[22:00:37] <a3li> jmbsvicetto: sounds reasonable
-[22:00:48] <Betelgeuse> scarabeus: I still don't think it's wise to hardcode infra.
-[22:01:01] <Betelgeuse> I don't see why Infra needs to be involved.
-[22:01:24] <ferringb> I prefer infra
-[22:01:47] <Betelgeuse> ferringb: How does it matter who does it?
-[22:01:58] <ferringb> I'd frankly much more prefer it if QA/devrel/infra were equivalent in power, rather than lumping things in so that devrel is the decider, infra the implementer, and qa the recommendor
-[22:02:28] <ferringb> Betelgeuse: if it's not explict they can go through infra, then the channel they'll get stuck with is devrel
-[22:02:34] <ferringb> as said, I don't like that many eggs in one basket
-[22:02:48] <Betelgeuse> ferringb: My points it should rather be anyone with ability to suspend access.
-[22:02:53] <Betelgeuse> s/points/point/
-[22:03:19] <ferringb> then hard code devrel or infra.
-[22:03:21] <jmbsvicetto> ferringb: I agree with Betelgeuse that leaving it up to "anyone" who can do it doesn't impose any "limites"
-[22:03:30] <jmbsvicetto> sorry, s/"limites"/"limits"
-[22:03:52] <ferringb> jmbsvicetto: I'd say to some degree it does- in the past if it wasn't codified, it defaulted to devrel
-[22:04:05] <ferringb> either way
-[22:04:10] <ferringb> I want it explicit either can do it
-[22:04:37] <ferringb> seems we're agreed, I'm just pushing for explicit "infra can pull the trigger if asked"- grok?
-[22:05:25] <scarabeus> so wording should be what
-[22:05:37] <jmbsvicetto> ferringb: I agree with either one can do it
-[22:05:55] <ferringb> scarabeus: "either infra or devrel, and they don't have to agree"
-[22:06:20] <ferringb> and yes, that opens up a fun question there ;)
-[22:07:24] <ferringb> comments?
-[22:07:35] <scarabeus> ... suspended by anyone with such privileges, pending analy...
-[22:07:36] <ferringb> or has all the EU folk passed out ;)
-[22:07:45] <scarabeus> i was inventing wording
-[22:08:05] <scarabeus> ??
-[22:08:07] <ferringb> ...suspended by anyone with such privileges (currently infra and devrel), pending...
-[22:08:18] <ferringb> note the 'explicit' part I'm being a stubborn mule about
-[22:08:22] <jmbsvicetto> ^^ +1
-[22:08:25] <a3li> k
-[22:08:33] <wired> sounds good
-[22:09:01] <ferringb> +1 from me obviously
-[22:09:14] <jmbsvicetto> ferringb: I know this might create some "tension" in the future between QA and devrel, but I think it can also help us to react quicker in "extreme cases"
-[22:09:23] <scarabeus> se upated link
-[22:09:39] <scarabeus> see
-[22:09:51] <a3li> then, there's me asking stupid questions again: why was the lead-or-two-members thing made?
-[22:10:11] <ferringb> jmbsvicetto: I'm not saying they should be at each others throats, but I don't hugely mind them being seperated and not always agreeing.  I get concerned when it's concentrated in one, or they're both ran by the same person/cadre
-[22:10:16] <wired> a3li: quicker response iirc
-[22:10:23] <scarabeus> a3li: because we can just say shut him without providing any feedback or reason
-[22:10:25] <a3li> wired: well, there's a lead and a deputy
-[22:10:33] <scarabeus> a3li: and do it later
-[22:10:38] <jmbsvicetto> scarabeus: +1 from me
-[22:10:44] <jmbsvicetto> ferringb: I understand and agree
-[22:11:11] <a3li> scarabeus: revoking permissions without needing to provide a reason sounds prone to abuse to me
-[22:11:28] <jmbsvicetto> a3li: the reason was to speed up reaction in case the lead and deputy aren't available at one point
-[22:11:41] <ferringb> a3li: someone may abuse their rights, yes.
-[22:11:42] <scarabeus> a3li: just imagine we would not have good reason, council would eat up qa for dinner in such case
-[22:11:54] <ferringb> a3li: it's a fair bet they'll get their asses spanked 5 minutes later by the rest of us however
-[22:12:17] <scarabeus> (i wrote that sentence as qa member)
-[22:12:20] <ferringb> can't make it perfect, have to rely on some checks/balances
-[22:12:38] <a3li> jmbsvicetto: well two leads is a sufficient rate of availability imo
-[22:12:48] <jmbsvicetto> a3li: in the past it wasn't
-[22:12:48] <a3li> ferringb: how about explicitly stating action in case of abuse in there then?
-[22:13:23] <scarabeus> a3li: we can update the wording if it gets abused, come on, we dont plan to suspend acess for 11 people tomorow :D
-[22:13:23] <jmbsvicetto> a3li: I don't think that's needed. Besides council being able to review the policy, any such abuses will constitute matter for a devrel process
-[22:13:38] <a3li> that goes in line with my question 2b) what happens if QA fails to provide reasoning in these 14 days?
-[22:13:52] <a3li> or that analysis
-[22:15:02] <scarabeus> usually we don't use the what if cases in those documents so far i could see, but common sense gives us pretty angry devrel on one side, angry developer on other, and really fcked up qa in the middle
-[22:15:17] <jmbsvicetto> My opinion is that would lead to an immediate reversal of the commit privileges removal and a devrel case
-[22:15:38] <jmbsvicetto> but there are ways to deal with that already
-[22:15:49] <scarabeus> where devrel already have some rules how to proceed when someone abuses power, so the qa member whom did froze it and didnt provide rest stuff is going to be deep fried
-[22:16:11] <a3li> scarabeus: have a link handy?
-[22:17:04] <ferringb> a3li: qa fails to provide cause in 14 days, and frankly no one cares, well, there is your answer
-[22:17:18] <ferringb> a3li: qa fails to provide cause in 14 days, people care, one way or another devrel/council winds up involved
-[22:17:35] <ferringb> (by "no one cares" I mean "no one cares nor disagress")
-[22:18:19] <a3li> ferringb: it's a bit too implicit for me as well, given that the rest of the thing is rather verbose
-[22:18:25] <ferringb> a3li: here's the thing
-[22:18:41] <ferringb> a3li: you start trying to lock everything down into rules, you provide manuevering room for trolls to play games
-[22:18:48] <Betelgeuse> If we want a fully documented way of acting then just leave it to devrel like currently: http://www.gentoo.org/proj/en/devrel/policy.xml
-[22:18:50] <ferringb> it makes a bad situation worse
-[22:19:22] <ferringb> a3li: enough is there imo to run with it, and make it work- and if it *doesn't* work, there are feedback mechanisms implicitly in place that means people will get very, very pissed
-[22:19:40] <ferringb> said pissed people will be sorting it (devrel/council among others)
-[22:20:11] <ferringb> that's, in my experience having been around these occurences, better than trying to codify each/every scenario
-[22:20:13] <jmbsvicetto> scarabeus: Did you count the votes?
-[22:20:18] <ferringb> if you still disagree, then go read some godel :P
-[22:20:24] <ferringb> count's 4 if memory serves
-[22:20:31] <scarabeus> yeah i have 4x aye
-[22:20:43] <ferringb> scarabeus: you were a +1?
-[22:20:44] <scarabeus> but i preffer to have all ayes possible
-[22:20:50] <jmbsvicetto> who's missing?
-[22:20:51] <ferringb> yeah, full tally is needed
-[22:21:01] <jmbsvicetto> a3li, Betelgeuse, bonsaikitten?
-[22:21:01] <ferringb> bonsai on both votes, betelgeuse in this case
-[22:21:36] <scarabeus> ah it is 3, a3li didnt vote too :)
-[22:21:41] <scarabeus> so what jorge said
-[22:22:00] <jmbsvicetto> scarabeus: then were missing 4: wired?
-[22:22:00] <ferringb> jmbsvicetto, me, wired.
-[22:22:03] <ferringb> scarabeus: your vote?
-[22:22:10] <scarabeus> i said previously +1
-[22:22:12] <scarabeus> so yep
-[22:22:21] <ferringb> wired: "sounds good" == +1?
-[22:22:29] <wired> yes +1
-[22:22:31] <a3li> ferringb: well, having everything set in stone is no good indeed. I find that part to be important though
-[22:22:36] <jmbsvicetto> a3li / Betelgeuse: what about you?
-[22:22:56] <ferringb> a3li: you should tangle someday with a troll who should've been a lawyer then
-[22:23:01] <ferringb> a3li: it'll break you of that view. :)
-[22:23:10] <a3li> as for voting, is there something like like abstention?
-[22:23:12] <scarabeus> ferringb: hehehe :)
-[22:23:16] <scarabeus> a3li: there is :)
-[22:23:22] <a3li> then that'll be my vote
-[22:23:44] <ferringb> mmm. crap.
-[22:23:48] <ferringb> inconclusive count
-[22:23:57] <Betelgeuse> scarabeus: Is the text meant to say that devrel will do the follow up by their own rules?
-[22:23:59] <ferringb> oh right, 4
-[22:24:04] <scarabeus> jorge, brian, alex, tomas = yes
-[22:24:04] <scarabeus> alex = abstain
-[22:24:07] <scarabeus> == accepted
-[22:24:19] <Betelgeuse> I am not sure what compromise would mean in practise.
-[22:24:30] <Betelgeuse> It implies some kind of acceptance from QA too.
-[22:24:37] <scarabeus> Betelgeuse: it is then handled by you
-[22:24:46] <jmbsvicetto> Betelgeuse: iirc, QA will make its case and present it to devrel.
-[22:24:57] <jmbsvicetto> scarabeus: ^^ wasn't that the proposal?
-[22:25:07] <scarabeus> yes
-[22:25:08] <Betelgeuse> scarabeus: Maybe we change the text to "Devrel will then handle it according to their own policyt" ?
-[22:25:35] <ferringb> I'm not a fan of devrel reversing QA opinion according to their own policies
-[22:25:42] <ferringb> it's contrary to purposes
-[22:25:54] <Betelgeuse> ferringb: Why involve devrel if they can't do anything?
-[22:26:02] <ferringb> Betelgeuse: I'm not saying they can't be involved
-[22:26:07] <ferringb> I'm just stating my main concern here, grok?
-[22:26:13] <scarabeus> Betelgeuse: devrel should then review just if qa didnt violate some dev rights but technical standpoint is basis for qa decision
-[22:26:42] <ferringb> alternatively, what do qa/devrel want their relationship/handling in this case to be?
-[22:26:47] <ferringb> (agreed to by both sides)
-[22:27:01] <ferringb> they're the ones who have to live by it after all
-[22:27:12] <jmbsvicetto> ferringb: if QA doesn't like the way devrel proceeds, they can always approach council
-[22:27:18] <jmbsvicetto> ferringb: checks and balances
-[22:27:46] <ferringb> jmbsvicetto: I'd rather they sort this particular channel out themselves and get the sign off on council, rather than council saying "here's how it is, enjoy" and having them come back
-[22:27:52] <scarabeus> Betelgeuse: i thought it more like devrel reviews what qa did and look if they didnt do big screwup :)
-[22:28:45] <Betelgeuse> scarabeus: the current text doesn't say that
-[22:28:51] <ferringb> yeah, I was noticing that
-[22:29:05] <scarabeus> ok so how do you read current one
-[22:29:07] <ferringb> last action didn't go that route if memory serves, but I could be wrong (and the doc could've changed since)
-[22:29:23] <Betelgeuse> scarabeus: revoke or find something that QA agrees to
-[22:29:54] <ferringb> doesn't really handle the case of devrel converting something into a suspension
-[22:30:11] <ferringb> although again, I strongly think the two groups should sort this out themselves since they have to live by it
-[22:30:24] <Betelgeuse> ferringb: That's I made the point of just using DevRel policy which addresses things like suspension
-[22:30:26] <ferringb> we sign off if it's sane, but they figure out the working relationship for that case.
-[22:30:49] <scarabeus> Betelgeuse: we can discuss this off between us two how to handle it cause we are up time for this section :)
-[22:30:55] <ferringb> Betelgeuse: with respect, QA hasn't seemed all that happy w/ devrel policy in application here
-[22:31:03] <Betelgeuse> ferringb: they haven't
-[22:31:11] <scarabeus> we weren't
-[22:31:15] <ferringb> thus... go figure it out
-[22:31:27] <ferringb> come back when one of y'all has beat the other one up, or you've got a working proposal
-[22:31:53] <ferringb> dictacting terms just means this goes boom the next time QA has to move on something (or devrel thinks QA is being powermad)
-[22:31:57] <Betelgeuse> i am fine with what scarabeus said.
-[22:32:35] <ferringb> qa owns the tech, devrel makes sure they're not being power mad; basically?
-[22:32:56] <Betelgeuse> ferringb: Cases like this are about never just about tech.
-[22:33:07] <ferringb> aware
-[22:33:27] <ferringb> but usually one can point to some pretty fucked up commits (tech) backing the claim of bad behaviour/not caring
-[22:33:33] <ferringb> eenie meenie
-[22:33:36] <jmbsvicetto> I need to leave now. I'll read the backlog later
-[22:33:47] <jmbsvicetto> I vonlunteer for being chair for next meeting
-[22:34:06] <scarabeus> ook if we wont find anyone else you will be :P
-[22:34:09] <wired> can we set a date before you go?
-[22:34:28] <scarabeus> i would go with 5.4.?
-[22:34:33] <ferringb> err
-[22:34:37] <ferringb> right, EU
-[22:34:43] -*- ferringb prefers 04/01
-[22:34:53] <scarabeus> mm/dd?
-[22:34:56] <ferringb> yep
-[22:35:02] <scarabeus> friday
-[22:35:02] <ferringb> many possibilities.
-[22:35:05] <wired> friday?
-[22:35:10] <scarabeus> PUB!?!?
-[22:35:16] <ferringb> awww
-[22:35:39] <scarabeus> but i can jus tbe there so no bigge
-[22:35:45] <scarabeus> 1. works for me, at this time
-[22:35:53] <scarabeus> ferringb: or you would preffer different time too ?
-[22:36:03] <ferringb> scarabeus: this one, I'm more intent to have it land on april fools day
-[22:36:11] <ferringb> purely for the 04/01 angle
-[22:36:12] <wired>  the first of the month could be an issue for me, but I cant tell now
-[22:36:13] <wired> hahahah
-[22:36:20] <wired> ferringb: nice ;p
-[22:37:13] -*- ferringb is fine with the 20 utc time if needs be, date's flexible
-[22:37:17] <ferringb> Betelgeuse: still around?
-[22:37:58] <scarabeus> ferringb: ok i am for it :)
-[22:38:02] <scarabeus> sounds fun
-[22:38:37] <ferringb> well, just a notion- will try to bring it up in the coming weeks
-[22:38:56] <Betelgeuse> ferringb: yes
-[22:38:57] <ferringb> QA's gleppified in terms of role/purpose
-[22:39:12] <ferringb> Betelgeuse: I'd like to extract the current devrel version of it y'all have into a glep
-[22:39:28] <Betelgeuse> ferringb: yeah I started a thread about that on gentoo-project
-[22:39:33] <ferringb> 'k, thanks
-[22:39:44] <Betelgeuse> ferringb: So we could put it to the next meeting
-[22:39:49] <scarabeus> yep sounds nice
-[22:39:54] <ferringb> not looking to lock down all details, just lock down the boundaries/range same as has been done for QA
-[22:40:07] <scarabeus> Betelgeuse: and we two need to talk about the wording of last sentence to reflect what i said and ment,
-[22:40:12] <scarabeus> any wordings anyone?
-[22:40:19] <scarabeus> i sucks in expressing my thoughts obviously
-[22:40:30] <scarabeus> (i sucks even in my native language, its not limited to english :D)
-[22:40:41] <ferringb> scarabeus: go with pseudocode
-[22:40:56] <scarabeus> ferringb: that i do so often :D
-[22:41:25] <scarabeus> anyway lets close this since we agreed on this topic and only tiny stuff is needed to be delt with between me and Peteri
-[22:41:35] <scarabeus> and move to the bugs
-[22:41:40] <scarabeus> which is actualy A bug
-[22:41:46] <scarabeus> which involves you Brian
-[22:41:51] <scarabeus> bug 344479
-[22:41:55] <willikins> scarabeus: https://bugs.gentoo.org/344479 "Slacker point for ferringb"; Gentoo Linux, Unspecified; NEW; tove:council
-[22:41:55] <ferringb> scarabeus: you, or diego?
-[22:42:09] <ferringb> eh?
-[22:42:15] <scarabeus> ferringb: that deputy part is done so i can act as lead if you didnt figure out yet :D
-[22:42:22] <Betelgeuse> scarabeus: Any objections from QA to just fall on DevRel policy?
-[22:43:32] <ferringb> if I'm going to get a slacker point for forgetting an email, well, y'all are going down with me
-[22:43:47] <ferringb> (not because I'll take you down, but because it happens a lot... meaning we should automate the fucking thing)
-[22:43:52] <scarabeus> ferringb: i am not saying that, i want to see what to do with it :)
-[22:43:55] <ferringb> either way, y'all decide if you want to spank me
-[22:43:59] <scarabeus> ferringb: and i deserve the same
-[22:44:00] <ferringb> <-- work
-[22:44:08] <scarabeus> ferringb: i sent it 3 days in advance so i violated it too
-[22:44:32] <ferringb> think a better notion is to just automate the bugger rather than trying to spank folk
-[22:44:38] <scarabeus> Betelgeuse: well if you guys will take into effect the qa resolution and act upon it
-[22:44:41] <ferringb> although that requires calendaring
-[22:44:51] <ferringb> either way, want to get lunch prior to meeting, thus...
-[22:44:52] <ferringb> <-- work
-[22:44:58] <Betelgeuse> I don't think we can give a slacker mark in the sense of GLEP 39
-[22:45:04] <Betelgeuse> But you can do some slapping around.
-[22:45:15] <ferringb> might just enjoy it.
-[22:45:21] <ferringb> beware the creepy guy.
-[22:45:37] -*- wired slaps ferringb around
-[22:46:01] <scarabeus> ok i think we wont do any resolution apart from "happens and should not" for now
-[22:46:08] <ferringb> hmm. gimp nick is in use.
-[22:46:08] <scarabeus> and someone should close the bug
-[22:46:24] <scarabeus> i would go with ferringb himself should close it and explain/appologise :P
-[22:46:29] <ferringb> scarabeus: council calendaring + automated emails is the dependency there
-[22:46:31] <scarabeus> till next meeting
-[22:47:10] <Betelgeuse> scarabeus: I am not really sure how the GLEP 48 vote ended
-[22:47:17] <Betelgeuse> any way I get to inspect the summary I guess :)
-[22:47:38] <scarabeus> :-)
-[22:47:57] -*- wired has to go
-[22:48:16] <scarabeus> Betelgeuse: it was accepted 4 to 7; but i will postprone it for rewording the last sentence maybe somehow to reflect what i said :)
-[22:48:26] <scarabeus> ok open floor is on list
-[22:48:27] <wired> I say we talk about the next meeting date over email
-[22:48:33] <wired> for finalization
-[22:48:34] <scarabeus> wired: sounds sane
-[22:48:41] <scarabeus> wired: could you sent starting mail?
-[22:48:45] <wired> i'll be back in >=30m
-[22:48:46] <wired> scarabeus: sure
-[22:48:48] <scarabeus> ok
-[22:48:58] <wired> thanks, c ya soon
-[22:49:03] <scarabeus> ok open floor
-[22:49:10] <scarabeus> anyone wants anything from us?
-[22:50:14] <scarabeus> oh and i would like to, as council, give big Thanks and icecream to idl0r/a3li for making the bugzie4 :)
-[22:51:04] <a3li> you're most welcome
-[22:52:27] <scarabeus> ok i think thats all given the silence,
-[22:52:27] <scarabeus> so council members feel released from duty!
-[22:52:27] <scarabeus> </meeting>
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110408-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20110408-summary.txt
deleted file mode 100644
index 4cf6dd0d57..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110408-summary.txt
+++ /dev/null
@@ -1,106 +0,0 @@
-Council 2011/04/08 meeting summary
-==================================
-
-
-Agenda
-------
-
- * roll call
-
- * project Canterbury[2]
- * Gentoo's restructure
- * progress on the slacking arches topic
-
- * open bugs with council involvement
- * next meeting date / chair
- * open floor - listen to the community
-
- [1] http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000
- [2] http://www.gentoo.org/
-
-
-Meeting
--------
-
- * roll call
-
-    here:
-
-    Betelgeuse
-    bonsaikitten
-    ferringb
-    jmbsvicetto
-    scarabeus
-    wired
-    chainsaw (late)
-
-
- * items for discussion / vote
-
-    * project Canterbury
-    * Gentoo's restructure
-
-    These two topics were added for April's Fool day. There was enough said about them, so we'll leave
-	them for next year.
-
-    * Council web app
-
-    Petteri asked for this topic to be added to the meeting right before it start as a student submitted
-	an application for GSoC for doing a council application[1].
-    As Petteri presented it, the application would provide at least the following 3 features: 1) doodle
-	like feature or doodle integration for setting times 2) irc bot for automatic log handling (integrate
-	with some existing software) 3) handling agendas. Other members noted that if it could also deal with
-	voting, that would be great.
-    There was some discussion about technical details but the council decided to focus on whether the
-	project was desired and leave the discussion about details for later.
-    The council members didn't object to the idea and are open to see what will come out of that project.
-	Petteri will mentor the student for the project and Brian will watch over it.
-
-    [1] - http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/jbartosik/1
-
-    * progress on the slacking arches topic
-
-    Jorge explained to the other council members that he had planned to start a new round of emails at the
-	start of the week, but work got in the way.
-    He informed the other members that he will send 3 or 4 emails during this weekend about "hiring people"
-	(to address the lack of people), "automated testing", "statistics" and a revised email about "arch
-	resources".
-    Alex volunteered to send the email about "automated testing" and manifested his interest to participate
-	in this discussion.
-
-    * open bugs with council involvement
-
-    bug 234706 - "slacker arches"
-    The council agreed on adding a note that it's working on this issue
-
-    bug 234711 - "GLEP 54"
-    The council agreed on adding a note that it has decided to use "live" as the suffix instead of "scm" if
-	this GLEP ever goes forward and to leave the bug open.
-
-    bug 237381 - "Document appeals process"
-    Jorge promised to finally take care of this bug.
-
-    bug 237381
-    bug 331987
-    Both bugs are on infra side so there's nothing for the council to do about them
-
-    bug 341959
-    Tomas noted that devmanual needs some updates and Alex volunteered to take care of this bug.
-
-    bug 344479
-    Jorge will take care of this bug.
-
-
- * Next meeting chair
-
-    Tomas
-
-
- * Next meeting date
-
-    Tuesday, 20110510 1900 UTC
-
-
- * Open floor - listen to the community
-
-	No issue was brought forward to the council.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110408.txt b/xml/htdocs/proj/en/council/meeting-logs/20110408.txt
deleted file mode 100644
index 0c34e417f8..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110408.txt
+++ /dev/null
@@ -1,292 +0,0 @@
-19:59 <@jmbsvicetto> so shall we get ready for the meeting?
-19:59  * amazingpudding is present 
-19:59  * wired here
-20:00  * jmbsvicetto is here
-20:00 <@Betelgeuse> here
-20:01 <@PSYCHO___> Aye
-20:01 <@PSYCHO___> Scarabeus
-20:01 <@jmbsvicetto> ferringb: ^^
-20:01 <@jmbsvicetto> I've phoned chainsaw, but he didn't answer
-20:02 <@jmbsvicetto> let's give him 5 minutes to show up or we'll start
-20:03 <@PSYCHO___> Ok
-20:03 -!- jmbsvicetto changed the topic of #gentoo-council to: Next meeting: Now | agenda: http://archives.gentoo.org/gentoo-dev-announce/msg_1647b68c074c4a0f1521fe10d9a7670a.xml | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | http://www.gentoo.org/proj/en/council/
-20:03 <@scarabeus> jup
-20:04 <@jmbsvicetto> Does anyone want to address the first 2 points in the agenda? (project Canterbury and Gentoo's restructure)
-20:04 <@jmbsvicetto> or can we leave that for next year? ;)
-20:04 <@PSYCHO___> Nup
-20:04 <@PSYCHO___> Yup
-20:05 <@amazingpudding> cb ... good plan, where do we start?
-20:05 <@Betelgeuse> jmbsvicetto: Gentoo should have obsoleted Debian and the others by then
-20:05 <@jmbsvicetto> Betelgeuse: I suppose we can start with the council app
-20:05 <@wired> well project canterbury was a success, nuff said :P
-20:06 <@jmbsvicetto> ok, it seems chainsaw isn't going to attend, so let's start
-20:06 <@Betelgeuse> For the web app we first need to decide if we want one and then what we would like in it
-20:06 <@jmbsvicetto> Betelgeuse: want to start?
-20:06 <@Betelgeuse> If we do it then it will be iterative so that people can offer input all the time
-20:06 <@Betelgeuse> jmbsvicetto: already did :)
-20:07 <@jmbsvicetto> ok, I don't know what I would use it for, so why should I care about it? What can it do for me / us?
-20:07 <@ferringb> Betelgeuse: lnk...?
-20:07 <@Betelgeuse> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/jbartosik/1
-20:07 <@Betelgeuse> Is this link public?
-20:08 <@wired> it is
-20:08 <@ferringb> ugh
-20:08 <@ferringb> google needs to lay off the tron/whatever-the-hell-gsoc11-image-uses font
-20:09 <@ferringb> Betelgeuse: haven't been involved in gsoc this year beyond commenting on proposals; when is the due date?
-20:09 <@Betelgeuse> ferringb: it was today
-20:09 <@Betelgeuse> ferringb: for applications
-20:09 <@ferringb> presume it's not immutable?
-20:09 <@ferringb> *now immutable
-20:09 <@Betelgeuse> ferringb: the feature set is not set in stone
-20:10  * ferringb wants the requirements locked in
-20:10 <@ferringb> deliverables w/out requirements makes it hard to evaluate the underlying intent
-20:10 <@ferringb> grok?
-20:11 <@Betelgeuse> Basically I see at least these as valuable 1) doodle like feature or doodle integration for setting times 2) irc bot for automatic log handling (integrate with some existing software) 3) handling agendas
-20:11 <@Betelgeuse> Handling voting is nice too
-20:11 <@Betelgeuse> so that you don't ahve to manually count on IRC
-20:11 <@wired> i like the idea, mainly for agenda and user submittions
-20:11 <@jmbsvicetto> chainsaw should show up in around 25 minutes
-20:11 <@wired> submissions even
-20:12 <@ferringb> Betelgeuse: gentoo has an openid provider service running?
-20:12 <@jmbsvicetto> I told him we would try to push any votings to the end
-20:12 <@PSYCHO___> Why not bond it ti our ldap
-20:12 <@jmbsvicetto> Betelgeuse: those 3 sound nice
-20:12 <@Betelgeuse> ferringb: you can proxy through dev.gentoo.org/~nick
-20:12 <@ferringb> Betelgeuse: eh
-20:12 <@Betelgeuse> ferringb: that's what we did for the recruiting app
-20:12 <@ferringb> sorry, keyboard's being fucky.  the 'eh' was a gutteral sound intended as a question. ;)
-20:13 <@ferringb> what, just verifying dev.gentoo.org/~me/ exists?
-20:13 <@Betelgeuse> ferringb: check the html source for dev.gentoo.org/~betelgeuse
-20:13 <@ferringb> cause that isn't really doing providing ;)
-20:13 <@PSYCHO___> Thats brutal :)
-20:13 -!- bicatali [~bicatali@gentoo/developer/bicatali] has joined #gentoo-council
-20:13 <@jmbsvicetto> Betelgeuse: btw, I got the impression that infra might host some django stuff soon. If that happens, django might prove a better choice than RoR
-20:14 <@Betelgeuse> jmbsvicetto: jbartosik did the recruiting app with rails last yea
-20:14 <@ferringb> Betelgeuse: check the source of dev.gentoo.org/~ferringb/
-20:14 <@ferringb> Betelgeuse: I'm talking about an *actual* openid provider
-20:14 <@jmbsvicetto> Betelgeuse: yeah, I know last year it was RoR
-20:14 <@ferringb> not requiring devs to hack up a local index.html
-20:14 <@Betelgeuse> ferringb: we don't have that
-20:14 <@ferringb> yeah, I know
-20:14 <@ferringb> hence the openid login bit is slightly off
-20:14 <@ferringb> that infra would have to be built out, bound to ldap
-20:14 <@Betelgeuse> it is but I would like infra to do git first
-20:14 <@Betelgeuse> :)
-20:15 <@ferringb> it's an uncontrolled dep, something of a critical one
-20:15 <@jmbsvicetto> so, no objection about seeing what we can get from a council app?
-20:15 <@jmbsvicetto> Does anyone want to deal directly with this issue?
-20:15 <@jmbsvicetto> Betelgeuse: you?
-20:15 <@Betelgeuse> Ideally we have a mentor from the council
-20:15 <@Betelgeuse> or at least someone closely involved
-20:16 <@Betelgeuse> I will at least be doing the libbash project
-20:16 <@Betelgeuse> But if there's no other takers then I can do that one too
-20:16 <@ferringb> proxy bit doesn't work when a non dev is used
-20:17 <@ferringb> although I'llbe damned if I can recall if that's even technically allowed (I'm fairly sure it's occured however)
-20:17 <@Betelgeuse> ferringb: there were plenty of discussions when someone nominated ciaramn
-20:17 <@wired> i find it wrong
-20:17 <@jmbsvicetto> ferringb: there's no requirement for the proxy to be a dev
-20:17 <@ferringb> Betelgeuse: "discussion" might be a nice term for those events. ;)
-20:18 <@wired> how can anyone take important global-level gentoo decisions and/or vote if they haven't even gone through the recruitment process
-20:18 <@ferringb> auth infrastructure there has some issues imo
-20:18 <@ferringb> openid makes sense (for allowing non devs to submit things), but requires gentoo infra. to have that sorted for the people who normally submit (council/devs)
-20:19 <@wired> ferringb: so we could have openid for users and ldap for devs
-20:19 <@Betelgeuse> It's quite easy to switch backends with devise any way
-20:20 <@Betelgeuse> So once infra provides something better it should be easy to add
-20:20 <@ferringb> but not particularly desirable to try and have differing auths in use
-20:20 <@ferringb> especially for someone who is starting out from scratch and doing this sort of thing
-20:20 <@ferringb> regardless, the infra/open-id thing I already beat up a bit, so I'll move on
-20:20 <@Betelgeuse> ferringb: multiauthentication is matter of hours with the library set suggested
-20:21 <@Betelgeuse> ferringb: And in this case copy paste from one of my projects
-20:21 <@jmbsvicetto> ferringb / Betelgeuse: perhaps we should discuss details later?
-20:21 <@ferringb> Betelgeuse: you know what you're doing.
-20:21 <@ferringb> as do I
-20:21 <@amazingpudding> yes please
-20:21 <@jmbsvicetto> for now we should only focus on whether the council app is something we want and or care?
-20:21 <@Betelgeuse> So did we agree that let's see what the project produces?
-20:22 <@wired> Betelgeuse: yes
-20:22 <@ferringb> Betelgeuse: one thing I've learned from gsoc is that dev's kind of suck at estimating times for others, since most of the time we've done it already and have a fair amount of experience ;)
-20:22 <@ferringb> just is a concern point
-20:22 <@Betelgeuse> ferringb: well jbartosik wrote the hobo_devise gem :)
-20:22 <@jmbsvicetto> seems like there's no objection, so we should pick someone to pursue this issue
-20:23 <@jmbsvicetto> so unless someone else steps forward, Betelgeuse will look into it?
-20:23 <@ferringb> Betelgeuse: eenie meenie.  you get my point :P
-20:23 <@Betelgeuse> jmbsvicetto: yes
-20:23 <@Betelgeuse> ferringb: yes
-20:23  * ferringb would like to track it if you don't mind
-20:23 <@ferringb> basically being the nagging "what about this, what about that?" voice. ;)
-20:23  * ferringb is good at nagging you see
-20:23 <@Betelgeuse> ferringb: sounds good
-20:25 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has joined #gentoo-council
-20:25 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
-20:25 <@Chainsaw> I'm here, sorry!
-20:25 <@wired> no worries, welcome
-20:25 <@Chainsaw> (On a bus right now, will have to disconnect in about 10 minutes when I get to my stop)
-20:25 <@Chainsaw> So, where were we?
-20:26 <@jmbsvicetto> Chainsaw: we just decided to see what a student has to show us for a council app (GSoC project) and that Betelgeuse and ferringb will work with him
-20:27 <@Chainsaw> jmbsvicetto: *nod*
-20:27 <@ferringb> modification to roles: betelgeuse is mentoring/whatnot, I'm harassing/watchinvg
-20:27 <@ferringb> *watching
-20:27 <@jmbsvicetto> ok, so let me talk about the slacking arches topic
-20:28 <@Chainsaw> I might be able to get a Mac Mini G4; which would allow me to get my G5 on linux again. (I think PPC64 is among those at risk)
-20:28 <@PSYCHO___> Its more you talking and us listening :)
-20:28 <@jmbsvicetto> So, I had planned to send another round of emails at the start of this week, but work got in the way
-20:28 <@jmbsvicetto> I'm planning to send 3 or 4 mails to the public mls this weekend
-20:29 <@jmbsvicetto> So the mails will focus on "hiring people" (to address the lack of people), "automated testing", "statistics" and a revised email about "arch resources"
-20:30 <@jmbsvicetto> scarabeus: Do you have any requirements / wishes about policies or are you happy in having that wait for the results of the discussions?
-20:30 <@Chainsaw> That seems the most productive approach, yes. Trying to address problem instead of trying to revoke status.
-20:30 <@Chainsaw> +the
-20:30 <@PSYCHO___> we can waut for sure
-20:31 <@jmbsvicetto> ok, so that's all I have about this for now
-20:31 <@Chainsaw> I feel at least partially responsible for the PPC/PPC64 situation, and will try to do better there.
-20:31 <@Chainsaw> My stop is coming up.
-20:31 <@Chainsaw> Will reconnect from home.
-20:31 <@Chainsaw> ~5 minutes at most.
-20:31 <@jmbsvicetto> Is there anything else you want to talk about before we go to bugs?
-20:31 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has quit [Read error: Connection reset by peer]
-20:32 <@wired> jmbsvicetto: I have a particular interest in the automated testing thingy, what are you planning to send in your email regarding that?
-20:33 <@jmbsvicetto> I plan to send an email starting a discussion about it but expressing why I care about it, what I envision we could be doing with it and asking for ideas about what to test, how to test and how to get us doing it
-20:33 <@jmbsvicetto> s/but/by/
-20:33 <@PSYCHO___> i wanted to ask if any of you know about git migration status for gentoo cvs tree not gentoo-x86
-20:33 <@ferringb> wrong forum
-20:33 <@ferringb> gentoo-scm ml
-20:34 <@ferringb> also, use the scarabeus nick please (recall we log this)
-20:34 <@jmbsvicetto> ferringb: that one has been focusing more on gentoo-x86 than the other trees
-20:34 <@wired> jmbsvicetto: thats about the same thing I have in mind, I can help and/or send that mail if you want some help there :)
-20:34 <@ferringb> mmm, right.  then the answer is "for existing projects, they can migrate if they want to".  I'm not aware of an infra push to kill cvs in full...
-20:34 <@ferringb> same applies for svn
-20:35 <@jmbsvicetto> wired: I'll send that email for sure, but all help in the discussion and getting the project help is most welcome
-20:35 <@PSYCHO___> if you make my net work i will gladly use the nick but so far i am stuck with droid
-20:35 <@jmbsvicetto> sorry, getting the project running*
-20:36 <@wired> jmbsvicetto: okie. ive been thinking about this since fosdem but never managed to sit down and write an email about it, i'll definately contribute :)
-20:36 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has joined #gentoo-council
-20:36 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
-20:36 <@Chainsaw> Right. Back.
-20:37 <@jmbsvicetto> so, anything else or should we move to bugs?
-20:37 <@Chainsaw> Please proceed.
-20:38 <@jmbsvicetto> I have a small issue with my work dns server at the moment, so can one of you please paste the bug numbers?
-20:38 <@Betelgeuse> jmbsvicetto: money run out? :)
-20:39 <@jmbsvicetto> the dns server seems to be unable to resolve names at times
-20:39 <@jmbsvicetto> ok, got resolution working again
-20:39 <@jmbsvicetto> I'll paste the bug numbers
-20:40 <@jmbsvicetto> bug 234706
-20:40 < willikins> jmbsvicetto: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz:council
-20:40 <@jmbsvicetto> Do we want to add a note to this one about the ongoing work? scarabeus want to do it?
-20:41 <@PSYCHO___> why it can wait until we sort it out
-20:41 <@PSYCHO___> not much ccs anyway
-20:42 <@jmbsvicetto> right, but we might want to add a simple note that the council is working on this
-20:42 <@jmbsvicetto> bug 234711
-20:42 < willikins> jmbsvicetto: https://bugs.gentoo.org/234711 "GLEP 54: scm package version suffix"; Gentoo Linux, Unspecified; NEW; dberkholz:lu_zero
-20:42 <@jmbsvicetto> any reason to keep it open?
-20:42 <@jmbsvicetto> bug 237381
-20:42 < willikins> jmbsvicetto: https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; NEW; dberkholz:dberkholz
-20:43 <@jmbsvicetto> This one is mine. I'll take care of this until next meeting. I promise
-20:43 -!- zmedico [~zmedico@gentoo/developer/zmedico] has quit [Ping timeout: 258 seconds]
-20:44 <@jmbsvicetto> So?
-20:44 <@jmbsvicetto> opinions?
-20:44 <@Chainsaw> I have complete confidence in your ability to resolve it.
-20:45 <@wired> +1 on a status update for the slacker bug, 237381 is all yours :)
-20:45 <@jmbsvicetto> I meant about bug 234711
-20:45 < willikins> jmbsvicetto: https://bugs.gentoo.org/234711 "GLEP 54: scm package version suffix"; Gentoo Linux, Unspecified; NEW; dberkholz:lu_zero
-20:46 <@wired> jmbsvicetto: iirc at a past meeting we decided that if 54 ever happens, we'd rather use "live" over "scm"
-20:46 <@PSYCHO___> yah what  wired said
-20:46 < Calchan>  /win 13
-20:46 <@amazingpudding> and flying unicorns instead of pigs
-20:47 <@jmbsvicetto> bug 316401 and bug 331987 are on infra side
-20:47 < willikins> jmbsvicetto: https://bugs.gentoo.org/316401 "Add resolution OBSOLETE"; Bugzilla, General Bugs; ASSI; betelgeuse:bugzilla
-20:47 <@wired> other than that update, i'd leave that bug there to remind us that we need to do something about it
-20:47 <@jmbsvicetto> right, but is there any reason to keep it open and not close it as WONTFIX?
-20:47 <@jmbsvicetto> ok
-20:47 <@jmbsvicetto> I'll add a note about the live over scm and let it be
-20:48 <@jmbsvicetto> bug 341959
-20:48 < willikins> jmbsvicetto: https://bugs.gentoo.org/341959 "council changed the waiting period in "eclass removal policy""; Doc Other, Devmanual; REOP; tove:qa
-20:48 <@Chainsaw> jmbsvicetto: Seems the best. I doubt 54 will ever make it.
-20:48 <@PSYCHO___> devmanual needs update
-20:49 <@wired> jmbsvicetto: i'll handle this one
-20:49 <@jmbsvicetto> PSYCHO___: anything else? Do you want to track this one?
-20:49 <@jmbsvicetto> wired: ok, thanks
-20:49 <@jmbsvicetto> the last one is bug 344479
-20:49 < willikins> jmbsvicetto: https://bugs.gentoo.org/344479 "Slacker point for ferringb"; Gentoo Linux, Unspecified; NEW; tove:council
-20:49 <@PSYCHO___> ook
-20:50 <@PSYCHO___> brian was supposed to close it
-20:50 <@wired> indeed
-20:50 -!- zmedico [~zmedico@gentoo/developer/zmedico] has joined #gentoo-council
-20:50 <@wired> ferringb: slacker mark for not hanlding your own bug? :D
-20:50 <@wired> handling*
-20:52 <@jmbsvicetto> Can any of you find any bug I've missed?
-20:52 <@wired> jmbsvicetto: im just kidding, lets give ferringb another chance to handle it
-20:52 <@jmbsvicetto> wired: sure
-20:53 <@jmbsvicetto> so unless I've missed any bug, we can move forward to next meeting's chair and date
-20:54 <@jmbsvicetto> anyone wants to volunteer to be next meeting's chair?
-20:54 <@PSYCHO___> i can do it
-20:55 <@amazingpudding> can do
-20:55 <@jmbsvicetto> which one of you will do it?
-20:56 <@amazingpudding> scarabeus is faster
-20:56 <@jmbsvicetto> hehe, ok
-20:56 <@PSYCHO___> hh
-20:56 <@jmbsvicetto> So next meeting date?
-20:56 <@jmbsvicetto> what about Friday, 6th of May?
-20:56 <@jmbsvicetto> 4 weeks from now
-20:56 <@PSYCHO___> ook
-20:57 <@amazingpudding> preliminary ok
-20:57 <@wired> 6th is fine, although i'd prefer tuesday
-20:57 <@PSYCHO___> 20:00
-20:57 <@jmbsvicetto> Betelgeuse / Chainsaw / ferringb: ^^ 
-20:57 <@jmbsvicetto> Do we want to try Tuesday for next meeting? 10th of May?
-20:57 <@Betelgeuse> 6th ok
-20:58 <@Betelgeuse> 19UTC preferred
-20:59 <@wired> no problem for 19utc here
-20:59 <@jmbsvicetto> ferringb / Chainsaw: ^^
-21:00 <@PSYCHO___> ...
-21:01 <@Chainsaw> I can do Tuesdays, as long as it's not the first of the month.
-21:01 <@jmbsvicetto> shall we discuss the date over email? I'd rather add it to the log / summary
-21:01 <@Chainsaw> Would that work for people?
-21:01 -!- Zorry [~zorry@gentoo/developer/zorry] has quit [Quit: No Ping reply in 180 seconds.]
-21:01 <@jmbsvicetto> it works for me. I can do both 6th and 10th (1900 and 2000 UTC)
-21:02 <@ferringb> jmbsvicetto: work interuption, pardon
-21:02 <@ferringb> as said, noon till 1pm my time (19:00utc) is *way* better than 2000 utc
-21:02 <@Chainsaw> 10th is the second Tuesday of the month. Yeah, I can be there.
-21:02 <@Chainsaw> And I can make 7pm work.
-21:02 <@PSYCHO___> 19:00 is ok
-21:02 <@Chainsaw> (It's 8pm my time anyway)
-21:02 <@ferringb> PSYCHO___: re: closing that bug, as I mentioned, will leave it up to other folk to sort.
-21:03 <@jmbsvicetto> so 1900 UTC? What day?
-21:03 <@Chainsaw> jmbsvicetto: Tuesday the 10th of May please.
-21:03 <@jmbsvicetto> ferringb: ok, I'll take care of that bug then
-21:04 <@wired> so, the 10th it is?
-21:04 <@ferringb> jmbsvicetto: day doesn't matter to me, 1900 is a hard req now though
-21:05 <@Betelgeuse> ferringb: I can do 20 if 19 doesn't work
-21:05 -!- PSYCHO___ [~AndChat@gentoo/developer/flyingspaghettimonster/scarabeus] has quit [Quit: Bye]
-21:05 <@jmbsvicetto> so unless anyone objects in the next 2 minutes, 10th of May, 19000 UTC
-21:05  * ferringb can't do 20
-21:05 <@ferringb> not without significant interuptions from work
-21:05 <@jmbsvicetto> 1900 *
-21:07 -!- NeddySeagoon [~NeddySeag@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-21:07 <@amazingpudding> i'm in .eu timezone again
-21:07 <@wired> jmbsvicetto: two minutes passed ;p
-21:07  * Chainsaw raises two thumbs
-21:07 <@Chainsaw> (And will try not to be on a bus/train at the time!)
-21:08 <@jmbsvicetto> ok, so next meeting 10th of May 1900 UTC
-21:08 <@wired> great
-21:08 <@jmbsvicetto> All that is left is to open the floor
-21:08 <@wired> thanks :)
-21:08 <@jmbsvicetto> A public service announcement, there's less than 3 hours left to vote in the foundation election
-21:08 <@Chainsaw> I voted!
-21:08  * wired voted
-21:09 <@jmbsvicetto> if you haven't voted yet, do so ASAP!!
-21:09 <@jmbsvicetto> thanks guys for your time
-21:09 <@wired> and thank you for chairing
-21:09 <@jmbsvicetto> I'm working on the summary and will try to commit it in a bit
-21:10 <@jmbsvicetto> Does anyone have any issue that would like to bring to the atttention of the council?
-21:10 <@Chainsaw> Thanks for calling jmbsvicetto. Putting your number in my phone now.
-21:12 <@jmbsvicetto> Chainsaw: you're welcome
-21:20 <@Chainsaw> Anyone for the council open mic night? You can bring a guitar?
-21:24 <@amazingpudding> bad idea
-21:27 <@jmbsvicetto> http://dpaste.com/530139/ <- any comments / correctiosn ?
-21:27 <@jmbsvicetto> corrections*
-21:30 <@ferringb> Chainsaw: ukele count?
-21:30 <@ferringb> *ukulele
-21:30 <@wired> jmbsvicetto: please word wrap :P
-21:30 <@wired> gqq :)
-21:30 <@jmbsvicetto> ferringb: I can bring a portuguese guitar too ;)
-21:31 <@ferringb> although I did see a rather entertaining attempt of bohemian rhapsody via ukulele
-21:31  * jmbsvicetto closes the meeting
-21:31 -!- jmbsvicetto changed the topic of #gentoo-council to: Next meeting: 20110510 1900UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110510-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20110510-summary.txt
deleted file mode 100644
index c155a1c6ef..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110510-summary.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Council 2011/05/10 meeting summary
-==================================
-
-
-Agenda
-------
-
- * roll call
-
- * vote/discuss: ChangeLogs must be used in all situations
-
- * open bugs with council involvement
- * next meeting date / chair
- * open floor - listen to the community
-
- [1] http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000
- [2] http://www.gentoo.org/
-
-
-Meeting
--------
-
- * roll call
-
-    here:
-
-    Betelgeuse
-    bonsaikitten
-    ferringb (late)
-    jmbsvicetto
-    scarabeus
-    wired
-    chainsaw
-
- * vote/discuss: ChangeLogs must be used in all situations
-    After some discussion the strictest rule was selected where ChangeLogs need
-    to be updated for all changes. The devmanual was already updated by Peteri
-    with the new wording [1,2] during the meeting.
-
-[1] - http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commitdiff;h=eee81246369d1124501528a289adbbb77a5e3cd1
-[2] - http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commitdiff;h=05923dc0acae7624116407b08cd9bb734e542826
-
- * Open bugs
-
-    Nothing changed since last meeting for the currently open bugs.
-
- * Next meeting chair
-
-    Jorge (jmbsvicetto)
-
- * Next meeting date
-
-    Wednesday, 20110608 1900 UTC
-
- * Open floor - listen to the community
-
-	No issue was brought forward to the council.
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110510.txt b/xml/htdocs/proj/en/council/meeting-logs/20110510.txt
deleted file mode 100644
index df1b5e1daa..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110510.txt
+++ /dev/null
@@ -1,318 +0,0 @@
-19:02 <@Chainsaw> So, we meeting?
-19:02 <@jmbsvicetto> scarabeus: are you chairing the meeting?
-19:04 <@scarabeus> yeah
-19:04 <@scarabeus> sorry i spent last 14 minutes getting to net
-19:04 <@scarabeus> lemme open eveyrthing i need
-19:05 <@scarabeus> i just opened lappy
-19:06 <@scarabeus> ok
-19:06 <@scarabeus> so we can start if nobody complains :)
-19:06 <@scarabeus> but there is one thing only on the topic :)
-19:06 <@scarabeus> so lets start with mandatory thingie
-19:06 <@scarabeus> roll call:
-19:07  * scarabeus obviously here
-19:07 <@Chainsaw> Yes, here.
-19:07 <@Chainsaw> Mr. Vicetto was here earlier.
-19:07 <@Chainsaw> Even the kitten.
-19:07 <@Chainsaw> Oh, and wired.
-19:08 <@scarabeus> so we lack only Betelgeuse and ferringb
-19:08 <@bonsaikitten> is here.
-19:09 <@scarabeus> wired, jmbsvicetto: show up again ;)
-19:09  * wired here
-19:09 <@Chainsaw> Just beetlejuice then.
-19:09 <@wired> lol
-19:09 <@jmbsvicetto> sorry, here
-19:10 <@scarabeus> ok
-19:10 <@scarabeus> 5 is enough for the meeting
-19:10 <@scarabeus> so lets rool i guess
-19:10 <@scarabeus> or does anyone has phone on those two?
-19:11 <@Chainsaw> jmbsvicetto usually calls me. He's very good about that.
-19:11 <@jmbsvicetto> I'll poke Betelgeuse and ferringb 
-19:11 <@scarabeus> Chainsaw: yeah he is great and responsible person
-19:12 <@scarabeus> Chainsaw: i still dont understand how the kde people could trust me to be next in the row for the kde team lead :)
-19:12 <@Betelgeuse> hello
-19:12 <@scarabeus> so thats six :)
-19:12 <@Betelgeuse> I always forget if there's no alarm.
-19:12 <@Betelgeuse> At least jmbsvicetto is a good one :)
-19:13 <@jmbsvicetto> I got voice mail for ferringb 
-19:13 <@scarabeus> ok so lets roll
-19:13 <@scarabeus> this months agenda is just one item
-19:13 <@jmbsvicetto> I'll leave him a message
-19:13 <@scarabeus> http://archives.gentoo.org/gentoo-dev-announce/msg_4032405a712196c9f18f29aaf8f54d72.xml
-19:13 <@scarabeus> unless i miss some reply
-19:13 <@scarabeus> (there was one about openrc news item but that is obsolete now)
-19:14 <@scarabeus> so the issue we are speaking about is nice discussion on gentoo-dev
-19:14 <@scarabeus> http://archives.gentoo.org/gentoo-dev/msg_eaefa325b31360324d0fe53d0b9071e6.xml
-19:15 <@jmbsvicetto> is there anything for us to decide?
-19:15 <@scarabeus> so the issue is that changelog is not used by some developers in certain cases, like package removals
-19:16 -!- NeddySeagoon [~NeddySeag@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-19:16 <@Chainsaw> I strongly believe that a removal is a change, and as such belongs in a changelog.
-19:16 <@Betelgeuse> And they claim that it's not required.
-19:16 <@scarabeus> well technically i would just say that we want devmanual to state that changelogs must be used for all relevant changes expect typo and whitespace changes
-19:16 <@jmbsvicetto> imho, we already have a policy. The "discussion" arises because some developers don't want to follow it
-19:16 <@bonsaikitten> I prefer complete changelogs just so that I can see from the changelog why a removal happened
-19:16 <@scarabeus> so it is explicit
-19:16 <@scarabeus> and even the typo is questional
-19:16 <@scarabeus> i personaly does not changelog only whitespace
-19:16 <@scarabeus> eg trailing spaces removal
-19:17 <@Betelgeuse> In theory you can break the ebuild with every change.
-19:17 <@Chainsaw> Yes, there is a story behind a removal. It should be captured.
-19:17 <@Chainsaw> In fixing a repoman warning, you can break the build.
-19:17 <@Chainsaw> It would be nice to know who changed it and what their motivation was.
-19:18 <@scarabeus> reverse dependencies can get broken with removal
-19:18 <@scarabeus> so removals tracking in changelog is nice
-19:19 <@Betelgeuse> How about voting on the strictest text: "All commits must be accompanied by ChangeLog entries" and if that doesn't pass then think how to relax it?
-19:19 <@scarabeus> good idea
-19:19 -!- kallamej [~kallamej@gentoo/developer/kallamej] has quit [Quit: bl2 here we go]
-19:19 <@wired> i like that
-19:20 <@jmbsvicetto> I'm ok with it
-19:20 <@scarabeus> i agree with that too (in future commits will be changelogs so everything will be shown anyway)
-19:20 <@bonsaikitten> Betelgeuse: "all" is too strict, changelog changes and whitespace fixes might not need changelog entries
-19:21 < Arfrever> Why would commits of changes in never used code (e.g. inside 'if [[ ${PV} == 9999 ]]' block in non-live ebuild) be mentioned in ChangeLog?
-19:21 <@scarabeus> because you alter the ebuild
-19:22 <@Betelgeuse> So let's vote.
-19:22 <@jmbsvicetto> Arfrever: you can always add an entry for the above stating that you're "syncing ebuild with live ebuild version"
-19:23 <@ferringb> Arfrever:  "house keeping" isn't a bad message...
-19:23 <@Betelgeuse> I vote yes for the reason scarabeus stated.
-19:23 <@wired> I vote yes
-19:23 <@scarabeus> i vote yes
-19:23 <@jmbsvicetto> yes
-19:23 <@ferringb> pardon folk, mildly in a sate of "walking dead" today
-19:23 <@ferringb> *state
-19:23 <@scarabeus> ferringb: well you shown up for the only relevant part :) so just use yar powaz
-19:24 < Arfrever> It doesn't make sense to mention changes not affecting any users of given ebuild.
-19:24 <@ferringb> "yes for strictest"
-19:24 <@bonsaikitten> I vote no on Betelgeuse's strict form, but agree with the general idea
-19:24 <@Betelgeuse> Arfrever: We think otherwise.
-19:24 <@Betelgeuse> You can never be sure any way.
-19:25 <@Betelgeuse> Chainsaw: your vote
-19:29 <@scarabeus> hm
-19:29 -!- alexxy[home] [~alexxy@gentoo/developer/alexxy] has joined #gentoo-council
-19:29 -!- ssuominen [~ssuominen@gentoo/developer/ssuominen] has joined #gentoo-council
-19:30 <@scarabeus> ok we have 6 votes so we can consider it official
-19:30 <@Betelgeuse> http://paste.pocoo.org/show/386527/
-19:30 <@Betelgeuse> Please comment on this and I can push it if ok
-19:31 <@scarabeus> ++
-19:31 < Arfrever> Please vote on excluding changes only in comments.
-19:31 <@ferringb> ';' instead of '-, but sure.
-19:31 <@ferringb> Arfrever: it's a vcs log
-19:31 -!- kallamej [~kallamej@gentoo/developer/kallamej] has joined #gentoo-council
-19:31 <@ferringb> if you seriously think commiting w/ a message '.' in your local vcs when you screw with comments is fine...
-19:31 <@ferringb> well, it's your local vcs
-19:31 <@ferringb> it's not the tree
-19:32 <@Betelgeuse> ferringb: semicolon where?
-19:32 <@ferringb> Betelgeuse: 3rd line addition
-19:32 <@ferringb> or whatever the appropriate english char may be
-19:32 <@Betelgeuse> ferringb: that's the old text
-19:32 <@Betelgeuse> ferringb: But I had to rewrap lines
-19:32 <@Betelgeuse> ferringb: Only first sentence changed in content
-19:32 <@ferringb> sure doesn't look it
-19:33 -!- bloodnoc [~roy@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-19:33 < Philantrop> Next time you're going to discuss the meaning of "should". :-) I'd make it "must".
-19:34 <@Betelgeuse> Philantrop: hmm true
-19:34 <@Betelgeuse> That was in my text voted also
-19:36 <@Betelgeuse> http://paste.pocoo.org/show/386531/
-19:36 <@Betelgeuse> changed to must
-19:37 <@ferringb> Arfrever: the kicker is, in certain cases, you're partally right.
-19:37 <@ferringb> Arfrever: the reality is, people will just adhere to the letter of the law rather than the intent
-19:37 <@ferringb> we already had that occur with removal
-19:38 -!- darkside_ [~darkside@gentoo/developer/darkside] has joined #gentoo-council
-19:38 <@ferringb> stupid that we have to essentially legislate common sense, but that's what it is right now ;)
-19:39 < NeddySeagoon> ferringb, common sense is much rarer that you might think :)
-19:39 <@ferringb> NeddySeagoon: well aware
-19:39 <@Betelgeuse> http://paste.pocoo.org/show/386532/
-19:41 <@scarabeus> i like the last update
-19:42 <@Betelgeuse> The meeting summary could point to wrapping repoman commit and the ssh tunnels
-19:42 <@Betelgeuse> Those should address the speed concerns raised
-19:42 <@Betelgeuse> at least I have never had issues
-19:43 <@Betelgeuse> I don't do things like KDE bumps though
-19:44 <@scarabeus> Betelgeuse: how?
-19:44 <@scarabeus> i just echangelog everything
-19:44 < Arfrever> `cvs commit` is faster than `repoman commit`. When ChangeLog is not updated during commit of deletions, then no CVS headers are changed and it's possible to commit changes in Manifest in the same commit as deletions of ebuilds.
-19:44 <@scarabeus> and then category-commit it
-19:45 <@jmbsvicetto> Arfrever: that argument isn't imho a valid argument for stop using repoman commit (cvs speed)
-19:45 <@Betelgeuse> scarabeus: Like I said I don't do those category wide commits :)
-19:46 <@jmbsvicetto> Arfrever: that is a good argument to get people working on replacements for cvs and or improving the QA scripts
-19:46 <@Betelgeuse> scarabeus: I use http://paste.pocoo.org/show/386533/
-19:46 <@jmbsvicetto> Betelgeuse: they can be very "stressing"
-19:46 <@Betelgeuse> scarabeus: to dig what I just told echangelog
-19:47 < Arfrever> jmbsvicetto: repoman wastes time on scanning other ebuilds not updated during committing.
-19:47 <@ferringb> Arfrever: that's not true.
-19:47 <@jmbsvicetto> last time I tried to do one for KDE I had to give up as my laptop just wasn't able to keep up with it
-19:47 <@ferringb> Arfrever: note the headers in ebuilds.
-19:47 <@ferringb> Arfrever: or headers in any other file frankly, that was modified.
-19:47 < Arfrever> ferringb: I meant commits of only deletions of ebuilds + change in Manifest.
-19:47 <@ferringb> Arfrever: those change, chksum changes, meaning double commit for manifest
-19:47 <+dberkholz> repoman takes like 10 seconds, this isn't a big issue
-19:47 <@ferringb> dberkholz: exactly.
-19:47 <@jmbsvicetto> and that's one reason I'd really would like to have git by now. People have to work on that, though
-19:48 <@ferringb> Arfrever: if you're going to complain about speed, complain about echangelog.
-19:48 <@ferringb> repoman commit's speed really isn't a point you can complain about
-19:48 <@Chainsaw> Sorry for the delay.
-19:48 <@Betelgeuse> Seems there's no objections to my latest devmanual patch so I'll push that in a couple minutes.
-19:48 <@Chainsaw> I am for the strict beetlejuice version. Yes.
-19:49 <@ferringb> beetlejuice beetlejuice beetlejuice!
-19:49  * ferringb wanders off to deal with the sand worms
-19:49 <@Chainsaw> ferringb: Walk without rhythm.
-19:50 <@ferringb> Chainsaw: or walk as if you were a desert mouse
-19:50 <@ferringb> Chainsaw: was referencing the more comical version of sand worms also ;)
-19:50 <@ferringb> Betelgeuse: honestly, no idea why I've not made that joke about your nick yet. ;)
-19:51 <@scarabeus> ok so we have conclusion on this issue i suppose guys :)
-19:52 < Arfrever> The patch for devmanual doesn't disallow `ln -fs /bin/true /usr/bin/echangelog` :) .
-19:52 <@Betelgeuse> Arfrever: Sure but I bet QA/DevRel can come up with something
-19:53 <@Betelgeuse> Arfrever: That doesn't end up updating ChangeLog
-19:53 <@scarabeus> so next on list is bugs, where there is no change since last month i suppose
-19:54 <@scarabeus> and the last thing on the list is the open floor and other topics brought by other members
-19:54 <@scarabeus> so anyone anything?
-19:54 <@Betelgeuse> jbartosik was supposed to be here for the council web app
-19:54 <@scarabeus> Betelgeuse: btw would you mind open bug with attached changelog? or just commit it directly, if you have no access just tell infra to allow developers group to touch devmanual
-19:54 <@Chainsaw> scarabeus: Nothing further your honour.
-19:55 <@Betelgeuse> scarabeus: I have push access and it's already in
-19:55 <@Betelgeuse> Any way we set a goal that we have something usable live for the meeting next month
-19:55 <@scarabeus> Chainsaw: does that mean that i have to wear those silly white hair now?
-19:55 < Arfrever> Also echangelog is known to break lines after very short limit. It should be changed to at least 144 :) .
-19:55 <@Chainsaw> scarabeus: Look in a mirror. You already are!
-19:55 <@Betelgeuse> Arfrever: You can open threads on mailing lists for that
-19:55 <@ferringb> Arfrever: ml.
-19:56 <@ferringb> this isn't going to be dissuaded by arguments about the tools potentially sucking
-19:56 <@ferringb> fix the tools
-19:56 <@Betelgeuse> If anyone wants access the Agilefant instance to track progress please query
-19:56 <@scarabeus> i can wait for public preview :)
-19:56 <@scarabeus> hope it is going well :)
-19:57 <+dberkholz> Arfrever: stop breaking my terminals, they're only 80 wide.
-19:57 <@Betelgeuse> scarabeus: GSoC hasn't officially started yet :)
-19:58 <@Betelgeuse> scarabeus: the coding period any way but we started early
-19:58 < Arfrever> dberkholz: You should switch to better terminals.
-19:58  * ferringb should level the +m if arguing over decisions continues
-19:58 <@ferringb> and yes, I'm an ass.
-19:59 <@ferringb> think my point is made however.
-19:59 <@Betelgeuse> Did you notice qiaomuf's blog post about libbash?
-19:59  * bonsaikitten waits for ferringb to get stabby
-20:00 <@ferringb> bonsaikitten: day's starting off that way.  one hopes it becomes more xen like before the folks I have to interview later today ;)
-20:00  * scarabeus throws his knife
-20:00 <@bonsaikitten> zen I hope
-20:00 <@ferringb> zen even.
-20:00 <@scarabeus> here borrow this ;)
-20:00 <@jmbsvicetto> ferringb: hopefully zen ;)
-20:00 <@scarabeus> ok so i guess thats it
-20:00 <@ferringb> xen from the stance of cutting a release in between interviewing. ;)
-20:00 <@jmbsvicetto> scarabeus: ok, quick note
-20:00 <@ferringb> either way
-20:01 <@scarabeus> jmbsvicetto: hm?
-20:01 <@jmbsvicetto> I've finally sent an email about the arch teams to the project ml right before the meeting started
-20:01 <@scarabeus> :)
-20:01 <@scarabeus> i see i see
-20:01 <@jmbsvicetto> and I'm about to send an email about the automatic testing
-20:01 <@scarabeus> so now for the next meeting :) 7.6. 19:00 UTC and who is willing to chair? :)
-20:01 <@jmbsvicetto> so let's see if anything comes out from that
-20:02 <@jmbsvicetto> are we back to Tuesdays or do we want to do it another day of the week?
-20:02 <@Betelgeuse> scarabeus: time works for me
-20:02 < Arfrever> scarabeus: Do you mean 2011-07-06?
-20:02 <@jmbsvicetto> I can do Tuesdays
-20:02 <@ferringb> 19:00 really is sucking ass for me
-20:02 <@Betelgeuse> Arfrever: context tells it's June
-20:02 <@jmbsvicetto> 2001-06-07
-20:02 < Arfrever> jmbsvicetto: It was in the past :) .
-20:02 <@ferringb> admittedly, 20:00 isn't always great either.  22:00 is the sweet spot for me, but I suspect horrible for the rest of y'all
-20:03 <@Chainsaw> I can do Tuesdays, but not the first Tuesday of the month.
-20:03 <@Chainsaw> That's the LUG meeting. Second Tuesday is totally fine though.
-20:03 <@ferringb> can't do mondays, tuesdays is viable, but wednesday is better
-20:03 <@ferringb> then thurs/fri start getting crazy. ;)
-20:03 <@scarabeus> so lets do it on wed
-20:03 <@Chainsaw> And if 22:00 is better for you, I can do that.
-20:03 <@Betelgeuse> ferringb: 22UTC starts at 1am
-20:03 <@scarabeus> it is option stuf
-20:03 <@ferringb> Betelgeuse: I got up at 5-6am on a saturday for one of these.
-20:03 <@ferringb> Betelgeuse: recall, I'm still trying to make y'all get up at a crazy hour in retaliation ;)
-20:04 <@ferringb> wednesday at 19 is fine
-20:04 <@Betelgeuse> ferringb: yes but maybe we can find a time that suits everyone :)
-20:04 <@ferringb> it's basically the "ok, fires are out" before the new fires start
-20:05 <@ferringb> Betelgeuse: early morn hours are what I've had for dealing w/ europe, but I've got meetings in the morning.
-20:05 <@ferringb> my schedule sucks, is the short version.
-20:05 <@Betelgeuse> Next meeting is the last one isn't it?
-20:05 <@ferringb> will adapt to y'alls since currently, you outnumber the usians anyways. ;)
-20:05 <@Chainsaw> Betelgeuse: Until the end of the world? That's 2012 isn't it?
-20:06 <@Betelgeuse> ferringb: better luck for the next election round :)
-20:06 <@Betelgeuse> Chainsaw: for our term
-20:06 <@ferringb> heh
-20:06 -!- darkside_ [~darkside@gentoo/developer/darkside] has left #gentoo-council []
-20:06 <@Chainsaw> Betelgeuse: Oh right.
-20:07 <@Betelgeuse> jmbsvicetto: Do you remember the election timetable?
-20:07 < NeddySeagoon> the nomination peropd should have started then.  Is that elections slacking again :)
-20:08 <@Chainsaw> Can I buy my TV commercials & news articles yet?
-20:08 <@Betelgeuse> NeddySeagoon: I think the elections take about a month so there's still time before July
-20:09 < NeddySeagoon> Betelgeuse, I thought it was a month each for nomintions and votes ... maybe my memory is fading with age
-20:10 <@ferringb> my memory concurs
-20:10 <@jmbsvicetto> iirc, the election takes place on July and the new council will take office in August
-20:10 <@ferringb> yep
-20:10 <@Betelgeuse> NeddySeagoon: the timeline has probably fluctuated but I'll leave that to the elections team
-20:10 <@Chainsaw> jmbsvicetto: Will we get new chairs?
-20:10 <@jmbsvicetto> NeddySeagoon: no, 15 days each for council (nomination and voting)
-20:10 <@ferringb> huh
-20:10 <@ferringb> either way
-20:10 <@jmbsvicetto> NeddySeagoon: the foundation is the one taking 1 month for each
-20:10 <@Betelgeuse> jmbsvicetto: Our first meeting is marked for July 14, 2010 for some reason
-20:11 <@jmbsvicetto> Chainsaw: hehe
-20:11 <@jmbsvicetto> Betelgeuse: ok, then my memory is "skewed"
-20:11 <@jmbsvicetto> I'll check the election schedule this week and will report it
-20:12 <@scarabeus> ok guys i have to disappear :)
-20:12 <@scarabeus> find next meeting chair and date, i am fine with everything :)
-20:12 -!- alexxy[home] [~alexxy@gentoo/developer/alexxy] has quit [Remote host closed the connection]
-20:12 <@Betelgeuse> I propose we start 5mins from now
-20:12 <@scarabeus> and if anyone of you mail me log i will create proper summary and commit during this week
-20:12 <@Chainsaw> Not the first Tuesday of the month.
-20:12 <@scarabeus> Betelgeuse: xD
-20:12 <@Chainsaw> Not a Friday/Saturday/Sunday.
-20:13 <@Chainsaw> Any other day/time, I'll move stuff to make it work.
-20:13 <@Betelgeuse> 2011-06-14 19UTC?
-20:13 <@Betelgeuse> Or 06-15 as it was better to ferringb
-20:13 <@Chainsaw> Either works for me.
-20:13 <@jmbsvicetto> I can be the chair for next meeting
-20:14 <@Chainsaw> That would be most appreciated.
-20:14 <@ferringb> eenie meenie
-20:14 <@ferringb> honestly my schedule just @!#*ing sucks
-20:14 <@ferringb> all days exempting weekend aren't great
-20:14 <@ferringb> wedn. is my preference, but it's not a hard req
-20:15 <@Betelgeuse> wired: time preferences?
-20:15 <@jmbsvicetto> So, 20110604 (Saturday) or 20110614 (Tuesday): what do you pick?
-20:15 <@Betelgeuse> jmbsvicetto: 0615?
-20:15 <@jmbsvicetto> sorry, 20110615 (Wednesday)
-20:15 <@ferringb> err
-20:15 <@wired> i prefer wednesday
-20:15 <@ferringb> crap.  forgot.  10-20 I'm moving.
-20:16 <@wired> any time after 1800 utc
-20:16 <@ferringb> specifically will be driving through redwood forests sometime on the 15th. :)
-20:16 <@ferringb> week prior being my preference
-20:16 <@ferringb> else I'll just have to send a proxy
-20:16 <@jmbsvicetto> next attempt: 20110604 (Saturday) or 20110608 (Wednesday)
-20:16 <@ferringb> 08. :)
-20:16 <@wired> 08 +1
-20:16 <@ferringb> <-- work beckons
-20:17 <@jmbsvicetto> Wednesday - 1900 UTC
-20:17 <@Betelgeuse> 08 ok
-20:17 <@jmbsvicetto> Betelgeuse / bonsaikitten / Chainsaw / ferringb / scarabeus / wired: 20110608 1900 UTC, is that ok for you?
-20:17 <@ferringb> yes
-20:18 <@Betelgeuse> yes
-20:18 <@bonsaikitten> yes
-20:18 <@Chainsaw> jmbsvicetto: Yes.
-20:19 <@wired> yes
-20:19 <@Chainsaw> Consensus!
-20:20 <@jmbsvicetto> we're missing scarabeus 
-20:20 <@Betelgeuse> 20:12 <@scarabeus> find next meeting chair and date, i am fine with everything :)
-20:20 <@Chainsaw> Summary: Yes.
-20:20 <@jmbsvicetto> ok, then we're settled :)
-20:20 <@jmbsvicetto> Thanks everyone
-20:21  * Chainsaw bows and leaves the room
-20:21 <@Betelgeuse> is summary done?
-20:21 -!- jmbsvicetto changed the topic of #gentoo-council to: Next meeting: 20110608 1900UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
-20:21 <@jmbsvicetto> Betelgeuse: scarabeus promised to do it soon
-20:22 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has quit [Quit: Leaving]
-20:22 <@jmbsvicetto> wired: mail about automatic testing finally sent to the mls
-20:22 <@Betelgeuse> 20:12 <@scarabeus> and if anyone of you mail me log i will create proper summary and commit during this week
-20:22 <@jmbsvicetto> oh, ok
-20:22 <@Betelgeuse> Someone needs to commit the log
-20:22 <@jmbsvicetto> I'll take care of the log later today
-20:23 -!- alexxy [~alexxy@gentoo/developer/alexxy] has joined #gentoo-council
-20:23 <@jmbsvicetto> Let's close this meeting then
-20:23 -!- alexxy [~alexxy@gentoo/developer/alexxy] has quit [Remote host closed the connection]
-20:23 <@Betelgeuse> thanks
-20:23 <@jmbsvicetto> If anyone wishes to call the council attention to any issue, please do so
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110608-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20110608-summary.txt
deleted file mode 100644
index 5bb232ab11..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110608-summary.txt
+++ /dev/null
@@ -1,141 +0,0 @@
-Council 2011/06/08 meeting summary
-==================================
-
-
-Agenda
-------
-
- * roll call
-
- * ChangeLog policy
- * GLEP48 review
- * Removal of support for old-style virtuals (ulm)
- * Review of the ending council term
- * Council web app
-
- * open bugs with council involvement
- * open floor - listen to the community
-
-
-Meeting
--------
-
- * roll call
-
-    here:
-
-    Betelgeuse
-    bonsaikitten
-    chainsaw
-    jmbsvicetto
-    scarabeus
-    wired
-
-    missing:
-
-    ferringb
-
-
- * items for discussion / vote
-
-    * ChangeLog policy
-
-    The policy approved by the council in the last meeting gave rise to some incidents and sparked much
-    debate. In the fallout Fabian made a request[1] for the council to discuss the ChangeLog generation.
-    Jorge suggested the council should divide this topic in 2 issues: the result of the policy approval
-    and the request to review the policy.
-    Jorge made a point of thanking both the QA lead and deputy lead for addressing the ChangeLog policy
-    and enforcing it inside QA, as well as thank DevRel (which Jorge and Petteri are part of) for their
-    resolution of the bug. Tony argued that the ChangeLog policy is working as intended. Petteri argued
-    that the policy is strict but that it does show how the problematic people react to policies in
-    general.
-    After some discussion regarding the "strictness" of the policy and whether to accept the request to
-    review the policy, the council decided to not review the policy with 5 no votes and 1 abstention.
-    The council issued a clarification note about the policy stating that as one removes the ChangeLog
-    while dropping a package from the tree, there is no need to update it while commiting a package
-    removal. 
-    The discussion then turned to the point about automatic generation of the ChangeLog. The following
-    debate mentioned having repoman -m call echangelog, having the ChangeLog files generated server
-    side and completing the move to the git tree.
-    A vote was called stating that the decision of the council about automated changelog messages is
-    that repoman be updated to add the commit message to changelog, until such time as changelogs can
-    be created server side. The council also urges individual developers to join the effort to move
-    the tree to git. The vote was carried with 5 yes votes and 1 abstention. 2 council members each
-    approved one part and abstained on the other.
-    Tony made a point of recalling that this decision does in no way affect the decision not to update
-    the changelog policy, so developers are still required to update changelogs for every commit.
-    Tomas[2] and Alex[3] provided some commit wrappers to call echangelog.
-
-    [1] - http://archives.gentoo.org/gentoo-dev/msg_2ff02d6910d797045af3659fb21c712f.xml
-    [2] - http://dpaste.com/552036/
-    [3] - http://paste.pocoo.org/show/403011/
-
-
-    * GLEP48 review
-
-    Jorge submitted a proposal to the ml to update GLEP48[4].
-    After some initial debate over the power granted to the QA team, the timeline in case
-    of an escalation to DevRel, the relation with DevRel and whether QA should only enforce
-    policies or also take part in creating policies, after the request by Patrick, Jorge
-    suggested pushing this back to the mls.
-    Petteri then asked the council to at least vote to commit the non suspension related
-    parts of the proposal. The diff[5] was approved with 6 yes votes.
-    Alec during this discussion presented some thoughts about the QA team[6].
-
-    [4] - http://archives.gentoo.org/gentoo-project/msg_ac161677a6e06a8647e16420eeae8d47.xml
-    [5] - http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/glep/glep-0048.txt?r1=1.3&r2=1.4
-    [6] - http://pastebin.com/C1jGF1DJ
-
-
-    * Removal of support for old-style virtuals (ulm)
-
-    Ulrich made a request to the council to remove the support for old-style virtuals[7].
-    Jorge asked if there could be any compatibility issue with old installations and Petteri
-    asked what would happen to the vdb for old packages. Ulrich replied there should be no
-    compatiblity issues as it should be comparable to a package removal. So if the PM can't
-    resolve the old-style virtual, the package depending on it would pull the new-style
-    virtual.
-    The proposal was approved with 6 yes votes.
-
-    [7] - http://archives.gentoo.org/gentoo-project/msg_7986aa2d9651c600f7302a8d84cc3721.xml
-
-
-    * Review of the ending council term
-
-    Several council members took this chance to look back at the ending term and to make their
-    evaluation of what was accomplished. Most agreed it was fun and that it was nice working
-    with the other elected members. The members also wished a good time for the next council.
-    There was some talk about the move to git, including that council wasn't able to get it done,
-    a mention about not having moved forward with the GLEP 39 reform and a listing of some ideas
-    for next council.
-
-
-    * Council web app
-
-    Joachim Bartosik, a GSoC student at Gentoo, who is working on a RoR app for council[8],
-    did a short demo for council members. The council was able to see the current state of
-    the app and the state of the meeting bot.
-
-    [8] - http://www.google-melange.com/gsoc/project/google/gsoc2011/jbartosik/19001
-
-
-
- * open bugs with council involvement
-
-    The only bugs mentioned during the meeting were:
-
-    bug 237381 - "Document appeals process"
-    Jorge said he failed to present a proposal for this bug.
-
-    bug 341959
-    Alex said he still needs to fix this bug and that he will do that soon.
-
-    bug 362803
-    Jorge commited the update approved in the council meeting to the text version
-    of the GLEP before the meeting ended. He promised to work in the html version
-    later in the day.
-
-
- * Open floor - listen to the community
-
-	No issue was brought forward to the council.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110608.txt b/xml/htdocs/proj/en/council/meeting-logs/20110608.txt
deleted file mode 100644
index 9fc4875f79..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110608.txt
+++ /dev/null
@@ -1,465 +0,0 @@
-19:00 <@wired> here we go :)
-19:01 <@jmbsvicetto> roll call
-19:01 <@jmbsvicetto> here
-19:01 <@Chainsaw> Present.
-19:02 <@wired> here
-19:02 <@Betelgeuse> here
-19:02 <@scarabeus> well we can say here
-19:03 <@jmbsvicetto> bonsaikitten / ferringb ^^
-19:03 <@jmbsvicetto> in the mean time, the agenda is on topic, but here is it again: http://archives.gentoo.org/gentoo-project/msg_0a7935a1097ba0aa41c3370a20679f9a.xml
-19:03 <@bonsaikitten> present and arming bears
-19:03 -!- jmbsvicetto changed the topic of #gentoo-council to: Next meeting: *now* | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/ | agenda - http://archives.gentoo.org/gentoo-project/msg_0a7935a1097ba0aa41c3370a20679f9a.xml
-19:04 <@Chainsaw> Ah yes, the Changelog policy.
-19:04 <@Chainsaw> Which I believe is working as intended.
-19:04 <@bonsaikitten> well, it might be a bit too strict as a response to the constant lawyering
-19:04 <@wired> more like the changelog massacre
-19:05 <@jmbsvicetto> even thought he issue started before, I forgot to mention Fabian and http://archives.gentoo.org/gentoo-dev/msg_2ff02d6910d797045af3659fb21c712f.xml
-19:05 <@Chainsaw> bonsaikitten: If people show malicious creativity, the ruleset will be firmed up in response.
-19:05 <@bonsaikitten> Chainsaw: I would apply malicious creativity to their metacarpals
-19:05 <@jmbsvicetto> For my part, I'd suggest we have 2 things to talk about here
-19:06 <@jmbsvicetto> 1. the result of the policy we applied
-19:06 <@jmbsvicetto> 2. the proposal to review it
-19:06 <@jmbsvicetto> give me a minute while I try to phone Brian
-19:06 <@Chainsaw> Okay.
-19:08 <@jmbsvicetto> no answer, so let's move on
-19:08 <@jmbsvicetto> Does anyone want to talk about 1 or just focus on 2?
-19:08 <@wired> imo the policy itself is not the issue here. sure, it's a bit too strict, but thats easily fixed. my primary concern is the whole attitude surrounding this issue.
-19:08 <@jmbsvicetto> I have a few words about 1, myself
-19:08 <@Betelgeuse> At least 1 let's you find out things.
-19:09 <@Chainsaw> jmbsvicetto: The result is that two developers have ended up in hot water.
-19:09 <@jmbsvicetto> Chainsaw: In my view there's a bit more about 1, that I want to mention
-19:09 <@Chainsaw> jmbsvicetto: I'm listening.
-19:10 <@Betelgeuse> My previous line was probably ambiguous. I mean the policy is strict but it does show how the problematic people react to policies in general.
-19:10 <@jmbsvicetto> First I want to thank both the QA lead and deputy lead for addressing the policy and enforcing inside QA
-19:10 <@jmbsvicetto> Then I also want to thank DevRel for their resolution for the bug
-19:11 <@Betelgeuse> jmbsvicetto: For the sake of the log let's say our resolution :)
-19:12 <@Chainsaw> Betelgeuse: Removal of CVS commit privileges I seem to recall.
-19:12 <@jmbsvicetto> Finally I'm very sad to see the length and extreme some of our developers are ready to go to boycot and refuse to follow a simple rule
-19:12 <@Chainsaw> jmbsvicetto: Which vindicates the decision to go with the firm & unambiguous policy.
-19:12 <@Betelgeuse> Chainsaw: I was referring to me and jmbsvicetto being part of DevRel.
-19:12 <@jmbsvicetto> Chainsaw: DevRel sustained QA lead decision to suspend commit privileges
-19:12 <@jmbsvicetto> Betelgeuse: and you're right :)
-19:13 <@Betelgeuse> jmbsvicetto: sustain?
-19:13 <@Betelgeuse> jmbsvicetto: I wrote the resolution to not take any direct stance on the suspension.
-19:13 <@jmbsvicetto> Betelgeuse: the devrel resolution agreed with the commit privilege suspension
-19:14 <@jmbsvicetto> Betelgeuse: that's what I mean. I'm sorry if I gave it any other meaning
-19:14 <@bonsaikitten> so, how do we fix this situation?
-19:14 <@Betelgeuse> jmbsvicetto: I was supposed to say that enough disciplinary action has already been taken.
-19:14 <@bonsaikitten> people seem to disagree with any rules ;)
-19:15 <@jmbsvicetto> so by my part moving on to 2
-19:15 <@Betelgeuse> s/I/It/
-19:15 <@jmbsvicetto> bonsaikitten / Chainsaw: I think we need a clear rule, but I also agree we should add 2 obvious exceptions: removing a package from the tree (it seems some don't consider this to be clear) and typo / comments fix
-19:16 <@Chainsaw> jmbsvicetto: No, I strongly disagree.
-19:16 <@Chainsaw> jmbsvicetto: Common sense & leniency is applied in *reading* of policies, not in *writing*.
-19:16 <@bonsaikitten> in a perfect world we wouldn't need the rules as people would just agree on common sense
-19:17 <@Chainsaw> jmbsvicetto: We have existing commit review practices that solve all this by concensus.
-19:17 <@jmbsvicetto> Chainsaw: can you please elaborate further? (I'm trying to determine if my comment wasn't clear or gave any wrong impressions)
-19:18 <@Chainsaw> jmbsvicetto: gentoo-dev@ <dev_a> Hey Chainsaw, you didn't update the Changelog for your commit X on foo-bar/baz-3.21 <Chainsaw> I didn't feel it was necessary, because blah blah blah.
-19:18 <@Chainsaw> jmbsvicetto: Two possible outcomes. (1) <dev_a> Oh, okay then. (2) <dev_a> I disagree, and I would like to hear what others have to say on this.
-19:18 <@jmbsvicetto> Chainsaw: ok, let me get back to 1 because I missed on crucial point: no matter how much one dislikes an approved policy, one has to respect it even while working on reviewing or removing it
-19:18 <@Chainsaw> jmbsvicetto: The leniency, the common sense, the view of the group as a whole... we have all this.
-19:19 <@bonsaikitten> Chainsaw: "stop attacking me you muppet" ;)
-19:19 <@Betelgeuse> jmbsvicetto: The first exception is probably clearer with something like "The ChangeLog must be updated with each commit until the removal of the whole package."
-19:19 <@jmbsvicetto> Betelgeuse: sure
-19:19 <@Chainsaw> Betelgeuse: Which will promptly get abused as "but I was removing something, it says that's okay. let me be."
-19:20 <@Betelgeuse> Chainsaw: If they abuse that I would just argue that they are malicious that should have a talk with QA.
-19:20 <@Betelgeuse> +and
-19:20 <@jmbsvicetto> All I'm saing is that I think it should be obvious that you don't run echangelog and commit saying I'm going to drop this from the tree and then commit the removal. However, some people are trying to use that absurd argument on their "campaign" against the echangelog policy
-19:20 <@wired> changing the wording will probably change nothing
-19:20 <@Chainsaw> jmbsvicetto: The correct response to an absurd argument is to reject it and keep the status quo.
-19:20 <@jmbsvicetto> that's why I'm saying we might want to "clear" that
-19:21 <@Chainsaw> jmbsvicetto: I am strongly opposed to making any further changes to the policy in question. It is unambiguous, it is producing inevitable but ultimately necessary & welcome results.
-19:21 <@scarabeus> how about we keep the strict policy, and ask infra to implement Fabians patch, if we decide that we want only generated changelogs it will save us some time
-19:22 <@jmbsvicetto> The second part was about people fixing a typo and comments - as long as it doesn't change the "code"
-19:22 <@Chainsaw> jmbsvicetto: And if the community feels that my hard line on this is wrong, I strongly encourage them to not vote me in for the next term.
-19:22 <@jmbsvicetto> Chainsaw: ok, I see your point
-19:22 <@jmbsvicetto> Chainsaw: to be clear, I'm open to make it a bit more flexible, but only about commits that don't change the code
-19:23 <@wired> I agree with Chainsaw here
-19:23 <@scarabeus> jmbsvicetto: all commits change code, even your whitespace sed can screwup
-19:23 <@jmbsvicetto> Should we have a vote on updating the policy or should we move on to other points, like getting automatic changelogs?
-19:23 <@Chainsaw> jmbsvicetto: The only safe commits are commits that do not change an ebuild.
-19:23 <@wired> I'd rather have exceptions to the written rule than open holes to the rule that will allow abuse
-19:23 <@jmbsvicetto> scarabeus: yes, but I'm talking about comment lines, not code lines
-19:23 <@bonsaikitten> automated changelogs are a good idea
-19:23 <@bonsaikitten> what needs to be done to get them?
-19:23 <@jmbsvicetto> bonsaikitten: just one second please
-19:24 <@Chainsaw> jmbsvicetto: Let me change this #!/bin/sh comment for a second.
-19:24 <@scarabeus> jmbsvicetto: well yeah but shit can happen you press enter while saving the file and do not notice and just commit the "tiny comment change" that breaks the ebuild :)
-19:24 <@jmbsvicetto> just to confirm, the majority isn't willing to discuss an update to the policy, correct? So no need for a vote and we can move forward
-19:24 <@Chainsaw> jmbsvicetto: It's okay, the rule says that anything with a leading hash is free game.
-19:24 <@wired> imo most people complaining about the strict rules are just using that to avoid doing something (removals) *they* think is wrong
-19:24 <@jmbsvicetto> Chainsaw: I understand, but that isn't what I'm talking about ;)
-19:25 <@Chainsaw> jmbsvicetto: But that's what I can turn your modification into with little thought.
-19:25 <@Betelgeuse> jmbsvicetto: To be sure you want to explicitly collect opinions.
-19:25 <@wired> in the end this whole deal is stupid, we are wasting tons of time arguing about something extremely easy to fix in a number of ways (other than changing the policy)
-19:25 <@jmbsvicetto> ok, so let's take care of this in a minute
-19:26 <@Chainsaw> wired: Refusal to delete ebuilds until the policy is changed, yes. I saw that. Where I come from we call that blackmail.
-19:26 <@Betelgeuse> I don't mind improving the documentation to be clearer on what happens when a package is removed.
-19:26 <@jmbsvicetto> Who votes about discussing changes to the policy? An yes vote means we will talk about updating it, a no vote means it stays as was approved and we move forward
-19:26 <@wired> Chainsaw: agreed. I find it hilariously stupid.
-19:26  * Chainsaw votes no; the policy is perfect, move on
-19:26 <@Betelgeuse> We could just add a new sentence: When the package is removed the ChangeLog is removed along with the rest of the files.
-19:26  * bonsaikitten abstains, indifferent either way as there are multiple solutions
-19:26 <@Betelgeuse> Or just note this in the summary
-19:27 <@wired> the whole changelog argument sucks. tons of email, bug comments, council time for something that's fixed with a 3 line script and an ssh master connection
-19:27 <@Betelgeuse> The exact text could just be left to people who usually maintain the document any way :)
-19:27 <@jmbsvicetto> Betelgeuse: I'll add a note in the summary about it - let's call if a "clarification of the policy"
-19:27 <@Betelgeuse> jmbsvicetto: Yeah and Recruiters/QA I think can improve the wording without council any way.
-19:27 <@jmbsvicetto> I'm still waiting for the votes so we can move forward
-19:28 <@jmbsvicetto> up till now we have: 1 no and 1 abstain
-19:28 <@wired> jmbsvicetto: I say we leave it as is.
-19:28 <@scarabeus> no keep the policy, the removal of the package is done without repoman and there is no possibility to run changelog in the category where you are doing the commit
-19:28 <@Betelgeuse> jmbsvicetto: no and let people who maintain document what happens with package removals
-19:29 <@jmbsvicetto> ok, so a no from me as well
-19:29 <@jmbsvicetto> so 5 no and 1 abstain vote
-19:29 <@wired> just a note
-19:29 <@wired> a strict policy doesn't mean we can't have exceptions ( Chainsaw's example was nice )
-19:30 <@jmbsvicetto> moving on, do we want to automate the process? How?
-19:30 <@jmbsvicetto> wired: sure
-19:30 <@Chainsaw> repoman -m could call echangelog & remanifest.
-19:30 <@wired> +1
-19:31 <@wired> I would also consider a server-side restriction if people get stubborn
-19:31 <@bonsaikitten> acceptable proposal
-19:31 <@scarabeus> i would preffer to run the thing on the server side only for rsync
-19:31 <@Chainsaw> wired: That's a technical solution to a social problem. Don't go there.
-19:31 <@scarabeus> so i just repoman commit
-19:31 <@jmbsvicetto> There was an argument about droping ChangeLogs altogether and get them create at cvs host. Do we want to address that?
-19:31 <@scarabeus> and then the server generatest the changelog on the server side from vcs
-19:31 <@wired> Chainsaw: agreed. infact I hate policies. but if we have to have them we have to make sure they are followed
-19:32 <@jmbsvicetto> Then there was also the argument about using a different scm altogether
-19:32 <@Chainsaw> jmbsvicetto: I believe the newer SCM would make adding autogeneration to the workflow easier.
-19:32 <@bonsaikitten> Chainsaw: future ideas
-19:32 <@Chainsaw> jmbsvicetto: So if anything, I would like to postpone automatic generation until that scm is in place.
-19:32 <@wired> jmbsvicetto: I'd welcome any better solution in the long run, but the repoman -m patch would be quicker until that happens
-19:32 <@Betelgeuse> I support server side generation and git but there's little concrete we can do besides join helping the efforts individually.
-19:32 <@Chainsaw> jmbsvicetto: What I see on the GIT migration worries me. It has a name.
-19:32 <@Chainsaw> jmbsvicetto: "Second system syndrome"
-19:33 <@jmbsvicetto> So, repoman -m calls echangelog for now and we strongly urge people to join the work to get the job done server side and moving to git?
-19:34 <@jmbsvicetto> shall we have a vote on that?
-19:34 <@scarabeus> Chainsaw: is it really that hard to do it on cvs side?
-19:34 <@scarabeus> Chainsaw: from what i see the script works on cvs quite fine
-19:35 <@scarabeus> ftr i expect git migration to take loong time unless somebody really adopt and work on it a lot
-19:35 <@Chainsaw> scarabeus: If you can easily do it on CVS, then I'm all for it.
-19:35 <@Chainsaw> scarabeus: What I don't want to see is it being used as another nail in the coffin of the CVS->GIT migration by adding more to the spec sheet.
-19:35 <@bonsaikitten> so if we can easily do it from CVS I'm all for it
-19:35 <@scarabeus> Chainsaw: nah the changelog generation on server side was always on "required for git migration"
-19:36 <@wired> it would probably make it simpler
-19:36 <@scarabeus> Chainsaw: it is harder to track changelog in git anyway :)
-19:36 <@scarabeus> (collisions)
-19:36 <@jmbsvicetto> ok, what about us voting the following:
-19:36 <@Chainsaw> scarabeus: *nod* That eases my reservations then.
-19:37 -!- angelos [angelos@gentoo/developer/angelos] has joined #gentoo-council
-19:38 <@jmbsvicetto> The council decision about automating changelog messages is that repoman be updated to add the commit message to changelog, until such time as changelogs can be created server side. The council also urges individual developers to join the effort to move the tree to git.
-19:38 < nirbheek> If I recall correctly, Fabian's analysis of server-side ChangeLog generation for CVS had numerous problems
-19:38  * Chainsaw votes YES
-19:38 <@wired> yes please
-19:38 <@scarabeus> yes
-19:39 <@jmbsvicetto> yes
-19:40 <@Chainsaw> (Please note that this in no way invalidates the vote on the unchanged policy; developers can commit to CVS without repoman and may try to do so)
-19:40 <@jmbsvicetto> yes from me as well
-19:40 <@bonsaikitten> I don't see the point of tacking on that git rider
-19:40 <@jmbsvicetto> who are we missing?
-19:40 <@bonsaikitten> yes to the first part, irrelevant to the second
-19:40 <@Betelgeuse> Chainsaw: I don't think committing without repoman in package directories is allowed
-19:40 <@jmbsvicetto> bonsaikitten: I'll not that on the summary
-19:41 <@jmbsvicetto> Betelgeuse: how do you vote?
-19:41 <@Chainsaw> Betelgeuse: I've seen it done without alarm bells ringing, so I just wanted to get that out there.
-19:41 <@Betelgeuse> Chainsaw: If you don't cause a problem you probably get away with it but doesn't make it allowed
-19:42 <@scarabeus> Chainsaw: that HAS a policy :) so QA should handle that :)
-19:42 <@Betelgeuse> jmbsvicetto: indifferent on the first as you could just as well wrap repoman as I do and yes and the second
-19:42 <@Betelgeuse> jmbsvicetto: so I don't see a need to mandate it
-19:42 <@Betelgeuse> if people find it easier then it can be added sure
-19:43 -!- tampakrap [~tampakrap@gentoo/developer/tampakrap] has joined #gentoo-council
-19:43 <@jmbsvicetto> Betelgeuse: sorry, I missed your 2nd point
-19:43 -!- antarus [~antarus@gentoo/developer/antarus] has joined #gentoo-council
-19:43 <@jmbsvicetto> Betelgeuse: "and yes and the second"? Yes to the 2nd point?
-19:43 <@scarabeus> just to be exact it is damn easy to dumb write wrapper: http://dpaste.com/552036/
-19:43 <@scarabeus> *write dumb
-19:44 <@Betelgeuse> scarabeus: indeed
-19:44 <@wired> scarabeus: I use this: http://paste.pocoo.org/show/403011/
-19:44 <@jmbsvicetto> Betelgeuse: mind clearing the above for the summary?
-19:45 <@Betelgeuse> jmbsvicetto: I support putting effort in to the git migration
-19:45 <@jmbsvicetto> ok, thanks
-19:45 <@jmbsvicetto> so let's move on
-19:45 <@jmbsvicetto> Have you read my proposal for the GLEP48 update?
-19:45 <@scarabeus> jmbsvicetto: post it for log purposes :)
-19:46 <@jmbsvicetto> yes, sorry I forgot to add the link
-19:46 <@jmbsvicetto> http://archives.gentoo.org/gentoo-project/msg_ac161677a6e06a8647e16420eeae8d47.xml
-19:48 <@bonsaikitten> jmbsvicetto: read it, looks sane and harmless at first glance
-19:48 < antarus> bonsaikitten: no it doesn't
-19:48 <@bonsaikitten> at first glance :)
-19:48 <@Betelgeuse> jmbsvicetto: The last point is problematic as it will take quite a while: 15 days QA + 17 days DevRel is a month to handle
-19:49 <@jmbsvicetto> Betelgeuse: 15 days and 17 days are the limits
-19:49 <@jmbsvicetto> nothing prevents QA and devrel from taking less time
-19:49 <@Betelgeuse> DevRel usually takes the full time.
-19:49 <@Betelgeuse> (or more when we fail)
-19:49 <@jmbsvicetto> and this is about the extreme case
-19:49 <@jmbsvicetto> sure, but we will have to take the blame for that
-19:50 <+dberkholz> i don't see why the QA team should be different from anyone else when escalating an issue to devrel
-19:50 < antarus> not to be a dick to flameeyes, but when the QA team is lead by crazy people I don't really feel happy giving them that kind of power
-19:50 <+dberkholz> since it's specifically about nontechnical issues
-19:50 <+dberkholz> so i'm not sure why that needs to be in the glep
-19:50 <@jmbsvicetto> One thing I didn't write was that the last time we talked about this, the idea was that if QA failed to comply with the 15 days then the suspension would be immediately reversed
-19:51 <@jmbsvicetto> Should we reduce that time window? 1 week?
-19:52 <@Betelgeuse> jmbsvicetto: If we go as dberkholz suggested they get the DevRel 3 days
-19:52 <@scarabeus> 3 days are enough
-19:52 <@scarabeus> remember qa fill the bug
-19:52 <@scarabeus> so they already have some evidence
-19:52 <@scarabeus> so they just need to put it up and post
-19:52 < c1pher> scarabeus: +1
-19:52 <@jmbsvicetto> I have no problem with taking that 15 days part out
-19:52 < antarus> jmbsvicetto: I am writing a short writeup, although I doubt anyone will  heed it ;p
-19:53 <@Betelgeuse> jmbsvicetto: The other problem is that the text says nothing what happens after someone is suspended.
-19:53 <@jmbsvicetto> given the discussion, let me replace the following:
-19:53 <@jmbsvicetto>  Whenever the QA team escalates an issue to DevRel, it shall have 15 days to
-19:53 <@jmbsvicetto> +  present the case and provide support evidence. DevRel shall then follow its
-19:53 <@jmbsvicetto> +  established policies to evaluate it.
-19:53 <+dberkholz> scarabeus: it's talking about escalating nontechnical issues only there. the bug is normally filed about technical ones...
-19:53 <@Betelgeuse> How do they get access restored or revoked permanently.
-19:53 <@Betelgeuse> jmbsvicetto: Just remove the point fully?
-19:54 <@Betelgeuse> jmbsvicetto: As they are the same as any other DevRel bug reporter.
-19:54 <@scarabeus> antarus: about abusing powers, did really diego over used them? or the QA resolution for samuli's bug for example is bad and offending (the attachment at the bug)?
-19:54 <@jmbsvicetto> with "Whenever the QA team escalates an issue to DevRel, it shall follow DevRel's established policies, meaning it has 3 days to present evidence about the case."
-19:55 <@scarabeus> jmbsvicetto: Whenever the QA team escalates an issue to the DevRel, it follows the Devrel's established policies.
-19:55 <@jmbsvicetto> Betelgeuse: My proposal in this update is to give the decision about suspension to QA as long as the issue remains techincal
-19:55 -!- NeddySeagoon [~NeddySeag@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-19:56 <@jmbsvicetto> So developers that won't fix the issue with QA, can appeal to the council or open a bug to devrel if they think QA is abusing powers
-19:56 < antarus> scarabeus: to get away from Diego for a moment, it is not clear to me how new QA policies are added
-19:56 <+dberkholz> so the idea is that QA can determine on its own how long suspensions should last, rather than it being set in stone by a glep. right?
-19:56 <@Betelgeuse> dberkholz: that's already the case with DevRel too
-19:56 <@jmbsvicetto> brb
-19:56 <@scarabeus> antarus: policies are added by council or by dicussion on -dev/qa mls and should be voted by qa members
-19:57 <@scarabeus> antarus: also there are not MUCH new policies as we are quite swamped by current ones anyway :D
-19:57 <+dberkholz> Betelgeuse: i agree with it, i was just trying to make sure that's what was intended
-19:57 <@Betelgeuse> Before QA fully handling the issues they really should have established practises on how they process issues.
-19:57 <@jmbsvicetto> dberkholz: yes
-19:57 <@scarabeus> s/we/QA/
-19:57 < antarus> scarabeus: I dislike that QA both makes and enforces policy
-19:58 <@bonsaikitten> good point
-19:58 <@wired> council should always have the final word on new global policies
-19:58 <@scarabeus> antarus: there is council above them if they accept weird policy council can smash their fingers
-19:58 < ssuominen> Half of the QA team doesn't even agree adding or removing a ChangeLog entry belongs to the team -> Unjustified removal of commit access
-19:58 < antarus> scarabeus: good I like finger smashing ;p
-19:59 <@bonsaikitten> so I think we won't reach a consensus there yet. Push back to ML for further discussion?
-19:59 <@jmbsvicetto> antarus: my point is that QA should enforce policies and provide input on creating policies
-19:59 <@Betelgeuse> ssuominen: council > QA
-19:59 <@jmbsvicetto> antarus: they shouldn't "approve" policies
-19:59 <+dberkholz> i prefer that QA both makes and enforces policy
-19:59 < antarus> dberkholz: I would be happier if policies were a bit more squishy
-19:59 <@jmbsvicetto> bonsaikitten: push back my proposal?
-19:59 < antarus> like debian, ironically ;)
-20:00 <@wired> qa suggests policy, council accepts policy, qa enforces them
-20:00 <@jmbsvicetto> bonsaikitten: I don't mind, but seeing as no one bothered to comment on it in the last week, I don't see that changing :P
-20:00 <+dberkholz> so would i. i also think there are too many policies for one-time occurrences because we don't let "enforcers" do anything without a policy for it
-20:00 <@bonsaikitten> jmbsvicetto: we're taking much time for a discussion that seems to have no clear goal yet
-20:01 <@jmbsvicetto> ok, proposal pushed back to the ml
-20:01 <@scarabeus> poor next council...
-20:01 <@jmbsvicetto> removal of old-style virtuals
-20:01 <@wired> scarabeus: heh
-20:01 <@scarabeus> wired: just joking :)
-20:01 <@jmbsvicetto> bonsaikitten: I'll be sponsoring this to the new council
-20:01 <@jmbsvicetto> (my GLEP48 update proposal)
-20:01 <@Betelgeuse> jmbsvicetto: Can we at least vote to commit the non suspension related parts?
-20:01 <@Betelgeuse> We should get at least the agreed parts committed.
-20:02 <@jmbsvicetto> I'm fine with that
-20:02 <@Betelgeuse> http://www.gentoo.org/proj/en/glep/glep-0048.html
-20:02 <@Betelgeuse> The official GLEP 48 can't be some diff somewhere
-20:02 <@jmbsvicetto> Betelgeuse: what part do you suggest we use?
-20:02 <@jmbsvicetto> Betelgeuse: do you mind pasting the diff so we can vote on it?
-20:03 <@jmbsvicetto> If it gets approved I pledge to commit it to the glep space or get someone to do it (me looks at antarus)
-20:03 <@scarabeus> jmbsvicetto: just ommit last for bullets from it and it is the previously approved update so lets just push that
-20:04 <@scarabeus> s/for/four/
-20:04 <@Betelgeuse> jmbsvicetto: http://paste.pocoo.org/show/403024/
-20:04 <@jmbsvicetto> scarabeus: I added an initial point as well
-20:04 < antarus> jmbsvicetto: http://pastebin.com/C1jGF1DJ
-20:04 < antarus> jmbsvicetto: is my short ditty
-20:04 <@scarabeus> jmbsvicetto: but that one is not questionable :)
-20:04 < antarus> I think suspending someone over missing Changelog entries is somewhat laughable
-20:05 < ssuominen> antarus: I call it power mongering.
-20:05 <@jmbsvicetto> I'm trying to open both here
-20:05 < antarus> I do appreciate that Gentoo had the balls to do it though ;)
-20:05 < antarus> ssuominen: death by a thousand cuts is a difficult problem to fix :/
-20:05 <@Betelgeuse> antarus: missing and explicitly refusing are different
-20:05 <@bonsaikitten> antarus: slippery slope ... what other rules are ignored?
-20:05 <@scarabeus> antarus: it was not over missing changelog, but over not willing to stop doing that
-20:06 < antarus> bonsaikitten: the proposal details severity bits attached to violations
-20:06 <@jmbsvicetto> antarus: skimming over your paste, that seems most appropriate to the QA team page than to GLEP48
-20:06 < antarus> bonsaikitten: I don't think missing changelogs are 'dangerous' to end users
-20:06 <@scarabeus> eg it was to be expected the policy will be further ignored by the developer if the access is kept
-20:06 < antarus> the proposal = my ditty
-20:06 <@jmbsvicetto> so, shall we commit the diff Betelgeuse pasted?
-20:06 <@jmbsvicetto> I say yes
-20:06 <@bonsaikitten> antarus: but disrespect of rules can be
-20:06 < antarus> jmbsvicetto: perhaps I should run for QA lead then ;p
-20:06  * Chainsaw votes YES for the Betelgeuse diff
-20:06 < ssuominen> antarus: yes, please
-20:06 < antarus> bonsaikitten: true enough ;)
-20:07 <@bonsaikitten> consider it a vote of confidence ;)
-20:07 < antarus> bonsaikitten: as I said, I appreciate the tenacity
-20:07  * scarabeus vote yes for the diff
-20:07 <+dberkholz> antarus: ever heard that story about broken windows and murders in new york city?
-20:07 <@Betelgeuse> yes
-20:07 <@wired> yes
-20:07 < nirbheek> antarus, I think it's overcompensation :p
-20:07 <@jmbsvicetto> so, 6 yes votes
-20:07  * bonsaikitten votes yes for the Betelgeuse diff
-20:07 < antarus> dberkholz: are you talking about the famous 'fail to assist' case?
-20:08 <@jmbsvicetto> antarus: If I can't commit that diff to the glep space, I'm going to poke you to do it
-20:08 < antarus> dberkholz: or something else?
-20:08 < antarus> jmbsvicetto: ok
-20:08 < antarus> jmbsvicetto: I'm pretty sure anyone can commit gleps though
-20:08 <+dberkholz> antarus: nope. telling the policy to go enforce people who break windows and put graffiti on walls lowered the murder rate by 72%
-20:08 <@jmbsvicetto> moving on, removal of old-style virtuals
-20:08 <+dberkholz> police*
-20:08 <@jmbsvicetto> ulm_ / zmedico: Do you guys have anything more to say about it?
-20:08 < antarus> dberkholz: I take your point
-20:09 < ulm> jmbsvicetto: should be all said in the posting to the ml and in the respective bug
-20:09 < zmedico> jmbsvicetto: no :)
-20:09 < antarus> I propose we move Gentoo to Singapore, I hear there is very little crime there
-20:09 <@jmbsvicetto> ulm: I only have one question: is there any compatibility issue for people with old installs?
-20:10 < ulm> I don't think so, it should be comparable to a package removal
-20:10 <@jmbsvicetto> ok, thanks
-20:10 < zmedico> yeah, roughtly
-20:10 <@jmbsvicetto> Can we vote on this proposal?
-20:10 < ulm> i.e. if portage doesn't resolve the old-style virtual any more, the package depending on it would pull in the new-style virtual
-20:11 <@Betelgeuse> What happens with vdb for old packages?
-20:11 <@Betelgeuse> ulm: hmm true
-20:12 <@jmbsvicetto> bonsaikitten / Chainsaw / scarabeus / wired: ^^
-20:12 <@scarabeus> i agree with the ban, it should not cause issues from what i see :)
-20:12 <@Chainsaw> jmbsvicetto: Please state the proposal, for the record.
-20:12 <@scarabeus> or should i say removal rather than ban? well anyway ack
-20:12 <@bonsaikitten> removing old-style virtuals, I'm in favour of that idea.
-20:12  * Chainsaw votes YES on removing old-style virtuals
-20:13 <@wired> yes
-20:13 <@jmbsvicetto> ok, let me add the link - http://archives.gentoo.org/gentoo-project/msg_7986aa2d9651c600f7302a8d84cc3721.xml
-20:13 <@Betelgeuse> yes
-20:13 <@jmbsvicetto> yes
-20:14 <@jmbsvicetto> so 6 votes for the removal
-20:14 <@jmbsvicetto> moving on
-20:14 < ulm> thanks
-20:14 <@jmbsvicetto> Do we want to look back at this term and share some thought and or make a balance?
-20:15 <@scarabeus> It was quite fun :) and i think we didn't do really bad job at this :)
-20:15 <@jmbsvicetto> thoughts*
-20:15 <@scarabeus> but we still didn't get GIT done :D
-20:15 -!- toralf [~toralf@g224126229.adsl.alicedsl.de] has joined #gentoo-council
-20:16 <@scarabeus> just look on nirbheeks sad face, he must be disappointed by this council
-20:17 <@bonsaikitten> so I resubmit for the next council to discuss and agree on signing keys and key distribution mechanisms
-20:17  * bonsaikitten is a persistent bugger :)
-20:17 <+dberkholz> if only we could take all the time spent in meetings and have the 7 of you work on git instead
-20:17 <@scarabeus> dberkholz: didn't i work on git? :D more on the eclass side but i did :D
-20:18 < nirbheek> scarabeus, I am disappoint.
-20:18 <+dberkholz> i propose that all council candidates not elected set aside time to do this, since they clearly had the time to spare =P
-20:18 <@jmbsvicetto> hehe
-20:18  * wired had substantially less time than what he wanted to spend on gentoo + the council this term
-20:19 <@scarabeus> btw bit offtopic how would you feel if council elect qa lead from the nominees generated by the qa team? (it is just question, not something i would plan as i am no longer even qa member)
-20:19 <@jmbsvicetto> Looking at my manifesto for the election, I clearly left GLEP 39 reform behind. I had a talk on FOSDEM with Petteri and Roy that touched the issue, but I didn't got to write any proposals yet
-20:19 <@bonsaikitten> well, better luck next time ;)
-20:20 <@jmbsvicetto> scarabeus: I believe council should not elect team leads
-20:20 <@scarabeus> i can say i improved the qa interaction :D or at least we spent almost all time talking about qa :D
-20:20 <@bonsaikitten> things never go as planned, but I think we had a good time here
-20:20 <@jmbsvicetto> scarabeus: and that's something for GLEP 39 ;)
-20:20 <@Chainsaw> And in the case of bonsaikitten, short term, big waves. Watch that space :)
-20:21 <@jmbsvicetto> It was a pleasure working with all of you on this term and I think we tried to get a few things rolling :)
-20:21 <@bonsaikitten> Chainsaw: and one does wonder if someone is crazy enough to vote me back in
-20:21 <@Chainsaw> bonsaikitten: You never know :)
-20:21 < antarus> bonsaikitten: nothing burned down :)
-20:21 <@bonsaikitten> antarus: I can change that
-20:21 <@scarabeus> bonsaikitten: why not, you didn't burn anything out :)
-20:21 <@Chainsaw> jmbsvicetto: Thank you for the various phone calls, which made a real difference for me.
-20:21 <@jmbsvicetto> I hope to also be able to get the arch teams and automation stuff moving
-20:21  * NeddySeagoon wonders if any of the current council are going to accept their nominations 
-20:21 <@Chainsaw> What nominations?
-20:22 <@wired> jmbsvicetto nominated us all
-20:22 <@bonsaikitten> NeddySeagoon: yes, as soon as I can think of a manifesto-like thingy
-20:22 <@bonsaikitten> more than "yes", in essence ;)
-20:22 < NeddySeagoon> wired, except one
-20:22 <@jmbsvicetto> NeddySeagoon: dilfridge fixed that ;)
-20:22 < NeddySeagoon> jmbsvicetto, yes
-20:22 <@jmbsvicetto> dilfridge: thanks again for that
-20:23 < NeddySeagoon> Chainsaw, read the projects ml
-20:23 <@jmbsvicetto> So, any more comments or should we move on?
-20:24 <@wired> yeah, here's to an even better term for the next council :)
-20:24 <@wired> nice working with y'all
-20:24 <@Betelgeuse> Thanks all.
-20:24 <@bonsaikitten> was nice to finally not be The Other Choice :)
-20:24 <@bonsaikitten> although I guess it kept people honest
-20:25 < NeddySeagoon> you don't get to retire until the new council is elected
-20:25 <@Chainsaw> NeddySeagoon: Oh shoot, you mean I have to cancel my ticket to the Bahamas?
-20:25 <@Chainsaw> NeddySeagoon: My plane leaves tomorrow morning!
-20:25 <@jmbsvicetto> One last thing I think we should do is quickly go over the current open bugs and give a short status update so the next council can have an idea where things stand
-20:25 < NeddySeagoon> Chainsaw, you can serve from there
-20:25 <@Betelgeuse> jmbsvicetto: has there been a change?
-20:26 <@jmbsvicetto> Chainsaw: no running away ;)
-20:26 <@Betelgeuse> jmbsvicetto: you around?
-20:26 <@Betelgeuse> jbartosik: ^
-20:26 < jbartosik> Yes :)
-20:26 <@wired> jmbsvicetto: I have one bug to still take care of before the elections
-20:26 <@jmbsvicetto> Betelgeuse: not by my part.
-20:26  * jbartosik begins talking about webapp
-20:26 <@Betelgeuse> jmbsvicetto: maybe we could look at the web app status before then
-20:26 <@jmbsvicetto> I failed to take care of bug 237381
-20:26 < willikins> https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; CONF; dberkholz:jmbsvicetto
-20:27 <@jmbsvicetto> Betelgeuse: ok
-20:27 <@jmbsvicetto> jbartosik: the floor is yours :)
-20:27 < jbartosik> You can see a working demo of the application on http://morning-winter-26.heroku.com/
-20:27 < jbartosik> Unfortunately there is a problem when application runs on heroku, and pages that give data to IRC bot
-20:27 < jbartosik> So I will need nicks of those who would like to talk to the bot later (if you want to, please say it now)
-20:28 <@bonsaikitten> so I shall disappear now. Talk to y'all soon / tomorrow :)
-20:29 < jbartosik> Allright looks like I'll just demo bot myself
-20:29 < jbartosik> As a guest you can view old & current agendas
-20:29 < jbartosik> If you want to suggest agenda items you need to register
-20:29 < jbartosik> If you do register, please use fake email (application doesn't need your real email).
-20:30 < jbartosik> When you're done looking on the application as a regular user please tell me
-20:30 < jbartosik> And give me a link to your profile ("Logged in as ..." in top-right corner)
-20:30 < jbartosik> Then I'll give you council member role
-20:30 <@Betelgeuse> jbartosik: http://morning-winter-26.heroku.com/users/3-betelgeuse
-20:31 <@jmbsvicetto> jbartosik: http://morning-winter-26.heroku.com/users/4-jorge-manuel-b-s-vicetto
-20:31 < jbartosik> Betelgeuse: Given
-20:31 <@scarabeus> http://morning-winter-26.heroku.com/users/5-scarabeus
-20:31 <@jmbsvicetto> jbartosik: what's the bot name?
-20:31 < jbartosik> jmbsvicetto:  I gave you council_member role
-20:32 < jbartosik>  jmbsvicetto: bot is not here, it's on #gentoo-council-webapp-testing
-20:32 < jbartosik> As council member when you view current agenda you can change it's state
-20:32 < jbartosik> To do this go to "Agendas" tab, then follow link to current agenda and click links on the bottom of the page
-20:32 < jbartosik> Note that when agenda becomes "old" (archived) a new agenda is created
-20:32 < jbartosik> As council members you can also add suggested items to current agenda, reject them and add voting options for items
-20:32 <@wired> http://morning-winter-26.heroku.com/users/6-wired/account
-20:32 < jbartosik> To do this view current agenda then click one of items and use buttons at the bottom of the page
-20:33 < jbartosik> wired: added role
-20:33 < jbartosik> Please let me know when you'd like to take a look at the bot
-20:35  * wired wants to see how voting works
-20:36 <@jmbsvicetto> jbartosik: I'm ready
-20:36 <@jmbsvicetto> wired: me too
-20:36 <+dberkholz> i'm curious about the weirder stuff
-20:36 <+dberkholz> like, stopping a vote in the middle, restarting it, changing the text of the vote, etc.
-20:36 < jbartosik> Please join #gentoo-council-webapp-testing
-20:36 <@wired> can someone vote through the interface later?
-20:36 < jbartosik> dberkholz: you can resume voting as many times as you want
-20:37 <@Betelgeuse> wired: not yet but it's been a couply weeks now
-20:37 <@Betelgeuse> +only
-20:37 <+dberkholz> jbartosik: can you reset the count?
-20:37 < jbartosik> dberkholz:  also you can vote many times for one item
-20:37 < jbartosik> dberkholz: oonly newest vote will be counted
-20:37 < jbartosik> dberkholz: no, ou can't reset vote now
-20:37 <+dberkholz> that mostly solves the problem, except when someone votes and then goes afk before the 2nd one
-20:40 < nirbheek> Wouldn't that set his/her vote to "abstain"?
-20:40 <@jmbsvicetto> jbartosik: ^^
-20:41 -!- ulm [~ulm@gentoo/developer/ulm] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
-20:45 -!- hypertux [~hypertux@vps1.joelegasse.com] has left #gentoo-council []
-20:52 -!- tampakrap [~tampakrap@gentoo/developer/tampakrap] has left #gentoo-council ["http://quassel-irc.org - Chat comfortably. Anywhere."]
-20:53 <@Betelgeuse> jmbsvicetto: ok let's move on
-20:53 <@jmbsvicetto> So does anyone have anything to say about the currently open bugs?
-20:54 <@jmbsvicetto> I just commited the update to GLEP48, so we can probably close bug 362803
-20:54 < willikins> jmbsvicetto: https://bugs.gentoo.org/362803 "GLEP 48 (QA Team's Role and Purpose) update per council decision"; Gentoo Linux, Unspecified; CONF; tove:qa
-20:54 <@jmbsvicetto> I'll work on the guideXML update later tonight
-20:54 <@scarabeus> jmbsvicetto: awesome :)
-20:55 <@wired> i still have to fix bug 341959 which I failed to take care of until now, I'll fix it soon
-20:55 < willikins> wired: https://bugs.gentoo.org/341959 "council changed the waiting period in "eclass removal policy""; Doc Other, Devmanual; CONF; tove:qa
-20:56 <@jmbsvicetto> If there is anything else, then we should open the floor to the community
-20:57 <@jmbsvicetto> This is the last chance to get anything in this council term, so do it now or ... ;)
-20:57 < jbartosik> nirbheek, jmbsvicetto: Not resuming vote doesn't change anyvotes already given.
-20:57 <@wired> jmbsvicetto: flip the switch
-20:57 <@wired> :)
-20:58 <@jmbsvicetto> ok, once more thank you for being here and for this last year
-20:58 -!- jmbsvicetto changed the topic of #gentoo-council to: Next meeting: up to the new council | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/ | agenda - http://archives.gentoo.org/gentoo-project/msg_0a7935a1097ba0aa41c3370a20679f9a.xml
-20:58  * jmbsvicetto closes the meeting
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110715-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20110715-summary.txt
deleted file mode 100644
index 78507ac861..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110715-summary.txt
+++ /dev/null
@@ -1,90 +0,0 @@
-Council 2011/07/15 meeting summary
-==================================
-
-
-Agenda
-------
-
- * allow all members to show up (5 min)
-
- * select the probable date for the monthly meetings (5 min)
- * discuss desired model of operation (15 min)
- * allow council members to present issues to be addressed in this term (15 min)
- * listen to the community to see if there are any issues it would like
-   to see the council address in this term (10 min)
- * next meeting date / chair
-
- * Open Floor (10 min)
-       
-
-Meeting
--------
-
- * roll call
-
-    here:
-
-    Betelgeuse
-    chainsaw
-    dberkholz
-    grobian
-    hwoarang
-    jmbsvicetto
-    ulm
-
- * vote/discuss:
-
-   * select the probable date for the monthly meetings
-
-     2nd Tuesday of the month at 1900 UTC
-     
-   * discuss desired model of operation (15 min)
-
-     After a review of some of the rules used by the previous council, the council
-     members opted to keep some and review others:
-     - instead of choosing the chair for the next meeting at the end of a meeting,
-     interested volunteers will send an email to the mls manifesting their willingness
-     and the council will setup a schedule for the whole year by rotating the task by
-     them. Chairs will also serve as secretaries and summaries should be maintained
-     during meetings by using a collaborative tool. 
-     - the council will use bugs to track issues. A specific council member will be
-     assigned to each bug to track it. The bugs progress will be reviewed on meetings.
-     - the council members will discuss issues in the mls before the meetings so they
-     can focus on voting during the meetings.
-     - the council is open to have a 2nd montly meeting (possibly on the 4th Tuesday
-     of the month) or impromptu meetings when required.
-     Petteri recalled the council webapp and bot work is progressing so that should
-     help with chairing the meetings.
-
-   * allow council members to present issues to be addressed in this term
-   
-     No member opted to present any issues at this time.
-
-   * Jorge requested during the meeting that the council election results be moved to
-     the elections project space and be linked from the council space, instead of the
-     current duplication. The council members agreed with the change and Jorge will
-     ensure it is carried out.
-
-   * Donnie asked for a clarification by the council members on whether they think a
-     global dev vote is required to update GLEP39 or not. The council voted 5 yes and
-     1 no that the council can't change GLEP39 as it requires a full developer vote.
-
-   * The council voted 4 yes and 3 no that there's no requirement for another meeting
-     this month to meet the requirements of GLEP39.
-
- * listen to the community to see if there are any issues it would like
-   to see the council address in this term
-
-   No issues were brought up to the council by the community.
-
- * Next meeting date
-
-   Tuesday, 20110809 1900 UTC
-
-
-The following items will be discussed in the mls before the next meeting:
-
- * council members will express their willingness to chair meetings
- * Donnie will create a schedule and distribute the chairing role on a rotation basis
-   by the above list
- * required advance notice for council meetings
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110715.txt b/xml/htdocs/proj/en/council/meeting-logs/20110715.txt
deleted file mode 100644
index 40d97c1b7c..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110715.txt
+++ /dev/null
@@ -1,420 +0,0 @@
-19:00 <@dberkholz> afternoon everybody
-19:01 <@dberkholz> who's here?
-19:01 <@Chainsaw> Ready and waiting.
-19:02 -!- adeel [~adeel@c-67-174-60-55.hsd1.ca.comcast.net] has joined #gentoo-council
-19:02 <@grobian> ready
-19:02 <@jmbsvicetto> time
-19:02 <@jmbsvicetto> so let's have roll call
-19:02  * hwoarang here
-19:02 -!- mode/#gentoo-council [-oo bonsaikitten DrEeevil] by jmbsvicetto
-19:02  * Chainsaw salutes
-19:02 <@jmbsvicetto> here
-19:02 <@grobian> here
-19:03 <@Chainsaw> Yes, present.
-19:03 <@dberkholz> jmbsvicetto: here, and i think your clock is a couple of minutes slow =P
-19:03 <@jmbsvicetto> yeah, I was writing a few things for the meeting. Sorry
-19:03 <@jmbsvicetto> Betelgeuse: pong
-19:04 <@dberkholz> ulm: around?
-19:05 <@jmbsvicetto> let me grab my phone to poke Betelgeuse 
-19:05 <@Betelgeuse> jmbsvicetto: hello
-19:05 <@jmbsvicetto> Betelgeuse: just in time ;)
-19:06 <@jmbsvicetto> I'm calling ulm 
-19:07 -!- adeel [~adeel@c-67-174-60-55.hsd1.ca.comcast.net] has quit [Quit: Leaving]
-19:07 <@jmbsvicetto> He should be poking in soon
-19:07 <@ulm> hi :)
-19:07 <@jmbsvicetto> so the agenda is on http://archives.gentoo.org/gentoo-dev-announce/msg_aff1618a1bd37eb4f991d4e386b74b77.xml
-19:08 <@jmbsvicetto> shall we move to the probable meeting schedule?
-19:08 <@Chainsaw> Please proceed.
-19:09 <@jmbsvicetto> Those of you that replied seem to prefer 1800 - 2200 UTC on weekdays, correct'
-19:09 <@jmbsvicetto> s/'/?/
-19:09 <@Chainsaw> Indeed, that would work very well for me.
-19:09 <@hwoarang> yeah seems better
-19:09 <@Chainsaw> Can't do the first Tuesday of each month, but no other restrictions Mon-Fri.
-19:09 <@grobian> ok, ready here
-19:09 <@jmbsvicetto> seems you may all be happy with keeping the 2nd Tuesday of the month too
-19:09 <@Chainsaw> I'll sign for that, yeah.
-19:09 <@hwoarang> +1
-19:09 <@grobian> tuesday is ok for me
-19:09 <@ulm> tuesday is fine
-19:10 <@Betelgeuse> ok
-19:10 <@dberkholz> 2nd tuesday at 1900 is the same as before, right? that would be fine with me
-19:10 <@jmbsvicetto> we might do 1900 until the day savings time kicks in and 1800 after that. But there's time to think about it (should happen on October irc)
-19:10 <@jmbsvicetto> iirc*
-19:11 <@Chainsaw> Yes, let's cross that bridge when we get there.
-19:11 <@Chainsaw> Sounds unanimous then.
-19:11 <@jmbsvicetto> So, we can keep the 2nd Tuesday of the month 1900UTC as the "default" schedule for meetings.
-19:11 <@ulm> jmbsvicetto: shouldn't it be the other way around, 1900 in summer and 2000 in winter
-19:12 <@jmbsvicetto> ulm: yeah, I think I went the wrong direction
-19:12 <@jmbsvicetto> So, do we want to set a desired "model of operation"?
-19:13 <@hwoarang> what exactly do you mean by that/
-19:13 <@grobian> what exactly do you mean?
-19:13 <@Betelgeuse> starting earlier works for me though :)
-19:14 <@Chainsaw> Can we lock the agenda 48 hours in advance of the meeting, rather than a week in advance of the meeting?
-19:14 <@jmbsvicetto> How do we want to conduct our meetings
-19:14 <@dberkholz> jmbsvicetto: could you remind those of us who are new of the current mode of operation?
-19:14 <@Chainsaw> That should still prevent us from booking stealth meetings and passing resolutions without scrutiny.
-19:14 <@jmbsvicetto> ok, a few things we decided for last term:
-19:14 <@Chainsaw> But we would be able to respond sooner to concerns.
-19:15 <@jmbsvicetto> no secretary. we rotate the role between members
-19:15 <@jmbsvicetto> we've used google's wave for a while to do summaries during meeting
-19:15 <@jmbsvicetto> use bugs to track council issues and try to discuss progress on each meeting
-19:16 <@jmbsvicetto> be open for 2nd monthly meeting or improptu meeting when required
-19:16 <@grobian> ok, sounds good, except for the google wave thing
-19:16 <@jmbsvicetto> This won't "release" us from having the regular meetings with enough advance notice
-19:17 <@jmbsvicetto> Betelgeuse / Chainsaw: Can you think of anything else?
-19:17 <@hwoarang> i wonder if one meeting per month suffices
-19:17 <@jmbsvicetto> btw, I'm logging this meeting and will do log and summary
-19:18 <@Chainsaw> jmbsvicetto: It is appreciated.
-19:18 <@Chainsaw> hwoarang: You would prefer to meet once a fortnight?
-19:18 <@dberkholz> i really appreciated having a dedicated secretary in the past. it can be a bit of a distraction to deal with that and maintain an active meeting
-19:18 <@jmbsvicetto> Do we want to set any other "rules" for meetings?
-19:18 <@hwoarang> Chainsaw: i would prefer to have two meetings/month each one of them being a short one
-19:18 <@hwoarang> instead of having a long one every month
-19:19 <@ulm> can we discuss topics on the council mailing list in advance, so that less time during the meetings will be spent for discussions?
-19:19 <@Chainsaw> hwoarang: There is no such thing as a short meeting. Not with 7 participants and an open floor segment.
-19:19 <@hwoarang> this will guarantee the continuity of the agenda
-19:19 <@jmbsvicetto> hwoarang: from last year experience, I can tell you that at times there's no need for that
-19:19 <@dberkholz> Chainsaw: there is if you set a time limit =)
-19:19 <@ulm> i.e. during the meetings there should be mostly votes, and the discussion could take place in advance
-19:19 <@hwoarang> Chainsaw: yeah but you will have shorter agendas
-19:19 <@grobian> +1 for discussing more and in-depth on the ML
-19:19 <@jmbsvicetto> dberkholz: well, I think we kept a very good track of logs and summaries in the last year
-19:19 <@dberkholz> ulm: yes, i greatly prefer that
-19:20 <@Betelgeuse> jmbsvicetto: the web app is progressing
-19:20 <@Betelgeuse> dberkholz: the meeting bot should help reduce the need for a secretary
-19:20 <@hwoarang> jmbsvicetto: fair enough. I trust your experience
-19:20 <@jmbsvicetto> ulm: that's also something we did / tried to do last year (get things discussed on ml before meetings)
-19:20 <@hwoarang> i seems though that the 31 days gap is quite large
-19:21 <@dberkholz> perhaps we could reserve the 4th tuesday as needed, but not schedule meetings in advance for it.
-19:21 <@hwoarang> unless of course there is active discussion on alias/ML beforehand
-19:21 <@jmbsvicetto> dberkholz: I'm fine with that
-19:22 <@jmbsvicetto> so, to address some of the points, no secretary for now? We'll pick someone at the end of the meeting to chair the following meeting?
-19:22 <@ulm> dberkholz/hwoarang: sounds good
-19:22 <@hwoarang> jmbsvicetto: yes
-19:22 <@grobian> jmbsvicetto: ok
-19:22 <@dberkholz> i'd like to discuss neddy's proposal that we select a permanent meeting chair
-19:22 <@hwoarang> this worked well in the previous term
-19:23 <@dberkholz> if you hate the idea, just say so and we can move on, but i think there's value to it.
-19:23 <@jmbsvicetto> dberkholz: ok. I'm against that idea, but let's discuss it
-19:24 <@Betelgeuse> dberkholz: If someone is willing then perhaps.
-19:24 <@grobian> Not sure if I misunderstood, but "permanent" doesn't sound good
-19:24 <@dberkholz> with 7 people and only 1 meeting a month, it seems like people may not have time to get experienced enough at running a meeting really effectively
-19:24 <@grobian> I think the suggestion for two overlapping terms is a good one
-19:24 <@hwoarang> I don't like this option either. You have a "single point of failure" :)
-19:24 <@jmbsvicetto> in my view the council is a colective body that shouldn't have individual roles - all members should be "equal"
-19:24 <@ulm> yeah, chair should rotate
-19:25 <@dberkholz> you already know my view from my manifesto =P
-19:25 <@jmbsvicetto> dberkholz: about the experience on chairing, last term it was a "voluntary" job
-19:25 <@jmbsvicetto> dberkholz: I don't know if all council members ended up doing it and a few of us did it a few times
-19:25 -!- tove [~tove@smtp.gentoo.org] has left #gentoo-council []
-19:26 <@jmbsvicetto> dberkholz: but I'd rather have it as something that people volunteer when they can than to make it a "title"
-19:26 <@dberkholz> ok, let's do it then.
-19:26 <@jmbsvicetto> or "role"
-19:27 <@jmbsvicetto> Are you guys happy with the rest or do you want to discuss any of it?
-19:27 < Smiley> Am I allowed to talk?
-19:27 < Smiley> Surely once the bot is done, that'll do the "chairing" for you
-19:28 <@dberkholz> somebody will need to run the bot, and it won't write a summary on its own either
-19:28 < Smiley> #
-19:28 <@dberkholz> i don't think it eliminates the need for chairs or secretaries, maybe just makes the jobs a little easier
-19:29 <@Betelgeuse> jbartosik: if you are around feel free to contribute but check the logs later at least
-19:29 <@jmbsvicetto> just to list them again, the 2 other things I mentioned (with some update from this meeting) are:
-19:29 <@jmbsvicetto>    use bugs to track issues and discuss progress on each meeting
-19:29 <@jmbsvicetto>    be open for a 2nd monthy meeting (4th Tuesday of the month) or improptu meeting when
-19:29 <@jmbsvicetto> required
-19:29 <@jmbsvicetto> Oh and we should always appoint a council member to track a bug
-19:29 <@dberkholz> i must have missed how we were going to get summaries
-19:29 < NeddySeagoon> dberkholz, my fixed chair suggestion was aimed at cutting out the 10 minutes every meeting agreeing the chair for next time.  Rotating works too, if the rotation is agreed in advance
-19:29 <@Chainsaw> jmbsvicetto: The bugs didn't always seem to work last year.
-19:29 <@dberkholz> collaborative editing on google wave still?
-19:29 <@Chainsaw> jmbsvicetto: But I can't think of a better way.
-19:30 <@grobian> jmbsvicetto: bugs - yes, open - yes but not restricted to one day
-19:30 <@jmbsvicetto> dberkholz: That can be a good tool. In any case, the chair is responsible for sending the emails announcing a meeting, doing the agenda and submitting logs / summaries at the end of the meeting
-19:30 <@jmbsvicetto> grobian: sorry, one day?
-19:31 <@grobian> jmbsvicetto: yes, as in only the 4th tuesday
-19:31 <@jmbsvicetto> grobian: I meant to say that we should have a dedicated council member tracking each bug
-19:31 < NeddySeagoon> jmbsvicetto, even more important that the chair is fixed well in advance
-19:31 <@dberkholz> we could just say who's interested in being chair right now, and rotate evenly among those people for the rest of the year.
-19:31 <@jmbsvicetto> NeddySeagoon: that's why we do it in the previous meeting - that should be 1 month in advance
-19:32 <@grobian> jmbsvicetto: seems a bit pointless to me at this stage (me being new)
-19:32 <@dberkholz> that way we wouldn't ever need to think about it again
-19:32 <@Betelgeuse> dberkholz: I can do a meeting or two
-19:32 < NeddySeagoon> jmbsvicetto, it costs 10 minutes ... its not productive time
-19:32 <@jmbsvicetto> dberkholz: that works for me too. There just might be a few times where I won't be available for a specific date
-19:32  * antarus throws chairs
-19:32 <@jmbsvicetto> NeddySeagoon: in the past it has taken 3 or 4 minutes tops
-19:32 <@dberkholz> if you aren't available during your "scheduled" date, just trade with somebody and update the webpage.
-19:33 <@jmbsvicetto> grobian: the 4th Tuesday was meant for the 2nd montly meeting (if we have it)
-19:33 <@jmbsvicetto> dberkholz: I'm fine with that
-19:33 <@grobian> jmbsvicetto: yes, and I wouldn't restrict to that.
-19:33 <@jmbsvicetto> and I volunteer to be chair on a rotating base
-19:33 <@jmbsvicetto> grobian: ok
-19:33 <@grobian> jmbsvicetto: NeddySeagoon: could we do the chair discussion upfront on the ML perhaps? When the agenda is announced or something?
-19:34 <@jmbsvicetto> grobian: I was adding Donnie's suggestion that we make the 4th Tuesday the "default" option for the 2nd meeting
-19:34 <@jmbsvicetto> grobian: no, the chair is the one sending that email
-19:34 <@jmbsvicetto> grobian: at most we need to do it shortly after a meeting
-19:34 < NeddySeagoon> grobian, thats a little late as the chair has to announce the agenda
-19:34 <@grobian> then shift it with a week :)
-19:35 <@jmbsvicetto> But I like Donnie's idea of rotating between those of us willing to do it
-19:35 <@dberkholz> man, i can't keep straight what we've decided on and what's left. jmbsvicetto, are you keeping a summary during the meeting already that we could follow?
-19:35 <@grobian> but this kind of discussions are better suited for a ML IMO
-19:35 < NeddySeagoon> grobian, it works on list, if its done just after the meeting
-19:35 <@jmbsvicetto> dberkholz: I'm trying too :)
-19:35 <@grobian> NeddySeagoon: fine with me
-19:35 <@dberkholz> jmbsvicetto: is there a link to it somewhere?
-19:35 <@jmbsvicetto> at this point we haven't decided how to do the summaries or how to choose the chair
-19:36 <@jmbsvicetto> dberkholz: sorry, not yet. I'm doing it locally on kwrite
-19:36 <@jmbsvicetto> let me see if I can open wave quickly
-19:36 <@hwoarang> jmbsvicetto: google wave might not work for a long time since google announced that i will stop it sooner or later
-19:36 <@dberkholz> google docs does collaborative stuff too
-19:36 <@hwoarang> we can use google docs
-19:36 <@hwoarang> just a plain text file
-19:36 <@jmbsvicetto> ok
-19:37 <@grobian> jmbsvicetto: what's the purpose of meeting in IRC all at the same time?  (what are the goals?)
-19:37 <@Betelgeuse> grobian: GLEP 39 says it must be an open meeting
-19:37 <@Betelgeuse> grobian: Any suggestions on other ways to do that?
-19:37 < NeddySeagoon> grobian, GLEP 39 requires it
-19:38 <@grobian> fine, but we don't have to be chatting around here and throwing in random ideas all the time, do we?
-19:38 <@Betelgeuse> grobian: we don't
-19:38 < Smiley> thats why you need a chair.
-19:38 < Smiley> and an agenda.
-19:38 < Smiley> and then you mute everyone, and ask each persons view, one by one. Unmuting them in turn.
-19:38 < NeddySeagoon> and up front work, so the meeting is focused
-19:38 <@grobian> is it also ok to just vote on matters, and perhaps talk to persons involved with discussions
-19:39 <@grobian> fine, doit.
-19:39 <@Betelgeuse> grobian: yes
-19:39  * Smiley shuts up again.
-19:39 <@jmbsvicetto> I'd say it has at least the following goals: to have the council as a team and not just a group of people, to spark discussions, to open up scrutiny on council's decisions, to allow community members to track meetings and to try to participate (even if by poking members privately)
-19:39 <@Betelgeuse> No format will automatically make people prepare.
-19:40 <@grobian> jmbsvicetto: ok, thanks
-19:40 < NeddySeagoon> Betelgeuse, nope but it makes for shorter meetings
-19:40 <@dberkholz> as far as i'm concerned, we could do pretty much everything on list, vote on the webapp, and meetings would just serve as due dates for tasks as well as open floor.
-19:40 < NeddySeagoon> then you get to bead early :)
-19:40 < Smiley> What is the obcession with being so quick?
-19:40 <@Betelgeuse> NeddySeagoon: What I have also noticed that helps is that chairs push things to vote.
-19:40 < NeddySeagoon> Betelgeuse, yep.
-19:40 < Smiley> If you have so little time - maybe you should reconcider if you have time to be on the council?
-19:40 <@jmbsvicetto> and yes, people have been talking about up front discussion for a long time, but talking doesn't make it happen
-19:40 <@grobian> Smiley: not quick, but effective
-19:41 < Smiley> effective needs a leader. imo.
-19:41 <@grobian> Smiley: yes
-19:41 <@hwoarang> council acts as a leader
-19:41 <@hwoarang> or it should
-19:41 < Smiley> Hum. This seems to be getting no where. :S
-19:42 < NeddySeagoon> hwoarang, The council needs an effective leader during meetings to keep meetings focused.
-19:42 <@jmbsvicetto> Smiley: focus is directly related to the topic in an agenda
-19:42 < Smiley> otherwise you'll end up like anon.
-19:43 <@jmbsvicetto> The topics in this first meeting aren't probably "too interesting". This is all about how we want to conduct in the future
-19:43 <@dberkholz> ok, so i think we've settled on rotating chairs (volunteers on list will be put into a schedule), and chairs will handle summaries too (ideally in a collaborative doc like gdocs)
-19:43 <@jmbsvicetto> after we get this sorted out we can focus on actually doing what we have / need to
-19:43 < Smiley> Right, Ok :)
-19:44 <@jmbsvicetto> dberkholz: yes, seems there's no objection to that
-19:44 <@hwoarang> yes
-19:45 <@grobian> ok, so it seems we can end the model of operation here sort of
-19:45 <@grobian> it probably needs to be revisited after a meeting or two
-19:45 <@dberkholz> the other main question that Chainsaw brought up was announcing meetings and agendas with a little less than 7 days notice. more like 2 or 3.
-19:45 <@jmbsvicetto> So shall we move forward? Does anyone have any topics you would like to address on this term?
-19:45 <@dberkholz> that way people don't need to do things so far in advance to get them into a meeting
-19:45 <@hwoarang> i agree
-19:46 <@jmbsvicetto> I still think the annoucement should be sent with at least 1 week in advance
-19:46 <@jmbsvicetto> The agenda can and has traditonally been discussed after that
-19:47 <@grobian> ok, so this is a thing to put on the agenda of the next meeting to decide?
-19:47 <@jmbsvicetto> we can talk / vote on it in the mls before next meeting
-19:48 <@ulm> dberkholz: if we want to discuss things on the ml before the meeting, then 48 hours is very little time
-19:48 <@dberkholz> ulm: yeah, i was thinking about that too.
-19:48 <@grobian> jmbsvicetto: I think that would be useful
-19:50 <@jmbsvicetto> There's also the 15 days in advance for GLEP votes - 8 days before meeting announcement. IIRC, that isn't written down on any GLEP but should be in a council meeting summary / log
-19:50 <@dberkholz> i agree, we should discuss this in more detail on the lists.
-19:50 <@jmbsvicetto> So no one wants to talk about any topic you would like to address this term?
-19:50 <@dberkholz> i've already posted them, i'm going to continue working toward those things
-19:51 <@hwoarang> jmbsvicetto: i liked dberkholz idea about no replacing all the council members every year
-19:52 <@grobian> I'd like some things to be done (cvs migration, multirepo, changelog, etc.) but I don't see them as special council things... it's community driven, isn't it?
-19:52 < NeddySeagoon> that works for the foundation
-19:52 <@jmbsvicetto> hwoarang: that's GLEP 39 reform
-19:52 <@Betelgeuse> grobian: yeah I also have plenty of ideas but they can be surved by one person driving them
-19:52 <@hwoarang> it seems to be a pretty good idead to keep things rolling
-19:52 <@hwoarang> jmbsvicetto: yes indeed
-19:53 <@jmbsvicetto> ok, then let me just add a quick topic
-19:53 <@jmbsvicetto> Move past council election results to the elections space and make
-19:53 <@jmbsvicetto> links from the council project to the elections pages
-19:53 <@Betelgeuse> s/surve/serve/
-19:53 <@hwoarang> jmbsvicetto: i dont follow
-19:54 <@jmbsvicetto> hwoarang: This topic was raised this week. The election results are (were?) recorded in the council and elections project space. There were also some divergences
-19:54 <@ulm> jmbsvicetto: you mean the pre-2009 results of council elections?
-19:54 <@jmbsvicetto> So if there's no objections, we'll store the results in the elections project space and link to them from the council space
-19:54 <@Betelgeuse> jmbsvicetto: ok
-19:54 <@hwoarang> ok
-19:54 <@jmbsvicetto> ulm: those would need to be moved to the elections space, yes
-19:55 <@dberkholz> yeah.
-19:55 <@ulm> makes sense, yes
-19:55 <@jmbsvicetto> ok, I'll take care of this one (if it's still pending)
-19:55 <@hwoarang> thanks
-19:56 <@dberkholz> something i'd like to sort out right away.
-19:56 <@jmbsvicetto> In that case, it's time to see if the community has any issues they like this council to address on this term
-19:56 <@dberkholz> do you think that glep 39 changes require a full developer vote?
-19:56 <@Betelgeuse> dberkholz: yes
-19:56 <@jmbsvicetto> dberkholz: yes
-19:56 < antarus> no
-19:56 < antarus> :):)
-19:56 <@ulm> dberkholz: yes
-19:56 <@dberkholz> i don't either, but majority rules =)
-19:57 < Calchan> dberkholz, these guys have voted against the council being able to change gelp 39 2 years ago
-19:57 < Calchan> explicitely
-19:57 <@jmbsvicetto> Calchan: I didn't vote (wasn't on council), but argued for it ;)
-19:57 < antarus> I'm a fan of the council being like parliment
-19:57 < antarus> it has real utlimate power ;)
-19:58 <@dberkholz> i'm still waiting to hear on the rest of the council folks
-19:58 <@hwoarang> i think we need a full dev vote
-19:58 <@grobian> dberkholz: yes
-19:58 <@dberkholz> as it will have a significant influence on how i conduct the rest of my term =)
-19:58 <@dberkholz> ok, sounds good.
-19:58 <@Betelgeuse> dberkholz: You can ask the elections team do hold an election to give council the powers.
-19:59 < Calchan> dberkholz, just take the first part of my council agenda almost 2 years ago and have them revote on it
-19:59 <@Betelgeuse> But votify should also work to ask opinions on multiple individual items at once.
-19:59 <@jmbsvicetto> antarus: most parliament's require a 2/3 to be able to change a constitution :P
-19:59 <@hwoarang> Betelgeuse: i am not sure about that. I think Robin said this is on TODO list
-20:00 <@dberkholz> jmbsvicetto: interestingly, glep 39 makes no such prohibition against changes by the group that it explicitly gives power over global issues
-20:00 <@jmbsvicetto> dberkholz: true
-20:00 <@Betelgeuse> hwoarang: probably works by ranking things below and above a pass item
-20:00 <@dberkholz> that's the basis of my opinion, but i can see where people might see it differently
-20:00 <@Betelgeuse> hwoarang: Robin was talking about multiple elections going simultaneously
-20:01 <@Betelgeuse> hwoarang: but you should be able to do it with one ballot
-20:01 <@hwoarang> right
-20:01 <@jmbsvicetto> dberkholz: but GLEP39 isn't a real GLEP. If you want, as a GLEP it should be marked as an information GLEP as it wasn't written or voted as a GLEP, but was instead subject to a global dev vote
-20:01 <@jmbsvicetto> about the multiple items vote, we can / should look at devotee
-20:02 <@jmbsvicetto> I've already suggested in the elections team that we should try to move to devotee instead of maintaining our own scripts
-20:02 <@Betelgeuse> antarus: I don't think most parliaments can change constitutions with a simple majority
-20:03 <@jmbsvicetto> ok, so if there's nothing else, we can adjourn this meeting
-20:03 <@jmbsvicetto> items to take care before next meeting:
-20:03 <@jmbsvicetto> 1. have interested council members send an email manifesting their willingness to do chair work
-20:04 <@jmbsvicetto> 2. create a schedule and distribute the chair role to the above list
-20:04 <@dberkholz> once we've got volunteers, i can put the schedule together and stick it on the council webpage
-20:04 <@grobian> jmbsvicetto: ok
-20:05 <@jmbsvicetto> 3. vote / decided pending issues
-20:05 <@Betelgeuse> jmbsvicetto: 4. work to fill the agenda with items important to each one :)
-20:05 <@hwoarang> what is the preferred way to talk about these? using alias or ML ?
-20:05 <@jmbsvicetto> One last thing, when will we have the next meeting?
-20:05 <@dberkholz> 2nd tuesday, which would be august 9
-20:06 <@grobian> must have this month, as discussed on ML
-20:06 <@jmbsvicetto> Do we want to wait for next month (there's the issue of this meeting not having the 1 week advance notice) or shall we schedule another meeting this month?
-20:06 <@dberkholz> that's incorrect
-20:06 <@dberkholz> we must have a meeting this month, and we're having it right now
-20:06 <@Betelgeuse> this one is sufficient
-20:06 <@grobian> ok, cool
-20:07 <@hwoarang> this should also go to the Google Calendar :)
-20:07 <@jmbsvicetto> I still argue that we didn't satisfy one of the requirements - the 1 week advance notice
-20:07 <@dberkholz> i was attempting to put it on, but chromium kept crashing.
-20:07 <@Betelgeuse> (unless a majority wants to oppose)
-20:07 <@Betelgeuse> jmbsvicetto: well you voted that council can't change GLEP 39
-20:07 <@jmbsvicetto> I did
-20:07 <@Betelgeuse> jmbsvicetto: GLEP 39 states nothing about a week notice
-20:08 <@Betelgeuse> jmbsvicetto: so by that logic re-election can't follow
-20:08 <@jmbsvicetto> yes, but previous Councils "decided" that
-20:08 <@jmbsvicetto> Betelgeuse: yes, but by that logic the rule that we pick the next runner up in case a council member quits, wouldn't apply as well
-20:08 < NeddySeagoon> are councils bound by decisions of pervious councils ?
-20:09 <@jmbsvicetto> Betelgeuse: and at least the last 2 or 3 councils have followed that rule
-20:09 <@dberkholz> i see that requirement as another part of the mode of operation of a given council, and i'm pretty sure we decided to discuss advance notice on the mailing list
-20:09 <@Betelgeuse> jmbsvicetto: I have wondered that practise myself but it can be thought to fall within the GLEP 39 text
-20:09 < NeddySeagoon> jmbsvicetto, its become a standard operating procedure then ?
-20:10 <@jmbsvicetto> NeddySeagoon: I think we need to do a GLEP 39 reform. But until we get it done and things properly documented, I'd avoid ignoring previous councils rules - to me that could only "mess things more"
-20:10 <@jmbsvicetto> NeddySeagoon: I'd argue it has
-20:11 <@jmbsvicetto> but anyway, are we done for this month or not?
-20:11 <@Betelgeuse> jmbsvicetto: I don't think a hard rule for a week notice being required to have a valid meeting makes sense.
-20:11 <@dberkholz> fyi everybody, i stuck our monthly meeting on the google calendar.
-20:11 < NeddySeagoon> jmbsvicetto, The council needs to distinguish between the requirements of GLEP39 and things that have become custom and practice.
-20:11 <@Betelgeuse> Opinions?
-20:12 <@Betelgeuse> We should of course do our best to send notices on time.
-20:12 <@jmbsvicetto> dberkholz: thanks
-20:13 <@hwoarang> personally, i think we need another meeting as well
-20:13 <@jmbsvicetto> NeddySeagoon: yes, that's why I want to split GLEP39 into the rules and the model of operation (which should fall under council's decision)
-20:13 < NeddySeagoon> jmbsvicetto, that makes sense
-20:13 <@dberkholz> we've got multiple vacations in between now and the next meeting such that we can't even get everybody to a meeting with 1-week notice until august 9
-20:14 <@jmbsvicetto> Chainsaw / grobian / ulm: ^^
-20:14 <@grobian> jmbsvicetto: on what?
-20:15 <@jmbsvicetto> I don't think you've expressed your opinion on this subject yet
-20:15 <@dberkholz> i need to leave now, but if you really want to vote on it, i don't think another meeting is in any way required.
-20:15 <@Chainsaw> jmbsvicetto: You know my opinion on advance notice; we disagree on that.
-20:15 <@jmbsvicetto> grobian: do we need another meeting this month or do we meet again on August 9th?
-20:15 <@jmbsvicetto> Chainsaw: ok
-20:15 <@ulm> jmbsvicetto: I'll be away end of the month, so it'll be difficult for me to attend to another meeting in july
-20:15 <@Chainsaw> jmbsvicetto: August 9 I would say, don't see the need for more.
-20:16 <@jmbsvicetto> so, let's vote this so we can end this meeting:
-20:16 <@grobian> jmbsvicetto: I would prefer to do another meeting this month, but give the current circumstances I can live with the 9th August
-20:16 <@Chainsaw> jmbsvicetto: End of July means start of school holidays; anyone with kids is going to be burdened.
-20:16 <@jmbsvicetto> Do we need another meeting this month to follow some perceived rule about the 1 week advance notice?
-20:16 <@Chainsaw> jmbsvicetto: No, we do not.
-20:16 <@hwoarang> jmbsvicetto: yes
-20:16 <@grobian> jmbsvicetto: yes
-20:16 <@ulm> jmbsvicetto: no
-20:16 <@Betelgeuse> jmbsvicetto: no
-20:16 <@jmbsvicetto> yes
-20:17 <@jmbsvicetto> dberkholz: no
-20:17 <@jmbsvicetto> who's missing?
-20:17 < NeddySeagoon> The nays have it
-20:17 <@jmbsvicetto> sorry, right
-20:17 <@grobian> you've got al 7
-20:17 <@jmbsvicetto> so 4 no and 3 yes votes
-20:17 <@jmbsvicetto> grobian: yes, I forgot to council dberkholz's vote. Sorry
-20:18 <@grobian> jmbsvicetto: hehe, :D
-20:18 <@jmbsvicetto> ok, so we're done for today and this month :)
-20:18 <@jmbsvicetto> bah, s/council/count/
-20:18  * Chainsaw salutes and marches off
-20:18 <@jmbsvicetto> Thank you all for showing up
-20:18 < Mepho> o/
-20:18 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has quit [Quit: Leaving]
-20:18  * hwoarang is out. bbl
-20:18 <@jmbsvicetto> I'll take care of the summary and log after dinner
-20:18 < NeddySeagoon> I wish we could get 55 for Foundation meetings
-20:18 <@jmbsvicetto> see you later
-20:19 < Mepho> meh forgot to ask stuff I wanted to, maybe next time
-20:19 <@grobian> throw it in
-20:19 < NeddySeagoon> Mepho, ask anyway, the council will read the backlog
-20:19 < Mepho> 1) having gentoo.org linked with "official" sites on social networks (encouraging users to join such groups on website) - though I am not on any of these, many people are.
-20:20 < chithead> I think any possible "1 week" rule violation has been healed by everybody showing up
-20:20 < Mepho> 2) Adding localisation category to handbooks, many people do work in pure english environment and do not really need useflags like "nls" in default profile (nto saying it should be removed, just that there could be few words said about -nls USE flag in "setting useflags" caregory)
-20:20 < Mepho> 3) another documentation proposal - strongly encourage newbies to read entire handbook, many of them stop using it after booting step, so later they can come to IRC channel and ask about USEflags etc.. rewriting handbook is probably too drastic, however adding line or two could save their time and ours (on irc, forums).
-20:20 < antarus> Mepho: for 2 and three you should contact nightmorph@
-20:20 < antarus> two and three
-20:20 < antarus> silly numbers
-20:20 <@grobian> are 2) and 3) really council territory?
-20:20 <@grobian> ^^^ see antarus
-20:21 < antarus> for social networking...contact pr@ ?
-20:21 < NeddySeagoon> file doc bugs
-20:21 < Mepho> I wasnt sure, yes
-20:21 < NeddySeagoon> is there a #gentoo-pr ?
-20:21 < Mepho> who to contact for propaganda?
-20:21 < Smiley> You'll never fix users tbh.
-20:21 < antarus> Mepho: email pr@, donnie and myself are both on it
-20:21 < Smiley> (I presume I'm ok to speak now the meeting is "over"? )
-20:21 < antarus> among others ;)
-20:21 < NeddySeagoon> Mepho, dabbott/comprookie2000
-20:22 < NeddySeagoon> Smiley, Open floor was on the agenda ... they skipped that bit
-20:22 < Smiley> NeddySeagoon: I thought so :S - I was being careful not to interuppt anymore ;)
-20:23 < NeddySeagoon> Smiley when council does not like the interruptions, they set +m
-20:23 <@grobian> NeddySeagoon: was announced, but nobody started talking, but the council members :)
-20:24 < NeddySeagoon> grobian, I missed the announce - but I was fairly vocal during the meeting anyway :)
-20:24 <@grobian> yeah, much appreciated
-20:24 < Smiley> I missed it too. Hope I didn't intrude too much. First time here.
-20:25 <@grobian> I'd say you didn't
-20:25 < NeddySeagoon> Smiley, Its like your local council meeting - you can go along and ask questions as long as you are not disrumptive
-20:26 < Smiley> NeddySeagoon: I've never been to a local council meeting :/ but cool. Makes sense.
-20:26 < Smiley> On that point, do you want more people to turn up for the meetings and take notice?
-20:27 < Mepho> maybe sending some message on other gentoo-* channels 10 minutes before (or other interval, announcements day before?)
-20:27 <@grobian> I guess that would show more involvement
-20:28 <@grobian> but I don't think it really helps to get something useful out of the meeting
-20:28 < Smiley> Mepho: I was thinking more like a document explaining what to expect, when your expected to talk, etc.
-20:28 <@grobian> you can always send questions/issues to the ML, IMO
-20:28 < NeddySeagoon> could post in #gentoo 10 min before the meeting start
-20:30 < Mepho> wouldn't it be possible to create some rank between arch tester and dev? Sometimes I think bugzilla is filled with confirmed bugs, with included patches, which just won't get to mainstream because there are not enough devs (or maybe arch testers?).
-20:32 < chithead> I can't speak for other teams, but x11 team is reluctant to apply patches if upstream has not accepted them
-20:33 < Mepho> Right now I am thinking of becoming arch tester myself, but I find myself trapped in wast ammount of documentation to read (hadnbook, dev guide, ebuild guide, other docs), though I consider myself experienced gentoo user (did some ebuilds for my own needs and stuff).
-20:33 <@grobian> Mepho: common complaint
-20:34 < Mepho> for example there is open bug for g15daemon, patch is well known (included in ubuntu upstream), but only shows on amd64 (buffer overflow, one line patch) and I guess there are just no people who could test it and accept
-20:35 < Mepho> especially because not everyone have g15 keyboard
-20:35 < Mepho> and we cant do much about this as development cycle of that sw is dead
-20:35 <@grobian> ok, but then it's really how the team deals with that, and how much they trust a user for something
-20:35 < Mepho> and there are many other examples like this :/
-20:36 <@grobian> even devs can't just commit anything/everything
-20:37 < Mepho> I understand
-20:38 <@grobian> ok, I'm off, laterzzz
-20:38 -!- grobian [~grobian@gentoo/developer/grobian] has quit [Quit: Zzzzzz]
-20:38 < Mepho> bb
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110809-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20110809-summary.txt
deleted file mode 100644
index b4d88ac857..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110809-summary.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Council meeting summary: 20110809 
-
-
-Meeting agenda:
-
- * Roll call (5 minutes; anyone later will be given a slacker mark)
-   - All present!
-     (dberkholz, hwoarang, betelgeuse, jmbsvicetto, ulm, grobian, chainsaw)
-
- * Required advance notice for council meetings (10 minutes)
-   - Vote: 7 days vs 2 days
-     - Result: 1-week notice is required
-   - If 7 days notice is required:
-     Vote: can the agenda be sent with only 2-day notice?
-     - Result: draft agendas should also be sent 1 week in advance
-
- * ChangeLog autogeneration [2] (20 minutes)
-   - Previous council already voted for autogeneration (20110608)
-   - Vote: Should we allow filtering of which commits show up?
-     - No filtering, on a 4-3 vote
-   - Vote: Retroactively change existing entries, yes or no.
-     - We will append to changelogs and retain all existing changelog 
-       messages.
-     - We may need to return to this when the git migration is ready. 
-       Current changelog messages will be old by then, so they won't be 
-       as interesting anymore, and people should have adjusted.
-   - Do we need a way to edit autogenerated changelogs to fix typos, 
-     etc? Should there be a backing store to overwrite messages? 
-     jmbsvicetto will reopen discussion about this.
- 
- * IRC cloaks: gentoo/user/cloaks [3] (5 minutes)
-   - Vote: Should we delegate this to devrel and userrel to work out?
-   - Summary: No decision was reached. Opinions were mixed on whether 
-     council should be involved, whether it fell under devrel or 
-     whether Freenode group contacts were even connected to devrel.
-     Further discussion on lists might help clarify how things should work.
-
- * Use of gentoo-council mailing list [4] (5 minutes)
-   - Vote: Should the -council mailing list again be used for discussion 
-     of council agenda items?
-     - No. -dev, -project, and the council alias is enough
-     - Update the -council list bug to indicate that the list should be closed.
-
- * Chair rotation (5 minutes)
-   - Schedule at http://dev.gentoo.org/~dberkholz/meeting_chairs.txt
-   - People can feel free to trade
-   - If multiple meetings occur in a month, that month's chair will run them.
-   - Donnie will add it to a table on the council webpage
- 
- * open bugs with council involvement
- * open floor - listen to the community
-
-Next meeting: Tuesday 20110913 1900 UTC
-
-
-Items proposed but not on the agenda:
-
- * Optional runtime dependencies [5]
-   - What is the decision to be made? If none, it's not on the agenda
-
- * Council terms: overlapping 2-year terms [6]
-   - Requires a full developer vote on changes to GLEP 39 so council 
-     approval is not relevant
-
-
-If you have anything you'd like to push to the council for
-discussion, feel free to reply to this thread.
-
- [1] http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900
- [2] http://archives.gentoo.org/gentoo-project/msg_3675d8a397ee2b5b3088df42e3352b6f.xml
- [3] http://archives.gentoo.org/gentoo-project/msg_5471f2db793e7fe9f50038fb23258c66.xml
- [4] http://archives.gentoo.org/gentoo-council/msg_6cad9409772fa44415e84005ff922145.xml
- [5] http://archives.gentoo.org/gentoo-dev/msg_2342bd1cad57e432a319c55e3ef7e6df.xml
- [6] http://archives.gentoo.org/gentoo-project/msg_f0e61e95ea9027d7c937e5ae956adb0d.xml
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110809.txt b/xml/htdocs/proj/en/council/meeting-logs/20110809.txt
deleted file mode 100644
index d10a564b4c..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110809.txt
+++ /dev/null
@@ -1,404 +0,0 @@
-19:00 < dberkholz@> for grobian, i'm gonna keep things simple and just try keeping an updated summary here: http://dev.gentoo.org/~dberkholz/20110809_summary.txt =)
-19:00 < dberkholz@> alright, i've got 1900. who's here?
-19:00 <   grobian@> dberkholz: weird, so you preselect what we can vote on
-19:00  * hwoarang here
-19:00 <       ulm@> here
-19:00 <   grobian@> here
-19:01  * Chainsaw is present
-19:01 < dberkholz@> Betelgeuse, jmbsvicetto: around?
-19:01 < dberkholz@> grobian: i presented two proposals, and i didn't see anyone present a third one...
-19:02 <   grobian@> but me
-19:02 <  hwoarang@> could you hold one until the rest are here? :)
-19:02 <  hwoarang@> and we have another item before that :)
-19:03 < dberkholz@> yeah, we're not doing anything but clarifying/discussing the agenda
-19:04 <  hwoarang@> should we call them? :)
-19:04 < dberkholz@> if you feel like it, go ahead. they've only got a minute to show up, so you'd better be quick =D
-19:04 <Betelgeuse@> dberkholz: yes
-19:04 <  Chainsaw@> jmbsvicetto has always been lenient with us.
-19:04 <  Chainsaw@> Can we give him a call please?
-19:05 <  hwoarang@> i will call him
-19:05 <jmbsvicett@> here
-19:05 <  hwoarang@> ah
-19:05 <  Chainsaw@> Thank you hwoarang.
-19:05 < dberkholz@> if someone's got his number handy, go ahead. let's get the meeting rolling..
-19:05 < dberkholz@> oh, good.
-19:05 <  Chainsaw@> Excellent. We are complete.
-19:05 <  hwoarang@> jmbsvicetto: too bad I would like to hear your voice :p
-19:05 <   grobian@> hmmm, Betelgeuse, jmbsvicetto come on
-19:06 < dberkholz@> they're both here now, we're set
-19:06 < dberkholz@> so, let's get started right off with the first topic, advance notice for meetings
-19:06 <jmbsvicett@> hwoarang: hehe
-19:06 <jmbsvicett@> I'll call Betelgeuse
-19:06 < dberkholz@> 19:04 <Betelgeuse@> dberkholz: yes
-19:06 <jmbsvicett@> right, sorry
-19:06 <Betelgeuse@> grobian: ?
-19:07 <   grobian@> Betelgeuse: sorry, huge lag here
-19:07 <   grobian@> didn't see you're around
-19:07 <  Chainsaw@> Yes, I was the one that suggested 48 hours might be enough.
-19:07 < dberkholz@> any reason we shouldn't vote on the 7-day vs 2-day advance notice?
-19:07 <  Chainsaw@> As opposed to a week.
-19:07 <   grobian@> voting is fine with me
-19:07 <jmbsvicett@> what are we voting on?
-19:07 <jmbsvicett@> The advance notice or the agenda posting?
-19:07 <  hwoarang@> yes
-19:08 < dberkholz@> first subpart is advance notice in general, advance agenda's the next bit if needed
-19:08 <jmbsvicett@> my argument has always been that we need 1 week advance notice, not that the agenda needs to be define with that 1 week notice
-19:08 <  hwoarang@> i second that
-19:08 <Betelgeuse@> dberkholz: And what happens if the deadline is missed?
-19:09 <  hwoarang@> jmbsvicetto: 1 week advance notice is good but you need to give to the community a draft of the upcoming agenda too
-19:09 < dberkholz@> ok, let's vote then: should a 1-week notice be required for a meeting?
-19:09 <   grobian@> hwoarang: +1
-19:09 <jmbsvicett@> yes
-19:09 <   grobian@> yes
-19:09 <       ulm@> yes
-19:09 <  hwoarang@> yes
-19:09 <  Chainsaw@> Okay.
-19:09 <  Chainsaw@> yes
-19:09 < dberkholz@> that's a majority, then.
-19:09 <  Chainsaw@> I am swayed, this one won't make it.
-19:09 <jmbsvicett@> Betelgeuse / dberkholz: your vote?
-19:10 < dberkholz@> irrelevant, but no
-19:10 <  hwoarang@> we still to answer Betelgeuse's question
-19:11 <  hwoarang@> slacker point for chairman?
-19:11 < dberkholz@> i don't think we need to deal with that unless it becomes an ongoing problem
-19:11 <jmbsvicett@> hwoarang: in my view, the 1 week notice is an approximate advanced notice. So if we miss it for a day or so, it isn't an obstacle.
-19:11 <Betelgeuse@> Yes I think we should aim to send things well in advance.
-19:11 <   grobian@> I do prefer a draft agenda by that time
-19:11 <  hwoarang@> jmbsvicetto: err why did we vote then if it is not a hard requirement?
-19:12 <  hwoarang@> i believe we need a draft of the agenda 1 week before
-19:12 < dberkholz@> on that note, let's move on to the 2nd part of this topic, the agenda notice
-19:12 <Betelgeuse@> We don't necessarily need to send things in stone.
-19:12 <Betelgeuse@> s/send/set/
-19:12 <  hwoarang@> sure
-19:12 <jmbsvicett@> hwoarang: because we should attempt to do it like that?
-19:12 < dberkholz@> anyone got a problem with voting on whether agendas must also be sent 1 week in advance?
-19:13 <  hwoarang@> jmbsvicetto: if the requirement is not hard, people will dont pay attention. I can easily imagine a 24-48 delay window
-19:13 <   grobian@> dberkholz: no problem
-19:13 <jmbsvicett@> dberkholz: no, move on
-19:13 <  hwoarang@> i would change that to s/agendas/proposed &/
-19:13 <  hwoarang@> or draft, whatever
-19:14 <Betelgeuse@> s/must/should/ unless we want to deal with what happens if it's not sent
-19:14 < dberkholz@> ok, let's vote: should draft agendas be sent 1 week in advance (as opposed to 48 hours)?
-19:14 <  hwoarang@> yes
-19:14 <   grobian@> yes
-19:14 <       ulm@> yes
-19:15 < dberkholz@> no, again
-19:15 <jmbsvicett@> yes (they may be empty if there's nothing in the list at that point)
-19:15 <  hwoarang@> on that note, discussion about the upcoming agenda should probably start 2 weeks before the meeting.
-19:15 <jmbsvicett@> and the mail should ask people to present issues to be discussed
-19:15 <   grobian@> agreed
-19:15 <  hwoarang@> jmbsvicetto: if agenda is empty, 1 week is too short to collect ideas
-19:15 <       ulm@> jmbsvicetto: good point
-19:16 <jmbsvicett@> I'm fine with 1 week for that
-19:16 <Betelgeuse@> sending what's currently on the table is fine
-19:16 <jmbsvicett@> hwoarang: I don't think that was a problem last year (starting the discussion 1 week before the meeting)
-19:16 < dberkholz@> any other decisions need to be made on that topic?
-19:17 <  hwoarang@> fair enough
-19:17 < dberkholz@> i'd like to move on to the changelog autogeneration
-19:17 <  Chainsaw@> Wow. Lag burst.
-19:17 <  Chainsaw@> Sorry if you were waiting on me for anything.
-19:18 < dberkholz@> first off, it's worth reminding everyone that the last council voted to autogenerate changelogs from commit messages
-19:18 < dberkholz@> i put up 2 more specific proposals to vote on; are there others that should be included?
-19:18 <   grobian@> I think it's not complete
-19:18 <jmbsvicett@> dberkholz: You've dropped from the possible votes, having the changelogs completely autogenerated from commit messages, correct? I read your proposal as suggesting only appending to existing files
-19:19 < dberkholz@> i didn't see it as an option that enough of us supported to put on the list, but if that's wrong then tell me
-19:19 <jmbsvicett@> That's one of the issues grobian raised in the ml before
-19:19 < dberkholz@> are there at least a couple of you that want to vote for that?
-19:19 <       ulm@> dberkholz: I think we need a possibility to retroactively change existing entries
-19:19 <       ulm@> otherwise it's going to be a mess
-19:19 <Betelgeuse@> dberkholz: I don't think we should have any kind of prefiltering for options
-19:19 <jmbsvicett@> I'm just trying to confirm I didn't lost anything. I'm ok with appending information to the existing files
-19:20 < dberkholz@> alright, let's simplify this into a couple of separate votes then
-19:20 <   grobian@> dberkholz: why not follow my initial three questions?
-19:20 <   grobian@> - should all commit message be included
-19:20 <   grobian@> - should commit messages be appended to/updated?
-19:20 <   grobian@> - should existing information in ChangeLog files be retained?
-19:21 < dberkholz@> i don't understand the 2nd one and how it's different from the 3rd one
-19:21 <   grobian@> modify a message vs keep the ChangeLog files that are in CVS now
-19:21 <jmbsvicett@> grobian: your 2nd question seems to be tied to the git notes proposal
-19:21 <   grobian@> you can just edit a ChangeLog file, but if it's generated, you need to change the commit message
-19:22 <   grobian@> jmbsvicetto: yes, that came out of that
-19:23 <jmbsvicett@> One question not directly related to ChangeLogs but that is tied to the whole discussion, assuming we move to git, do we expect users to continue using rsync or move to git?
-19:23 < dberkholz@> that's so far OT for this discussion
-19:23 <  hwoarang@> yes
-19:23 <   grobian@> you mean, should ChangeLogs be in the tree committed somehow?
-19:23 < dberkholz@> git-scm list is the place for that
-19:23 <jmbsvicett@> The point is that the whole debate about whether commit messages should be in rsync or in the scm is null if users are supposed to keep using rsync
-19:23 <  hwoarang@> we should find a solution without having git in mind
-19:23 <bonsaikitt > I would assume that at least initially users will continue with rsync
-19:24 <  Chainsaw@> hwoarang: Agreed, it will make the git migration easier if we get this in place on CVS first.
-19:24 <   grobian@> but I agree it goes OT on the subject mostly
-19:24 <  hwoarang@> git may take ages
-19:24 <jmbsvicett@> dberkholz: The question is tied to the above: do we expect users to have access to the scm commit messages or not
-19:24 <   grobian@> Chainsaw: I implemented it last week for Prefix, all ChangeLogs are generated in the Prefix rsync tree
-19:24 < dberkholz@> we're using CVS today, and they don't, and we're voting on stuff we can do today
-19:24 <  hwoarang@> jmbsvicetto: i think users will still need rsync
-19:24 < dberkholz@> so the answer must be no
-19:25 < dberkholz@> git's been floating around for 5 years now, we can't make decisions that depend on it happening soon
-19:25 <  hwoarang@> exactly
-19:25 <jmbsvicett@> yes, I agree with that
-19:25 <       ulm@> users will need things like ${PORTDIR}/metadata and it's not clear how to handle that in git
-19:25 < dberkholz@> let's try to get back to the changelog topic here
-19:25 <jmbsvicett@> but a large part of the discussion on ChangeLogs, has git in the background
-19:26 <  hwoarang@> which is wrong :)
-19:26 <jmbsvicett@> I'm not arguing otherwise
-19:26 <   grobian@> jmbsvicetto: my intention was to separate it, so the functional requirements can be put on the table
-19:26 <jmbsvicett@> ok, so let's get back to changelogs
-19:26 < dberkholz@> let's return to grobian's initial questions and vote on the first one
-19:26 <   grobian@> hence my three questions largely dealing with policies
-19:26 < dberkholz@> should we allow filtering of which commit messages show up in changelogs?
-19:26 <   grobian@> no
-19:27 <       ulm@> yes
-19:27 <  hwoarang@> yes
-19:27 <Betelgeuse@> no
-19:27 <jmbsvicett@> no (I keep the vote from previous council)
-19:27 < dberkholz@> yes
-19:27 <  Chainsaw@> no
-19:27 < dberkholz@> good, that's settled.
-19:28 < dberkholz@> no filtering
-19:28 < dberkholz@> now let's vote on his third question, since that's pretty easy to figure out too: should we overwrite old changelog entries with commit messages or retain that information?
-19:29 <jmbsvicett@> dberkholz: let's vote on the 2nd as I have a suggestion to split the 3rd in 2 questions
-19:29 < dberkholz@> ok, hold on.
-19:29 < dberkholz@> what's your suggestion?
-19:29 <   grobian@> does everybody understand the 2nd question?
-19:29 <       ulm@> no
-19:29 <   grobian@> I may have not made myself clear
-19:29 <       ulm@> please clarify
-19:29 < dberkholz@> it seems like you want a backing store for changelog messages in addition to the commit message
-19:29 <   grobian@> ok, consider the ChangeLog of today
-19:29 <   grobian@> if you have a typo, or forgot a bugreference
-19:29 < dberkholz@> so there's still a place to edit
-19:29 <jmbsvicett@> 3. Should we try to retain information from old ChangeLogs? 4. Should we allow to cut-off / implement an automatic rule to cut-off large / old ChangeLogs?
-19:29 <   grobian@> you just edit the ChangeLog
-19:30 < dberkholz@> seems like QA or a repoman rule can take care of part 4 there
-19:30 <jmbsvicett@> dberkholz: it's a policy issue, in my view
-19:30 <   grobian@> jmbsvicetto: that has nothing to do with old ChangeLog information to me
-19:31 <   grobian@> ulm: if you generate a changelog from commit messages, you cannot just add that bugref by editing the commit message or something
-19:31 < dberkholz@> it doesn't really have pertinence to this specific topic of autogeneration, since the information's there regardless
-19:31 <jmbsvicett@> grobian: with your proposal, we either start with empty changelogs for all packages and append as people commit to the packages or we start with the current changelog content and append to it
-19:31 <       ulm@> grobian: yeah, I think I understand it now ;)
-19:31 <   grobian@> jmbsvicetto: no, see the prefix tree
-19:31 <       ulm@> and there's nothing worse than a misspelled user name in credits ;)
-19:31 <   grobian@> jmbsvicetto: http://rsync1.prefix.freens.org/app-admin/chrpath/ChangeLog
-19:31 <   grobian@> that's not empty
-19:32 <   grobian@> jmbsvicetto: but completely generated
-19:32 < dberkholz@> it's generated from historic cvs commit messages, not empty
-19:32 <   grobian@> ulm: that's nasty, yes
-19:32 <jmbsvicett@> grobian: right, that's the 2nd option: you use what exists already - in this case instead of appending to the current file you generate it automatically from commit messages
-19:33 < dberkholz@> maybe you need an AUTHORS file or header info for that kind of information
-19:33 <   grobian@> jmbsvicetto: no, this comes from cvs log, not from ChangeLog
-19:33 <   grobian@> jmbsvicetto: as I showed in my original mail, sometimes there is a difference in content here
-19:33 <jmbsvicett@> grobian: yes, I understand
-19:33 <   grobian@> jmbsvicetto: question 3 is exactly about that
-19:33 <jmbsvicett@> grobian: what I meant was that you could either start from 0 or use existing information. When reusing what exists, there are 2 options: append to current files or regenerate them
-19:33 <   grobian@> jmbsvicetto: do we care about the different content so much that we need to do complicated stuff to retain the content of the ChanegLog files
-19:34 <       ulm@> grobian: yes
-19:34 < dberkholz@> i don't know why we would start from zero, that option never even occurred to me
-19:34 <jmbsvicett@> ok, then let's keep your 3rd and answer to my 4th as well
-19:34 <   grobian@> starting from 0 seems like a non-option to me
-19:34 <Betelgeuse@> Should we move the discussion back to ml?
-19:34 <jmbsvicett@> It's a theoretical option. I don't support it
-19:34 <Betelgeuse@> Seems like people are still in the discussion step
-19:35 <   grobian@> if it isn't clear enough what we're voting on, we're forced to yes
-19:35 <jmbsvicett@> we might want to discuss a bit more about the remaining 3 questions
-19:35 <   grobian@> do we think we know what we're talking about?
-19:35 <jmbsvicett@> grobian: yes
-19:35 <   grobian@> jmbsvicetto: do you think 2 is isolated enough?
-19:35 <jmbsvicett@> yes
-19:35 < dberkholz@> http://dev.gentoo.org/~dberkholz/20110809_summary.txt
-19:35 <   grobian@> can we vote on it then?
-19:36 < dberkholz@> i've put my understanding of our votes there
-19:36 <jmbsvicett@> grobian: if I may, "Should ChangeLog remain an editable file or should it become a file supporting only append mode?"
-19:36 < dberkholz@> i'm totally fine with voting on both of them right now
-19:36 <   grobian@> jmbsvicetto: then you'll have to bring back discussion to -dev
-19:36 <   grobian@> or -project
-19:36 <   grobian@> or whatever
-19:37 <  hwoarang@> i dont understand what is the problem with typos
-19:37 <   grobian@> because that's a unconsidered option
-19:37 <  hwoarang@> ah ok sorry
-19:37 < dberkholz@> they can't be fixed if they come from commit messages, and some of us really don't want to live with them forever
-19:37 <  hwoarang@> yes my mistake
-19:37 <   grobian@> jmbsvicetto: my vision is that it should disappear as file
-19:37 <jmbsvicett@> grobian: that is exactly what you want us to vote, right?
-19:37 <   grobian@> jmbsvicetto: purely virtual
-19:38 <  hwoarang@> i am fine to vote for these items too btw
-19:38 <   grobian@> I assumed a "generated changelog", is the way to go
-19:38 <jmbsvicett@> ok, let's replace file with medium. Is that better?
-19:38 < dberkholz@> ok, who's not ready to vote on whether we should overwrite or retain existing info?
-19:39 <   grobian@> s/info/ChangeLog/
-19:39 < dberkholz@> sure. existing changelog messages
-19:39 <       ulm@> dberkholz: by "existing info" you mean current contents of ChangeLog files?
-19:39 < dberkholz@> yep, thanks for asking
-19:39 <   grobian@> ready for voting on that here
-19:40 <jmbsvicett@> dberkholz / grobian: Sorry, are we voting for 2 or 3? 2 = immutable + append vs free edition, 3 = can we autogenerate info or do we need to retain 100% complaince with existing changelogs?
-19:40 <   grobian@> seems 3 to me
-19:40 < dberkholz@> here's the vote: do we overwrite existing changelog messages from cvs logs, or retain existing changelogs and only append new commit messages?
-19:41 < dberkholz@> just say "yes" for overwrite
-19:41 <jmbsvicett@> dberkholz: you've put the 2 questions together
-19:41 <   grobian@> overwrite
-19:41 <  Chainsaw@> append
-19:41 <       ulm@> retain existing changelogs
-19:41 <  hwoarang@> retain
-19:42 < dberkholz@> retain/append for me too
-19:42 <  Chainsaw@> (4 retain, 1 overwrite so far)
-19:42 <jmbsvicett@> I'd prefer append to existing files
-19:42 <   grobian@> ok, interesting
-19:42 < dberkholz@> good, that's 2 out of 3. the most complex is last, and i'm wondering whether we should discuss it more on lists
-19:43 <Betelgeuse@> retain is ok but if it delays the implementation I am fine with overwriting
-19:43 <   grobian@> think so
-19:43 <   grobian@> because people want to retain, the ChangeLog file probably remains existing, so editing is easy
-19:43 <   grobian@> which makes 2 a moot point
-19:43 <Betelgeuse@> The question might become moot any way if we start restricting the timespan.
-19:43 <   grobian@> Betelgeuse: in that case the retain of previous vote is, strange
-19:44 <  Chainsaw@> jmbsvicetto? Betelgeuse?
-19:44 <jmbsvicett@> Betelgeuse: you mean allowing to cut-off the files?
-19:44 <   grobian@> because all cases it actually makes sense to retain are in the far past
-19:44 <   grobian@> the rest is all echangelog + repoman commit
-19:44 <jmbsvicett@> grobian: from the complaints, I'd expect that to be true for ~99% of the cases
-19:44 <Betelgeuse@> grobian: I am not really sure if everyone does that
-19:44 <  Chainsaw@> I am lagged again, aren't I. So sorry.
-19:45 <   grobian@> jmbsvicetto: apart from removes, ok, but you just voted for all commits to be included
-19:45 <   grobian@> no filtering
-19:45 < dberkholz@> we might need to discuss that again whenever a git migration is close to figure out whether that changes things, but it can wait
-19:46 <jmbsvicett@> grobian: I voted for adding all messages to changelogs, but I'm open to a discussion if it should be possible to cut-off the files - cut-off old entries
-19:46 <   grobian@> let's move on, this is confusing enough in itself
-19:46 <   grobian@> jmbsvicetto: yes, of course, and so I do
-19:46 <   grobian@> jmbsvicetto: if you assume the first, the 3rd is sort of edge case
-19:46 < dberkholz@> yeah, let's try to get through the other couple of topics.
-19:46 <   grobian@> anyway, let's move on, we'll discuss on ML
-19:46 <Betelgeuse@> grobian: As long as we keep the ancient history I would prefer the existing entries over the cvs commit messages
-19:47 <   grobian@> Betelgeuse: cvs is retaining history, I hope git does that too
-19:47 <  hwoarang@> it is not clear to me whether we have a final solution or not
-19:47 <jmbsvicett@> grobian: it does
-19:47 <   grobian@> Betelgeuse: if it doesn't, I wouldn't put my hopes on it
-19:47 <   grobian@> hwoarang: no
-19:47 < dberkholz@> we have a solution to 2/3 of the questions, the other one should get discussed on the list
-19:47 <jmbsvicett@> hwoarang: the discussion will continue in the ml
-19:47 <  hwoarang@> ok
-19:47 < dberkholz@> the next topic is IRC cloaks for contributors, users, etc.
-19:48 < dberkholz@> there seemed to be some interest on -project to delegate this to devrel and userrel to work out as they see fit
-19:48 <jmbsvicett@> dberkholz: about that, one thing that might not be clear to everyone is that cloaks are handled by the freenode group contacts
-19:48 <   grobian@> jmbsvicetto: I recall you weren't to happy about the vote question, is that still the case for you?
-19:48 <       ulm@> jmbsvicetto: please remind me, who's our group contact currently?
-19:49 <Betelgeuse@> ulm:  I am
-19:49 <jmbsvicett@> The current group contacts were related to devrel, undertakers and userrel, but that isn't a requirement
-19:49 <jmbsvicett@> Betelgeuse is our primary group contact. The rest are me, Calchan and rane
-19:49 <jmbsvicett@> grobian: for the cloaks? I'm not against the vote, I'd just like people to clarify what we'd be voting on
-19:50 < dberkholz@> the vote is that it is not a council issue
-19:50 <  hwoarang@> i think there are 2 questions here
-19:50 <  hwoarang@> 1) do we want them? 2) if yes, who will manage them
-19:50 <   grobian@> jmbsvicetto: and I'd appreciate knowing that
-19:50 <  Chainsaw@> dberkholz: I note that I have failed to opt into the meeting chair list. Can I host the september one?
-19:50 <  Chainsaw@> Okay, all in favour of giving out user/contributor cloaks?
-19:51  * Chainsaw raises hand
-19:51 < dberkholz@> i still don't think it's a council issue and i would like to vote to delegate this to devrel and userrel
-19:51 <jmbsvicett@> Chainsaw: we already do contributor -> ATs/HTs
-19:51 < dberkholz@> regardless of how i personally feel about it
-19:52 <jmbsvicett@> dberkholz: I also don't think this needs to be handled at the council level
-19:52 < dberkholz@> assigning people more work isn't really my favorite thing to do =)
-19:52 <   grobian@> dberkholz: agree on that
-19:52 <  hwoarang@> dberkholz: whether we want them or not is a project issue. then we can delegate it to devrel
-19:52 <jmbsvicett@> but I understand tampakrap and hwoarang's wish to have a global policy about it
-19:52 <jmbsvicett@> and support it
-19:52 <   grobian@> let them present a policy first?
-19:52 <   Calchan > in case you're interested in the opinion of this group contact, please make sure that whatever you decide is OK with those that are going to deal with it
-19:52 <  hwoarang@> the policy is to grant a user/* cloak on developer's request
-19:52 <jmbsvicett@> I think that's the best course of action
-19:53 <   Calchan > hwoarang, no
-19:53 < dberkholz@> i would like to propose a vote to delegate this to devrel and userrel
-19:53 <   grobian@> ok, Calchan are you ok with discussing and chiming in on ML?
-19:53 <   Calchan > hwoarang, we don't grant user cloaks atm
-19:53 < dberkholz@> both the decision and the action
-19:53 <  hwoarang@> Calchan: this is why council's vote is required
-19:53 <  hwoarang@> to decide if user's cloak should be back in the game
-19:53 <  hwoarang@> do we want them as Gentoo project?
-19:53 <jmbsvicett@> hwoarang: I don't think it needs a council vote
-19:54 < dberkholz@> so, after repeating myself 3 times, maybe i should be more clear
-19:54 <  hwoarang@> i thought it was a global issue
-19:54 <jmbsvicett@> hwoarang: we can have global discussions that reach an agreement without council intervention
-19:54 <  hwoarang@> ok
-19:54 <   Calchan > hwoarang, are you seriously going to force group contacts to act against their will? if not, why don't you let them decide
-19:54 <Betelgeuse@> dberkholz: just start collecting votes :)
-19:54 < dberkholz@> vote: should devrel and userrel determine how and whether to give contributor and user cloaks?
-19:54 < dberkholz@> yes.
-19:54 <  hwoarang@> dberkholz: accoring to Calchan this is not a devrel, userrel issue
-19:55 <  hwoarang@> more likely a gentoo-groupcontacts issue
-19:55 <       ulm@> no
-19:55 <   grobian@> dberkholz: no vote at all, it's not clear, and not an issue for council
-19:55 <   Calchan > hwoarang, I have never said that, and now I shut up :o/
-19:55 <Betelgeuse@> hwoarang: currently devrel runs group contacts
-19:55 < dberkholz@> considering the group contacts are all devrel and userrel, and if they aren't currently then they should be, i still do consider it under their umbrella(s)
-19:55 <  hwoarang@> ok
-19:56 <Betelgeuse@> Calchan: Really Group Contacts shouldn't be able to veto but certainly their opinions should be listened to. In this case as I am both in the council and devrel the question is theoretical.
-19:56 <jmbsvicett@> dberkholz: let me repeat myself, that the current group contacts were at the time and still are devrel, undertakers and userrel was a coincidence
-19:56 <  hwoarang@> Calchan: you said that I am trying to force group contacts to act against their will
-19:56 < dberkholz@> i've gotten 1 yes from me, 1 no from ulm, and nothing else from anyone
-19:56 <jmbsvicett@> dberkholz: to be clear, it's up to the current group contacts and freenode to chose the group contacts (per informal policy, whim or however you want to call it)
-19:56 < dberkholz@> so why are even discussing this if we aren't making any decisions?
-19:56 <jmbsvicett@> dberkholz: meaning that there's no gentoo policy on this and there's limited influence
-19:57 <Betelgeuse@> dberkholz: I will vote blank as I am too involved on either side any way
-19:57 <jmbsvicett@> dberkholz: make it a devrel + userel decision - no
-19:57 <jmbsvicett@> dberkholz: move it to the mls so that the community can reach an agreement - yes
-19:57 <  hwoarang@> we already had a discussion
-19:57 <       ulm@> right, let's have interested parties present a policy and then we can vote on it
-19:57 <  hwoarang@> why do we need to wait 30 more days
-19:57 <   grobian@> sounds like a plan
-19:57 < dberkholz@> if the community had reached an agreement, we wouldn't be screwing around here discussing it still
-19:57 <  hwoarang@> sigh
-19:58 < dberkholz@> alright, i'm done with this topic
-19:58 <  hwoarang@> dberkholz: Betelgeuse said that this could be part of devrel GLEP proposal
-19:58 < dberkholz@> we're not getting anywhere with it
-19:58 < dberkholz@> anyone else?
-19:58 <   grobian@> next topic
-19:58 <       ulm@> dberkholz: move on
-19:58 <   grobian@> easy vote
-19:58 <jmbsvicett@> move one
-19:58 <jmbsvicett@> on*
-19:59 < dberkholz@> ok, the -council list
-19:59 < dberkholz@> do we need it to discuss agenda items, in addition to -dev, -project, and the council alias for procedural stuff?
-19:59 <Betelgeuse@> no
-19:59 <jmbsvicett@> no
-19:59 <       ulm@> yes
-19:59 <   grobian@> yes
-20:00 <Betelgeuse@> If it's reopened someone needs to draft guidelines on when to post there.
-20:00 <  Chainsaw@> yes
-20:00 <  hwoarang@> no
-20:00 < dberkholz@> no
-20:00 <  Chainsaw@> Tie-breaker?
-20:00 <  Chainsaw@> -project it is.
-20:00 <   grobian@> 4 no, 3 yes, right?
-20:00 <Betelgeuse@> yes
-20:01 <  Chainsaw@> Indeed. We lose. Sorry grobian.
-20:01 <Betelgeuse@> Chainsaw: For me it's ok if you want to take next meeting
-20:01 <   grobian@> that's the game
-20:01 < dberkholz@> alright, i have a current chair schedule
-20:01 <   grobian@> dberkholz: so action point, that bug should be updated, and people poked to close that list down
-20:01 < dberkholz@> anyone got a problem with it?
-20:02 <jmbsvicett@> dberkholz: I'm ok with it
-20:02 <  Chainsaw@> dberkholz: I would like to be on it, but other then that it looks good :)
-20:02 < dberkholz@> Chainsaw: reload
-20:02 < dberkholz@> if you want to be on it again, find another volunteer =)
-20:02 <jmbsvicett@> If you want to adjust it still, we should pick the next month's chair and have a vote in the mls for a (the?) final proposal
-20:02 <  Chainsaw@> dberkholz: Thumbs up.
-20:03 <  Chainsaw@> jmbsvicetto: Outdated comment. Happy with it now.
-20:03 <  hwoarang@> dberkholz: please keep this list on your devspace
-20:03 <jmbsvicett@> ok
-20:03 < dberkholz@> alright, i'm going to put that into a table on the council page
-20:03 <   grobian@> jmbsvicetto: hmmm, I cannot guarantee my agenda now, I would like to allow for individual arrangements amongst council members
-20:03 < dberkholz@> and if anyone wants to trade, feel free
-20:03 <jmbsvicett@> yeah, please move it to the council web space
-20:04 <jmbsvicett@> grobian: sure, there's no problem with that
-20:04 <   grobian@> jmbsvicetto: ok
-20:04 <jmbsvicett@> but whenever someone does an arrangement, that person has to update the file
-20:04 <   grobian@> sounds fair
-20:05 < dberkholz@> anything else we need to get through today?
-20:05 <  hwoarang@> should we update the council page
-20:05 <  hwoarang@> section 4
-20:05 <jmbsvicett@> hwoarang: we can add a link there
-20:06 < dberkholz@> sure, i'll do that to describe the chair selection while i'm doing the table
-20:06 <jmbsvicett@> dberkholz: not from me
-20:06 <  hwoarang@> Also the meeting date is the second Tuesday
-20:06 <  hwoarang@> not monday
-20:06 < dberkholz@> anyone got an open-floor item besides the 2 that are explicitly not on the agenda? =D
-20:07 <jmbsvicett@> For the log, the next meeting will be held on Tuesday 20110913 1900 UTC
-20:07 < dberkholz@> great, that wraps things up for today. thanks everyone
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110913-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20110913-summary.txt
deleted file mode 100644
index d4b9d97bd4..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110913-summary.txt
+++ /dev/null
@@ -1,124 +0,0 @@
-Council meeting summary: 20110913
-
-
-Agenda
-------
-
- * Roll call (5 minutes; anyone later will be given a slacker mark)
-
- * Vote on whether to make Manifest signing mandatory (proposed by bonsaikitten)
- * Review open bugs with council involvement
-
- * Open floor - listen to the community
-
-
-Meeting
--------
-
- * roll call
-
-    here:
-
-    Betelgeuse
-    chainsaw
-    dberkholz
-    grobian
-    hwoarang
-    jmbsvicetto
-    ulm
-
-
- * vote/discuss:
-
-   * Vote on whether to make Manifest signing mandatory (proposed by bonsaikitten)
-
-     The council didn't address this point in the meeting as there was no concrete proposal
-     to be discussed / voted by the council. Some council members addressed this issue in the
-     #gentoo-council channel with Patrick before the meeting.
-
-   * Review open bugs with council involvement
-
-     After an initial confusion about the number of open bugs, the council addressed the 9
-     open bugs[1].
-
-     [1] - https://bugs.gentoo.org/buglist.cgi?cmdtype=dorem;remaction=run;namedcmd=council;sharer_id=42650;list_id=422625
-
-     * bug 331987 - https://bugs.gentoo.org/show_bug.cgi?id=331987
-
-     The council agreed with infra's suggestion to do an SMTP level bounce for mails directed
-     to the council ml. Tony will ask infra to provide the number of users affected, so the
-     council can reply to the 2nd question on comment #9.
-
-     * bug 341959 - https://bugs.gentoo.org/show_bug.cgi?id=341959
-
-     Council members agreed that this bug is fixed and decided Markos will ask Torsten if he's
-     ok with the bug being closed.
-
-     * bug 362803 - https://bugs.gentoo.org/show_bug.cgi?id=362803
-
-     Jorge acknowledged he forgot to update the xml file and will ask Torsten if he wants to
-     take care of the bug or he'll take care of it.
-
-     * bug 374931 - https://bugs.gentoo.org/show_bug.cgi?id=374931
-
-     Everyone agreed this bug should be closed as the council webapp is already running.
-     Petteri will take care of this.
-     To help test the council webapp, Markos will try to use it for the next meeting.
-
-     * bug 234706 - https://bugs.gentoo.org/show_bug.cgi?id=234706
-
-     Tony argued that since this bug lost its champion and that the affected arches
-     seem to be responsive again, the bug should be closed as OBSOLETE. The other
-     members agreed.
-
-     * bug 234711 - https://bugs.gentoo.org/show_bug.cgi?id=234711
-
-     The council members decided to close this bug as OBSOLETE since it depends on
-     GLEP55 which was not accepted.
-
-     * bug 237381 - https://bugs.gentoo.org/show_bug.cgi?id=237381
-
-     Donnie explained that he added a section to the council page following this
-     request. Other members agreed that section was clear enough and that the bug
-     should be closed as fixed.
-
-     * bug 316401 - https://bugs.gentoo.org/show_bug.cgi?id=316401
-
-     The council considers this bug to be resolved from council side and Petteri
-     will ask Christian about closing it.
-
-     * bug 330361 - https://bugs.gentoo.org/show_bug.cgi?id=330361
-
-     Jorge addressed Fabian's question and explained that the current automatic
-     builds are working correctly and that python2 is set as default on stage3.
-     Jorge also explained that this bug is about not having python3 in the stages
-     and that his and releng opinion about that was presented clearly in the bug.
-     The council members agreed that council should not be involved on this bug
-     and decided to reassign the bug to releng and defer to their decision.
-
-   * Vote on a remaining issue from last meeting regarding echangelog generation
-
-     Before the meeting started, Donnie suggested we used any remaining time to
-     go over one issue that had remained from the previous meeting: should we
-     require that autogenerated changelogs have a way to edit them afterwards to
-     fix typos and such.
-     After a discussion about whether the council could vote on this issue or not,
-     there was a discussion about what was being voted on.
-     Jorge argued that as he recalled this issue had been considered "obsolete"
-     as the decisions in the previous meeting implied the existence of a file.
-     Fabian argued that even though that was his understanding at the meeting, after
-     rethinking about it, he thought it would be possible not to have a file. He
-     also acknowledged that he believed the intention had been to have a file.
-     In the end, given some open questions and nearing the end of the meeting, the
-     council decided to move this discussion back to the mls - Markos will start
-     a new thread, independent from the current git discussion, well before the
-     next meeting.
-
- * listen to the community to see if there are any issues it would like
-   to see the council address in this term
-
-   No issues were brought up to the council by the community.
-
- * Next meeting date
-
-   Tuesday, 20111011 1900 UTC
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20110913.txt b/xml/htdocs/proj/en/council/meeting-logs/20110913.txt
deleted file mode 100644
index c7431afcb6..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20110913.txt
+++ /dev/null
@@ -1,388 +0,0 @@
-19:01 <@Chainsaw> Alright, let's get started.
-19:01 <@Chainsaw> Roll call.
-19:01 <@Chainsaw> Chainsaw is here.
-19:01  * grobian is here
-19:01 <@dberkholz> present and reporting for duty
-19:01 <@Chainsaw> dberkholz, hwoarang, betelgeuse, jmbsvicetto, ulm: ping
-19:01  * jmbsvicetto is here
-19:02  * hwoarang here
-19:02 <@Betelgeuse> hello
-19:02 <@ulm> here
-19:02 <@Chainsaw> That is everyone, thank you.
-19:02 <@Chainsaw> Okay, we have 3 bugs with council involvement.
-19:02 <@Chainsaw> Correction, 4.
-19:03 <@Chainsaw> What do we need to do to move https://bugs.gentoo.org/show_bug.cgi?id=331987 along?
-19:03 <@jmbsvicetto> Chainsaw: I count 10
-19:03 <@Chainsaw> jmbsvicetto: I look forward to seeing your list.
-19:04 <@jmbsvicetto> I think we never replied to Robin - https://bugs.gentoo.org/show_bug.cgi?id=331987#c9
-19:04 <@dberkholz> Chainsaw: i count 9, from assignee and CC
-19:05 <@jmbsvicetto> Petteri replied on comment 10, but I don't think we decided anything (council)
-19:05 <@Chainsaw> Can we make this decision now?
-19:05 <@hwoarang> we did din't we?
-19:05 <@jmbsvicetto> hwoarang: I mean about comment 9, not about closing the ml
-19:05 <@Chainsaw> hwoarang: We made a decision, but we did not follow up with robbat2.
-19:05 <@ulm> we did in last meeting
-19:06 <@grobian> bounce + send email people can subscribe to -project
-19:06 <@hwoarang> ok
-19:06 <@Chainsaw> post-merge, how should mails to -council be handled? (I suggest SMTP-level
-19:06 <@Chainsaw> bounce since the address will not be valid anymore)
-19:06 <@jmbsvicetto> ok, I didn't recall that. We should probably add a comment there then
-19:06 <@Chainsaw> ^ This is the easy one, where "we concur" is an easy answer.
-19:06 <@ulm> the archive of -council will be preserved I hope?
-19:06 <@Chainsaw> - What should be done with the subscribers that are only on -council and not on
-19:06 <@Chainsaw> -project?
-19:06 <@Chainsaw> ^ That is the more interesting question.
-19:06 <@dberkholz> i'd go with whatever's easiest w/ infra for mails to the list
-19:07 <@dberkholz> autosubscribe but still send the confirmation email
-19:07 <@dberkholz> that way people still have to opt in, but the barrier to entry is low
-19:08 <@jmbsvicetto> hmm, I think autosubscribe will get them in, so they'll be able to opt-out, not opt-in
-19:09 <@Chainsaw> Well, it sounds like we have consensus on the first matter, but not on the second.
-19:09 <@jmbsvicetto> I do agree with the autosubscription
-19:09 <@hwoarang> would be nice to know how many ppl are subscribed in -council
-19:09 <@ulm> maybe send a last message to -council explaining that the list will be closed down and that people should subscribe to -project instead?
-19:09 <@grobian> I'm flexible, if people want autosubscription, it's ok with me
-19:09 <@hwoarang> would be the decision much easier
-19:09 <@dberkholz> well, i want it to be treated as if they just sent an email to gentoo-project+subscribe
-19:09 <@dberkholz> so they get the email saying "do you really want to sign up?" and have to reply
-19:10 <@Chainsaw> Okay. Shall we reply that we agree with the SMTP-level rejection, but ask how many people are affected by the second question?
-19:10 <@grobian> I prefer the way I wrote down first, but better explained by ulm
-19:10 <@Chainsaw> That way we do not have to discuss the details until we know how big of an issue it really is.
-19:10 <@Chainsaw> If we are talking about 3 people, we might as well e-mail them individually.
-19:10 <@hwoarang> if the audience is small then autosubscribe them
-19:10 <@hwoarang> otherwise be polite and let them decide what to do
-19:11 -!- jbartosik [~jbartosik@gentoo/developer/jbartosik] has quit [Ping timeout: 260 seconds]
-19:11 <@hwoarang> just my 0.02c
-19:11 <@grobian> what are the different opinions here?
-19:11 <@grobian> if we can all easily agree, we're done with it
-19:11 <@jmbsvicetto> Robin asked we filed a bug to know those numbers, so let's just make the request on that bug and we can have a quite vote after we get the numbers
-19:11 <@Chainsaw> grobian: Do we agree that we need to know the numbers affected?
-19:12 <@dberkholz> 1) email them and tell 'em to switch. 2) autosubscribe w/ confirmation email 3) autosubscribe w/o confirmation
-19:12 <@jmbsvicetto> s/quite/quick/
-19:12 <@dberkholz> is there another option?
-19:12 <@grobian> Chainsaw: not important to me, if we want automigration, we don't care if it's 3, or 30000 people
-19:12 <@Chainsaw> grobian: But do you agree to ask for numbers and postpone?
-19:12 <@Chainsaw> grobian: I would like to move the discussion forward to other bugs. There's 9 more.
-19:12 <@grobian> Chainsaw: if you all want that, then I agree if we then can make a "decision" before the next months' meeting
-19:13 <@grobian> this takes way too long for a simple little issue
-19:13 <@hwoarang> true
-19:13 <@Chainsaw> grobian: I know, that is why I am asking you all to agree to a set of two answers.
-19:13 <@Chainsaw> grobian: "1) Yes, that is fine. 2) Please give us the number of affected subscribers."
-19:13 <@ulm> sounds good
-19:13 <@jmbsvicetto> Chainsaw: let's vote on waiting for numbers before starting a mail vote
-19:13 <@grobian> Chainsaw: ok, agreed
-19:13 <@Chainsaw> ulm, grobian: Thank you.
-19:13 <@Chainsaw> jmbsvicetto: Agreed?
-19:14 <@jmbsvicetto> yes
-19:14  * Chainsaw posts
-19:14 <@Chainsaw> https://bugs.gentoo.org/show_bug.cgi?id=341959
-19:15 <@Chainsaw> The bug is still open. Is it clear what we need to do to close it?
-19:16 <@ulm> Chainsaw: tove reopened it with comment #5
-19:16 <@hwoarang> the new patch is already merged to devmanual
-19:16 <@hwoarang> i think the bug is fixed
-19:16 <@grobian> tove: are you still around?
-19:16 <@hwoarang> let me check the devmanual
-19:16 <@grobian> let's ask him
-19:16 <@Chainsaw> If tove agrees, it would be good to close this off.
-19:17 <@hwoarang> ok
-19:17 <@grobian> ok, he's not here, let's ask on the bug
-19:17 <@jmbsvicetto> I think the mention about eclass deprecation could also be tied to the recent discussions on doing eclass bumps on major rewrites
-19:17 <@Chainsaw> hwoarang: Could you post to that bug please?
-19:17 <@Chainsaw> hwoarang: You were last to respond.
-19:17 <@hwoarang> yes I will
-19:17 <@Chainsaw> hwoarang: Thank you.
-19:17 <@Chainsaw> jmbsvicetto: https://bugs.gentoo.org/show_bug.cgi?id=362803
-19:18 <@Chainsaw> jmbsvicetto: Was that update done please? If it was, could you resolve the bug?
-19:18 <@jmbsvicetto> Chainsaw: I forgot to touch the xml. I'll try to do it this week, but if anyone wants to do it quickly, feel free to
-19:18 <@Chainsaw> All: https://bugs.gentoo.org/show_bug.cgi?id=374931 <- What is left to do?
-19:19 <@jmbsvicetto> Chainsaw: I'll take care of the bug in either case
-19:19 <@Chainsaw> jmbsvicetto: tove implied he was willing to do it. Could you post a reply saying so?
-19:20 <@grobian> Chainsaw: bug seems to suggest the system is up now
-19:20 <@Chainsaw> grobian: So can it be resolved?
-19:21 <@dberkholz> ask jbartosik whether it's fixed, since he reported it
-19:21 <@grobian> Chainsaw: ask betelgeuse, he was mentoring
-19:21 <@jmbsvicetto> Chainsaw: the app is up, but it's probably best to leave this one to Petteri
-19:21 <@Chainsaw> Betelgeuse: Is that bug ready to be resolved? If not, could you post an update saying what is outstanding please?
-19:21 <@Betelgeuse> Let's close that.
-19:21 <@Chainsaw> All: https://bugs.gentoo.org/show_bug.cgi?id=234706 <- With Halcy0n no longer on the council, is this dead?
-19:21 <@Chainsaw> Betelgeuse: Thank you. Could you do that?
-19:22 <@Betelgeuse> new bugs can be filed with https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Hosted%20Projects
-19:22 <@Chainsaw> MIPS & PowerPC appear to be back to life, so is it obsolete?
-19:22 <@grobian> Chainsaw: I vote for yes on 234706
-19:22 <@Chainsaw> Thank you grobian. Other opinions on 234706 please?
-19:22 <@Chainsaw> I would like to mark it RESO OBSOLETE.
-19:22 <@grobian> agreed
-19:22 <@ulm> yeah, it's obsolete
-19:22 <@Chainsaw> Both for losing its champion, and for the situation having been more or less resolved now.
-19:23 <@hwoarang> Betelgeuse: if we go to close that bug maybe it is time to use tha application?
-19:23 <@jmbsvicetto> Chainsaw: that bug lead to the mail discussions of the previous council
-19:23 <@hwoarang> it is not clear to me if the application is deployer or not :)
-19:23 <@jmbsvicetto> Chainsaw: if there's no one "fighting" for that bug, I'd close it
-19:23 <@dberkholz> maybe hwoarang wants to volunteer to be the first victim
-19:23 <@Betelgeuse> hwoarang: hopefully
-19:23 <@dberkholz> since he's chairing the next meeting
-19:24 <@hwoarang> is it up and running?
-19:24 <@hwoarang> i have to check first :)
-19:24 <@jmbsvicetto> Betelgeuse: how's the bot doing?
-19:24 <@Chainsaw> https://bugs.gentoo.org/show_bug.cgi?id=234706#c9
-19:24 <@Chainsaw> "This proposal has lost its champion. On a personal note, I believe that the
-19:24 <@Chainsaw> situation has improved since this bug was filed, and that the status quo is
-19:24 <@Chainsaw> acceptable."
-19:24 <@dberkholz> you're chairing, you can make the call. try it out and see if it meets your standards
-19:24 <@hwoarang> kk
-19:24 <@Betelgeuse> jmbsvicetto: I think the bot needs to be started manually atm
-19:25 <@Chainsaw> https://bugs.gentoo.org/show_bug.cgi?id=234711 <- There is mostly PM discussion here, is there more that is required of us?
-19:25 <@jmbsvicetto> but is it working? Last time I tried it, it wasn't working that well
-19:25 <@Betelgeuse> hwoarang: you probably want to email jbartosik and ask what he thinks
-19:25 <@hwoarang> ok
-19:25 <@Chainsaw> jmbsvicetto: But isn't that a new issue then?
-19:26 <@jmbsvicetto> Chainsaw: GLEP54 and GLEP55 bugs never got "resolved". I think the argument has been that there never was a final decision about them
-19:26 <@Betelgeuse> jmbsvicetto: jbartosik did work on QA towards the end of the project so hopefully better
-19:26 <@Chainsaw> jmbsvicetto: Yes. So is there more that we can do to move them along?
-19:26 <@grobian> sdeems like portage + pms work
-19:26 <@grobian> for the next EAPI
-19:26 <@ulm> jmbsvicetto: IIRC, 54 was accepted but 55 was declined by some previous council
-19:26 <@jmbsvicetto> Chainsaw: I think we should probably push them back
-19:27 <@Chainsaw> jmbsvicetto: No is a valid answer. But I do not want it to linger out of apathy.
-19:27 <@Chainsaw> jmbsvicetto: Push back?
-19:27 <@jmbsvicetto> ulm: yes, 55 was declined
-19:28 <@Chainsaw> And 55 is RESO LATER.
-19:28 <@jmbsvicetto> Chainsaw: handle it back to pms or the proponents and tell them they need to work on it or drop it
-19:28 <@Chainsaw> jmbsvicetto: "The council believes that this GLEP is not ready for implementation as-is, and invites proponents to reopen this bug with suggestions to move it forward."
-19:29 <@Chainsaw> jmbsvicetto: RESO LATER?
-19:29 <@Betelgeuse> RESO LATER is gone
-19:29 <@Chainsaw> Betelgeuse: RESO OBSOLETE?
-19:29 <@jmbsvicetto> iirc, 55 ended up as RESO LATER because of the discussion on how to allow major changes to repo format
-19:29 <@ulm> GLEP 54 was "Conditionally approved on whether GLEP 55 is approved."
-19:29 <@ulm> 20090514 meeting
-19:29 <@jmbsvicetto> Chainsaw: RESO CANTFIX ?
-19:29 <@jmbsvicetto> or OBSOLETE
-19:30 <@grobian> NEEDINFO
-19:30 <@Chainsaw> jmbsvicetto: "Because this GLEP is dependent upon GLEP 55, which was not accepted by the council, we believe that the current proposal can not be implemented. We would respectfully request that a new GLEP is filed for this matter." RESO CANTFIX
-19:30 <@Chainsaw> jmbsvicetto: ?
-19:30 <@jmbsvicetto> The final discussion on 55 isn't obsolete, imho
-19:30 <@jmbsvicetto> seems ok to me (54)
-19:30 <@Chainsaw> grobian, ulm: Does that sound acceptable please?
-19:31 <@jmbsvicetto> Chainsaw: new GLEP or that the GLEP is revised
-19:31 <@grobian> Chainsaw: yes, ok with me
-19:31 <@ulm> Chainsaw: sounds like the best we can do about it, for the time being
-19:31 <@Chainsaw> jmbsvicetto: New GLEP is clearer, it prevents a new lingering state.
-19:31 <@Chainsaw> jmbsvicetto: And avoids the dependency on the dead 55.
-19:31 <@jmbsvicetto> ok
-19:32 <@Chainsaw> Posted, thank you.
-19:32 <@Chainsaw> jmbsvicetto: https://bugs.gentoo.org/show_bug.cgi?id=237381 <- What can we do about this one?
-19:32 <@dberkholz> anyone feel like pushing on glep 55?
-19:32 <@dberkholz> or is it just going to sit there?
-19:32 <@Chainsaw> dberkholz: It is RESO LATER, which means I am not considering it in this review.
-19:33 <@Chainsaw> dberkholz: (As I am reviewing open bugs with the council)
-19:33 <@Chainsaw> Betelgeuse: https://bugs.gentoo.org/show_bug.cgi?id=316401 <- I believe this is resolved, if you agree, could you please close it?
-19:33 -!- darkside_ [~darkside@gentoo/developer/darkside] has joined #gentoo-council
-19:33 <@jmbsvicetto> Chainsaw: someone needs to describe / document the appeals process
-19:34 <@dberkholz> i think that's fixed
-19:34 <@jmbsvicetto> Chainsaw: I've been meaning to take care of that one for a long time, but I keep getting distracted with other stuff
-19:34 <@Chainsaw> jmbsvicetto: But "someone" is not a person on this council, so we need to be more specific.
-19:34 <@dberkholz> see http://www.gentoo.org/proj/en/council/#doc_chap3
-19:34 <@Betelgeuse> Chainsaw: see the last comment
-19:34 <@Betelgeuse> Chainsaw: I will ask idl0r if it can be closed
-19:35 <@dberkholz> can we just close the appeals bug?
-19:35 <@Chainsaw> dberkholz, Betelgeuse: So you would vote RESO FIXED; "This has been adequately documented in http://www.gentoo.org/proj/en/council/#doc_chap3. This issue has been resolved."
-19:35 <@Chainsaw> jmbsvicetto: Are you willing to join in on that?
-19:35 <@jmbsvicetto> dberkholz: I think the bug was asking for a more detailed description and was mostly directed towards disciplinary appeals
-19:36 <@dberkholz> i'm pretty sure that description was actually posted after the bug was filed
-19:36 <@jmbsvicetto> Chainsaw: If the reporter accepts that, sure
-19:36 <@Chainsaw> jmbsvicetto: The reporter is not present at this time.
-19:36 <@jmbsvicetto> Chainsaw: let me rephrase, yes, let's close it and see if the reporter is fine with that
-19:36 <@Chainsaw> jmbsvicetto: But if we as the council feel that the matter is resolved, I feel the bug should be closed.
-19:36 <@Chainsaw> jmbsvicetto: Thank you.
-19:36 <@Chainsaw> Is my summary agreed?
-19:36 <@Chainsaw> If so, I will post that now.
-19:36 <@jmbsvicetto> yes
-19:37 <@grobian> yes
-19:37 <@ulm> yes
-19:37 <@Chainsaw> Cheers guys. Posted.
-19:37 <@dberkholz> the bug was filed in late 2008, i added the appeal description in early 2009
-19:37 <@Chainsaw> jmbsvicetto: https://bugs.gentoo.org/show_bug.cgi?id=362803 -> This is with tove then?
-19:38 <@jmbsvicetto> Chainsaw: with me
-19:38 <@Chainsaw> Betelgeuse: You were last to post in https://bugs.gentoo.org/show_bug.cgi?id=330361
-19:38 <@jmbsvicetto> Chainsaw: If he doesn't take care of it, I will
-19:38 <@Chainsaw> Betelgeuse: Is there an action point for the council?
-19:38 <@Chainsaw> jmbsvicetto: Thank you. Could you post a chase on the bug?
-19:38 <@Chainsaw> jmbsvicetto: In the interests of transparency, etc.
-19:38 -!- jbartosik [~jbartosik@gentoo/developer/jbartosik] has joined #gentoo-council
-19:39 <@jmbsvicetto> Chainsaw: you skipped 316401 which should be done for us
-19:39 <@Chainsaw> <Chainsaw> Betelgeuse: https://bugs.gentoo.org/show_bug.cgi?id=316401 <- I believe this is resolved, if you agree, could you please close it?
-19:39 <@jmbsvicetto> Chainsaw: I added a note to that bug
-19:39 <@Chainsaw> I did no such thing.
-19:39 <@Chainsaw> jmbsvicetto: Thank you.
-19:39 <@jmbsvicetto> Chainsaw: sorry, it seems it were my eyes who skipped your comment
-19:40 <@grobian> python3, isn't the stage building fine in that regard by now, jmbsvicetto ?
-19:40 <@Chainsaw> jmbsvicetto: Not to worry. Betelgeuse says it is in hand.
-19:40 <@jmbsvicetto> grobian: it is building fine, but the "request" was to drop python3 from stage3 (it's still there)
-19:41 <@jmbsvicetto> You should be able to read my opinion (and that of releng) about that bug in my comments there
-19:41 <@Betelgeuse> Chainsaw: probably not
-19:41 <@Betelgeuse> Chainsaw: hopefully people can solve what's left among themselves
-19:41 <@grobian> my feeling is that bug can be closed
-19:41 <@jmbsvicetto> basically, we won't add manual hacks to fix an issue with the tree - python3 is in the stage3 because the system set pulls it in
-19:41 <@grobian> right
-19:42 <@grobian> I vote for WONTFIX then
-19:42 <@jmbsvicetto> for what is worth, I'm sure no one in releng will "fix this" even if council were to "push" a decision about it
-19:43 <@jmbsvicetto> grobian: I'd vote WONTFIX, but I should probably excuse myself from this bug
-19:43 <@Chainsaw> jmbsvicetto: "The council feels it is inappropriate to manually filter dev-lang/python-3 from the tree as it is marked stable." RESO WONTFIX?
-19:43 <@grobian> jmbsvicetto: heh
-19:44 <@Chainsaw> ^ grobian, Betelgeuse?
-19:44 <@jmbsvicetto> Chainsaw: I'd be more happy if the decision was "the council considers there's nothing to gain from intervening on this issue and defers to releng"
-19:44 <@grobian> Chainsaw: I'm thinking
-19:44 <@Chainsaw> jmbsvicetto: That kicks the can further down the street.
-19:44 <@grobian> Chainsaw: what jmbsvicetto said
-19:44 <@hwoarang> i agree
-19:44 <@Chainsaw> That is a majority, so I will post that.
-19:45 <@grobian> Chainsaw: I like that Council has nothing to decide here, it's in the end just a package that is added, and stable now
-19:45 <@ulm> +1
-19:45 <@Chainsaw> "The council feels there is nothing to gain from interfering on this issue. We defer to Release Engineering and consider their vote binding."
-19:45 <@Chainsaw> RESO WONTFIX
-19:45 <@Chainsaw> Agreed?
-19:45 <@ulm> or reassign
-19:46 <@Chainsaw> Leave open, assign to releng@gentoo.org?
-19:46 <@ulm> yes
-19:46 <@Chainsaw> grobian, hwoarang, jmbsvicetto?
-19:46 <@hwoarang> yes
-19:46 <@ulm> releng can close it if they want
-19:46 <@grobian> Chainsaw: reassign releng with your message
-19:47 <@Chainsaw> releng@gentoo.org did not match anything
-19:47 < darkside_> it is actually release@g.o iso releng@
-19:47 <@Chainsaw> Right, thank you.
-19:47 <@Chainsaw> That has been posted.
-19:48 <@Chainsaw> That leaves us with 4 open bugs.
-19:48 <@Chainsaw> And active work going on within them.
-19:48 <@grobian> good job so far
-19:48 <@jmbsvicetto> Chainsaw: yes
-19:48 <@Chainsaw> I would like to open the floor for community involvement, unless there is any other business from the council members at this time?
-19:48  * Chainsaw looks round the room
-19:49 <@dberkholz> there's the one thing i mentioned beforehand
-19:49 <@dberkholz> regarding changelog autogeneration
-19:49 <@grobian> dberkholz: suggested to continue voting on the changelog points
-19:49 <@Chainsaw> grobian: It seemed to be in the discussion phase still, with no clear set of points to vote on.
-19:49 <@dberkholz> the remaining point, which was unclear to some of us (at least me) at the last meeting, was whether we should require that autogenerated changelogs have a way to edit them afterwards to fix typos and such.
-19:50 <@ulm> I don't think that we should vote on it now, if it wasn't in the agenda
-19:51 <@grobian> it preferably should have been discussed, so have to agree with ulm here
-19:51 <@dberkholz> sigh.
-19:51 <@dberkholz> can we just start adding a template field to the agenda that says "old business" then?
-19:51 <@dberkholz> it's clearly an unresolved issue from the previous meeting that could have been voted upon then, but whatever
-19:51 <@Chainsaw> dberkholz: It is any other business, so I am happy to discuss it. But I do not believe we have a clear-cut set of vote items.
-19:52 <@Chainsaw> dberkholz: Could you put it up for next month please?
-19:52 <@Chainsaw> It is unfortunate, but I have been set a time limit of 1 week for the draft agenda.
-19:52 <@grobian> I don't thing we need a meeting per se, if it were to be discussed and all of us would agree
-19:53 <@dberkholz> i might wait a couple more meetings just to see how absurdly long the council can take to vote on this minor issue. =P
-19:53 <@jmbsvicetto> ulm / grobian: we could vote on this matter
-19:53 <@Chainsaw> That limits what I can add to it. I wanted less notice so we could be more flexible, but I was not in majority on that.
-19:53 <@jmbsvicetto> we did leave it for a voting in the mls
-19:53 <@grobian> jmbsvicetto: I'm prepared for the issue, so no problem to vote from my side, but technically speaking I think we should have everyone prepared on this
-19:54 <@jmbsvicetto> iirc, this issue was also considered "obsolete" since the decisions made implied that we would still have a file and so it would be possible to edit it
-19:55 <@Chainsaw> It, like many things, hinges on a git conversion.
-19:55 <@ulm> jmbsvicetto: that was my understanding too
-19:55 <@grobian> I'm reinterpreting what's written down, and I now think it doesn't force that ;)
-19:55 <@Chainsaw> So, do we want to spend time on this? We can if you want to?
-19:55 <@grobian> but yes, I believe that was the intention last meeting
-19:55 <@grobian> which I think is a shame
-19:56 <@jmbsvicetto> Chainsaw: I think we should try to clarify whether the decisions imply the existance of a file or not
-19:56 <@dberkholz> i need to get going in a few minutes here
-19:56 <@grobian> Chainsaw: I still think the discussion needs to be opened, since jmbsvicetto had new ideas last meeting
-19:56 <@jmbsvicetto> Chainsaw: if so, then we don't need to vote about this issue. If not, we can quickly vote
-19:56 <@Chainsaw> jmbsvicetto: If there is an ambiguity, we should vote on a set of points that clarifies the earlier decision.
-19:56 <@Chainsaw> jmbsvicetto: And I am happy to do that now, as it is a continuation of what we voted on before.
-19:57 <@jmbsvicetto> I'm ready to discuss vote
-19:57 <@jmbsvicetto> + /
-19:57 <@grobian> I want: ChangeLog file being generated completely from VCS log, nothing stored
-19:57 -!- _AxS_ [~axs@gentoo/user/axs] has joined #gentoo-council
-19:57 <@Chainsaw> grobian: But do you want that now? Can we do that with CVS?
-19:57 <@grobian> yes
-19:57 <@grobian> Prefix is doing it
-19:57 <@grobian> for both CVS and SVN by the way
-19:57 <@ulm> I want to be able to correct mistakes
-19:58 <@Chainsaw> ulm: That is what I like about having a file, yes. And I have made mistakes in Changelogs before that I fixed.
-19:58 <@grobian> right, for simplicity, I just take mistakes for granted
-19:58 <@Chainsaw> ulm: But at least that is a clear A/B vote. Do we want to move, in the current CVS tree, towards automatically generated Changelogs, removing the files from the tree?
-19:58 <@grobian> people suggested using git notes for making fixes to commit messages
-19:58 <@hwoarang> errr git is a long-shot atm
-19:59 <@Chainsaw> grobian: That means running patch in your mind, rather than on a file.
-19:59 <@hwoarang> i think the solution should be based on the current $VCS
-19:59 <@jmbsvicetto> Chainsaw: automatic generation was already voted for
-19:59 <@ulm> grobian: if git will allow such a thing, I'm fine with it
-19:59 <@grobian> ulm: which implies, we only do it when git comes
-19:59 <@Chainsaw> jmbsvicetto: Then we do not appear to have a clear A/B vote that we can work on now.
-19:59 <@jmbsvicetto> I agree with voting on an implementation that is not tied to a particular VCS
-20:00 <@Chainsaw> jmbsvicetto: As such I suggest that this is moved back to the mailing list for discussion, well in advance of the next draft agenda being set.
-20:00 <@jmbsvicetto> Chainsaw: it was approved by the previous council and wasn't reverted by this council on the previous meeting
-20:00 <@Chainsaw> jmbsvicetto: We are nearing 1 hour of meeting now, and dberkholz will have to leave.
-20:00 <@grobian> I think if we want commit messages to be edited somehow, we make it hard for ourselves, and echangelog being called automatically from repoman is the closest option to "autogeneration"
-20:00 <@jmbsvicetto> ok, I'm fine with that
-20:00 <@hwoarang> the discussion in ML has already moved to git specific stuff
-20:01 <@hwoarang> i am not sure if it makes sense to keep that discussion
-20:01 <@Chainsaw> hwoarang: Then I suggest that it is steered with an appropriate comment.
-20:01 <@jmbsvicetto> hwoarang: I never started the discussion - my fault :\
-20:01 <@hwoarang> Chainsaw: well yes
-20:01 <@Chainsaw> I would like to open the floor at this point?
-20:01 <@jmbsvicetto> hwoarang: The current discussion on the dev ml was started on a parallel issue
-20:01 <@hwoarang> but the git discussion will kick in eventually at some point
-20:01 <@jmbsvicetto> Chainsaw: I'm fine with that
-20:01 <@hwoarang> someone has to constantly drive this thread :)
-20:02 <@Chainsaw> hwoarang: Perhaps the initial message will need to be more stern on what is and isn't appropriate for the discussion?
-20:02 <@hwoarang> ok
-20:02 <@hwoarang> i will take care of that since I chair the next meeting
-20:02 <@Chainsaw> hwoarang: Thank you.
-20:02 <@jmbsvicetto> hwoarang: I suggest you start a new thread
-20:02 <@hwoarang> will reset(?) the discussion as soon as possible
-20:02 <@hwoarang> yes
-20:02 <@Chainsaw> jmbsvicetto: I second that.
-20:03 <@grobian> git reset --hard :)
-20:03 <@jmbsvicetto> hehe
-20:03 <@Chainsaw> jmbsvicetto: Would you be willing to do a summary of this meeting please, to make sure that it is impartial?
-20:03 <@jmbsvicetto> Chainsaw: me doing the summary and it being impartial? ;)
-20:04 <@grobian> since dberkholz is leaving, can we round up?
-20:04 <@jmbsvicetto> Chainsaw: I can take care of it later
-20:04 <@Chainsaw> jmbsvicetto: It would be more impartial than if I wrote it. I was planning to do this during the meeting, but I got carried away with the discussion.
-20:04 <@Chainsaw> jmbsvicetto: I would rather admit this now then post a sub-par summary.
-20:04 <@jmbsvicetto> Chainsaw: I'll take care of it
-20:04 <@Chainsaw> grobian: I am happy to round up. I believe we can open the floor to the community at this time.
-20:04 <@Chainsaw> jmbsvicetto: It is most appreciated.
-20:05 <@Chainsaw> Do we agree that the next meeting is on the second Tuesday of next month please?
-20:05 <@dberkholz> i'd like to see us start sending summaries to -dev-announce again, too, so that everyone gets some visibility into what the council is doing.
-20:05 <@hwoarang> yes
-20:05 <@Chainsaw> dberkholz: I second that.
-20:05 -!- zmedico [~zmedico@gentoo/developer/zmedico] has quit [Remote host closed the connection]
-20:05 <@grobian> yes
-20:05 <@jmbsvicetto> Chainsaw: right, we need to set the date for the next meeting
-20:06 <@Chainsaw> The second Tuesday of the next month works well for me.
-20:06 <@hwoarang> dberkholz: +1
-20:06 <@dberkholz> why do we need to agree on a yearlong policy that we set a meeting or two ago?
-20:06 <@grobian> that is the 11th?
-20:06 <@jmbsvicetto> October 10th?
-20:06 <@Chainsaw> That would be the 11th of October, indeed.
-20:06 <@dberkholz> tuesday 11 october, 1900 utc
-20:06 <@Chainsaw> dberkholz: Yes. That works for me.
-20:06 <@jmbsvicetto> sorry, 11th, not 10th
-20:06 <@grobian> ok, 11th
-20:07 <@jmbsvicetto> btw, the daylight savings only kick in at the end of the month, correct?
-20:07 <@Chainsaw> dberkholz: Because we are all human, and our circumstances may change?
-20:07 <@grobian> jmbsvicetto: 30th of october
-20:07 <@Chainsaw> dberkholz: And because it is a nice harmonious "we all agree" moment for the end of the meeting?
-20:07 <@jmbsvicetto> grobian: Europe, right? iirc, US does it on a different weekend
-20:08 <@grobian> jmbsvicetto: Europe/Amsterdam
-20:08 <@jmbsvicetto> grobian: Europe/Portugal too, iirc
-20:08 <@grobian> Chainsaw: thank you mister chairman for this productive meeting
-20:08 <@Chainsaw> jmbsvicetto: Thankfully we plan meetings for UTC, which means we are blissfully unaffected.
-20:08 <@dberkholz> i'm just getting all cranky in my old age
-20:08  * Chainsaw bows to grobian and closes the meeting, so dberkholz can leave
-20:09 <@dberkholz> thanks Chainsaw, nice meeting
-20:09 <@jmbsvicetto> Chainsaw: well, I won't be surprised if we want to push it back 1 hour after the day light savings
-20:09 <@ulm> jmbsvicetto: I think that's the plan indeed ;)
-20:09  * grobian nods
-20:09 <@jmbsvicetto> Thanks Chainsaw for taking care of the meeting
-20:09 <@Chainsaw> Any time. Willing to do it again if there's a slot later in the year.
-20:10 <@Betelgeuse> thanks and sleepy time
-20:10 <@Chainsaw> Good night.
-20:10 <@grobian> gnight
-20:10 <@jmbsvicetto> night, I'm heading out
-20:11 <@Chainsaw> jmbsvicetto: Thanks again for the summary.
-20:14 <@dberkholz> oh btw everyone, the chair schedule is on the council webpage now
-20:15 <@grobian> dberkholz: seen, thanks
-20:16 -!- Chainsaw changed the topic of #gentoo-council to: Next meeting: October 11, 1900UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20111011-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20111011-summary.txt
deleted file mode 100644
index 1fd34b7cfa..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20111011-summary.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Council meeting summary: 20111011
-
-
-Agenda
-------
-
-* Roll call (5 minutes; anyone later will be given a slacker mark)
-
-* Vote on whether we want to edit generated ChangeLogs and if
-'yes' discuss the abstract implementation so we can finally start
-working on that. 
-
-* EAPI-1 in profiles
-
-* Review open bugs with council involvement
-
-* Open floor - listen to the community
-
-Meeting
--------
-
- * roll call
-
-    here:
-
-    Betelgeuse
-    chainsaw
-    dberkholz
-    grobian
-    hwoarang
-    jmbsvicetto
-    ulm
-    
-
-
- * vote/discuss:
-
-	* Vote on whether we want to edit generated ChangeLogs and the
-	abstract implementation that was decided
-
-	The council decided to allow edits on ChangeLogs. The implementation
-	will be discussed with the portage developers.
-
-	* EAPI-1 in profiles
-
-	The council decided to allow EAPI-1 in profiles
-
-*  Open bugs
-	
-	* Bug #316401: No progress since last month. idl0r agreed to take care
-	of it.
-
-	* Bug #331987: No progress since last month. antarus provided the
-	subscriber numbers for gentoo-project and gentoo-council mailing lists.
-	54 subscribers found to be only subscribed in gentoo-council but not in
-	gentoo-project. The council decided to move these subscribers to
-	gentoo-project and send them a message informing them how to 
-	remove themselves from the new gentoo-project mailing list. 
-
-	* Bug #341959. No progress. hwoarang agreed to talk to tove about
-	that and sort it out.
-
-	* Bug #383467. jmbsvicetto will take care of that on behalf of the
-	elections team.
-
-* Open floor - Discussion
-
-	 No issues were brought up to the council by the community.
-	
-* Next meeting date
-
-	Tuesday, 20111108 1900 UTC (will be decided later because of daylight
-	saving time )
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20111011.txt b/xml/htdocs/proj/en/council/meeting-logs/20111011.txt
deleted file mode 100644
index cdc5d2b28a..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20111011.txt
+++ /dev/null
@@ -1,303 +0,0 @@
-[20:00:18] <hwoarang> time to start?
-[20:00:18] <grobian> present
-[20:00:20] <jmbsvicetto> here
-[20:00:42] <dberkholz> hi
-[20:00:48] <hwoarang> ulm: Betelgeuse ^
-[20:00:52] <hwoarang> hmm missing Chainsaw?
-[20:00:55] <ulm> here
-[20:01:33] <hwoarang> lets wait a couple of minutes
-[20:01:46] <jmbsvicetto> hwoarang: let me power up my laptop so I can get chainsaw's phone number
-[20:01:55] <hwoarang> kk
-[20:02:08] * hwoarang has changed topic for #gentoo-council to: "Next meeting: October 11, 1900UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/ | Meeting Now! | agenda : http://dev.gentoo.org/~hwoarang/council-20111011-agenda.txt"
-[20:02:15] <Betelgeuse> hwoarang: here
-[20:03:44] * hwoarang has changed topic for #gentoo-council to: "Next meeting: Now | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/ | agenda : http://dev.gentoo.org/~hwoarang/council-20111011-agenda.txt"
-[20:03:57] <jmbsvicetto> hwoarang: who's missing? Just Chainsaw?
-[20:04:00] <hwoarang> yeah
-[20:04:28] <hwoarang> will you call him?
-[20:04:38] <jmbsvicetto> I'm calling
-[20:05:22] <jmbsvicetto> He should be around soon
-[20:05:38] <hwoarang> okey
-[20:06:14] --> Chainsaw (~chainsaw@gentoo/developer/atheme.member.chainsaw) has joined #gentoo-council
-[20:06:14] *** Mode #gentoo-council +o Chainsaw by ChanServ
-[20:06:20] <Chainsaw> Sorry!
-[20:06:30] -*- Chainsaw bows to jmbsvicetto and takes his seat
-[20:06:39] <jmbsvicetto> Hi Tony :)
-[20:06:50] <hwoarang> no prob :)
-[20:07:04] <hwoarang> live summary here: http://dev.gentoo.org/~hwoarang/council-20111011-summary.txt
-[20:07:08] <hwoarang> 1st Item
-[20:07:20] <hwoarang> vote: Edit the generated changelogs
-[20:07:34] <hwoarang> seems like the community wants to have this ability
-[20:08:01] <grobian> ok, we're voting now?
-[20:08:10] <hwoarang> http://archives.gentoo.org/gentoo-project/msg_c970aaa4a10a0c36f51e15fe0d1f72df.xml
-[20:08:14] <hwoarang> for reference ^
-[20:08:39] <hwoarang> I think we are good to vote here
-[20:08:41] <grobian> yes, changelogs must be able to be changed always
-[20:08:47] <dberkholz> i've kinda changed my mind since last time we discussed this, it's just a hassle to deal with.
-[20:09:04] <hwoarang> dberkholz: depends on the implementation I guess
-[20:09:11] <Betelgeuse> It's not a requirement but feel free to timplement.
-[20:09:28] <Chainsaw> I want to be able to edit what I submit, in case I miss something.
-[20:09:42] <Chainsaw> So: Yes to editing.
-[20:09:44] <ulm> +1
-[20:09:46] <hwoarang> +1
-[20:10:07] <jmbsvicetto> My opinion is that our voting 2 (3?) months ago meant we would need to keep a file, so it would be possible to edit it
-[20:10:10] <hwoarang> Betelgeuse: i don't agree that this is not a requirement
-[20:10:19] <hwoarang> cause based on that the implementation changes
-[20:10:22] <hwoarang> substantialy
-[20:10:31] <hwoarang> *ll
-[20:10:38] <grobian> jmbsvicetto: yes, so see my reply to the thread hwoarang just pointed to
-[20:10:57] <dberkholz> i pretty much agree with vapier, i don't see this ability as a requirement either.
-[20:11:05] <grobian> http://archives.gentoo.org/gentoo-project/msg_5dfed9997951547d2f08f933d84b97b2.xml
-[20:11:42] <hwoarang> So I guess everyone is on board either as +1 or just do it if you want
-[20:12:39] <hwoarang> any objections otherwise we are moving forward
-[20:12:50] <jmbsvicetto> At this point I agree with Betelgeuse that this is not a requirement, but feel free to implement
-[20:13:47] <hwoarang> the implementation is simple enough anyway. Has the user touched the changelog? Yes? ok so repoman wont write anything to it
-[20:13:50] <dberkholz> this isn't consensus-based, it's majority-based ... objections don't matter if they're the minority.
-[20:14:08] <grobian> hwoarang: that's wrong logic ;)
-[20:14:22] <hwoarang> grobian: let me know why
-[20:14:37] <grobian> if you touch changelog + ebuild, something is wrong
-[20:15:09] <hwoarang> why? you probably want to write a different message to Changelog
-[20:15:16] <hwoarang> and not the one you will use on the commit message
-[20:15:32] <grobian> then the whole point of the changelog discussion is moot
-[20:15:37] <hwoarang> err no
-[20:15:44] <hwoarang> sometimes the changelog has to be verbose :)
-[20:15:47] <grobian> we don't want people to write "^" in the changelog
-[20:15:48] <hwoarang> very verbose :p
-[20:15:55] <_AxS_> ..would it not be safer to allow edits but only secondarily?  ie, commit with repoman, and then you can edit the changelog after?
-[20:15:57] <grobian> or just add a space to make them omit a a changelog entry
-[20:16:19] <hwoarang> grobian: i think this is not the case anymore
-[20:16:39] <grobian> hwoarang: true, but it was the reason this whole discussion started
-[20:16:56] <hwoarang> ppl you did that wont bother editing changelog manually
-[20:17:03] <hwoarang> will simply run repoman commit and let him do the job
-[20:17:05] <jmbsvicetto> hmm, we also voted against "omitting" stuff from changelogs, correct?
-[20:17:05] <grobian> if we decide now we all behave, we don't need to regulate anything, and we can just continue to do useful stuff
-[20:17:27] <jmbsvicetto> so the commit message to repoman should be save in the changelog
-[20:17:29] <hwoarang> grobian: the point is to get rid of the manual echangelog thingie
-[20:17:33] <hwoarang> jmbsvicetto: yes
-[20:17:33] <Chainsaw> grobian: Assuming common sense on the side of the developer has been tried.
-[20:17:42] <grobian> hwoarang: that's a technical argument you should have with portage people
-[20:17:45] <Chainsaw> grobian: It was not a success.
-[20:18:04] <grobian> Chainsaw: sorry?
-[20:18:10] <hwoarang> grobian: right now repoman will still need to run echangelog internally to write changelog
-[20:18:35] <grobian> and how does that change?
-[20:18:42] <hwoarang> change what?
-[20:18:51] <grobian> if we decide anything?
-[20:19:07] <grobian> we just decided 4-3 we won't auto-generate the log, but always store  it on disk in VCS somewhere
-[20:19:09] <hwoarang> do you have another implementation in mind?
-[20:19:16] <hwoarang> yes
-[20:19:38] <grobian> so, poke zmedico to add echangelog code to repoman
-[20:19:46] <hwoarang> correct
-[20:19:52] <grobian> council only sets the policy that for each change a changelog entry should exist
-[20:19:56] <hwoarang> that is why I am saying
-[20:19:58] <hwoarang> *what
-[20:20:01] <grobian> s/exist/be written/
-[20:20:13] <ulm> we have a decision, right? so can we please move on and move further discussions to the ml?
-[20:20:22] <ulm> otherwise this is a waste of time
-[20:20:24] <_AxS_> ..would it help if the actual, exact issue which is being voted on is explicitly stated?
-[20:20:34] <Chainsaw> _AxS_: It was, and a decision has been reached.
-[20:20:41] -*- Chainsaw agrees with ulm, let's move on
-[20:20:42] <hwoarang> ulm: we have nothing to push back do we?
-[20:20:47] <hwoarang> this is now a task for the portage@ ppl
-[20:21:05] <ulm> hwoarang: all the better then
-[20:21:22] <grobian> hwoarang: yes, our request for them to do it, or any voluntyeer to work with them
-[20:21:32] <grobian> ok, next topic please
-[20:21:37] <jmbsvicetto> hwoarang: It's a task for any interested party and assigned to the portage people
-[20:22:34] <jmbsvicetto> s/assigned to/we kindly ask the assistance of/
-[20:22:48] <grobian> +1
-[20:23:02] <hwoarang> sorry guys I have a huge lag
-[20:23:08] <hwoarang> moving to task 2
-[20:23:13] <hwoarang> EAPI1 in profiles
-[20:23:32] <hwoarang> related discussion: http://archives.gentoo.org/gentoo-dev/msg_59c8c04883735f0b090f6e3f0525241e.xml
-[20:24:20] <jmbsvicetto> Thanks to Donnie's poke I reviewed the thread and corrected my memory from it
-[20:24:38] <grobian> imo the consensus of that thread is that eapi-1 is ok (nothing higher)
-[20:24:41] <jmbsvicetto> so, +1 on setting EAPI=1 on profiles
-[20:24:42] <ulm> I'd rather bump profiles to EAPI 2 immediately
-[20:24:46] <hwoarang> from what I can tell it seems safe enough to do it
-[20:24:47] <dberkholz> i'll summarize again.
-[20:24:48] <dberkholz> 18:31 < dberkholz@> 17:15 < dberkholz@> in the "Call for items for September 13 council meeting" thread.
-[20:24:51] <dberkholz> 18:32 < dberkholz@> basically, nobody really cared about EAPI=1, people had problems with USE deps in 2 and  not long enough support for EAPI=4
-[20:25:10] <Chainsaw> EAPI 0 -> 1 has a lot of benefits and no downsides that I can see.
-[20:25:13] <Chainsaw> I'm all for it.
-[20:25:16] <hwoarang> ulm: there was a discussion about how to handle USE masks in >EAPI2
-[20:25:19] <jmbsvicetto> ulm: I'd prefer we stick to EAPI-1
-[20:25:22] <hwoarang> >=
-[20:25:30] <hwoarang> EAPI1 seems better to me
-[20:25:31] <grobian> I'm ok with EAPI-1
-[20:25:40] <Chainsaw> 2 and higher have pitfalls.
-[20:25:47] <ulm> hwoarang: that USE masks are possible doesn't imply that they must be used ;)
-[20:25:51] <jmbsvicetto> ulm: I'd be interested in getting some experimental profiles where we could try a bump to a more recent EAPI version
-[20:26:06] <hwoarang> ulm: afaik there is no provision for app-foo/bar[test] in profiles
-[20:26:09] <hwoarang> is it?
-[20:26:11] <dberkholz> i'd prefer to take the incremental step forward and approve 1 right now.
-[20:26:18] <dberkholz> we can then talk about 2 separately.
-[20:26:20] <ulm> but of course, I'm o.k. with EAPI 1
-[20:26:26] <hwoarang> good
-[20:26:37] <ulm> only we'll have the same discussion at a later point then :p
-[20:26:39] <Betelgeuse> EAPI 1 ok
-[20:26:56] <hwoarang> baby steps
-[20:27:12] <hwoarang> moving to item 3
-[20:27:16] <hwoarang> open bugs
-[20:27:18] <jmbsvicetto> ulm: we can start the work on experimental profiles after we approve EAPI-1
-[20:27:33] <ulm> jmbsvicetto: yeah, let's do that
-[20:28:06] <hwoarang> ok
-[20:28:24] <hwoarang> bug #316401
-[20:28:27] <willikins> hwoarang: https://bugs.gentoo.org/316401 "Add resolution OBSOLETE"; Bugzilla, General Bugs; IN_P; betelgeuse:bugzilla
-[20:28:53] <Chainsaw> !seen idl0r
-[20:28:53] <willikins> Chainsaw: idl0r was last seen 31 minutes and 36 seconds ago, saying ":D" in #gentoo.de
-[20:28:59] <hwoarang> no progress since last month. It seems to me it is fixed
-[20:29:03] <Betelgeuse> hwoarang: https://bugs.gentoo.org/page.cgi?id=fields.html#status
-[20:29:06] <Betelgeuse> hwoarang: it's not there yet
-[20:29:15] <hwoarang> oh right
-[20:29:17] <hwoarang> sorry 
-[20:29:23] <Chainsaw> * You've invited idl0r to #gentoo-council (leguin.freenode.net)
-[20:29:25] <Chainsaw> Summons issued.
-[20:29:52] <hwoarang> in case he does not show up by the end of the meeting
-[20:29:57] <a3li> poked him
-[20:29:59] <hwoarang> I will try to talk to him in #infra
-[20:30:34] <hwoarang> bug #331987
-[20:30:37] <willikins> hwoarang: https://bugs.gentoo.org/331987 "Merge -council and -project mailing lists"; Gentoo Infrastructure, Mailing Lists; UNCO; scarabeus:infra-bugs
-[20:30:40] <hwoarang> no progress as well
-[20:31:05] --> idl0r (~idl0r@gentoo/developer/idl0r) has joined #gentoo-council
-[20:31:08] <idl0r> hey
-[20:31:17] <Chainsaw> Thank you for joining us idl0r.
-[20:31:32] <Chainsaw> Could you add the description in bugzilla please, for bug #316401
-[20:31:32] <willikins> Chainsaw: https://bugs.gentoo.org/316401 "Add resolution OBSOLETE"; Bugzilla, General Bugs; IN_P; betelgeuse:bugzilla
-[20:31:43] <Chainsaw> Or do you require further assistance from us?
-[20:32:03] <idl0r> sec.
-[20:33:02] <idl0r> ah that one
-[20:33:17] <ulm> hm, I cannot find the word "obsoleted" in my dictionary
-[20:33:43] <jmbsvicetto> ulm: obsoleted or obsolete ?
-[20:33:43] <ulm> should be "obsolete" IMHO (but I'm not a native speaker)
-[20:33:45] <idl0r> i'll need to fight me through the templates again and add all resolutions and so on
-[20:33:59] <Betelgeuse> ulm: it should be obsolete
-[20:34:01] <grobian> obsolete is in the dictionary
-[20:34:16] <Betelgeuse> ulm: Where did you see "obsoleted"?
-[20:34:24] <ulm> Betelgeuse: in your comment #0
-[20:34:30] <ulm> "The bug has become obsoleted."
-[20:34:43] <dberkholz> in that use, obsoleted would be bad grammar anyway.
-[20:35:06] <Chainsaw> Has become obsolete, or has been obsoleted by X.
-[20:35:19] <Chainsaw> But "made obsolete" would be preferred.
-[20:35:29] <Betelgeuse> Feel free to go and add the better and as the comment calls for :)
-[20:35:55] --> idella4 (~idella4@gentoo/contributor/idella4) has joined #gentoo-council
-[20:35:56] <idl0r> Chainsaw: so it'll take some time again, it was/is more low priority on my TODO
-[20:36:16] <idl0r> or if a3li want to do that.. :)
-[20:37:58] <hwoarang> moving on
-[20:38:11] <hwoarang> bug #331987
-[20:38:14] <willikins> hwoarang: https://bugs.gentoo.org/331987 "Merge -council and -project mailing lists"; Gentoo Infrastructure, Mailing Lists; UNCO; scarabeus:infra-bugs
-[20:38:19] <hwoarang> is someone willing to talk to robbat2 about that?
-[20:38:35] <hwoarang> no progress since last month
-[20:39:05] <jmbsvicetto> hwoarang: we're waiting on the numbers, correct?
-[20:39:11] <hwoarang> yeah
-[20:39:34] <hwoarang> should we push this forward in case @infra forgotten about his?
-[20:39:36] <hwoarang> *this
-[20:39:39] <hwoarang> or just wait
-[20:40:39] <hwoarang> ok lets just wait then 
-[20:41:03] <hwoarang> bug #331987
-[20:41:04] <willikins> hwoarang: https://bugs.gentoo.org/331987 "Merge -council and -project mailing lists"; Gentoo Infrastructure, Mailing Lists; UNCO; scarabeus:infra-bugs
-[20:41:20] <hwoarang> i will talk to tove in IRC soon. Bugzilla talking did not work out
-[20:41:42] <hwoarang> bug #383467
-[20:41:45] <willikins> https://bugs.gentoo.org/383467 "Council webpage lacks results for 2010 and 2011 elections"; Website www.gentoo.org, Projects; CONF; hwoarang:jmbsvicetto
-[20:41:52] <jmbsvicetto> I've taken this bug for myself
-[20:41:58] <jmbsvicetto> I'll take care of it asap
-[20:42:21] <hwoarang> jmbsvicetto: thanks
-[20:42:48] <hwoarang> Last item: Open floor 
-[20:43:02] <hwoarang> @community. Now it is time to jump in
-[20:43:23] <Chainsaw> a3li: Are you able to assist with bug #316401 please?
-[20:43:25] <willikins> Chainsaw: https://bugs.gentoo.org/316401 "Add resolution OBSOLETE"; Bugzilla, General Bugs; IN_P; betelgeuse:bugzilla
-[20:43:34] <Chainsaw> a3li: I would prefer to be able to close it off.
-[20:44:14] <a3li> Chainsaw: when idl0r provides me with bugzilla access, then yes
-[20:44:30] <Chainsaw> idl0r: Are you able to do that please?
-[20:44:44] <a3li> not right now, that is. but tomorrow/this week
-[20:44:47] <idl0r> sure
-[20:45:00] <Chainsaw> idl0r: Many thanks. Then I will consider this to be sorted.
-[20:45:15] <idl0r> you're welcome
-[20:45:38] <hwoarang> seems like we finished :)
-[20:46:04] <idl0r> done (access)
-[20:46:09] <Chainsaw> idl0r: Cheers.
-[20:46:13] <grobian> thanks
-[20:46:21] <-- idella4 (~idella4@gentoo/contributor/idella4) has left #gentoo-council ("Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is")
-[20:46:22] <Chainsaw> jmbsvicetto: Thanks again :)
-[20:46:30] <hwoarang> the summary is live here
-[20:46:33] <hwoarang> http://dev.gentoo.org/~hwoarang/council-20111011-summary.txt
-[20:46:52] <hwoarang> if you want to comment on that. I will review it and send it for review before announcing it
-[20:47:01] <jmbsvicetto> Chainsaw: np :)
-[20:47:04] <grobian> hwoarang: deceded -> decided
-[20:47:07] <hwoarang> right
-[20:47:18] <hwoarang> next meeting is on November 8th
-[20:47:20] <grobian> electiosns -> elections
-[20:47:30] <jmbsvicetto> Markos, thanks for chairing the meeting
-[20:47:35] <dberkholz> good deal. thanks hwoarang
-[20:48:21] <hwoarang> ok i will send the review to the alias tonight and tomorrow to -dev-announce
-[20:48:24] <jmbsvicetto> hwoarang: I'd suggest s/EAPI1/EAPI-1/ just to make it more readable
-[20:48:28] <hwoarang> ok jmbsvicetto
-[20:49:05] <jmbsvicetto> hwoarang: I'm fine with this summary. Feel free to submit / commit it from my part
-[20:49:13] <grobian> +1
-[20:49:33] <hwoarang> @all: Once I upload everything I will open the bug for repoman
-[20:49:35] <ulm> summary is o.k., thanks hwoarang
-[20:50:01] <Chainsaw> Thumbs up for summary.
-[20:50:03] <grobian> hwoarang: there already is one by diego
-[20:50:38] <hwoarang> there are plenty
-[20:50:47] --> NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-[20:50:57] <grobian> hwoarang: https://bugs.gentoo.org/show_bug.cgi?id=337853
-[20:51:23] <hwoarang> Betelgeuse has also opened a number of bugs about changelog entires on removal and addition
-[20:51:30] <grobian> hwoarang: want me to comment on that bug with council hat?
-[20:51:32] <hwoarang> we should probably merge them to a single one
-[20:51:48] <hwoarang> grobian: i'd prefer first to make summary public and then poke them
-[20:51:57] <grobian> hwoarang: fine, your call
-[20:52:40] <Betelgeuse> hwoarang: I have?
-[20:52:51] <grobian> Betelgeuse: yeap :D
-[20:52:58] <hwoarang> Betelgeuse: mind if you mark 365361 and 177290 as duplicates?
-[20:53:06] <hwoarang> those two at least ^
-[20:53:50] <grobian> hwoarang: I think once you push out the summary, you should comment on those bugs referring to the summary
-[20:54:02] <hwoarang> yeah
-[20:54:10] <hwoarang> probably add a comment and close them
-[20:54:14] <hwoarang> move everything to a single bug
-[20:54:16] <grobian> although 365361 has already summary defined, but now also the generation thing
-[20:54:22] <grobian> sth like that
-[20:54:31] <Betelgeuse> hwoarang: not exactly the same thing but as long as both get impelmented I don't midn
-[20:54:57] <grobian> cool antarus uses his new wings
-[20:55:13] <hwoarang> Betelgeuse: ok i will make that clear when I add the comment
-[20:56:13] <grobian> now we have the stats for -council and -project, can we make a decision in 5 minutes?
-[20:56:42] <hwoarang> we could if everyone is still here ;p
-[20:57:04] <grobian> jmbsvicetto, Chainsaw, dberkholz, ulm, Betelgeuse ping?
-[20:57:10] <jmbsvicetto> pong
-[20:57:13] <Chainsaw> Yes grobian?
-[20:57:27] <grobian> can we decide on bug 331987 now?
-[20:57:29] <willikins> grobian: https://bugs.gentoo.org/331987 "Merge -council and -project mailing lists"; Gentoo Infrastructure, Mailing Lists; UNCO; scarabeus:infra-bugs
-[20:57:44] <jmbsvicetto> grobian: I poked infra about the numbers ;)
-[20:57:52] <grobian> jmbsvicetto: thx
-[20:57:56] <jmbsvicetto> let me read the numbers
-[20:58:22] <Chainsaw> 54 users affected.
-[20:58:33] <hwoarang> probably stale entries?
-[20:58:40] <Chainsaw> I would subscribe to project without a personal approach. If it was <10, a more personal approach would be warranted.
-[20:58:41] <grobian> could we just move them?
-[20:58:50] <dberkholz> just move 'em.
-[20:59:06] <hwoarang> yeah move them and close the list
-[20:59:08] <dberkholz> and let them know while you're at it, mentioning in the note how to unsubscribe
-[20:59:21] <dberkholz> since they'll suddenly be on a list with more traffic
-[20:59:24] <grobian> move + post-move msg on project both are merged
-[20:59:35] <Chainsaw> grobian: Yes, that sounds sensible.
-[20:59:52] <jmbsvicetto> move + close + note about how to unsubscribe (if possible)
-[21:00:00] <hwoarang> good
-[21:00:06] <ulm> jmbsvicetto: sounds good
-[21:00:17] <grobian> ok, so do we have a majority for just moving them in the first place?
-[21:00:23] <jmbsvicetto> +1
-[21:00:25] <hwoarang> +1
-[21:00:28] <grobian> +1
-[21:00:41] <Chainsaw> Agreed.
-[21:00:48] <grobian> ok, so yes
-[21:01:27] <jmbsvicetto> I don't think we need to vote on closing the ml - we already did it
-[21:01:28] <grobian> next thing is probably if we want to notify them
-[21:01:48] <grobian> if the ml software can do it, or we need to send an additional answer is just an implementation
-[21:02:36] <jmbsvicetto> I'd ask infra if they can send an automated message about unsubscribing. If not, we can send the message grobian talked about and add a note about how to unsubscribe from that list
-[21:02:47] <grobian> +1
-[21:02:48] <hwoarang> jmbsvicetto: thanks
-[21:02:56] <hwoarang> i will add that bit to the summary
-[21:05:03] <grobian> ok, thanks once again
-[21:05:47] <Chainsaw> bonsaikitten: I'm taking those xen bugs from idella4 if that's okay.
-[21:06:15] <bonsaikitten> Chainsaw: yes please
-[21:07:06] <-- grobian (~grobian@gentoo/developer/grobian) has quit (Quit: Zzzzz)
-[21:07:07] <jmbsvicetto> hwoarang: If you don't anything else from me, I'll take care of a few things at work before I leave
-[21:07:18] <hwoarang> no everything is good
-[21:07:32] <jmbsvicetto> ok, thanks for chairing
-[21:07:35] <jmbsvicetto> later
-[21:08:22] * hwoarang has changed topic for #gentoo-council to: "Next meeting: November 8, 1900UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/"
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20111108-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20111108-summary.txt
deleted file mode 100644
index cb292fc565..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20111108-summary.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-Summary of Gentoo council meeting 8 November 2011
-
-Roll call
-=========
-betelgeuse
-chainsaw
-calchan (proxy for dberkholz)
-grobian
-hwoarang
-jmbsvicetto
-ulm
-
-ChangeLog and commit messages
-=============================
-Discuss/vote: Do we require identical ChangeLog entries and commit
-messages?
-
-The Council agreed that developers are free to use different messages
-for ChangeLog and commit, but they are responsible for the messages,
-and the Council still expects appropriate messages to be used.
-<http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/>
-
-Eclasses policy
-===============
-Discuss/vote: Are developers allowed to remove functions from
-eclasses, or change the API in general?
-
-The Council agreed that the following wording shall be added to the
-eclass writing guide in the devmanual:
-   "When removing a function or changing the API of an eclass, make
-   sure that it doesn't break any ebuilds in the tree, and post a
-   notice to gentoo-dev at least 30 days in advance, preferably with
-   a patch included."
-
-Actions:
-- Provide a patch for the devmanual (betelgeuse).
-- Start a discussion on the mailing lists on how to deal with eclass
-  APIs in general (grobian).
-
-Open bugs with Council involvement
-==================================
-Bug 331987: No progress since last month.
-Action: Inform Infra about last month's Council decision (jmbsvicetto).
-
-Bug 341959: No progress since last month.
-Action: hwoarang will talk to tove and sort it out.
-
-Open floor
-==========
-No issues were brought up to the council by the community.
-
-Next meeting date
-=================
-13 December 2011, 20:00 UTC.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20111108.txt b/xml/htdocs/proj/en/council/meeting-logs/20111108.txt
deleted file mode 100644
index eae6c4864d..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20111108.txt
+++ /dev/null
@@ -1,328 +0,0 @@
-20:00 <@ulm> O.K., let's start
-20:00 <@ulm> roll call
-20:01  * hwoarang here
-20:02 <@ulm> Betelgeuse, chainsaw, dberkholz, grobian, jmbsvicetto?
-20:02 <@grobian> here
-20:02 <@grobian> sorry
-20:02 <@grobian> connection is very flacky
-20:03 <+dberkholz> 18:59 < dberkholz+> Calchan is gonna proxy for me at tuesday's meeting
-20:03 <+dberkholz> i'm leaving for the airport in a few minutes
-20:03 <@ulm> k
-20:03 <+dberkholz> in case he doesn't pop his head up for any reason, i'll go for identical msgs and on the api issue, at least a 90-day wait before breakage, or no breakage at all
-20:03 <@jmbsvicetto> pong
-20:04 <@jmbsvicetto> here
-20:04 <@jmbsvicetto> ulm: Do you need me to call anyone?
-20:04 <@ulm> jmbsvicetto: betelgeuse, calchan, and chainsaw are still missing
-20:06 <@ulm> !seen chainsaw
-20:06 < willikins> ulm: Chainsaw was last seen 2 hours, 51 minutes and 55 seconds ago, quitting IRC (Quit: Leaving) and a moment before saying "idella4: I'm afraid we can't let users run the entire show though. See what Zorry thinks." in #gentoo-dev
-20:06 <@ulm> anyway, who's logging?
-20:06 <@jmbsvicetto> ulm: give me a minute and I'll call Petteri and Tony
-20:08  * Betelgeuse fails
-20:08 <@jmbsvicetto> Betelgeuse should be around in a minute
-20:10 <@jmbsvicetto> calling chainsaw
-20:11 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has joined #gentoo-council
-20:11 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
-20:11  * Chainsaw salutes jmbsvicetto 
-20:11 < Calchan> sorry, got delayed in a meeting
-20:11 <@jmbsvicetto> Heya Tony :)
-20:12 <@ulm> so Calchan (dberkholz's proxy) still missing, but let's start
-20:12 <+dberkholz> ulm: look up 2 lines =P
-20:12 <+dberkholz> Calchan: ok, i'll tag off with you then.
-20:12 <@ulm> oops, sorry
-20:12 <@ulm> all there
-20:12 <@ulm> who's logging?
-20:12 <@jmbsvicetto> ulm: I have logs
-20:13 <@ulm> First topic: ChangeLog and commit messages
-20:13 <@ulm> Do we require identical ChangeLog entries and commit messages?
-20:13 <@grobian> no
-20:14 <@jmbsvicetto> no
-20:14 <@ulm> no
-20:15 <@hwoarang> makes no sense so no
-20:15 < Calchan> it would be a yes from here
-20:15 <@Chainsaw> No
-20:15 <@jmbsvicetto> but it's up to the developer using different messages to ensure the messages are appropriate. So using the ability to have different messages to write "stupid messages" on ChangeLogs is not ok
-20:15 <@grobian> obviously
-20:15 <@Chainsaw> If I correct a spelling error in a Changelog, the commit message should be "fixing typo balh -> blah".
-20:15 <@Chainsaw> Not the whole message again.
-20:15 <@ulm> Betelgeuse?
-20:16 <@Betelgeuse> ulm: I agree with Chainsaw that it shouldn't be a strict rule. Preferred whenever it makes sense.
-20:16 <@ulm> jmbsvicetto: I think everybody agrees on that
-20:17 <@jmbsvicetto> ulm: It seems it's best we make it clear
-20:18 <@ulm> hm, how about "it's recommended to use the same message for changelog and as commit message"?
-20:18 <@grobian> recommended fine with me, basically what repoman commit now does
-20:18 <@jmbsvicetto> ulm: sorry, what I meant was that it was best we made a comment like I did above so there's no doubt about our goal
-20:19 <@ulm> anyone can come up with a good wording?
-20:19 <@jmbsvicetto> ulm: I'm fine with stating as recommended or just adding a note that developers are still responsible for the messages used and that we still expect changelogs to have appropriate messages
-20:19 <@grobian> usual rules on writing useful changelog and commit messages apply?
-20:19 <@jmbsvicetto> grobian: seems good to me
-20:20 <@grobian> s/useful/appropriate/
-20:20 <@ulm> grobian: yes, I think that's fine
-20:20 <@grobian> I like that more
-20:20 < Calchan> ulm, "Please use the same commit and Changelog message whenever you do not have a strong reason of doing otherwise" how's that?
-20:20 <@ulm> and short ;)
-20:20 <@grobian> Calchan: that's a different message, IMO
-20:21 <@grobian> I have no problem with people doing ugly [myebuild] version bump commit messages, while  having "Version bump." as changelog message
-20:21 < Calchan> grobian, I was just suggesting at ulm's request, anything else is good with me if it's good with you
-20:21 <@jmbsvicetto> Calchan: one could argue that would still allow to use the "ignore this" messages for changelog.
-20:22 <@grobian> Calchan: of course, was just explaining my opposal ;)
-20:22 <@ulm> So, "Usual rules on writing appropriate ChangeLog and commit messages apply."?
-20:22 <@grobian> it's off-topic, but basically we want to repeat that we want to see appropriate messages being used
-20:22 <@grobian> ulm: +1
-20:22 <@ulm> Can everyone live with this?
-20:23 < Calchan> ulm, wfm
-20:23 <@Betelgeuse> I would rather spell out what "Usual rules" mean
-20:23 <@ulm> Betelgeuse: Then suggest a wording. ;)
-20:24 < Calchan> or point/link to them
-20:24 <@grobian> Betelgeuse: as long as we avoid "common sense", since that seems not to be a shared thing
-20:24 <@jmbsvicetto> what about: "developers are free to use different messages for ChangeLog and commit, but they're responsible for the messages used and the council still expects appropriate messages to be used" ?
-20:25 <@grobian> + for both
-20:25 <@grobian> ?
-20:25 <@Betelgeuse> http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html
-20:25 <@Betelgeuse> and jmbsvicetto's wording is fine
-20:25 <@grobian> ohw, nice page
-20:26 <@ulm> +1 for jmbsvicetto's wording
-20:26 < Calchan> jmbsvicetto, I like the fact that this rules out the fact that devrel may be involved in such situations, not entirely sure it's a good thing though
-20:26 <@grobian> Can we add Betelgeuse's link to that blub too?
-20:26 <@ulm> grobian: yep
-20:27 <@jmbsvicetto> +1 on adding the link
-20:27 <@grobian> ok, jmbsvicetto's + Betelgeuse's link for me then
-20:27 <@grobian> :)
-20:28 <@ulm> o.k., that's 4 out of 7 at least
-20:28 <@ulm> next topic?
-20:28 <@grobian> ok
-20:29 <@jmbsvicetto> sure
-20:29 <@ulm> Eclasses policy
-20:29 <@ulm> Are developers allowed to remove functions from eclasses, or change the API in general?
-20:29 <@ulm> http://archives.gentoo.org/gentoo-project/msg_87aecc20ce7030e321ab2db6c90f36cc.xml
-20:30 <@grobian> I tend to think the gx86 tree should be fine with it, we cannot really take all existing overlays into account
-20:30 < Calchan> not without reasonable warning time, eg 90 days
-20:30 <@Betelgeuse> I don't know if you noticed but vapier has been doing it with less than a days notice
-20:30 <@grobian> I'd suggest normal 30 days warning
-20:31 <@hwoarang> if nobody uses them what is the problem?
-20:31 <@grobian> sure, but if there are no consumers, why not remove some thing?
-20:31 < Calchan> hwoarang, overlays may still be using them
-20:31 <@ulm> grobian: Plus posting the diff to -dev ML
-20:31 <@grobian> ulm: agreed
-20:31 <@jmbsvicetto> I think we shouldn't make things harder than needed, so we should be able to change API. A reasonable advanced notice is desirable, though. I'd say 30 or 60 days
-20:31 <@hwoarang> Calchan: i thought we do not support overlays
-20:31 <@grobian> ulm: for removal, I guess a diff isn't strictly useful
-20:31 <@hwoarang> as in, we only have control over the gx86
-20:31 <@Betelgeuse> There is no reason to break overalys for no benefit
-20:32 < Calchan> grobian, you're not talking about a single package here, but about an eclas which may be used by multiple packages, and 30 days may not be enough to fix thm all
-20:32 <@ulm> grobian: I was thinking about API changes in general
-20:32 <@ulm> what's the waiting period for eclass removal?
-20:32 < Calchan> hwoarang, whether we support them or not they do exist and we may not want to anger our community more than reasonnable
-20:32 <@grobian> ulm: ok, might make sense, but that's close to -dev review of all changes to eclasses
-20:32 <@ulm> can someone remind me please?
-20:32 <@jmbsvicetto> hwoarang: we should give overlay mantainers a chance to react to changes in eclasses
-20:32 <@grobian> Calchan: grep is your friend
-20:33 <@Betelgeuse> ulm: http://devmanual.gentoo.org/eclass-writing/index.html
-20:33 <@Betelgeuse> ulm: 30 days
-20:33 < Calchan> grobian, tools don't matter in this discussion
-20:33 <@grobian> copy the eclass to your overlay
-20:33 <@grobian> I think a notice, 30 days makes sense
-20:33 <@grobian> ebuilds disappear to
-20:33 <@grobian> sometimes entire ranges (KDE)
-20:34 <@jmbsvicetto> Calchan: when dealing with substantial changes to eclasses, it's probably a better idea to "bump" the eclass.
-20:34 <@Betelgeuse> grobian: shadowing eclasses are a bad thing
-20:34 <@ulm> 30 days for API change should be sufficient, if it's sufficient for eclass removal
-20:34 <@grobian> Betelgeuse: tell me… but well, if you don't want to fix your ebuilds...
-20:34 <@Betelgeuse> grobian: they tend to get oudated and users won't get bug fixes etc
-20:34 < Calchan> jmbsvicetto, then it's a different eclass, what we are talking about right now is changing the API of a given one
-20:34 <@jmbsvicetto> Betelgeuse: but it might be simpler to copy an eclass to an overlay while updating the ebuilds to the new eclass
-20:35 <@grobian> So, who is concerned about overlays here?
-20:35 <@jmbsvicetto> Calchan: sure
-20:35 <@hwoarang> i am not
-20:35 <@grobian> me neither
-20:35 <@jmbsvicetto> grobian: me, in the sense we should give sufficient advanced notice to overlay maintainers
-20:35 <@Betelgeuse> grobian: to a degree
-20:35 < Calchan> I think a warning period and adding an ewarn in the changed function so that users/devs notice the change is the right thing to do
-20:36 <@grobian> I do agree with a notice
-20:36 <@grobian> Calchan: can agre with that
-20:36 < Calchan> and 30 days is too short for an eclass imo
-20:36 <@jmbsvicetto> Calchan: the problem with that are the QA notices (the python eclass used that for a while)
-20:36 <@grobian> prefer even
-20:36 < Calchan> jmbsvicetto, can you expand a bit?
-20:36 <@grobian> it's horror on rsync0
-20:37 < Calchan> jmbsvicetto, oh yes I know what you mean
-20:37 <@jmbsvicetto> Calchan: we want eclass maintainers to provide a warning to ebuild / overlay maintainers, but we might not like for them to have eclasses throw tons of QA warnings on every minor change
-20:37 < Calchan> jmbsvicetto, but that's an entirely different issue, of an incompetent/non-cooperative dev
-20:37 <@jmbsvicetto> Calchan: I know. I just wanted to be "clear"
-20:37 < Calchan> you don't have to be stupid about it
-20:38 <@jmbsvicetto> that's the problem with "common sense" not being enough - we sometimes have to say "too much"
-20:38 <@grobian> :(
-20:38 < Calchan> talking helps a lot in these case, you just have to be willing to do it
-20:39 <@hwoarang> somehow developement has been evolved in a strict set of rules for the past 2 years
-20:39 < Calchan> because we are socially lazy
-20:39 <@hwoarang> not sure if we follow the right path
-20:39 <@jmbsvicetto> so, I think we all agreed about requiring notification, we haven't agreed about how long it should be, though
-20:39 <@hwoarang> you take away all the fun with so many ruls
-20:39 <@hwoarang> *rules
-20:39 <@ulm> hwoarang: blame the ones that stretch common sense
-20:39 <@hwoarang> and you will keep devrel buzy in the near future
-20:40 <@Betelgeuse> hwoarang: the standing practise btw is that you shouldn't do it
-20:40 <@Betelgeuse> people just started doing it and no-one complained
-20:40 <@Chainsaw> 30 days is definitely too short. Let's triple it. 90 days?
-20:40 <@Betelgeuse> besides me any way
-20:40 <@hwoarang> so you add more rules
-20:40 < Calchan> Chainsaw, yes
-20:40 <@hwoarang> because you can't control these people?
-20:40 <@Chainsaw> I agree that overlays can't hold you back forever.
-20:40 <@hwoarang> smart :)
-20:40 <@Chainsaw> But some notice seems a fair thing to do.
-20:40 <@Betelgeuse> hwoarang: so throw them out then?
-20:40 <@grobian> eclass function drop == last rite ebuild == 30 days
-20:40 <@Betelgeuse> hwoarang: or accept that people can do whatever they want?
-20:41 <@jmbsvicetto> I believe 90 days is too long. I'd argue for 30 or 60 days
-20:41 <@hwoarang> what is the point make 98% of devs "suffer" because of your rules
-20:41 <@hwoarang> instead of kick problematic devs out?
-20:41 < Calchan> Chainsaw, let's word it as "whenever possible"
-20:41 <@hwoarang> *making
-20:41 <@Chainsaw> jmbsvicetto: In that case I would prefer 60 over 30, yes.
-20:41 <@ulm> if 30 days are sufficient for removing an eclasss, it should be sufficient for removal of a function
-20:41 <@grobian> hwoarang: that 2% need those rules to act "common" instead of kicking them out?
-20:41 <@Betelgeuse> ulm: 30 days from the point when nothing uses it any more
-20:41 <@ulm> otherwise people will remove and re-add the eclass :p
-20:41 <@Betelgeuse> ulm: so it has taken a while to get there
-20:42 <@grobian> Betelgeuse: how can you know?  You shouldn't drop a function that's in use in gx86, obviously
-20:42 <@jmbsvicetto> I'm sorry for my comment about "common sense". May I suggest we continue with this discussion and return to the "common sense" / "rules" discussion later (if needed)?
-20:42 <@hwoarang> it seems to me that we keep voting +2 rules on every meeting
-20:42 <@hwoarang> anyway
-20:42 <@Betelgeuse> hwoarang: My general point was that we are changing a rule to more closely match what peole are doing
-20:42 < Calchan> jmbsvicetto, what's the cost of keeping a function in an eclass for 90 days?
-20:42 <@Betelgeuse> hwoarang: Feel free to suggest no rules about it.
-20:43 <@Betelgeuse> grobian: It's more likely faster to adjust things in this case.
-20:43 <@grobian> eclass removal time should be equal at least to eclass function removal
-20:43 <@hwoarang> i did not say no rules. I say trust the devs and spank those you fail to behave
-20:43 <@hwoarang> *who
-20:43 <@Chainsaw> grobian: That is correct. In that case 30 everywhere. If it is felt that this is too short, I'm sure it will be tabled again.
-20:43 <@jmbsvicetto> Calchan: we're talking about API changes, so it's not just about keeping a function. What about changing a function spec? Or requiring calling pkg_setup where it wasn't needed before
-20:43 <@grobian> if 30 is too short, we need to up the limit for all of them
-20:44 <@Chainsaw> grobian: (Shame though, I do think eclass work should be double or triple what ebuild work requires)
-20:44 <@Chainsaw> grobian: And in the interest of reaching consensus, double.
-20:44 <@grobian> Chainsaw: I'm willing to go there, but not if you can remove an eclass in 30 days
-20:45 <@jmbsvicetto> as I said, I'm fine with both 30 or 60 days
-20:45 <@Chainsaw> grobian: Yes, I see your point that eclass removal/API change should both require the same delay.
-20:45 <@Betelgeuse> it should be noted that with eclass removal you can't install the thing
-20:45 <@jmbsvicetto> ulm: should we start counting votes?
-20:45 <@Betelgeuse> with minor api changes you could install a thing but wrongly
-20:45 <@ulm> jmbsvicetto: yes
-20:45 <@grobian> dropping the eclass vs a function is as bad to overlays (the only ones it should hurt)
-20:45 <@Chainsaw> That is the failure scenario I dread the most, Betelgeuse.
-20:45 < Calchan> ulm, yes, let's start voting but state exactly what we're voting on
-20:45 <@ulm> Let's first vote if we need an additional rule at all.
-20:46 <@Betelgeuse> ulm: it's not really additional as I said
-20:46 <@ulm> And if this is accepted, let's vote on a wording.
-20:46 <@jmbsvicetto> ulm: I'd call an update to eclass policy
-20:46 <@jmbsvicetto> +it
-20:46 <@jmbsvicetto> and I think we should update it to cover API changes
-20:46 <@Betelgeuse> ulm: So you want to first vote on if the current policy should be removed altogether?
-20:46 <@ulm> Betelgeuse: Then let me suggest a wording "When removing a function or changing the API of a widely used eclass, make sure that it doesn't break any ebuilds in the tree, and post a notice to gentoo-dev at least 30 days in advance."
-20:47 <@Chainsaw> ulm: That sounds good, yes.
-20:47 <@grobian> jmbsvicetto: that's too vague.  Feels like we should push that back for discussion
-20:47 <@grobian> the agenda topic was just whether or not you can remove functions from an eclass
-20:47 < Calchan> grobian++
-20:47 <@jmbsvicetto> grobian: I didn't meant it to be vague. I'm just arguing that what we're talking about fits inside the already existing eclass policy (or policies if you prefer)
-20:47 <@jmbsvicetto> ulm: +1
-20:48 <@Betelgeuse> ulm: +1 preferably with a patch incldued
-20:48 <@grobian> jmbsvicetto: yeah, so in that case, I say, no vote, because it's a non-issue at the current state, as Betelgeuse already replied iirc
-20:48 <@ulm> Betelgeuse: You volunteer to provide a patch? ;)
-20:48 <@jmbsvicetto> grobian: so you would prefer we create / set a single eclass policy listing all rules about eclasses?
-20:48 <@Betelgeuse> ulm: in the email to gentoo-dev :)
-20:49 <@grobian> I would love to see a discussion on APIs in general on eclasses, and how to deal with them
-20:49 < Calchan> ulm, s/widely// and s/30/90/ and it's a yes
-20:49 <@Betelgeuse> ulm: but yes I can patch devmanual
-20:49 <@grobian> if we should use versioning, strict API rules + versioning like libtool does
-20:49 <@ulm> Calchan: I'm against the 90 days
-20:50 <@Betelgeuse> grobian: My idea was to vote something to replace the current policy. The finer details could evolve in later meetings.
-20:50 <@jmbsvicetto> grobian: if so, then I'm fine with pushing this back to the mls. If not, I think what ulm suggested, with Betelgeuse's note about adding a patch to the eclass, seems reasonable to add to the current rules
-20:50 <@Betelgeuse> So does the current rule stand until we reach a decision?
-20:50 <@grobian> Betelgeuse: makes no sense to me to vote for something that's not yet there
-20:50 <@Betelgeuse> As such QA should start encorcing things?
-20:50 <@Betelgeuse> or anyone else
-20:51 <@ulm> In principle we have 4 votes in favour for the proposed wording...
-20:51 < Calchan> ulm, between no rule and 30 days I'll take 30 days
-20:51 <@Chainsaw> ulm: Which does sound like a majority.
-20:51 <@jmbsvicetto> ulm: if you didn't, count me as +1 on the proposed wording
-20:51 <@grobian> Can we then please open the discussion on the MLs too?
-20:51 <@jmbsvicetto> grobian: seems a good idea to me
-20:51 <@Chainsaw> Calchan: Exactly. We should propose a change of the duration later. An easy yes/no vote that should have no problems making it onto the agenda.
-20:51 <@grobian> ulm: and, can you remove "widely-used"?
-20:52 <@jmbsvicetto> grobian: we can even present it as a reform of eclass policy (policies)
-20:52 <@grobian> you should NEVER break any ebuild in gx86
-20:52 <@grobian> regardless how insignificant
-20:52 < Calchan> ulm, I'm with grobian, "widely" opens a nasty door
-20:52 <@grobian> "common sense"
-20:52 <@ulm> generally used?
-20:52 <@grobian> ulm: all eclasses, period
-20:52 <@Betelgeuse> ulm: all eclasses
-20:52 < Calchan> ulm, we only have one class of eclasses
-20:52 <@Chainsaw> ulm: Don't give people a chance to argue terminology. Eclass. You can't discuss your way out of that.
-20:52 <@ulm> ok, s/widely //
-20:53 <@grobian> a used eclass, erm, so an unused one you can drop all functions from?
-20:53 <@Chainsaw> ulm: No further objections your honour.
-20:53 <@ulm> grobian: that's covered bu "removing eclasses" I guess
-20:53 <@ulm> *by
-20:53 <@grobian> When removing a function or changing the API of an eclass, make sure that it doesn't break any ebuilds in the tree, and post a notice to gentoo-dev at least 30 days in advance.
-20:54 < Calchan> ulm, grobian is right, just say eclass, make it simple
-20:54 <@jmbsvicetto> grobian: + with a patch of the proposed change
-20:54 <@ulm> grobian: yep
-20:54 <@grobian> jmbsvicetto: patch: 30 lines of -
-20:55 <@grobian> jmbsvicetto: but if you prefer, I could live with that
-20:55 <@ulm> Who will start the discussion about 30/90 days in -dev?
-20:55 <@jmbsvicetto> grobian: until you can check the patch you won't know whether it's 30 lines of -, 100 of +, or a complete rewrite of the eclass ;)
-20:55 <@grobian> jmbsvicetto: ok, you convinced me… sigh, python anyone?
-20:55 <@jmbsvicetto> ulm: the discussion is not about 30/90 days, but about general rules for an eclass policy
-20:56 <@grobian> eclass ABI policy
-20:56 <@jmbsvicetto> ulm: what can be changed in an eclass without requiring using a new version, what type of API consistency is required, etc
-20:56 <@grobian> what changes need review on -dev ML
-20:56 <@ulm> k
-20:56 < Calchan> ulm, so are we done voting, or can we start, and on what?
-20:57 <@ulm> yes, I think we're done with that topic
-20:57 <@ulm> next: open bugs
-20:57 <@grobian> I think I can try to start a discussion on the eclass API thing
-20:57 <@grobian> if noone else wants
-20:57 <@ulm> grobian: good
-20:57 <@jmbsvicetto> grobian: be my guest
-20:57 <@ulm> bug 331987
-20:57 < willikins> ulm: https://bugs.gentoo.org/331987 "Merge -council and -project mailing lists"; Gentoo Infrastructure, Mailing Lists; UNCO; scarabeus:infra-bugs
-20:58 <@ulm> any progress there?
-20:59 <@jmbsvicetto> I think infra is waiting for our reply to antarus numbers
-20:59 <@ulm> "The council decided to move these subscribers to gentoo-project and send them a message informing them how to remove themselves from the new gentoo-project mailing list." says the October summary
-20:59 <@grobian> 54 people, move, send them a notification they're now subscribed to -project
-20:59 <@jmbsvicetto> given the prior discussion, I think we all agree to have infra move the 54 people subscribed to council, but not project to the latter ml
-21:00 <@ulm> So, who will take care of it?
-21:01 <@grobian> can we just cut and paste that sentence in the bug?
-21:01 <@jmbsvicetto> ulm: I'll bug infra and leave a comment in that bug later
-21:01 <@ulm> jmbsvicetto: o.k.
-21:01 <@ulm> bug 341959
-21:01 < willikins> ulm: https://bugs.gentoo.org/341959 "council changed the waiting period in "eclass removal policy""; Doc Other, Devmanual; IN_P; tove:qa
-21:02 <@ulm> "hwoarang agreed to talk to tove about that and sort it out."
-21:02 <@ulm> hwoarang: any progress?
-21:02 <@hwoarang> sorry i didn't. i will try again
-21:02 <@ulm> k
-21:02 <@jmbsvicetto> ulm: bug 383467
-21:02 < willikins> https://bugs.gentoo.org/383467 "Council webpage lacks results for 2010 and 2011 elections"; Website www.gentoo.org, Projects; CONF; hwoarang:jmbsvicetto
-21:03 <@ulm> jmbsvicetto: right, that's the last one
-21:03 < Calchan> some would say that reflects reality :op
-21:03 <@ulm> jmbsvicetto: "jmbsvicetto will take care of that on behalf of the elections team."
-21:03 <@jmbsvicetto> I wasn't able to get to this before, but I've already copied the old elections results to the elections space and I'll be fixing the links there from the council page later today
-21:04 <@ulm> good
-21:04 <@jmbsvicetto> so I should be able to close this bug today or up till the end of the week
-21:04 <@ulm> any bug that I've missed?
-21:05 <@ulm> if not, open floor
-21:05 <@grobian> ok, open floor
-21:06 <@grobian> anyone?
-21:07 <@ulm> seems not to be the case
-21:07 <@ulm> let's close the meeting then
-21:07 <@grobian> cool, then my connection survived
-21:07 <@ulm> thanks everybody
-21:08 <@grobian> ok, thank you mister chairman
-21:08 <@ulm> I haven't done an online summary, but I hope I can do it tomorrow
-21:09 <@ulm> grobian: you'll be next chair, btw
-21:09 <@jmbsvicetto> ulm: thanks for chairing
-21:09 <@jmbsvicetto> ulm: do you need me to send you the log or want me to commmit it?
-21:09  * Chainsaw bows to all and disappears
-21:09 <@ulm> jmbsvicetto: would be nice if you'd just commit it
-21:10 <@jmbsvicetto> ulm: will do
-21:10 <@ulm> thanks
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20111213-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20111213-summary.txt
deleted file mode 100644
index fd6500d004..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20111213-summary.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-Summary of Gentoo council meeting 13 December 2011
-
-Roll call
-=========
-betelgeuse
-chainsaw
-dberkholz
-grobian
-jmbsvicetto
-ulm
- 
-missing
--------
-ssuominen (proxy for hwoarang)
-
-
-"Sighted pages" in the Gentoo wiki
-==================================
-Discuss/vote: Is this a council issue at the moment? [1]
-
-The Council aggreed unanimously that this is not an issue for the
-Council at the moment.  The issue not yet clear, which makes it hard to
-form an opinion on the subject, which is believed to be more of an issue
-of the wiki team.
-The Council advises to take up the issue with the wiki team.  For this
-case, it seems that the Council should only get involved through the
-normal escalation procedures, as last resort.
-
-In a side remark, the Council suggests using the term "reviewed pages",
-which seems to express more clearly what the pages are about.
-
-
-Quiet build default in Portage
-==============================
-Discuss/vote: Should the quiet default get reverted before affected
-Portage versions get stabilised? [2]
-
-The Council agreed that quiet-build behaviour of Portage should be made
-an opt-in for existing installs (chainsaw, jmbsvicetto, grobian).  The
-suggested implementation for this is by reverting the default of
-quiet-build.
-Indifferent to the value of this default for existing installs:
-dberkholz, ulm, betelgeuse.
-
-The Council agreed that quiet-build behaviour of Portage can be made the
-default for new installs (dberkholz, betelgeuse, jmbsvicetto, chainsaw,
-grobian).  A possible implementation for this suggested by jmbsvicetto
-is via the stage building process (catalyst) to enable quiet-build in
-the produced make.conf.
-Indifferent to the value of this default for new installs: ulm.
-
-The Council likes to note that the quiet-build option in itself seems
-unknown to many, and hence leads to people searching for long how to
-change it.  Some pointers to documentation may be necessary.  As
-understood, a GLEP 42 news item is already planned.  Another way of
-getting it better documented would be to add it commented out to
-make.conf.
-
-
-Open bugs with Council involvement
-==================================
-There are currently no open Council bugs
-
-
-Open actions from last meeting
-==============================
-- eclass API change devmanual patch from meeting 20111108 (betelgeuse)
-  A patch to the devmanual was committed during this meeting.
-- eclass API changes discussion from meeting 20111108 (grobian)
-  No progress has been made (no discussion has been opened yet).
-- moving council elections results to the elections project space (jmbsvicetto)
-  No progress has been made (open issue is the dates of some old council
-  elections).
-
-
-Open floor
-==========
-No issues were brought up.
-
-
-Next meeting date
-=================
-10 January 2012, 20:00 UTC.
-
-
-[1] http://archives.gentoo.org/gentoo-project/msg_01e478ad89a5a27ff42471ba37fba287.xml
-[2] http://archives.gentoo.org/gentoo-project/msg_4e282bb4e6ac2611de2a39171a803c48.xml
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20111213.txt b/xml/htdocs/proj/en/council/meeting-logs/20111213.txt
deleted file mode 100644
index ba56557ca4..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20111213.txt
+++ /dev/null
@@ -1,281 +0,0 @@
-21:00 -!- grobian changed the topic of #gentoo-council to: meeting now: December 13, 20:00 UTC - agenda: http://dev.gentoo.org/~grobian/agenda-13-12-2011.txt | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | http://www.gentoo.org/proj/en/council/
-21:00 <@  grobian> my clock is off by 3 minutes?
-21:00 <@dberkholz> Current UTC (or GMT/Zulu)-time used: Tuesday, December 13, 2011 at 20:00:54
-21:01 <@dberkholz> http://www.timeanddate.com/worldclock/
-21:01 <@  grobian> hehe
-21:01 <@  grobian> shall we wait a little to see if ssuominen shows up?
-21:01 *** grobian prefers so
-21:01 <@ Chainsaw> Yes, our agenda is not all that full.
-21:01 <@ Chainsaw> Let's give it a moment.
-21:01 <@Betelgeus> jmbsvicetto: yes
-21:01 <@  grobian> so, the agenda for today, I'll update it online: http://dev.gentoo.org/~grobian/agenda-13-12-2011.txt
-21:02 <@  grobian> who's here already?
-21:02 *** Chainsaw is present
-21:02 <@      ulm> here
-21:02 <@jmbsvicet> Here
-21:02 <@  grobian> good
-21:02 <@dberkholz> sounds fine, that way i won't have to do as much of this while my call's still running.
-21:02 <@jmbsvicet> so we're only missing Samuli, right?
-21:02 <@  grobian> so, seems like we're waiting for samuli
-21:02 <@  grobian> yeah
-21:03 <@jmbsvicet> He hasn't replied to my poke on #-dev yet
-21:03 <@ Chainsaw> jmbsvicetto: Would you happen to have a phone number for him?
-21:03 <@  grobian> yeah :/
-21:03 <@jmbsvicet> Anyone has any other way to reach him?
-21:03 <@dberkholz> apparently we should require email confirmation from proxies
-21:03 <@jmbsvicet> Chainsaw: sorry, no.
-21:03 <@  grobian> dberkholz: well, it's a slacker mark for hwoarang, I'd suppose
-21:04 <@dberkholz> yeah, if he doesn't show up in the next min or two
-21:04 <@  grobian> give it a few more minutes
-21:04 <@  grobian> agenda is small, like you said
-21:04 <@jmbsvicet> we could 5 while we wait for Samuli
-21:04 <@jmbsvicet> +do
-21:05 <@  grobian> the open actions thing?
-21:05 <@jmbsvicet> yes
-21:05 <@  grobian> fine with me, everyone agrees?
-21:05 <@      ulm> fine
-21:05 <@dberkholz> k
-21:05 <@dberkholz> got links to the stuff?
-21:05 <@  grobian> ok, all: so I've added point 5 to the agenda, if everyone agrees with it
-21:06 <@ Chainsaw> Agreed with point 5, please proceed.
-21:06 <@  grobian> it's basically progress reports
-21:06 <@jmbsvicet> dberkholz: http://dev.gentoo.org/~grobian/agenda-13-12-2011.txt
-21:06 <@  grobian> http://www.gentoo.org/proj/en/council/meeting-logs/20111108-summary.txt
-21:06 <@  grobian> last meeting we had this API thing with eclasses
-21:06 <@dberkholz> jmbsvicetto: i meant in that agenda, nothing in pt 5 is linked. so i'll go refer back to it
-21:06 <@jmbsvicet> dberkholz: I see
-21:06 <@      ulm> grobian: there's two points called 5 ;)
-21:06 <@jmbsvicet> ulm: first 5 ;)
-21:06 <@  grobian> ulm: reload
-21:06 <@  grobian> :D
-21:07 <@  grobian> dberkholz: that previous council meeting summary link
-21:07 <@dberkholz> checking now
-21:07 <@  grobian> Betelgeuse: did you finish/commit that devmanual patch you would do?
-21:07 <@Betelgeus> grobian: let me check
-21:08 <@Betelgeus> grobian: apparently not :(
-21:08 <@  grobian> ok, well, me and jmbsvicetto didn't do anythijng either :)
-21:08 <@Betelgeus> I will work on it on the side while waiting
-21:09 <@dberkholz> well, i guess that's an easy item
-21:09 <@dberkholz> just slap these guys upside the head and move on
-21:09 <@  grobian> ok, done
-21:09 <@jmbsvicet> I'll either ask through the mls for some help regarding some of the old elections dates or I'll pick some dates myself
-21:09 <@  grobian> ok, wait timeout?
-21:10 <@jmbsvicet> grobian: let's move forward. If Samuli shows up he can join the discussion
-21:10 <@  grobian> yeah, ok
-21:10 <@  grobian> let's go to point 2 then
-21:10 <@  grobian> does anybody feel like we should be voting on that wiki feature?
-21:11 <@jmbsvicet> I think that should be discussed by the wiki team
-21:11 <@  grobian> ok
-21:11 <@      ulm> grobian: It's a good thing IMO, but I think the decision is with the wiki team
-21:11 <@  grobian> that's 2
-21:12 <@jmbsvicet> if there's no agreement, people can then appeal to the council
-21:12 <@Betelgeus> http://paste.pocoo.org/show/520427/
-21:12 <@Betelgeus> ok?
-21:12 <@  grobian> Betelgeuse: ok with me, how about point 2?
-21:13 <@  grobian> Chainsaw: dberkholz: do you think the wiki change is a council issue?
-21:13 <@ Chainsaw> It's not even apparent to me what the required feature is.
-21:13 <@      ulm> Betelgeuse: That's exactly the wording we've decided upon in the previous meeting, so obviously it's o.k.
-21:14 <@jmbsvicet> grobian: you haven't stated your opinion yet either
-21:14 <@  grobian> Chainsaw: allow me to take that as a no?
-21:14 <@ Chainsaw> grobian: Certainly.
-21:14 <@  grobian> jmbsvicetto: I agree with hwoarang in ML, not a council issue at the moment
-21:14 <@dberkholz> grobian: nope
-21:15 <@dberkholz> i think the wiki team can decide on that just fine
-21:15 <@      ulm> Chainsaw: Normal wiki users would only see "sighted pages", i.e. pages tagged as o.k. by somebody who has sighting status
-21:15 <@  grobian> dberkholz: agreed
-21:15 <@      ulm> It's sort of a protection against vadalism
-21:15 <@  grobian> Betelgeuse: your vote?
-21:15 <@      ulm> *vandalism
-21:15 <@dberkholz> basically "approved pages" since the term "sighted" doesn't make any sense to me
-21:15 <@  grobian> might be a translation from german
-21:16 <@ Chainsaw> Approved or reviewed, please.
-21:16 <@ Chainsaw> Because sighted made no sense to me either. Hence my failure to form an opinion on the subject.
-21:16 <@jmbsvicet> Given our "vote", you should suggest that to the wiki team ;)
-21:16 <@dberkholz> reviewed is actually a lot better
-21:16 <@Betelgeus> grobian: agree with jmbsvicetto
-21:17 <@  grobian> ok, thanks
-21:17 <@  grobian> I'll add the suggestions
-21:17 <@      ulm> well, english wikipedia calls it "sighted versions" too
-21:17 <@dberkholz> probably written by a native german =P
-21:17 <@  grobian> (I update agenda as we go)
-21:17 <@ Chainsaw> ulm: Still made no sense to me.
-21:18 <@  grobian> ok, does anyone wants to make another statement about this topic?
-21:18 <@  grobian> if not, I'd like to continue to the more pressing point 3
-21:18 <@ Chainsaw> grobian: Point 3 please, let's get to the proper discussion.
-21:19 <@  grobian> OK, quiet build default of Portage
-21:19 <@  grobian> before going into pros cons, I think it's good to just get opinions:
-21:19 <@ Chainsaw> This behaviour change has been forced on users on an opt-out basis. That should have been opt-in.
-21:19 <@  grobian> who would like portage to remain printing build information by default
-21:19 <@ Chainsaw> Yes. Restore previous defaults immediately.
-21:19 <@  grobian> (differently: who wants portage to have --quiet-build=n)
-21:20 <@dberkholz> again, i'm fine letting the portage team make this decision. i don't think we need to determine the UI
-21:20 <@jmbsvicet> http://dpaste.com/673022/ <- that's my "starting point" for this discussion
-21:20 <@      ulm> I'm indifferent about it. It's a default and it can be changed.
-21:20 <@  grobian> jmbsvicetto: so, you do, or you don't want to have a say on the default
-21:21 <@  grobian> if we're all indifferent about it, we don't have to discuss either
-21:21 <@  grobian> in a way
-21:21 <@jmbsvicet> grobian: pending the discussion here, I'm inclined to go with: Revert the change, announce the new setting and enable it on stages
-21:21 <@  grobian> ok
-21:21 <@      ulm> jmbsvicetto: can you line-wrap that pastebin?
-21:21 <@jmbsvicet> ulm: let me do it
-21:22 <@  grobian> me: make it opt-in (so with chainsaw here)
-21:22 <@  grobian> Betelgeuse: should portage quiet output change?
-21:23 <@jmbsvicet> ulm: http://dpaste.com/673023/
-21:23 <@Betelgeus> Was there a poll on forums?
-21:23 <@      ulm> jmbsvicetto: much better :)
-21:23 <@  grobian> Betelgeuse: I recall yes, and it was all over with people disliking
-21:23 <@  grobian> but then you get in that discussion on the vocal minority
-21:24 <@jmbsvicet> grobian: The most important issue to me here isn't whether I want opt-in or opt-out, but whether I want to move away from the delegate position and call this to the council because of the way it was done and of the results
-21:24 <@jmbsvicet> ulm: sorry, I'm spoiled by my 1920x1080 screen ;)
-21:24 <@  grobian> jmbsvicetto: I'm not there yet ;)
-21:25 <@  grobian> Chainsaw: would you be ok with jmbsvicetto's suggestion, to disable  build info by a default setting in the stages?
-21:26 <@jmbsvicet> grobian: that's just a possible vote about this.
-21:26 <@ Chainsaw> grobian: I'm not sure I follow.
-21:26 <@ Chainsaw> grobian: I want the change to be backed out, because it has been forced on users. They should have a choice in this matter.
-21:26 <@dberkholz> Betelgeuse: yeah, the poll was still pretty split. a little in favor of revert but not a ton
-21:26 <@  grobian> Chainsaw: I mean echo "EMERGE_OPTS='--quiet-build=y'" >> etc/make.conf
-21:26 <@jmbsvicet> The idea on that would be: opt-in for current installs, widely publicize that new option and change the default for new installs (people should have some sort of control on new installs - even on large installs)
-21:27 <@dberkholz> Betelgeuse: take that back, more like 116 in favor of the current situation vs 211 for reverting
-21:27 <@  grobian> Chainsaw: I try to figure out if you're lenient towards changing the default for new users, ^^^ see jmbsvicetto
-21:27 <@ Chainsaw> jmbsvicetto: That sounds acceptable.
-21:27 <@  grobian> ok
-21:28 <@  grobian> who would accept this behaviour to be changed for new installs?
-21:28 <@dberkholz> i would be fine with defaults as a setting in make.conf, so even existing users see it as an etc-update change
-21:28 <@dberkholz> not just new installs
-21:28 <@jmbsvicet> bonsaikitten: Does that also sound good to you?
-21:28 <@Betelgeus> CONFIG_PROTECT change or stage shouldn't be a problem
-21:29 <@  grobian> dberkholz: so, you're ok with changing the defautl for a new install
-21:29 <@dberkholz> oh, wait, make.conf doesn't come in like that.
-21:29 <@dberkholz> forgot.
-21:29 <@jmbsvicet> Chainsaw / bonsaikitten: given your issues with large installs, would that also work for you? ^^
-21:29 <@ Chainsaw> dberkholz: It won't, no. But that style of change would have been better. As it would have given me a choice.
-21:29 <@dberkholz> grobian: well, i find it frustrating that new installs would be different from existing ones, in terms of changing the default
-21:29 <@  grobian> Betelgeuse: that means you're ok with changing the default for new installs?
-21:29 <@dberkholz> the path-dependent behavior bothers me
-21:29 <@jmbsvicet> dberkholz: the idea is that on a new install (using a stage), you're already touching a system
-21:29 <@Betelgeus> grobian: yes
-21:30 <@  grobian> dberkholz: so you're indifferent about the setting, but you don't like the default changing?
-21:30 <@jmbsvicet> dberkholz: my idea is to add the setting through catalyst
-21:30 <@  grobian> Chainsaw: just to verify, you could live with a default change set like this, right?
-21:30 <@dberkholz> i'm fine with the default changing, i don't really care. but if people want a mechanism for "accepting" a change in the default, i want it to behave the same way on new and existing systems
-21:30 <@jmbsvicet> another option that has been mentioned is adding the default commented to /etc/make.conf so users can read it and enable it if desired
-21:31 <@dberkholz> otherwise you end up with existing users who would've loved the change but have nfc how to enable it, then it's suddenly magically different when they reinstall
-21:31 <@  grobian> ulm: jmbsvicetto: what do you think about changing the default for new installs?
-21:32 <@  grobian> dberkholz: can solve with news item or elog, no?
-21:32 <@      ulm> As I said, I'm indifferent on it. Let the Portage team decide.
-21:32 <@jmbsvicet> I don't know if I was clear about what I meant. My idea is for the default to be verbose output and to add to the new stages in /etc/make.conf a FEATURES="quiet-build" (whatever is the correct option) so that by default new install would have quiet output
-21:32 <@      ulm> Adding it commented to the example make.conf is a good idea though.
-21:33 <@jmbsvicet> another option is for that line to be commented out so users would have to opt-in on new installs as well
-21:33 <@ Chainsaw> jmbsvicetto: Yes, that sounds very good. Opting in.
-21:33 <@dberkholz> i've been using parallel builds for years, so it's not a change for me, it's making things behave consistently across the board
-21:33 <@jmbsvicet> Chainsaw: It might be a "harder" sale for those that prefer / favour the silent output, though
-21:34 <@ Chainsaw> jmbsvicetto: They should opt into their behaviour change, not force it upon everyone else.
-21:34 <@dberkholz> grobian: are you tracking who's voted which way to see where everyone stands?
-21:34 <@jmbsvicet> zmedico: Do you want to say anything about this?
-21:34 <@  grobian> yes
-21:34 <@  grobian> jmbsvicetto: reload
-21:34 <@  grobian> Chainsaw: I don't think the portage team is unwilling to do anything on this matter
-21:35 <@  grobian> they did this with best intentions
-21:35 <@ Chainsaw> jmbsvicetto: As said, I am delighted that they have developed features that people like. And I hope that lots of people opt in and sing their praises.
-21:35 <@ Chainsaw> jmbsvicetto: But I do not want it, and I do not want my Gentoo system to shift the goal posts arbitrarily when I update it.
-21:35 <@jmbsvicet> grobian: you forgot me on change default for new installs
-21:35 <@  grobian> you like, or not, or no idea?
-21:35 <@jmbsvicet> I like
-21:36 <@  grobian> reload
-21:36 <@jmbsvicet> that's part of my "tentative" proposal ;)
-21:36 <@dberkholz> Chainsaw: but it's different for when you reinstall it? then moving the goal posts is fine?
-21:36 <@  grobian> I like that approach as well
-21:36 <@jmbsvicet> grobian: you might want to add a note about doing it from catalyst
-21:36 <@ Chainsaw> dberkholz: I have to customise a new install anyway. It is not a hassle there.
-21:36 <@  grobian> defaults change, but this way, we don't change for exising users
-21:36 <@ Chainsaw> dberkholz: But a system that has behaved a specific way for years, should continue to behave that way unless I tell it to change. You're welcome to suggest changes to me with news articles.
-21:36 <@  grobian> we've had other changes in the past, like openrc and so on
-21:37 <@dberkholz> honestly, the thing that confused me the most was when -v didn't "fix" it, and i had to go digging through the man page.
-21:37 <@dberkholz> other than that, i didn't care at all
-21:37 <@  grobian> it should be documented better how to change it
-21:37 <@ Chainsaw> dberkholz: i.e. my cars steering wheel should not suddenly invert "because all computer games are like that" when I take it for the next service.
-21:37 <@ Chainsaw> dberkholz: It violates the principle of least astonishment. Even if it makes sense for a lot of people, and some want it.
-21:37 <@dberkholz> umm, you also don't update your car on a regular basis, do you?
-21:38 <@ Chainsaw> dberkholz: It goes for MOT annually.
-21:39 <@  grobian> let's try to get back on the solutions track here
-21:39 <@  grobian> it seems like jmbsvicetto's solution of changing the default via make.conf for new installs is serving both camps
-21:39 <@ Chainsaw> Yes, I am happy to sign on for that.
-21:40 <@  grobian> people building their own stages (with catalyst/metro) control their make.conf anyway, so not affected
-21:40 <@ Chainsaw> Portage should behave as it always has, and I expect the next update to fix the regression.
-21:40 -!- Polynomial-C [~Poly-C@gentoo/developer/Polynomial-C] has quit [Quit: GNU/Linux, because I'd rather own a free OS than steal one that's not worth paying for.]
-21:40 <@  grobian> Chainsaw: ok
-21:41 <@dberkholz> ok, so you're saying portage should not ever change its default behavior. got it.
-21:41 <@  grobian> Chainsaw: I think that's actually by vote of 3-to-2 is what the council decided now
-21:41 <@ Chainsaw> dberkholz: Indeed. Changes in behaviour should be initiated by the user through the configuration file.
-21:42 <@jmbsvicet> grobian: to be clear, I'm going to use catalyst to add a commented line to make.conf warning about the setting and showing how to activate it - so it will be opt-in for current and new installs
-21:42 <@ Chainsaw> dberkholz: And if you believe you have a killer new feature that many want, you write a news article suggesting that they add FEATURES="snowplow" to their config.
-21:42 <@  grobian> jmbsvicetto: hmm, how does that solve anythinjg?
-21:43 <@  grobian> jmbsvicetto: that changes no out-of-the-box behaviour at all, does it?
-21:43 <@jmbsvicet> grobian: right, but it shows users in make.conf how to do it. It also addresses the inconsistency point raised by dberkholz
-21:44 <@  grobian> what you suggest is a note
-21:44 <@  grobian> in my agenda
-21:44 <@jmbsvicet> grobian: I'm open to add it commented or not, if there's an agreement about changing the defaults for new installs
-21:44 <@  grobian> jmbsvicetto: by vote there sort of is
-21:45 <@  grobian> at least that's my understanding of it
-21:45 <@  grobian> 3 people in favour
-21:45 <@jmbsvicet> ok
-21:45 <@jmbsvicet> grobian: catalyst can be updated either way if needed
-21:46 <@  grobian> so, dberkholz, ulm and Betelgeuse don't want to make a statement about the default
-21:46 <@  grobian> the remaining three people are in favour of keeping the current default (for all existing users)
-21:47 <@  grobian> as compromise, we have that new installs get this new quiet output by default (via make.conf), 5 people in favour
-21:48 <@jmbsvicet> ok
-21:48 <@  grobian> if anyone disagrees with that, now's the time
-21:48 <@Betelgeus> For future reference hopefully people learn to discuss changes like this beforehand
-21:48 <@  grobian> Betelgeuse: I'll add that as note
-21:48 <@ Chainsaw> Betelgeuse: That would certainly by less disruptive.
-21:48 <@ Chainsaw> be, even.
-21:48 <@jmbsvicet> I do agree we should ask people to discuss this stuff well before implementing it
-21:49 <@  grobian> it was already implemented a long time ago
-21:49 <@  grobian> the default just changed
-21:49 <@  grobian> anyway
-21:49 <@  grobian> I made that note
-21:49 <@jmbsvicet> implement the change
-21:49 <@dberkholz> that's the implementation he's talking about.
-21:49 <@  grobian> heh
-21:49 <@  grobian> is there anyone who wants to say more about this point?
-21:49 <@  grobian> if not, let's move on
-21:50 <@dberkholz> for future reference to zmedico, i'm betting that if you had done things differently by talking/announcing in advance, it would've stayed the way you made it.
-21:50 <@jmbsvicet> move on
-21:50 <@  grobian> ok, well, point 4 is kind of simple
-21:50 <@  grobian> done
-21:50 <@  grobian> point 5 we already did
-21:51 <@  grobian> updated with Betelgeuse's input now ;)
-21:51 <@  grobian> so, open floor
-21:51 <@  grobian> anyone who would like to bring up a topic?
-21:52 <@  grobian> sounds like not
-21:52 -!- Polynomial-C [~Poly-C@gentoo/developer/Polynomial-C] has joined #gentoo-council
-21:52 <@jmbsvicet> just as a heads-up, I've switched the chairing of next meeting with Fabian. So he's doing January and I'll do May.
-21:52 <@  grobian> everybody ok with closing the meeting here?
-21:52 <@jmbsvicet> I'm fine with it
-21:52 <@  grobian> next meeting 10 of january 2012
-21:53 <@Betelgeus> jmbsvicetto: Could we get teh chari list to the toipc
-21:53 <@Betelgeus> typo++
-21:53 <@  grobian> ok, thanks all!
-21:53 <@ Chainsaw> Yes, I think we're done.
-21:53 <@ Chainsaw> Thank you.
-21:53 <@  grobian> I'll send the agenda around after polising up a bit
-21:54 <@jmbsvicet> grobian: Thanks for chairing
-21:54 <@  grobian> yw
-21:55 -!- jmbsvicetto changed the topic of #gentoo-council to: Next meeting: January 10th, 20:00 UTC | Meeting chairs: http://www.gentoo.org/proj/en/council/#doc_chap5 | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | http://www.gentoo.org/proj/en/council/
-21:55 <@jmbsvicet> Betelgeuse: ^^
-21:55 <@      ulm> grobian: thanks for chairing
-21:56 -!- Zorry [~zorry@gentoo/developer/zorry] has left #gentoo-council ["http://quassel-irc.org - Chat comfortably. Anywhere."]
-21:56 <@  grobian> how about this slacker point, by the way?
-21:57 <@Betelgeus> msising meeting != slacker point
-21:57 <@  grobian> who updates that?
-21:57 <@Betelgeus> hwoarang: is just marked as unattending
-21:57 <@Betelgeus> you only get a slacker mark for two consecutive
-21:59 <@  grobian> oh
-21:59 <@  grobian> ok
-22:01 <@Betelgeus> jmbsvicetto: thanks
-22:03 -!- jbartosik [~jbartosik@gentoo/developer/jbartosik] has joined #gentoo-council
-22:09 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has left #gentoo-council ["Leaving"]
-22:10 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving]
-22:10 -!- pchrist [~spirit@gentoo/developer/pchrist] has joined #gentoo-council
-22:11 -!- NeddySeagoon [~NeddySeag@gentoo/developer/NeddySeagoon] has joined #gentoo-council
---- Log closed Tue Dec 13 22:18:47 2011
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120110-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20120110-summary.txt
deleted file mode 100644
index 4928223e76..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120110-summary.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Agenda of Gentoo council meeting 10 January 2012
-
-Roll call
-=========
-betelgeuse
-blueness (proxy for chainsaw)
-dberkholz
-grobian
-hwoarang
-jmbsvicetto
-ulm
-
-
-Issues raised after call by the community
-=========================================
-No issues were brought up to the Council
-
-
-Open bugs with Council involvement
-==================================
-There are currently no open Council bugs
-
-
-Open actions from last meeting
-==============================
-- eclass API changes discussion from meeting 20111108 (grobian)
-  Discussion has been opened [1].
-- moving council elections results to the elections project space (jmbsvicetto)
-  No progress has been made (open issue is the dates of some old council
-  elections).
-
-
-Open floor
-==========
-No issues were brought up.
-
-
-Next meeting date
-=================
-14 February 2012, 20:00 UTC.
-
-
-
-[1] http://archives.gentoo.org/gentoo-project/msg_b25787ca84c1790154d540be8a3daf43.xml
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120110.txt b/xml/htdocs/proj/en/council/meeting-logs/20120110.txt
deleted file mode 100644
index 9011bf5172..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120110.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-21:00 <@  grobian> okies
-21:00 <@  grobian> ping Betelgeuse hwoarang jmbsvicetto ulm ulm_ dberkholz blueness 
-21:00 <  blueness> here
-21:01 <@ hwoarang> here
-21:01 <@      ulm> here
-21:01 <+dberkholz> hi
-21:02 <@  grobian> hmmm, jmbsvicetto and Betelgeuse are still missing
-21:05 <@  grobian> jmbsvicetto said last time he'd by swamped in work at this time, so that may explain
-21:05 <  blueness> long seen time on Betelgeuse, over a day
-21:05 <@  grobian> agenda is supershort, which makes it easy to deal with, it's on http://dev.gentoo.org/~grobian/agenda-20120110
-21:06 <@  grobian> yeah, he usually pops in, though
-21:06 <@  grobian> if everybody agrees, in open actions, I "closed" my action, given my post to -project on the matter
-21:07 <@ hwoarang> i dont follow
-21:07 <@ hwoarang> you mean [1] ?
-21:07 <@ hwoarang> re eclass API
-21:08 <@  grobian> yeah
-21:08 <@  grobian> it's an open action on the agenda
-21:09 <@Betelgeus> grobian: hello
-21:09 <@Betelgeus> sorry about being late
-21:09 <@  grobian> ah, Betelgeuse 
-21:09 <@  grobian> anyone got contact details for jmbsvicetto 
-21:09 <@Betelgeus> grobian: I can phone him
-21:09 <@  grobian> I searched my cards
-21:10 <@  grobian> do we all agree that the agenda is very short?  That is, if there's no open floor questions, we're done if jorge just says he's ok with the agenda
-21:11 <@ hwoarang> fine with me
-21:11 <  blueness> Chainsaw gave me no issues to raise, so sure
-21:11 <@  grobian> yeah
-21:11 <@  grobian> any open floor issues?
-21:11 <@Betelgeus> grobian: jmbsvicetto is coming
-21:12 <@  grobian> Betelgeuse: thanks a lot
-21:12 <@jmbsvicet> sorry :(
-21:12 <@jmbsvicet> Petteri thanks for calling me
-21:13 <@  grobian> ok, we all agree on the agenda?
-21:13 <@  grobian> I take that as a yes
-21:13 <  blueness> yes
-21:13 <@  grobian> Anyone who wants to raise issues in the open floor?
-21:13 <@jmbsvicet> quickly reading backlog and agenda
-21:14 <@  grobian> jmbsvicetto: open actions, I assume no update from your part?
-21:14 <@jmbsvicet> grobian: sorry, no
-21:14 <@  grobian> ok, updated
-21:14 <@jmbsvicet> I looked at the elections page this weekend, but wasn't able to complete the move
-21:15 <@jmbsvicet> grobian: agenda is ok for me
-21:15 <@  grobian> well, then, if there's no open floor issues, thank you all for being here, and thanks for this productive meeting ;)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120214-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20120214-summary.txt
deleted file mode 100644
index 4095e90546..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120214-summary.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Roll call
-=========
-betelgeuse
-chainsaw
-dberkholz
-grobian
-hwoarang
-jmbsvicetto
-ulm
-
-
-Issues raised after call by the community
-=========================================
-No issues were brought up to the Council
-
-
-Open bugs with Council involvement
-==================================
-No progress on open Council bugs
-
-Open floor
-==========
-No issues were brought up.
-
-
-Next meeting date
-=================
-13 March 2012, 20:00 UTC.
-
-
-
-[1] http://archives.gentoo.org/gentoo-project/msg_b25787ca84c1790154d540be8a3daf43.xml
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120214.txt b/xml/htdocs/proj/en/council/meeting-logs/20120214.txt
deleted file mode 100644
index 062a5bd190..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120214.txt
+++ /dev/null
@@ -1,122 +0,0 @@
---- Log opened Tue Feb 14 20:03:35 2012
-20:03 -!- mode/#gentoo-council [+v dberkholz] by ChanServ
-20:03 -!- Irssi: Join to #gentoo-council was synced in 1 secs
-20:03 <jmbsvicett@> Chainsaw: I have Donnie's number on the other laptop :\
-20:03 <  Chainsaw@> Good evening dberkholz.
-20:03 < dberkholz+> hi guys, sorry.
-20:03 <jmbsvicett@> anyone has access to email? He sent a phone number for FOSDEM
-20:03 <   grobian@> ah, good
-20:04 <   grobian@> jmbsvicetto: not necessary any more ;)
-20:04 < dberkholz+> i totally suck. got all distracted w/ fosdem stuff
-20:04 <jmbsvicett@> Hi Donnie
-20:04 <Betelgeuse@> jmbsvicetto: There is no requirement to decide anything so we are fine for that rule.
-20:04 < dberkholz+> i think the only question was the poland friends site, right?
-20:05 <jmbsvicett@> Betelgeuse: I think we already have 4, otherwise we would hit that rule. Last time it happened was 2 or 3 years ago
-20:05 <   grobian@> dberkholz: do you have an agenda at hand?
-20:05 <     _AxS_ > jmbsvicetto: umm..  regarding that rule, technically couldn't you just decide that (without quarum) you guys not have the meeting until later? :)
-20:05 <jmbsvicett@> Betelgeuse: the point of that rule is to ensure no meeting is hold without quorum
-20:06 <jmbsvicett@> _AxS_: last time that happened the rule was applied
-20:06 <jmbsvicett@> _AxS_: but in an case, we do have a quorum
-20:06 < dberkholz+> grobian: well, the only item was regarding the gentoo poland group and name/logo use, which is clearly a trustees question imho
-20:06 < dberkholz+> grobian: so there isn't any agenda for the meeting
-20:06 <jmbsvicett@> Betelgeuse, Chainsaw, dberkholz, grobian, hwoarang and jmbsvicetto are around.
-20:06 <   grobian@> dberkholz: we have a discussion here that the agenda wasn't sent a week in advance, like we decided in our first meeting
-20:07 < dberkholz+> how can you send a nonexistent agenda?
-20:07 < dberkholz+> there was nothing to discuss
-20:07 <   grobian@> dberkholz: like I did
-20:07  * Chainsaw confirms his presence
-20:07 <   grobian@> dberkholz: but we think we can get away with it, because it's empty
-20:07 <  Chainsaw@> (On time & unprompted, for the record!)
-20:07 < dberkholz+> Chainsaw: yeah, i took your spot on that one
-20:07 <   grobian@> Chainsaw: woohoo :)
-20:08 <   grobian@> ulm: around?
-20:08 <       ulm@> yes
-20:08 <jmbsvicett@> so, dberkholz do you want to open the meeting? ;)
-20:08 <jmbsvicett@> dberkholz: we just need to do a head count an open the floor
-20:08 <jmbsvicett@> and*
-20:09 <   grobian@> jmbsvicetto: I guess the open actions haven't changed, right?
-20:09 < dberkholz+> where's hwoarang?
-20:09 <jmbsvicett@> grobian: not mine :-\
-20:09 <  hwoarang@> i am here
-20:09 < dberkholz+> ok, that's everyone
-20:09 <jmbsvicett@> dberkholz: for the record, I suggest we open the meeting do a roll call and then open the floor
-20:10 <   grobian@> ack
-20:10 <jmbsvicett@> so you can list that in the log
-20:10 < dberkholz+> everyone on the council has spoken now, but if you insist on formal process, i guess that's fine
-20:11 <jmbsvicett@> dberkholz: I'd say it's best to be safe than sorry ;)
-20:11 < dberkholz+> so, council folks, say you're here again.
-20:11 <jmbsvicett@> here
-20:11 <   grobian@> here
-20:11 <  Chainsaw@> Present.
-20:11 < dberkholz+> Betelgeuse, hwoarang, ulm: say hi again
-20:11 <  hwoarang@> hi
-20:11 <       ulm@> here
-20:11 <Betelgeuse@> hi
-20:12 < dberkholz+> i feel much safer now, don't you? =P
-20:12 <Betelgeuse@> no
-20:12 <jmbsvicett@> x
-20:12 <jmbsvicett@> dberkholz: it's a "warm" feeling :P
-20:12 < dberkholz+> jmbsvicetto: any progress on bug 383467?
-20:13 < willikins > dberkholz: https://bugs.gentoo.org/383467 "Council webpage lacks results for 2010 and 2011 elections"; Website www.gentoo.org, Projects; CONF; hwoarang:jmbsvicetto
-20:13 <jmbsvicett@> so, are we ok with this meeting or do you want us to hold another meeting this month?
-20:13 <jmbsvicett@> I think we're ok and don't see a need for a new meeting
-20:13 <jmbsvicett@> dberkholz: no, sorry
-20:13 < dberkholz+> that's the only open bug i see
-20:13 <  Chainsaw@> jmbsvicetto: I'm glad we agree on that. Then the next meeting can be in March.
-20:13 <   grobian@> I think we're ok if we stick to roll-call + open floor
-20:13 <Betelgeuse@> I would call for agenda items. If there are then hold a meeting.
-20:14 < dberkholz+> grobian sent out a call on feb 2...
-20:14 <Betelgeuse@> We could also just hold our March meeting early March
-20:14 < dberkholz+> if people didn't reply to that, they apparently had no issues
-20:14 <Betelgeuse@> dberkholz: true
-20:14 < dberkholz+> btw, thank you for that grobian, much appreciated
-20:14 <Betelgeuse@> So I guess we are fine as people forgetting to attend is not a big problem.
-20:14 <   grobian@> dberkholz: yw
-20:15 < dberkholz+> got caught up in a big morass with the fosdem trip, getting my phone stolen, etc.
-20:15 < dberkholz+> so, let's open the floor up, and if there's nothing, we'll wrap up in a couple minutes
-20:15 <jmbsvicett@> dberkholz: I can't find any other bug as well
-20:16 <  Chainsaw@> Good evening Zorry.
-20:16 <     Zorry > hi Chainsaw
-20:16 <jmbsvicett@> I caught up with emails today and the only issue I saw was mentioned, besides the Gentoo Poland Group, was the issue about enabling PIE on all setuid files and that was "refused" by grobian as it was still premature to send to council
-20:16 <   grobian@> ok, so can we get back to the "meeting"?
-20:17 <   grobian@> can we agree on an empty agenda?
-20:17 <  Chainsaw@> Agreed.
-20:17 <jmbsvicett@> yes
-20:17 <Betelgeuse@> yes
-20:17 <       ulm@> yes
-20:17 < dberkholz+> right. so consider the floor open
-20:17 <  Chainsaw@> Zorry: Was there anything you wanted to raise?
-20:18 <     Zorry > nope just looking in
-20:18 <   grobian@> as a note: I send the call for agenda items, but expect the chair to decide what to put on the agenda and send the agenda around 1 week in advance
-20:18 <   grobian@> in case this was unclear
-20:18 < dberkholz+> and as another friendly note, i'd recommend to the rest of you that you put 1- and 2-week reminders on your calendars, unlike me
-20:19 < dberkholz+> for the meetings you're chairing
-20:19 <   grobian@> is it perhaps better to let the chair send the call as well?
-20:19 <  Chainsaw@> Yes, I use the company CRM these days. It helps.
-20:21 < dberkholz+> ok, it's been 3 minutes. last chance to raise an issue
-20:21 <jmbsvicett@> grobian: if you don't mind sending the intial email, I appreciate it
-20:21 <   grobian@> I happily do so
-20:21 <Betelgeuse@> grobian: could include the chair in the email
-20:22 <Betelgeuse@> grobian: maybe then he will notice to do something :)
-20:22 <   grobian@> Betelgeuse: ah, YOU for next month :)
-20:22 <jmbsvicett@> :)
-20:22 <   grobian@> good suggestion, I'll try to do that
-20:22 < dberkholz+> we just need to build this stuff into the council webapp
-20:22 <   grobian@> next meeting = 13th march?
-20:22 <  Chainsaw@> That works for me, thank you.
-20:23 <Betelgeuse@> dberkholz: Now that I am chairing we could take it for a spin
-20:23 <jmbsvicett@> grobian: yes
-20:23 <   grobian@> ok, I got it down in my agenda now :)
-20:23 < dberkholz+> alright, we're done for today. next meeting is 2000 utc on march 13. Betelgeuse will chair.
-20:23 <jmbsvicett@> dberkholz: ok, thanks
-20:23 <   grobian@> thanks dberkholz
-20:24 <jmbsvicett@> I need to leave now. See you all later
-20:24 < dberkholz+> thanks for coping with my slackerness
-20:24 <Betelgeuse@> thanks
-20:24 <       ulm@> thanks
-20:24 < dberkholz+> btw, if any of you are interested in my gsoc mentoring talk from fosdem, it's online now — http://monk.ly/yjCfiA
-20:24 <   grobian@> thanks, I saw it live though :)
-20:25 < dberkholz+> watch it so that if a bus hits me, we're still ok =)
-20:25 <Betelgeuse@> dberkholz: btw did GSoC get announced in FOSDEM? Maybe I wasn't following exactly when it happened.
-20:27 < dberkholz+> Betelgeuse: yep
-20:27 <   grobian@> ok, later all
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120313-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20120313-summary.txt
deleted file mode 100644
index dc13730993..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120313-summary.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-Roll call
-=========
-betelgeuse
-chainsaw
-dberkholz
-grobian
-hwoarang
-jmbsvicetto
-ulm
-
-Default locale
-==============
-
-The council unanimously agreed that the handbook should have a section
-asking the user to select a locale. As a result a bug was opened to
-change the handbook:
-
- https://bugs.gentoo.org/show_bug.cgi?id=408073
-
-The council voted that the default locale should not be changed.
-
-Open floor
-==========
-grobian asked for opinions on re-evaluation glep 55.
-
-
-Next meeting date
-=================
-03 April 2012, 19:00 UTC.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120313.txt b/xml/htdocs/proj/en/council/meeting-logs/20120313.txt
deleted file mode 100644
index ad1d61ac35..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120313.txt
+++ /dev/null
@@ -1,294 +0,0 @@
-<13.03.2012 20:01> <@Betelgeuse> helo
-<13.03.2012 20:01> <@grobian> yo
-<13.03.2012 20:01> <+dberkholz> hi
-<13.03.2012 20:01> <@Chainsaw> 250 chainsaw.gentoo.org ready
-<13.03.2012 20:02> <@grobian> MAIL FROM: <grobian@gentoo.org>
-<13.03.2012 20:02> <@Betelgeuse> agenda: http://archives.gentoo.org/gentoo-dev-announce/msg_6531c9554a3050e94eac3388bc38f4b8.xml
-<13.03.2012 20:02> < willikins> grobian, you have notes! [20:42] <chithead> it seems that the portage and x11 overlay versions of libSM have diverged. if you make changes to those ebuilds it is important to notify x11 team because we use the x11 overlay packages for bumping
-<13.03.2012 20:02> <@grobian> Betelgeuse: do we skip the EAPI5 thing or not?
-<13.03.2012 20:02> <@Betelgeuse> As a sub bullet for 2) I think we want to touch on Tommy[D]'s request
-<13.03.2012 20:03> <@Betelgeuse> My initial idea was to first open the process in general
-<13.03.2012 20:03> <+dberkholz> the person who submitted it withdrew the proposal and wanted to write up cross-compile stuff for the next council
-<13.03.2012 20:03> <@grobian> jmbsvicetto: ulm ping
-<13.03.2012 20:04> <@Betelgeuse> hwoarang: ping
-<13.03.2012 20:04>  * hwoarang here
-<13.03.2012 20:04> <@ulm> here
-<13.03.2012 20:05> <@Chainsaw> Present.
-<13.03.2012 20:05> <@Betelgeuse> I will call Jorge
-<13.03.2012 20:05> <@grobian> |I was texting
-<13.03.2012 20:07> <@Betelgeuse> didn't connect
-<13.03.2012 20:07> <@Betelgeuse> so let's start
-<13.03.2012 20:07> <@Betelgeuse> 2. EAPI 5
-<13.03.2012 20:07> <@Betelgeuse> Tommy[D] wanted us to vote on the inclusion of a feature. 
-<13.03.2012 20:07> <@grobian> specs first
-<13.03.2012 20:07> <@Betelgeuse> Usually we have voted only on ready specs.
-<13.03.2012 20:08> <@Chainsaw> Anything to vote on? No? Move on.
-<13.03.2012 20:08> <@ulm> someone should go through the open EAPI bugs and collect the features that are candidates for EAPI 5
-<13.03.2012 20:09> <@Betelgeuse> ulm: http://video.fosdem.org/2012/crossdistro/Gentoo_EAPI_5.webm
-<13.03.2012 20:09> <@ulm> Betelgeuse: do you have a summary in textual form? ;)
-<13.03.2012 20:10> < Tommy[D]> Betelgeuse: as i wrote in response to your announcement, i will ask for the next council session with a provided spec, so just drop it for now :)
-<13.03.2012 20:10> <@grobian> I'd suggest to actually flesh that out first on the mls
-<13.03.2012 20:10> <@grobian> ^^^ betelgeuse
-<13.03.2012 20:10> <@Betelgeuse> ulm: I can upload the slides (they have bug ids)
-<13.03.2012 20:10> <+dberkholz> maybe we should just make a tracker bug instead
-<13.03.2012 20:10> <@ulm> Betelgeuse: yes, slides would be fine
-<13.03.2012 20:11> <@jmbsvicetto> pong
-<13.03.2012 20:11> <@jmbsvicetto> sorry guys, I forgot the meeting :-\
-<13.03.2012 20:11> <+dberkholz> jmbsvicetto: good, now i'm not the only one =)
-<13.03.2012 20:11> <@Betelgeuse> Ok so to conclude: the council encourages starting to submit EAPI 5 items for specification with implementations to Portage. All agree?
-<13.03.2012 20:11> <+dberkholz> sure
-<13.03.2012 20:11> <@ulm> +1
-<13.03.2012 20:11> <@grobian> sure
-<13.03.2012 20:12> <@hwoarang> ok
-<13.03.2012 20:12> <@Betelgeuse> Tommy[D]: thanks
-<13.03.2012 20:12> <@Betelgeuse> Tommy[D]: Sorry about undercommunication on the agenda.
-<13.03.2012 20:12> <@jmbsvicetto> +1
-<13.03.2012 20:12> <@Chainsaw> Yes. Agreed.
-<13.03.2012 20:12> <@Betelgeuse> ok point 2
-<13.03.2012 20:12> <@Betelgeuse> default locale
-<13.03.2012 20:12> <@Chainsaw> UTF8 is a good thing to have, but...
-<13.03.2012 20:13> <@Betelgeuse> actually 3a
-<13.03.2012 20:13> <@Chainsaw> It seems to lock you into a country.
-<13.03.2012 20:13> <@Chainsaw> Did you say Debian had implemented a pretend-country for this purpose?
-<13.03.2012 20:13> <@jmbsvicetto> Chainsaw: I've seen the proposal to use C.UTF-8 a few times when this discussion is raised
-<13.03.2012 20:13> <@grobian> can someone remind me why documenting this in the install doc isn't sufficient?
-<13.03.2012 20:13> <@jmbsvicetto> I recall reading about it on the dev ml at least 2 times in the last 6 months.
-<13.03.2012 20:14> <@grobian> jmbsvicetto: yeah, but it doesn't exist
-<13.03.2012 20:14> <@Chainsaw> grobian: Something to be said for that, all of my kit is en_GB.UTF-8.
-<13.03.2012 20:14> <@jmbsvicetto> grobian: I thought debian had created it
-<13.03.2012 20:14> <@grobian> Chainsaw: same here
-<13.03.2012 20:14> <@Chainsaw> grobian: Especially now that eselect handles the env.d aspects...
-<13.03.2012 20:14> <@grobian> jmbsvicetto: exactly
-<13.03.2012 20:14> <@Chainsaw> grobian: It is no longer such a hardship.
-<13.03.2012 20:15> <@grobian> multibyte stuff is expensive
-<13.03.2012 20:15> <@Chainsaw> grobian: So, counter-proposal is to better document the existing tools?
-<13.03.2012 20:15> <@grobian> whether you want to have support for it available, is another thing
-<13.03.2012 20:15> <@grobian> Chainsaw: I believe it already is documented like this, isn't it?
-<13.03.2012 20:15> <@Chainsaw> I want UTF-8, and think developers should have it. You can't write Flameeyes correctly, for example. Petten o-with-funky-stripe etc.
-<13.03.2012 20:16> <@jmbsvicetto> Chainsaw: iirc, one of the proposals for releng to use it was related to some packages failing to build with the C locale
-<13.03.2012 20:16> <@Chainsaw> jmbsvicetto: Test suites tend to implode, yes.
-<13.03.2012 20:16> <+dberkholz> btw, here's the debian bug about introducing C.UTF-8: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522776
-<13.03.2012 20:16> <@Chainsaw> jmbsvicetto: If you turn those off it is generally okay.
-<13.03.2012 20:17> <@grobian> I've no problems making en_US.UTF-8 the default, but it's the same as portage's --quiet-build in some sense
-<13.03.2012 20:17> <@Chainsaw> grobian: I would be against defaulting to a specific country.
-<13.03.2012 20:17> < cam___> all packages build fine with utf8 enabled?
-<13.03.2012 20:17> <@Chainsaw> grobian: C.UTF-8 looks more sensible, but is extra work.
-<13.03.2012 20:18> <+dberkholz> gentoo already defaults to en_US
-<13.03.2012 20:18> <+dberkholz> read the docs
-<13.03.2012 20:18> <+dberkholz> i mean, everything on our site uses american english
-<13.03.2012 20:18> <@ulm> we should leave LANG at C or POSIX
-<13.03.2012 20:18> <@Betelgeuse> Portage could default to C when building even if C.UTF-8 is otherwise the default.
-<13.03.2012 20:18> <@ulm> and only set LC_CTYPE which is less intrusive
-<13.03.2012 20:18> <@Betelgeuse> So stuff building is not really an issue.
-<13.03.2012 20:19> <@ulm> otherwise, there may be undesired side effects
-<13.03.2012 20:19> <+dberkholz> ulm: that is precisely what C.UTF-8 does
-<13.03.2012 20:19> <@grobian> Why is adding a strong suggestion to set UTF-8 locale in http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=8 not enough?
-<13.03.2012 20:19> <@grobian> the default must be C/POSIX, IMO
-<13.03.2012 20:20> <@grobian> though you should be free to override, and actually be encouraged to do so
-<13.03.2012 20:20> <@grobian> apart from that the system should be capable of doing UTF-8 and so on
-<13.03.2012 20:20> <@ulm> grobian: you certainly have a point, locale is one of the things that every user should configure for his system
-<13.03.2012 20:20> < cam___> are there some other distros utf8 by default?
-<13.03.2012 20:21> <@Betelgeuse> cam___: Installers probably set it.
-<13.03.2012 20:21> <@hwoarang> i tend to agree that a strong suggestion in the guide is enough
-<13.03.2012 20:21> <@grobian> ulm: and even individual users can configure it
-<13.03.2012 20:21> <@Betelgeuse> I think Ubuntu went years ago but don't remember specifics.
-<13.03.2012 20:21> <@ulm> grobian: right
-<13.03.2012 20:21> <@Chainsaw> grobian: I support your idea.
-<13.03.2012 20:21> <@Betelgeuse> So let's start with this: Should the handbook have a section for the user to choose a locale?
-<13.03.2012 20:22> <@ulm> yes
-<13.03.2012 20:22> <@grobian> Betelgeuse: yes
-<13.03.2012 20:22> <@Chainsaw> Betelgeuse: Yes. It should.
-<13.03.2012 20:22> <+dberkholz> so you're saying we should incorporate the existing localization guide content directly into the handbook?
-<13.03.2012 20:22> <@grobian> Ubuntu indeed seems to be en_US.UTF-8 by default
-<13.03.2012 20:22> <@grobian> (just checked)
-<13.03.2012 20:23> <+dberkholz> we already talk a little about locales in the handbook, see http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=6
-<13.03.2012 20:23> <@Chainsaw> grobian: I find that Ubuntu has made so much bad calls lately, that I would discourage using them as a guide.
-<13.03.2012 20:23> <@grobian> Chainsaw: just as info, I don't agree with their choice, although I understand from their perspective and vision on their users
-<13.03.2012 20:23> <@Betelgeuse> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=12
-<13.03.2012 20:24> <@Betelgeuse> dberkholz: it is linked to from there
-<13.03.2012 20:24> <@Betelgeuse> dberkholz: I think we want to put a little more emphasis
-<13.03.2012 20:24> <@Chainsaw> Betelgeuse: Yes, it seems too optional this way.
-<13.03.2012 20:24> <@grobian> I think dberkholz's link is actually the place where you want to suggest actually enabling something by default
-<13.03.2012 20:24> <@grobian> iso just making it available
-<13.03.2012 20:25> <@Betelgeuse> jmbsvicetto, hwoarang, dberkholz: input please
-<13.03.2012 20:25> <@Chainsaw> grobian: Better place there, yes. But the current examples are a bit sparse.
-<13.03.2012 20:25> <@grobian> Chainsaw: agreed
-<13.03.2012 20:26> <@Chainsaw> Evening Zac.
-<13.03.2012 20:26> <+dberkholz> sure, i'd be fine with adding extra emphasis on enabling a utf-8 locale in that section i pointed to
-<13.03.2012 20:26> <+dberkholz> seems very reasonable
-<13.03.2012 20:26> <@jmbsvicetto> Betelgeuse: I like the idea of improving the docs
-<13.03.2012 20:26> <@Chainsaw> dberkholz: Okay, let's do that. Update the documentation, but make no actual system changes.
-<13.03.2012 20:27> <@Betelgeuse> Second question: Do we want to mandate a new default at this point?
-<13.03.2012 20:27> < cam___> why not in http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=8#doc_chap3 along with keymap and clock?
-<13.03.2012 20:27> <@jmbsvicetto> I think we should also "encourage" anyone interested in looking at the C.UTF-8 locale
-<13.03.2012 20:27> <@grobian> Betelgeuse: I guess no, since it's the user to chose there
-<13.03.2012 20:27> <@Chainsaw> jmbsvicetto: Do we have one though?
-<13.03.2012 20:28> <@grobian> jmbsvicetto: it's there on Debian
-<13.03.2012 20:28> <@Chainsaw> jmbsvicetto: Is that not a Debian-specific patch that we do not carry?
-<13.03.2012 20:28> <@grobian> jmbsvicetto: not with us
-<13.03.2012 20:28> <@grobian> We should just explain a bit better where ti find our own land/language code
-<13.03.2012 20:28> <@jmbsvicetto> something we should talk with vapier about?
-<13.03.2012 20:28> <@ulm> Chainsaw: yes, it's debian specific
-<13.03.2012 20:29> <@grobian> jmbsvicetto: no, don't need it, and upstream apparently don't want it
-<13.03.2012 20:29> <@Chainsaw> jmbsvicetto: If the documentation is better, it shouldn't be required.
-<13.03.2012 20:29> <@Chainsaw> jmbsvicetto: Besides, fighting upstream is labour-intensive.
-<13.03.2012 20:29> <+dberkholz> we don't ship that locale
-<13.03.2012 20:29> <+dberkholz> that's the problem
-<13.03.2012 20:29> <@grobian> how can C be UTF-8 anyway
-<13.03.2012 20:29> <@Betelgeuse> https://bugs.gentoo.org/show_bug.cgi?id=408073
-<13.03.2012 20:29> <+dberkholz> and i'm not terribly interested in adding customizations at that level
-<13.03.2012 20:29> <@jmbsvicetto> grobian / Chainsaw: If we could pick C.UTF-8, I'd prefer us making that the default
-<13.03.2012 20:29> <@grobian> it's POSIX, so ASCII
-<13.03.2012 20:29> <@Chainsaw> jmbsvicetto: But we can't.
-<13.03.2012 20:29> <@grobian> jmbsvicetto: we can't and it's nonsense
-<13.03.2012 20:30> < ssuominen> I would ship 02locale by default set to en_US.UTF-8 and update the locale documentation for that
-<13.03.2012 20:30> < ssuominen> shipped in bl-2
-<13.03.2012 20:31> <@ulm> ssuominen: LANG or LC_CTYPE?
-<13.03.2012 20:31> < ssuominen> LANG
-<13.03.2012 20:31> <@grobian> what's the benefit of that?
-<13.03.2012 20:31> <@ulm> ssuominen: then I would be against it
-<13.03.2012 20:31> < ssuominen> leave LC_CTYPE below that commented out
-<13.03.2012 20:31> < ssuominen> as an example
-<13.03.2012 20:32> <@grobian> Betelgeuse: can we get back on track, please?
-<13.03.2012 20:32> <@Betelgeuse> grobian: yes
-<13.03.2012 20:32> <@Betelgeuse> Can I have a clear yes /no on the second question
-<13.03.2012 20:33> <@grobian> Betelgeuse: no, since we won't force another default
-<13.03.2012 20:33> <@Betelgeuse> (if the answer is no we can clearly move on as no changes need to be discussed)
-<13.03.2012 20:34> <+dberkholz> i would be ok with it, if it were shipped upstream, but not if we have add it ourselves
-<13.03.2012 20:34> <@hwoarang> i dont see the point for a default locale in installation images. So "no" for me
-<13.03.2012 20:34> <@ulm> Betelgeuse: no if it would mean changing LANG
-<13.03.2012 20:35> <@Betelgeuse> ulm: so you would like changing some LC_*?
-<13.03.2012 20:35> <@ulm> Betelgeuse: I wouldn't oppose it
-<13.03.2012 20:36> <@ulm> count it as abstain
-<13.03.2012 20:36> <@Betelgeuse> jmbsvicetto, Chainsaw 
-<13.03.2012 20:37> <@Chainsaw> Betelgeuse: No. Do not make system changes, stick with a documentation change and call it a day.
-<13.03.2012 20:39> <@jmbsvicetto> Betelgeuse: if we can't use C.UTF-8 to try to fix the building issues with the C locale and document how to set a locale, I think we shouldn't set a new default
-<13.03.2012 20:39> <@grobian> jmbsvicetto: fix building issues by forcing en_US.UTF-8 locale in build-env?
-<13.03.2012 20:39> <@Betelgeuse> What we build with is a different item I think.
-<13.03.2012 20:39> <@Betelgeuse> what grobian said
-<13.03.2012 20:39> <@Chainsaw> jmbsvicetto: C.UTF-8 is a Debian-specific thing that we do not have.
-<13.03.2012 20:39> <@hwoarang> that's a diffenent issue
-<13.03.2012 20:40> <@Chainsaw> And please, can we move on. This is a yes or no question.
-<13.03.2012 20:40> <@jmbsvicetto> grobian: I guess we could do that - if the user doesn't have a UTF-8 locale
-<13.03.2012 20:40> <@jmbsvicetto> Chainsaw: I know, but I think it might / could be an option
-<13.03.2012 20:40> <@Betelgeuse> We have enough no's to call it a decision.
-<13.03.2012 20:40> <@jmbsvicetto> Chainsaw: count mine as a no
-<13.03.2012 20:40> <@Chainsaw> That's unanimous. Move on please.
-<13.03.2012 20:41> <@Betelgeuse> Ok that concludes the official agenda items.
-<13.03.2012 20:41> <@grobian> jmbsvicetto: let's delay discussion for a bit
-<13.03.2012 20:41> <@Betelgeuse> Anything for the open floor?
-<13.03.2012 20:41> <@jmbsvicetto> grobian: sure
-<13.03.2012 20:42> <@grobian> Betelgeuse: maybe a little q for the other council members how they see re-evaluating glep-55
-<13.03.2012 20:42> <@Betelgeuse> grobian: sure
-<13.03.2012 20:42> <@jmbsvicetto> grobian: My reasons to dislike it are still valid (imho)
-<13.03.2012 20:42> <@grobian> possible, useful, whether it will change anything, etc.
-<13.03.2012 20:42> <@Betelgeuse> I voted for it the last time.
-<13.03.2012 20:42> <@Chainsaw> grobian: I thought it was a bad idea then, and it still is a bad idea now.
-<13.03.2012 20:43> <@grobian> I'm not a big fan of changing the ebuild extension myself
-<13.03.2012 20:43> <+dberkholz> i prefer the header solution
-<13.03.2012 20:43> <@jmbsvicetto> grobian: I don't think a file format that changes its "extension" on every update is "sane" and I still think the EAPI version should not be part of the file name
-<13.03.2012 20:44> <@hwoarang> i haven't read the entire thread but I don't want to change the extension
-<13.03.2012 20:44> <@ulm> I think my opinion on the matter is clear ;)
-<13.03.2012 20:44> <@grobian> yeah it is
-<13.03.2012 20:44> <@grobian> ok, so my conclusion is that this council won't change the state of glep-55
-<13.03.2012 20:44> <@Chainsaw> grobian: I agree with that summary.
-<13.03.2012 20:44> <@jmbsvicetto> as ebuild is a text format, I think EAPI should be defined on the header or top of the file
-<13.03.2012 20:44> <@grobian> so it's useless to bring it up again, if people ask for that
-<13.03.2012 20:45> <@Chainsaw> grobian: Indeed.
-<13.03.2012 20:45> <@ulm> BTW, ferringb and myself have started a wiki page to collect what has been proposed so far: http://wiki.gentoo.org/wiki/Alternate_EAPI_mechanisms
-<13.03.2012 20:45> <@jmbsvicetto> so it seems
-<13.03.2012 20:45> <@grobian> jmbsvicetto: the only real problem I see, and that is what Glep-55 solves, is what an older PM would do with a newer ebuild it doesn't grok
-<13.03.2012 20:46> <@ulm> grobian: see the wiki page :)
-<13.03.2012 20:46> <@grobian> however, I tend to believe that the possible scope of problems there in reality is fairly limited
-<13.03.2012 20:46> <@grobian> (I strongly dislike XML or Python ebuilds)
-<13.03.2012 20:46> <@jmbsvicetto> grobian: That's why I'd be open for a one-time extension change so that we could introduce some fault-tolerance / future-proof features in the PMs
-<13.03.2012 20:46> <@grobian> (if they ever come around, an extension change IS a good idea)
-<13.03.2012 20:46> <@grobian> jmbsvicetto: that's not the point of glep-55
-<13.03.2012 20:47> <@grobian> jmbsvicetto: in that case, you can stick as well with .ebuild
-<13.03.2012 20:47> <@jmbsvicetto> yes, but to me that's what we should be looking into ;)
-<13.03.2012 20:47> <@grobian> ulm: excellent comparison/study material
-<13.03.2012 20:47> <@jmbsvicetto> grobian: sure, but if we really need to change the name to take advantage of that "mis-feature" of old PMs, I'd be ok with it
-<13.03.2012 20:48> <@jmbsvicetto> grobian: I just think we should try to pack as much sensible features as possible when we do that - so we don't have to do it again N months after
-<13.03.2012 20:48> <@grobian> jmbsvicetto: I don't see the point, Zac/ulm already gave ways to work around it
-<13.03.2012 20:48> <+dberkholz> i'd rather do it again N months after
-<13.03.2012 20:48> <@grobian> anyhow, this is just chat to me
-<13.03.2012 20:49> <+dberkholz> otherwise we spend forever trying to get a perfect solution that does it all
-<13.03.2012 20:49> <@grobian> not really something for the meeting per se
-<13.03.2012 20:49> <+dberkholz> when in reality, iteration works a lot better
-<13.03.2012 20:49> <@grobian> dberkholz: got some point in there
-<13.03.2012 20:49> <@jmbsvicetto> grobian: one thing that I think we should try to pack in this change is the discussion about the PM cache format
-<13.03.2012 20:50> <@grobian> isn't that something totally different?
-<13.03.2012 20:50> <@grobian> a portage internal?
-<13.03.2012 20:50> <@ulm> jmbsvicetto: I'd rather keep such discussions separate
-<13.03.2012 20:51> <+dberkholz> grobian: made that mistake enough times to see it coming these days =)
-<13.03.2012 20:52> <@jmbsvicetto> grobian: then there's also the idea of having a <features> file under the top of a repo (inside metadata?) and the idea of reworking profiles
-<13.03.2012 20:52> <@jmbsvicetto> grobian: unless we can define a new cache format that could be used by all PMs
-<13.03.2012 20:52> <@grobian> aren't we now packing up the x-mas tree with everything we can, like we do for gx86 git migration?
-<13.03.2012 20:53> <@grobian> guarantee to get nowhere anywhere near soon
-<13.03.2012 20:53> <@grobian> see dberkholz
-<13.03.2012 20:54> <@jmbsvicetto> yes, I understand dberkholz's point
-<13.03.2012 20:55> <@jmbsvicetto> but I think we may need to rethink the tree / repo / cache structure and try to come up with a way that allows us to implement changes without requiring adding one-time files to repos or replacing ebuild extensions
-<13.03.2012 20:55> <@Betelgeuse> grobian: so you got the answer I guess, so anything else?
-<13.03.2012 20:56> <@jmbsvicetto> Betelgeuse: anyway, I'll stop now
-<13.03.2012 20:56> <@grobian> Betelgeuse: yeah, long ago, see my "summary"
-<13.03.2012 20:56> <@Betelgeuse> so next meeting
-<13.03.2012 20:56> <@grobian> that's after easter?
-<13.03.2012 20:57> <@Betelgeuse> 10th April yeah
-<13.03.2012 20:57> <@grobian> anyone else going on holiday for easter?
-<13.03.2012 20:57> <@hwoarang> 10th may be a bit odd
-<13.03.2012 20:57> <@grobian> if not, no point in trying to persuade to move the date
-<13.03.2012 20:57> <@hwoarang> as it is after easter and I will be on vacations :/
-<13.03.2012 20:58> <@grobian> ah, number 2
-<13.03.2012 20:58> <@hwoarang> grobian: i wont be here so I will be interested in changing the date
-<13.03.2012 20:58> <@jmbsvicetto> grobian: hopefully, the hospital move should be done around that date
-<13.03.2012 20:58> <@grobian> both 3 and 17 are fine for me
-<13.03.2012 20:58> <+dberkholz> i'll probably be traveling the afternoon of the 10th, not sure exactly when i'm leaving though
-<13.03.2012 20:58> <@Betelgeuse> so move to 17th?
-<13.03.2012 20:58> <+dberkholz> same goes for the 17th for me, actually =D
-<13.03.2012 20:58> <@grobian> I'd like that very much
-<13.03.2012 20:58> <@grobian> ah
-<13.03.2012 20:58> <+dberkholz> how about the 3rd?
-<13.03.2012 20:58> <@hwoarang> id prefer 3rd
-<13.03.2012 20:59> <@grobian> fine with me
-<13.03.2012 20:59> <@Betelgeuse> I can be in Pacific time but probably still works
-<13.03.2012 20:59> <@Betelgeuse> It should be ok time there too
-<13.03.2012 20:59> <@ulm> both 3 and 17 are o.k. for me
-<13.03.2012 20:59> <+dberkholz> that'll be 1pm pacific, it's fine generally speaking
-<13.03.2012 20:59> <@jmbsvicetto> I might be busy with the Hospital, but for the next month or so I won't know right until the meeting time
-<13.03.2012 21:00> <@Betelgeuse> jmbsvicetto: so no difference been 3rd and 10th?
-<13.03.2012 21:00> <@jmbsvicetto> no
-<13.03.2012 21:00> <+dberkholz> jmbsvicetto: gonna have a proxy on standby, then?
-<13.03.2012 21:00> <@jmbsvicetto> nor 17th likely
-<13.03.2012 21:00> <@jmbsvicetto> dberkholz: yeah, I'll try to get someone for next meeting
-<13.03.2012 21:00> <@Chainsaw> First Tuesday of the month is normally a linux user group meeting for me, but if that date works best I'll move it.
-<13.03.2012 21:01> <@grobian> ok, so 3rd it will be?
-<13.03.2012 21:01> <@ulm> seems so
-<13.03.2012 21:01> <@hwoarang> ok
-<13.03.2012 21:01> <@Betelgeuse> ok
-<13.03.2012 21:02> <@jmbsvicetto> Betelgeuse: btw, thanks for calling me. We have terrible coverage at the hospital, for now. That's why you didn't caught me
-<13.03.2012 21:02> <@ulm> start at 19:00 UTC because of DST?
-<13.03.2012 21:02> <@grobian> ulm: ok
-<13.03.2012 21:02> <+dberkholz> i just moved it to the 3rd in the google calendar
-<13.03.2012 21:02> <@Betelgeuse> ulm: ok
-<13.03.2012 21:02> <@hwoarang> ok
-<13.03.2012 21:02> <+dberkholz> sure, 1900 is fine
-<13.03.2012 21:02> <@jmbsvicetto> sure
-<13.03.2012 21:02> -!- ulm changed the topic of #gentoo-council to: Next meeting: April 3rd, 19:00 UTC | Meeting chairs: http://www.gentoo.org/proj/en/council/#doc_chap5 | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
-<13.03.2012 21:03> <@Betelgeuse> Did we have a practise on writing summaries. Presumably I'll post one?
-<13.03.2012 21:03> <@grobian> I'll send call for items next week then
-<13.03.2012 21:03> <@grobian> hmmm, if I have wireless reception then...
-<13.03.2012 21:03> <@Betelgeuse> Thanks everyone and see you next time.
-<13.03.2012 21:03> <@grobian> ulm: mind sending the call yourself, next tuesday?  I'll be in the middle of knowhere
-<13.03.2012 21:04> <@Betelgeuse> grobian: atd?
-<13.03.2012 21:04> <@grobian> heh
-<13.03.2012 21:04> <@ulm> grobian: yes, I can do
-<13.03.2012 21:04> <@grobian> I'm not that advanced here
-<13.03.2012 21:04> <@grobian> I edit the emails each time
-<13.03.2012 21:04> <@grobian> ulm: ok, thanks
-<13.03.2012 21:04> <@Betelgeuse> grobian: that's why I said atd instead of crond :)
-<13.03.2012 21:05> <@grobian> too lazy to lookup how mutt is scripted
-<13.03.2012 21:05> <@grobian> ok, thanks for chairing Betelgeuse
-<13.03.2012 21:05> <@jmbsvicetto> Betelgeuse: thanks for chairing the meeting
-<13.03.2012 21:07> <@grobian> jmbsvicetto: I thought you referred to the release building process with the locale thing
-<13.03.2012 21:07> <@Chainsaw> Betelgeuse: Thanking you.
-<13.03.2012 21:07> <@Betelgeuse> no problem
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120403-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20120403-summary.txt
deleted file mode 100644
index b232cdc10a..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120403-summary.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-Summary of Gentoo council meeting 3 April 2012
-
-Roll call
-=========
-Present: betelgeuse, chainsaw, dberkholz, grobian, hwoarang, ulm.
-Missing: jmbsvicetto.
-
-EAPI specification in ebuilds
-=============================
-Discuss/vote which of the proposals should be further pursued and
-worked out in detail:
-  A: Parse bash assignment statement
-  B: Comment in first line of header
-  C: Bash function
-  D: Filename extension (GLEP 55)
-  E: External metadata file
-  F: None, keep status quo
-
-The council members expressed their preference for option A.
-Subsequently, a vote on option A was taken, which has been accepted
-with 5 yes votes and 1 abstention.
-
-Action: Work out exact specification until next meeting (ulm).
-
-New udev and separate /usr partition
-====================================
-Decide on whether a separate /usr is still a supported configuration.
-If it is, newer udev can not be stabled and alternatives should be
-investigated. If it isn't, a lot of documentation will have to be
-updated. (And an alternative should likely still be provided.)
-
-The council has voted in favour of a separate /usr being supported
-(5 yes, 1 no vote).
-
-During the discussion, some concerns were raised that we might not be
-able to provide a modified or forked udev version. Chainsaw assured
-that if necessary, he will maintain a udev version that supports said
-configuration.
-
-It was remarked that a solution that comprises both the forked udev
-version (separate /usr) and the latest versions is possible and
-therefore should not block either way preferred by users.
-
-herds.xml and mail aliases
-==========================
-Should devs be required to add themselves to herds.xml when adding to
-mail alias?
-
-This was rejected by the council (5 no votes).
-
-Open bugs with council involvement
-==================================
-Bug 383467 "Council webpage lacks results for 2010 and 2011 elections":
-Postponed, because jmbsvicetto isn't present.
-
-Bug 408073: "Make the user choose a locale"
-Action: ulm will ping the docs team.
-
-Open floor
-==========
-No issues were brought up to the council by the community.
-
-Next meeting date
-=================
-8 May 2012, 19:00 UTC.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120403.txt b/xml/htdocs/proj/en/council/meeting-logs/20120403.txt
deleted file mode 100644
index 1b4f9fd264..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120403.txt
+++ /dev/null
@@ -1,384 +0,0 @@
-<ulm> Agenda is here:
-      http://archives.gentoo.org/gentoo-project/msg_ac95bed78694852cd09f20a07437b805.xml
-								        [21:01]
-<ulm> Roll call
-<dberkholz> hi
-<grobian> here
-<Chainsaw> Present.
-<dberkholz> fwiw, i've always got logs if nobody else does.
-<hwoarang> hi							        [21:02]
-*** nimiux (~nimiux@gentoo/developer/nimiux) has joined channel
-    #gentoo-council
-<ulm> Betelgeuse, jmbsvicetto?
-<Chainsaw> Do we have phone numbers for the gentlemen in question?      [21:03]
-<ulm> yes							        [21:04]
-<ulm> I'll call them
-<Chainsaw> Thank you.
-<ulm> seems I don't have the right number of betelgeuse		        [21:06]
-<ulm> "number is incomplete"
-<dberkholz> hmm, i might have it. lemme check. it could've been on my stolen
-	    phone						        [21:07]
-<ulm> and only mailbox for jmbsvicetto 
-<hwoarang> the phone numbers should be available in the council@ alias from
-	   June
-<dberkholz> just texted Betelgeuse				        [21:08]
-<Betelgeuse> dberkholz: hello
-<Betelgeuse> dberkholz: thanks for the reminder
-<dberkholz> we're still short by one jorge
-<Betelgeuse> I have a bunch of numbers for him
-<Chainsaw> The coverage at his hospital is supposed to be spotty, so a text is
-	   probably best.					        [21:09]
-*** AdmiralNemo (~dustin.ha@vpn.softekinc.com) has joined channel
-    #gentoo-council
-<Betelgeuse> I got through to one number but a woman responded in Portuguese
-								        [21:11]
-<grobian> lol
-<ulm> we've got a long agenda today, so I suggest that we start	        [21:12]
-<hwoarang> it's been 12' can we start?
-<grobian> Betelgeuse: is that the 4153 one?
-<ulm> EAPI specification in ebuilds
-<Betelgeuse> grobian: xxx xxx 250
-<dberkholz> indeed we do. if i'd noticed the times on that agenda, i would've
-	    said something.
-<Betelgeuse> grobian: 4153 did not connect			        [21:13]
-<Betelgeuse> ulm: agreed
-<grobian> I texted that number
-<ulm> discussion on -dev and the wiki page are linked from the agenda
-*** thrice` (thrice@unaffiliated/thrice/x-000000001) has joined channel
-    #gentoo-council						        [21:14]
-<grobian> ulm: my reponse/input:
-	  http://dev.gentoo.org/~grobian/altEAPImechs.txt
-<dberkholz> so, of methods A-F, i'd be ok with A, B, or E.	        [21:15]
-<hwoarang> A or F for me
-<grobian> F A C							        [21:16]
-<ulm> I'd much prefer B, but A would be o.k. too
-<Chainsaw> As long as we do not attempt D, which has been voted out in the
-	   past...
-<Chainsaw> And with the understanding that F is the preferred option...
-								        [21:17]
-<dberkholz> i suppose F too, but i'd rather see some forward motion even if
-	    the chosen solution has some cons.
-<Chainsaw> Most of the others look good.
-<_AxS_> for clarification -- F is do nothing and ensure that portage depends
-	on an appropriate bash for EAPI=0 ?
-*** thrice` (thrice@unaffiliated/thrice/x-000000001) has left channel
-    #gentoo-council: #gentoo-council
-<ulm> right, F is to do nothing
-<dberkholz> F is basically say this problem isn't important because we haven't
-	    needed it for the past 5 years.
-<grobian> … or we silently broke PMS' restriction of bash version because we
-	  didn't care enough					        [21:18]
-<ulm> Chainsaw: any preferences?
-<Chainsaw> ulm: F please!
-<ulm> Betelgeuse?						        [21:19]
-<Betelgeuse> ulm: D A B C E					        [21:20]
-<grobian> lol
-<Betelgeuse> F
-<Betelgeuse> as in fail
-<Betelgeuse> Anyone know what the status of xattrs is?
-<Betelgeuse> If it's in any way feasible.			        [21:21]
-<grobian> yeah, won't work everywhere
-<dberkholz> ha. that's an idea i was talking about years ago.
-<dberkholz> we'd hate to stop supporting gentoo on aix though. =P
-*** johu (~johu@gentoo/developer/johu) has quit: Quit: No Ping reply in 180
-    seconds.
-<ulm> so, there seems to be preference for options A and F
-*** johu (~johu@gentoo/developer/johu) has joined channel #gentoo-council
-								        [21:22]
-<dberkholz> B also seemed fairly popular
-<grobian> any reason people dislike C?
-<Betelgeuse> dberkholz: it could come in an external file for people without
-	     xattr support
-<ulm> grobian: it's summarised on the wiki page already
-<Betelgeuse> so they pay a small performance penalty
-<grobian> ulm: yeah, but see my link
-<grobian> metadata influences Portage's "ugly die behaviour": users won't see
-	  it							        [21:23]
-<dberkholz> Betelgeuse: yep, that had occurred to me. it is a fun idea, isn't
-	    it?
-<ulm> so, how should we proceed?
-<Chainsaw> I could live with A. B assign meaning to comments without a
-	   shebang.						        [21:24]
-<Chainsaw> And that seems very, very wrong to me.
-<ulm> I could work out a more detailed proposal for option A for the next
-      meeting
-<Chainsaw> But, if I could have F, that would be even better.
-<hwoarang> it seems everyone understand the proposals so I think we are safe
-	   to vote?
-<grobian> the only concensus at the moment is F?
-<hwoarang> seems like most of us have more than one items of preference
-								        [21:25]
-<ulm> A is slightly preferred
-<grobian> I prefer to put the portage team in the loop for their input on some
-	  candidates for the best match (performance, ease of implementation)
-<dberkholz> A seems to be the only one everybody is OK with
-<grobian> say those that would get a council majority vote
-<hwoarang> so basically A					        [21:26]
-<dberkholz> assuming i got this right: http://pastebin.com/35HS216n
-<ulm> grobian: I believe zmedico prefers A
-<Chainsaw> dberkholz: That's helpful, thanks. A looks like a winner then.
-<_AxS_> ulm: by vote (ranking in order), A is the winner with 22, followed by
-	F with 16.						        [21:27]
-<grobian> betelgeuse also was ok with F
-<ulm> _AxS_: yes, I've put it into a Condorcet/Schulze calculator too ;)
-<Chainsaw> So let's move forward. Proposal A, yes/no?
-<_AxS_> ulm: ah.  (i didn't know there was a name for that, i just wrote it
-	out)
-<ulm> A, then F, then B
-* Chainsaw votes yes						        [21:28]
-<ulm> Chainsaw: that's A against F?
-<Chainsaw> ulm: We can only do yes/no votes last I checked.
-<ulm> o.k., let's vote yes/no on A
-<ulm> yes from me
-* Chainsaw votes yes (again)					        [21:29]
-<grobian> A: yes
-<Betelgeuse> Chainsaw: Well we just need to reach a majority in some fashion
-<hwoarang> yes
-<ulm> Betelgeuse: your vote?
-<Betelgeuse> So are we voting on the exact specifics now or just the approach?
-<dberkholz> are we just re-doing everything we just did?
-<Chainsaw> Betelgeuse: Option A. Yes/no?			        [21:30]
-<dberkholz> i would've sworn we just finished saying all the ones we'd be fine
-	    with, and now we seem to be doing it again one at a time
-<Chainsaw> dberkholz: Yes, it is most tedious.
-<ulm> Betelgeuse: exact specifics will follow, but as outlined on the wiki
-      page as of today
-<_AxS_> i think this vote is for official concensus on A
-<Chainsaw> _AxS_: Yes.
-* grobian nods
-<dberkholz> ok, i'm yes on A/B/F, and ping me in 20 minutes when the rest of
-	    you are ready =P
-<Betelgeuse> Chainsaw: neutral					        [21:31]
-<Chainsaw> Betelgeuse: There is no abstaining from a yes or no vote.
-<ulm> I count 5 yes and one abstention
-<Chainsaw> ulm: Not unanimous but sufficient?
-<grobian> ok, so we're on schedule now
-<Chainsaw> grobian: Yes, that agenda is bang on.		        [21:32]
-<ulm> that's sufficient I guess
-<hwoarang> yes it is
-<ulm> so I hope we'll have the exact specifics (PMS patch) ready for the next
-      meeting
-<Betelgeuse> Chainsaw: I guess depending on how you look at it could be
-	     counted as no.
-<Betelgeuse> Chainsaw: But I don't think you must say anything.	        [21:33]
-<grobian> ulm: make it an action point
-<ulm> grobian: k
-<ulm> next topic
-<ulm> New udev and separate /usr partition
-<ulm> Chainsaw: Do you want to comment on this?
-<Chainsaw> Indeed. In my opinion, a separate /usr partition has been a
-	   supported configuration for a very long time and should remain so.
-<Chainsaw> You will have seen a statement by Jaco Kroon, who admins an order
-	   of magnitude more Gentoo servers than me.		        [21:34]
-<Chainsaw> We are both in the same predicament, in that we have LVM2 systems
-	   with /usr separate, as per the official guide.
-<Chainsaw> I do not feel that the new udev should be allowed to have stable
-	   keywords unless it is capable of handling a separate /usr in a
-	   graceful fashion.
-<Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough?
-								        [21:35]
-<Chainsaw> For the avoidance of doubt, I do not contest the unmasking, nor the
-	   ~amd64 keyword on it.
-<_AxS_> ... point of order on the agenda, regarding the conclusion about what
-	would occur if /usr will remain supported ....  udev can go stable if
-	a means of supporting /usr-on-separate partition (via initramfs or
-	other) is a possibility, no?
-<ulm> Chainsaw: separate /usr, as in separate /usr without an initramfs?
-<Chainsaw> Betelgeuse: No. That is additional work for a clearly broken
-	   package.
-<dberkholz> here's the thing
-<dberkholz> who's going to either "port" udev as necessary, or maintain an old
-	    version forever?					        [21:36]
-<dberkholz> we can't proclaim things like this from on high without a route
-	    forward
-<Chainsaw> I will keep an old version going until the end of time.
-<hwoarang> if udev is moving that way, we can't stay 'old' forever
-<dberkholz> what happens when kernel 3.6 no longer supports it?
-<Chainsaw> Then dev(tmp)fs will win.
-<ulm> or static /dev as in the old times ;)			        [21:37]
-<dleverton_> As a point of interest, does anyone know exactly what changed in
-	     udev to stop /usr from working?
-<hwoarang> given that udev is going to be merged to systemd, this discussion
-	   may render moot
-<dberkholz> i was just about to mention that.
-<ulm> dleverton_: IIUC it depends on programs in /usr now	        [21:38]
-<dleverton_> Unconditionally?
-<Chainsaw> I never thought I'd speak out in favour of openrc...
-<Chainsaw> But I will use openrc over systemd any day.
-<_AxS_> ...there's a fair bit of talk on this issue, and from more than just
-	gentoo.  If gentoo took the stance of definitely not sticking with
-	upstream (and probably forking udev), i think that there would be
-	support for this.
-<ulm> dleverton_: /usr/bin/udevadm
-<Chainsaw> And to confirm, if that means "Chainsaw maintains udev in Gentoo"
-	   and "point at Chainsaw if you disagree", I can live with that.
-								        [21:39]
-<dleverton_> OK
-<grobian> Chainsaw: that makes a change, and probably you can find people that
-	  support you
-<Chainsaw> grobian: I have jkroon on my team. We can handle Asterisk.   [21:40]
-<Chainsaw> grobian: I am sure we can handle udev too.
-<ulm> Chainsaw++						        [21:41]
-<hwoarang> what do udev maintainers think about this?
-<grobian> Chainsaw: I mean, it's hard to say something must remain supported
-	  if there is no people doing that, so if you back it, I'm happy to
-	  support you
-<Chainsaw> grobian: I will do what it takes, on company time.	        [21:42]
-<Chainsaw> grobian: Expect an Asterisk-style patchset on top of what upstream
-	   does to tame it into reasonable behaviour.
-<grobian> Yes, separate /usr should remain supported
-<ulm> so, should we have a vote on it in this meeting?		        [21:43]
-<grobian> ^^^ my vote
-<Chainsaw> ulm: I think we should.
-<ulm> or postpone it?
-<hwoarang> postpone it for what?
-<Chainsaw> ulm: Because if we postpone it, there is time for udev to be
-	   stabled under "it's been 30 days!" conditions.
-<_AxS_> the discussion we just have about udev is somewhat aside from the
-	issue.  It would be pertinent, i think to vote on continuing to
-	support separate /usr or not
-<ulm> o.k., then please vote yes/no
-<Betelgeuse> yeah we should at least delay udev going stable
-<grobian> could either flesh out building the "separate /usr" team, or vote
-	  now assuming it will happen
-<Betelgeuse> As long as there is no automated help for people to automatically
-	     get initramfs I vote yes				        [21:44]
-<Chainsaw> Separate /usr is a supported configuration. I vote yes.
-<dberkholz> umm
-<hwoarang> i vote no, because diverting from upstream is not an ideal option
-	   for me						        [21:45]
-<dberkholz> i'm fine with supporting that in the sense that older udevs could
-	    be maintained forever
-<dberkholz> but i'm not ok with never stabling new versions
-<Chainsaw> That isn't the question though dberkholz.
-<grobian> this is not about stabling packages
-<Chainsaw> The question is whether separate /usr is a supported configuration.
-<ulm> The question is: "Decide on whether a separate /usr is still a supported
-      configuration."
-<Chainsaw> If it is, then stabling udev and "the hell with you LVM2 weirdos"
-	   is no longer an option.				        [21:46]
-<ulm> as in the agenda
-<dberkholz> and my vote is conditional on this not blocking stabilization of
-	    new udev
-<dberkholz> as long as the other configuration is somehow supported
-<Chainsaw> dberkholz: Whilst you can't have it both ways...
-<grobian> you could make a profile				        [21:47]
-<Chainsaw> dberkholz: My plan is to patch reasonable behaviour back into udev,
-	   and going with the upstream releases as long as it is feasible.
-<dberkholz> sure i can. maintain old udev-XXX forever, put an elog in new udev
-	    that says "if you want separate /usr without initramfs, block old
-	    udev or whatever
-<dberkholz> err, install old udev, mask new
-<grobian> do it's masked/unmasked there
-<Chainsaw> dberkholz: That is the python 3 disaster all over again. *NO*
-<dberkholz> well, i want new crap, and i don't want to wait around for custom
-	    gentoo ports all day. that is why we do vanilla.
-<dberkholz> fork udev into a different package name then	        [21:48]
-<Chainsaw> dberkholz: Then put it back under package.mask and go nuts.
-<zmedico> yeah, use a virtual
-<dberkholz> we already have a device-manager virtual
-<zmedico> problem solved :)
-<dberkholz> dev-manager
-<ulm> anyway, including another yes from me, I count 4 yes and 1 no     [21:49]
-<grobian> so this seems to be able to be solved, apart from the question
-	  whether or not separate /usr  is supported
-<ulm> which is a majority
-<_AxS_> there are ways to provide support for /usr with a newer udev; again,
-	the stabilization of udev (in the long term) should not really be an
-	issue with this vote, should it?
-<Chainsaw> _AxS_: It does not block newer udev from being stabled in the long
-	   term.
-<Chainsaw> _AxS_: It just blocks stabling with a some armwaving about
-	   initramfs generators over in the corner there.	        [21:50]
-<Chainsaw> (Which is going to happen. Sorry for my lack of trust in people,
-	   but it will)
-<_AxS_> *nod*.  right.  ok, well ulm closed voting so i'll go back to my
-	corner.
-<ulm> _AxS_: we should make sure that there's reasonable documentation about
-      setting up an initramfs though
-<_AxS_> ulm: oh yes -- i was figuring the solution on how to support separate
-	/usr with new udev would be tabled at the mext meeting (if necessary)
-<grobian> ok, next?						        [21:51]
-<ulm> dberkholz: should I count you as an abstention for the last vote?
-<Chainsaw> _AxS_: I would recommend raising the implementation details for
-	   next meeting, yes.
-<dberkholz> ulm: nah, i'm for it.				        [21:52]
-<dberkholz> the implementation details are my concern, but that's not the
-	    vote.
-<ulm> o.k., that's 5 yes 1 no then
-<ulm> has anyone further comments on this topic?
-<Chainsaw> dberkholz: My immediate concern is the prevention of stabling by
-	   stealth, which is now done. We can agree further work offline.
-								        [21:53]
-<Chainsaw> As in, outside of this meeting. Let's move on.
-<ulm> next topic
-<ulm> herds.xml and mail aliases
-<grobian> answer: no						        [21:54]
-<hwoarang> no
-<ulm> I think that has been more or less answered on the ml already
-<dberkholz> if this is even a question, that means it should be automated.
-<ulm> no from me, too
-<Chainsaw> No.
-<Betelgeuse> no
-<Chainsaw> (It's a laudable goal, but it will not work this way.)       [21:55]
-<ulm> so obviously no majority, at least not for the way it has been proposed
-								        [21:56]
-<ulm> I guess we can move on
-<ulm> Open bugs with council involvement
-<ulm> bug 383467						        [21:57]
-<willikins> ulm: https://bugs.gentoo.org/383467 "Council webpage lacks results
-	    for 2010 and 2011 elections"; Website www.gentoo.org, Projects;
-	    CONF; hwoarang:jmbsvicetto
-<ulm> jmbsvicetto isn't present, so I guess we won't get an answer on this one
-<grobian> answer is probably: ETOOBUSY :)
-<ulm> anyone has comments about this bug?
-<ulm> seems not to be the case					        [21:58]
-<ulm> bug 408073
-<willikins> ulm: https://bugs.gentoo.org/408073 "Make the user choose a
-	    locale"; Documentation, Installation Handbook; CONF;
-	    betelgeuse:docs-team
-<dberkholz> sounds like we need to heckle cam.
-<dberkholz> ulm, wanna ping on the bug?				        [21:59]
-<ulm> can do
-<Chainsaw> Okay, so when we will we meet again?
-<hwoarang> Betelgeuse: can we please have the logs + summary from the last
-	   meeting? It's been a month and it does not look good	        [22:00]
-<dberkholz> well, we finally did something interesting this time, so it's
-	    worth posting the logs more speedily =)
-<ulm> Chainsaw: May 8th?
-<dberkholz> may 8 is more or less fine for me, with the caveat that my next
-	    baby's due date is may 7.				        [22:01]
-<Betelgeuse> hwoarang: yeah I will do it when this meeting wraps up.
-<Chainsaw> May 8 works well for me, yes please.
-<hwoarang> thanks a lot
-<Betelgeuse> hwoarang: sorry about it and thanks for reminding me
-<grobian> ulm: May 8th ok
-<ulm> who's chair for next month?
-<grobian> jmbsvicetto:
-<grobian> I don't mind doing it for him				        [22:02]
-<ulm> k
-<grobian> I suspect he'll be busy still
-<hwoarang> grobian: you probably want to get in touch with him
-<ulm> grobian: let him comment by e-mail
-<hwoarang> in case he wont make it, lets be prepared
-<grobian> yup
-<grobian> I'll be just his stand in
-<grobian> send him an email and such
-<ulm> tahnks							        [22:03]
-<ulm> so, open floor
-<Chainsaw> The mics are on guys & gals.
-<Chainsaw> Share your thoughts.
-<grobian> deafening silence					        [22:04]
-<_AxS_> ... not much to say, all the big stuff was covered already      [22:05]
-<ulm> then let's close the meeting
-<ulm> thanks to all of you, it was very efficient this time
-<Chainsaw> *big hammer* *BANG*
-<Chainsaw> Very civilised as well.
-<grobian> thanks for chairing ulm				        [22:06]
-<Chainsaw> Even got the results I wanted. Thank you all.
-<dberkholz> thx
-*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
-    "Next meeting: May 8th, 19:00 UTC | Meeting chairs:
-    http://www.gentoo.org/proj/en/council/#doc_chap5 |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 |
-    http://www.gentoo.org/proj/en/council/"			        [22:07]
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120508-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20120508-summary.txt
deleted file mode 100644
index fb7349e5a4..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120508-summary.txt
+++ /dev/null
@@ -1,122 +0,0 @@
-Council 2012/05/08 meeting summary
-==================================
-
-
-Agenda
-------
-
- * Introduction and roll call (5 minutes)
- * EAPI specification in ebuilds [2] (20 minutes)
-
-   1. Vote on final PMS wording [3] (discussion [4])
-   2. Vote to change the status of GLEP55 [5]
-
- * Separate /usr partition vote of last meeting (20 minutes)
-
-   Following the vote about Gentoo supporting separate /usr
-   installations in the last meeting, the mls became active
-   about the meaning and consequences of such vote.
-   William made a direct request to the council to review the
-   vote [6].
-
- * Review of the council term (10 minutes)
-
-   Roy suggested [7] the council members do a review of their
-   mandate in the last meeting before the election.
-
- * Open floor
-
- [1] - http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900
- [2] -
-http://archives.gentoo.org/gentoo-project/msg_e6eafd6be25794ca503e0ac9d6968cd3.xml
- [3] -
-http://archives.gentoo.org/gentoo-pms/msg_3a441be5e49cc06689ecab00da461278.xml
- [4] -
-http://archives.gentoo.org/gentoo-pms/msg_ef7635aa655913f2386e64e385f5a6ae.xml
- [5] - http://www.gentoo.org/proj/en/glep/glep-0055.html
- [6] -
-http://archives.gentoo.org/gentoo-project/msg_5a3e7a62abc3f6f529cbb18d85f2fbcf.xml
- [7] -
-http://archives.gentoo.org/gentoo-project/msg_0e09e374488d2393c6cf794e349dc614.xml
-
-
-Meeting
--------
-
- * roll call
-
-    here:
-
-    Betelgeuse (late)
-    chainsaw
-    dberkholz
-    grobian
-    hwoarang
-    jmbsvicetto
-    ulm
-
- * vote/discuss:
-
-   * EAPI specification in ebuilds
-
-     * Vote on final PMS wording
-
-       The council approved with 6 yes votes the final PMS wording as submitted on
-       http://archives.gentoo.org/gentoo-project/msg_e6eafd6be25794ca503e0ac9d6968cd3.xml
-
-     * Vote to change the status of GLEP55
-
-       The council approved with 6 yes votes to change the status of GLEP55 to rejected.
-       Per Ulrich's suggestion, the GLEP status heading will be changed to "the council
-       rejected this GLEP in its 2012-05-08 meeting in favor of parsing the EAPI from
-       the first non-blank and non-comment line of ebuilds.
-
-
-    * Separate /usr partition vote of last meeting
-
-      Following the discussions in the dev and project threads about the last meeting
-      vote on the separate /usr partition as well as the thread on this meeting's agenda,
-      the council members agreed that as Tony stated "sufficient understanding & agreement
-      has been built on the mailing lists".
-
-
-    * Review of the council term
-
-      As suggested by Roy, the council members did a review of this council term.
-      Tony remarked he feels this council did particularly well on attendance. Fabian
-      collected his thoughts on http://dev.gentoo.org/~grobian/achievements-council-1112.txt
-      Donnie suggests having fewer rotating chairs and have them do a few meetings in
-      a row to improve efficiency. Jorge also noted that picking chairs in advance
-      does help getting meetings prepared. Several members argued be prepared is very
-      important. Petteri noted council members should be proactive and Jorge noted how
-      work got a toll on his time for council duties.
-      Donnie was bothered by the "red tape" and the amount of time council spent on issues
-      that weren't really up to it. He also maintains the believe that innovations should
-      be pushed by individuals and that the council should do everything to quickly get out
-      of the way.
-   
-
-    * Open bugs with council involvement
-
-      * bug 383467
-
-        Jorge noted this bug was his and that the council voting results are already available
-        at the elections page http://www.gentoo.org/proj/en/elections/council/ . He also promised
-        to complete the conversion of the 2005 nominees file, fix the master ballot for last year
-        election as noted by Ulrich, to drop http://www.gentoo.org/proj/en/council/#doc_chap9
-        and link back to the elections page.
-
-      * bug 411069
-
-        Ulrich argued the council shouldn't be CC'ed on this bug and as other council members
-        agreed this isn't a council issue, the council has been removed from CC of this bug.
-
-
- * next meeting:
-
-   Tuesday, 20120612 1900 UTC
-
-
- * open floor:
-
-   No issues were brought to the council attention.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120508.txt b/xml/htdocs/proj/en/council/meeting-logs/20120508.txt
deleted file mode 100644
index 9565fce177..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120508.txt
+++ /dev/null
@@ -1,237 +0,0 @@
-19:02 -!- jmbsvicetto changed the topic of #gentoo-council to: meeting: now - agenda: http://archives.gentoo.org/gentoo-dev-announce/msg_f360c5b4fc50c6a3238f403475db6479.xml | Meeting chairs: http://www.gentoo.org/proj/en/council/#doc_chap5 | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
-19:02 <@jmbsvicetto> roll-call
-19:02  * Chainsaw would just like to confirm that he is present, on time and without any phone calls
-19:02 <@ulm> here
-19:02 <+dberkholz> .
-19:03 <@jmbsvicetto> here
-19:03 <@grobian> here
-19:03 <@jmbsvicetto> hwoarang: ping
-19:03 <@hwoarang> im here
-19:04 <@jmbsvicetto> Let's wait 2 more minutes for Betelgeuse. I'll call him if he doesn't show up
-19:04 <@grobian> ok
-19:05 <@jmbsvicetto> any comments about the agenda?
-19:05 <@grobian> agenda is ok
-19:06 <@Chainsaw> It is agreeable. Let's proceed.
-19:06 <@jmbsvicetto> I'm calling Betelgeuse
-19:06 <@jmbsvicetto> He says he'll be joining us in a couple minutes
-19:07 <@jmbsvicetto> so let's start
-19:07 < _AxS_> jmbsvicetto: re agenda - review of open bugs?
-19:07 <@jmbsvicetto> 2. EAPI specification in ebuilds
-19:07 <@jmbsvicetto> _AxS_: true, I left that out
-19:07 <@jmbsvicetto> _AxS_: we'll address that before open floor
-19:07 <@jmbsvicetto> Are we ready to vote in the final PMS wording?
-19:07 <@grobian> yup
-19:08 <@ulm> wording is here: http://archives.gentoo.org/gentoo-project/msg_e6eafd6be25794ca503e0ac9d6968cd3.xml
-19:08 <+dberkholz> sounds good to me.
-19:09  * Chainsaw votes yes
-19:09 <@jmbsvicetto> I vote yes
-19:09 <@hwoarang> sounds good
-19:09 <@grobian> I vote yes
-19:09 <@jmbsvicetto> hwoarang / dberkholz / ulm: your vote?
-19:09 <+dberkholz> 19:08 < dberkholz+> sounds good to me.
-19:10 <@hwoarang> i said it sounds good to me
-19:10 <@ulm> of course yes
-19:10 <@jmbsvicetto> so 6 yes votes
-19:10 <+dberkholz> when you ask whether we're ready to vote without asking us to actually vote, it can be a little confusing.
-19:10 <@jmbsvicetto> Shall we vote to change the status of GLEP55?
-19:10 <@ulm> pushed ;)
-19:10 <@grobian> jmbsvicetto: yes, let's vote
-19:10 <@jmbsvicetto> dberkholz: yes
-19:10 <@jmbsvicetto> So how do you vote?
-19:11 <@grobian> jmbsvicetto: ask for our vote
-19:11 < NeddySeagoon> change it to what ?
-19:11 <@jmbsvicetto> ok, let me rephrase
-19:12 <@ulm> NeddySeagoon: I have propose to change its status to rejected
-19:12 <@ulm> *proposed
-19:12 <@hwoarang> i agree
-19:12 <@jmbsvicetto> Vote: Should we change the status of GLEP55 to rejected?
-19:12 < _AxS_> NeddySeagoon: starting at 'If the EAPI ...' and continuing to '... these values are different'
-19:12 <@hwoarang> jmbsvicetto: yes
-19:12 <@jmbsvicetto> yes
-19:12  * Chainsaw votes that GLEP55 is to be rejected, so, yes
-19:12 <@ulm> yes
-19:12 <+dberkholz> re-JEC-ted
-19:12 <@grobian> eapi pms wording: vote yes
-19:13 <@grobian> glep 55 reject: vote yes
-19:13 <@jmbsvicetto> so the motion was approved with 6 yes votes
-19:13 -!- Betelgeuse [~betelgeus@gentoo/developer/Betelgeuse] has joined #gentoo-council
-19:13 -!- mode/#gentoo-council [+o Betelgeuse] by ChanServ
-19:13 <@jmbsvicetto> 3. Separate /usr partition vote of last meeting
-19:13 <@Betelgeuse> osrry guys
-19:13 <@ulm> do we need to agree on a short sentence for that glep's status line?
-19:13 <@Betelgeuse> All parking lots for my building were taken
-19:14 <@jmbsvicetto> Betelgeuse: we just finshed voting for point 2. yes to the pms wording and yes to reject GLEP55
-19:14 <@jmbsvicetto> ulm: do you have any proposal?
-19:15 <+dberkholz> my understanding was that the status line was predefined to be one of the available statuses at the bottom of the glep page.
-19:15 <@ulm> "Status: The council rejected this GLEP in its 2012-05-08 meeting in favor of parsing the EAPI from the first non-blank and non-comment line of ebuilds."
-19:15 <@ulm> dberkholz: usually there's a short Status section
-19:16 <@ulm> see glep 49 or 50 for example
-19:16 <@grobian> I can agree with ulm's status line
-19:16 <@hwoarang> so do i
-19:16 <+dberkholz> oh, i thought you were referring to the other status section in the header.
-19:16 <+dberkholz> that's not confusing at all =P
-19:16 <@jmbsvicetto> I agree with the proposal
-19:17 <+dberkholz> that's fine, i don't think we need to even vote on it.
-19:17 <+dberkholz> but whatever
-19:17 <@jmbsvicetto> we should also add a history note about it having been rejected before
-19:17 <@jmbsvicetto> but I'll leave that for the GLEP editors to address
-19:17 <@jmbsvicetto> so, shall we move to point 3?
-19:18 <@ulm> well, probably we don't need a formal vote on it
-19:18 <@Chainsaw> Yes please.
-19:18 <@grobian> yes plese
-19:18 <@jmbsvicetto> Separate /usr partition vote of last meeting 
-19:18 <@jmbsvicetto> WilliamH / dberkholz / grobian / Chainsaw: is there anything left to address at this meeting?
-19:18 <@Chainsaw> I believe sufficient understanding & agreement has been built on the mailing lists.
-19:18 <@grobian> my current understanding is there there are no more questions on this topic
-19:18 <+dberkholz> seems like the busybox thing has addressed the concerns i saw.
-19:18 < WilliamH> It seems that agreement has been built to me also. I brought
-19:19 <@Chainsaw> i.e. I much prefer "option 2" and WilliamH much prefers "option 1", but we both agree that both solutions are valid.
-19:19 < WilliamH> Chainsaw: agreed, either option should work well for users now, and we have documentation for how to make initramfs if folks want to go that way.
-19:20 <@jmbsvicetto> In that case, shall we move to point 4?
-19:20 <@Chainsaw> Please do.
-19:20 <@grobian> yes please
-19:20 <@jmbsvicetto> Does anyone want to do a review of this council's term?
-19:20 <@jmbsvicetto> Let me just add a quick note that next month we will have the election for the next council
-19:20 <@Chainsaw> I believe we did particularly well on attendance this year.
-19:20 <@grobian> NeddySeagoon: mine's here: http://dev.gentoo.org/~grobian/achievements-council-1112.txt
-19:21 <@Chainsaw> With regards to slacker marks, appointing of proxies, meetings going ahead as planned, etc.
-19:21 < NeddySeagoon> pass on 'lessons learned' for the new council - if any
-19:21 <+dberkholz> i'd recommend that we have fewer rotating chairs, and have them do a few meetings in a row to improve efficiency.
-19:21 <@ulm> certainly it helps if everyone is well prepared for the meetings
-19:22 <@grobian> dberkholz: nod
-19:22 <@hwoarang> when does the nomication period start?
-19:22 <@ulm> which generally was the case in this council's term
-19:22 < NeddySeagoon> grobian, thank you
-19:22 <@Betelgeuse> jmbsvicetto: HAasn't the new council usually started in July?
-19:22 <@Betelgeuse> So we would still meet in June.
-19:22 <@jmbsvicetto> picking chairs in advance helps getting meetings prepared
-19:22 <@Chainsaw> Yes, be prepared is a great life motto.
-19:22 <@hwoarang> Betelgeuse: the elections were always in june
-19:22 <@Betelgeuse> hwoarang: elections != first meeting
-19:22 <@hwoarang> yes we do have one more meeting
-19:22 <@jmbsvicetto> Betelgeuse: sure, but the election takes place next month
-19:22 <+dberkholz> two things that particularly bothered me were the apparent desire for lots of bureaucratic handwaving as well as spending council times on things that weren't really our call
-19:23 <@Betelgeuse> Of course it doesn't matter if we skip the monthly meeting
-19:23 < NeddySeagoon> Betelgeuse, yes - June is your last meeting
-19:23 <@Betelgeuse> as there will any way be a new council
-19:23 <@Betelgeuse> Any way for review what I have been doing is that I have been mostly reactive and a good council member would be proactive.
-19:24 <@Betelgeuse> In some discussions anyw ay
-19:24 < NeddySeagoon> Betelgeuse, the new council should take over in early July.  July 4th actually
-19:24 <@jmbsvicetto> One thing that hit me this term was free time - the move of the hospital sucked most of my life - much more than what I was already expecting
-19:24 <@Chainsaw> dberkholz: Bureaucracy is a bad thing. Can you call out the red tape so it can be cut?
-19:24 <@hwoarang> yeah two months without meeting is too much i guess
-19:24 <@jmbsvicetto> It also prevented me from being chair when I had planned to and led to me missing my first meeting
-19:24 < _AxS_> ...so, council meeting and then vote meeting?
-19:24 <+dberkholz> Chainsaw: one example that stands out in my mind is doing an official roll call after everyone on the council has already spoken since the meeting's start time
-19:25 <+dberkholz> not a big time sink, but it made me want to punch a hole in the wall
-19:25 <@Chainsaw> dberkholz: Yes, that could just be "I see we're all here, moving on".
-19:25 < NeddySeagoon> waiting 5 minutes after there is a quorum
-19:25 <@ulm> dberkholz: when was that the case?
-19:25 <@Chainsaw> dberkholz: Hope it wasn't my meeting.
-19:25 <@jmbsvicetto> _AxS_: the council voting isn't done through a meeting
-19:25 < _AxS_> jmbsvicetto: ah. nvm
-19:25 <@grobian> I like the roll-call, makes it nicely explicit
-19:26 <+dberkholz> that said, if that's the biggest complaint, we don't seem to have major issues
-19:26 <@jmbsvicetto> just to let you guys know, I've decided I won't run for another term and plan instead to run the next council election
-19:26 <+dberkholz> i continue to believe that innovations in gentoo should be pushed by individuals, and the council should do everything we can to quickly get out of their way
-19:26 <+dberkholz> with *quickly* being the key point, especially in the case of gleps
-19:27 <@Chainsaw> jmbsvicetto: What? But who would place the phone calls?
-19:27 <@hwoarang> yeah council is sort of a bottleneck
-19:27 <@jmbsvicetto> Chainsaw: I'm sure we can find someone to do that ;)
-19:27 <@Betelgeuse> jmbsvicetto-bot
-19:28 <+dberkholz> i mean, we really have no excuse for the whole glep 55 issue. that's been what, like 4 years?
-19:28 <@jmbsvicetto> :P
-19:28 <@ulm> dberkholz: yeah, this really sucks
-19:28 <@Chainsaw> dberkholz: We've said no twice now. I'm sure it'll stick.
-19:28 <@Betelgeuse> I fealt like there weren't that many agenda items in general. Not necessarily a bad thing but maybe people were not submitting everything that could have been.
-19:29 <@ulm> that's why I pushed it so vehemently
-19:29 <@jmbsvicetto> dberkholz: iirc, it was rejected 2 times before. But if you mean the time it took to approve an alternative, then I agree
-19:29 <+dberkholz> Chainsaw: i mean the problem being solved by it, not the specific implementation in the glep
-19:29 <@Betelgeuse> jmbsvicetto: rejeted 2 times?
-19:29 <@Betelgeuse> jmbsvicetto: one time was a tie
-19:29 <@jmbsvicetto> Betelgeuse: my memory has failed me then
-19:30 <@Betelgeuse> I should have brought it for a revote quickly though
-19:30 <@Betelgeuse> To get an actual opinion
-19:30 < NeddySeagoon> Betelgeuse, maybe it means things were resolved among the devs - no arbitration needed
-19:30 <@Betelgeuse> NeddySeagoon: I don't think it was in this case
-19:31 <@Betelgeuse> There's no consensus to this day either
-19:31 < NeddySeagoon> Betelgeuse, in the case of GLEP 55 - thats true
-19:31 <@jmbsvicetto> NeddySeagoon: One thing that looking back I regret is that the council didn't solve the whole python3 issue quickly
-19:31 <@jmbsvicetto> I spent much more time as a devrel member on that, than as a council member.
-19:32 <@grobian> jmbsvicetto: disagree
-19:32 < NeddySeagoon> jmbsvicetto, how would you help another council to avoid that mistake?
-19:33 <@jmbsvicetto> NeddySeagoon: I feel that in trying not to get involved on specific issues (at least I as a council member was trying to do that), the council didn't realize or valued the impact that had in the whole distro and community
-19:34 <@hwoarang> you can't really realize that unless you are really involved in the development
-19:34 <@hwoarang> i mean really *daily* development
-19:35 <@hwoarang> observing a distro from the far top is not the ideal way to understand this sort of problems
-19:35 <@jmbsvicetto> NeddySeagoon: so in my case I'd say the balance between letting issues be sorted by individual teams and trying to have a common ground in the distro / community wasn't attained in this case
-19:35 < NeddySeagoon> Thats the 10 minutes on this topic ... thank you
-19:36 < NeddySeagoon> unless you want to add more of course
-19:36 <@jmbsvicetto> anyone has anything else left to say?
-19:36 <+dberkholz> we have 9 gsoc students this year, doing all kinds of cool stuff.
-19:36 <@Chainsaw> I think we did well. Vote for us.
-19:37 <@hwoarang> hopefully this year we make use of the gsoc projects
-19:37 < NeddySeagoon> Chainsaw, no comment as I may be an election official again
-19:37 <@jmbsvicetto> Thank you Donnie and Alec for your work on GSoC
-19:37 <@grobian> ok, can we do open bugs/open floor?
-19:37 <@jmbsvicetto> let's move on
-19:37 <@Chainsaw> Let's do bugs first then please.
-19:38 <@Chainsaw> What do we have?
-19:38 <@jmbsvicetto> can one of you please list the bugs? Unfortunately I don't have access to bugzilla from work
-19:38 <@jmbsvicetto> (I refuse to accept a "forged" certificate)
-19:38 <@ulm> bug 383467 and bug 411069 only
-19:38 < willikins> ulm: https://bugs.gentoo.org/383467 "Council webpage lacks results for 2010 and 2011 elections"; Website www.gentoo.org, Projects; CONF; hwoarang:jmbsvicetto
-19:38 <@jmbsvicetto> ok, the first one is mine
-19:39 <@jmbsvicetto> as you can check on http://www.gentoo.org/proj/en/elections/council/ we already have the votes there
-19:39 <@jmbsvicetto> voting results*
-19:39 < _AxS_> willikins: bug 411069 is?
-19:39 < willikins> _AxS_: https://bugs.gentoo.org/411069 "Portage shouldn't check $EAPI to get the EAPI"; Portage Development, Core - Ebuild Support; CONF; ciaran.mccreesh:dev-portage
-19:40 <@ulm> jmbsvicetto: the "master ballot" for the last election isn't the master ballot
-19:40 <@jmbsvicetto> I need to convert an html page to xml from 2005 and will try to convert the results page to something along http://www.gentoo.org/proj/en/elections/trustees/2008/foundation-200802.xml
-19:40 <@jmbsvicetto> ulm: thanks, I'll fix that
-19:41 <@jmbsvicetto> So, if you're happy with the current result, I plan to drop http://www.gentoo.org/proj/en/council/#doc_chap9 from the council page and link to the election's page instead
-19:41 <@ulm> yes, please do
-19:41 <@jmbsvicetto> unless there's any objection, I'll take care of that tonight
-19:42 <@jmbsvicetto> !bug 411069
-19:42 < willikins> jmbsvicetto: https://bugs.gentoo.org/411069 "Portage shouldn't check $EAPI to get the EAPI"; Portage Development, Core - Ebuild Support; CONF; ciaran.mccreesh:dev-portage
-19:42 <@jmbsvicetto> anything left to do on this one?
-19:42  * ulm doesn't think the council should be CCed on this one
-19:43 < _AxS_> is this part of what agenda item #2 covered?
-19:43 <@ulm> _AxS_: no, it's a different issue
-19:44 <@jmbsvicetto> ulm: so should we remove ourselves from that bug?
-19:44 <@ulm> I'd say so. leave it to Zac
-19:45 < _AxS_> ulm: ..the decision affects it tho; the use case they present is no longer valid, since inherit can't be prior to eapi now ..?
-19:45 <@ulm> as it's a very technical issue and only affects few cases
-19:45 <@ulm> _AxS_: yes, part of it isn't relevant any more
-19:46 <@jmbsvicetto> Betelgeuse / Chainsaw / grobian / hwoarang / dberkholz: any comments?
-19:46 <@Chainsaw> jmbsvicetto: Don't see work for us to do.
-19:46 <@grobian> I tend to think it's not a council issue at the moment
-19:46 <@hwoarang> we shouldnt be there anymore
-19:47 <@jmbsvicetto> ulm: please remove us from the bug then
-19:47 <@ulm> done
-19:47 <@jmbsvicetto> 5. Open floor
-19:47 <@jmbsvicetto> Does anyone have any issues for the council to look at?
-19:48 <@Betelgeuse> interesting case in that bug
-19:51 <@jmbsvicetto> I'll wait 5 more minutes before closing the meeting
-19:51 <@hwoarang> just to be clear. are we having a meeting next month?
-19:51 <@jmbsvicetto> yes
-19:52 <@hwoarang> ok
-19:52 <@jmbsvicetto> hwoarang: you're the apppointed chair
-19:52 <@grobian> when?
-19:52 < NeddySeagoon> you should even with the election in progress
-19:52 <@jmbsvicetto> Tuesday, June 12th 1900 UTC is the predefined date
-19:52 <@grobian> ok
-19:52 <@hwoarang> is there an ETA for the nomination/election period?
-19:53 <@jmbsvicetto> hwoarang: I'll talk to Roy and other interested election officials about it and send an email to the dev ml this week
-19:54 <@hwoarang> jmbsvicetto: thank you
-19:54 <@grobian> meeting closed?
-19:54 <@jmbsvicetto> 2 - 15 (nomination) and 17 - 30 (voting) are the likely dates
-19:55 <@jmbsvicetto> yes
-19:55  * jmbsvicetto closes the meeting
-19:55 <@grobian> ok, thanks for chairing jmbsvicetto
-19:55 -!- nelchael [~nelchael@gentoo/developer/nelchael] has quit [Quit: Backups? We doan *NEED* no steenking baX%^~,VbKx NO CARRIER]
-19:55 <@hwoarang> thanks jmbsvicetto
-19:55 < NeddySeagoon> jmbsvicetto, that works for me
-19:55 <@Betelgeuse> thanks
-19:55 <@ulm> thanks
-19:55 -!- jmbsvicetto changed the topic of #gentoo-council to: next meeting: June 12th 1900 UTC | Meeting chairs: http://www.gentoo.org/proj/en/council/#doc_chap5 | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120612-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20120612-summary.txt
deleted file mode 100644
index 557c2b1168..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120612-summary.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Council 2012/06/12 meeting summary
-==================================
-
-
-Agenda
-------
-
- * Introduction and roll call (5 minutes)
- * Use $@ to append extra arguments to the "default" function in src_configure and src_install
-   for EAPI5
-
- * Open floor
-
- [1] - http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900
- [2] -
- http://archives.gentoo.org/gentoo-dev/msg_920c6d6daafe7702bfa3b8a2bc21e0c1.xml
-
-Meeting
--------
-
- * roll call
-
-    here:
-
-    Betelgeuse
-    a3li (proxy for chainsaw)
-    grobian
-    hwoarang
-    jmbsvicetto
-    ulm
-	
-	missing:
-	dberkholz
-
- * vote/discuss:
-
-   * Use $@ to append extra arguments to the "default" function in
-     src_configure and src_install functions
-
-	The council believes that $@ is not the ideal way to pass extra arguments
-	to the default function. It was deciced to either introduce new variables
-	for that purpose or do nothing about this and ask developers to
-	re-implement the "default" function if they need to pass extra arguments.
-	This will be pushed back to the gentoo-dev mailing list.
-
- * next meeting:
-
-   Will be decided by the new council
-
-
- * open floor:
-
-   No issues were brought to the council attention.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120612.txt b/xml/htdocs/proj/en/council/meeting-logs/20120612.txt
deleted file mode 100644
index dd2d4b226d..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120612.txt
+++ /dev/null
@@ -1,147 +0,0 @@
-[20:01:20] <hwoarang> !time
-[20:01:20] <willikins> hwoarang: Europe - London - Tue Jun 12 20:00 BST
-[20:01:39] <hwoarang> jmbsvicetto grobian ulm dberkholz Betelgeuse a3li
-[20:01:40] <hwoarang> ping ^
-[20:01:46] <grobian> hwoarang: pong
-[20:01:46] <hwoarang> who's here
-[20:01:47] <ulm> pong
-[20:02:22] <jmbsvicetto> pong
-[20:02:27] <jmbsvicetto> I'm here
-[20:02:45] <jmbsvicetto> I poked Betelgeuse on #-devrel a few minutes ago and
-he didn't reply, so we might need to call him
-[20:03:32] <hwoarang> seems like we miss quite a few people
-[20:03:46] <jmbsvicetto> a3li: ping
-[20:04:28] <jmbsvicetto> I'm calling Betelgeuse
-[20:04:58] <a3li> jmbsvicetto: hi
-[20:05:06] <grobian> jmbsvicetto: thx
-[20:05:42] <jmbsvicetto> He should show up soon
-[20:05:55] <hwoarang> good
-[20:05:57] <grobian> good, allows me to make a pot of tea ;)
-[20:05:59] <hwoarang> we still miss dberkholz
-[20:06:20] <hwoarang> i'll wait 4' more minutes (till 20:10) and then move on
-[20:10:47] <Betelgeuse> hello
-[20:10:54] <Betelgeuse> Sorry about the delay
-[20:10:59] <grobian> just in time (tm)
-[20:11:05] <Betelgeuse> My 4G stick had trouble getting an address
-[20:11:11] <hwoarang> !time
-[20:11:12] <willikins> hwoarang: Europe - London - Tue Jun 12 20:10 BST
-[20:11:18] <hwoarang> ok time to begin
-[20:11:34] <hwoarang> agenda:
-http://archives.gentoo.org/gentoo-project/msg_affe2989c83112c5b08dcd77226790fa.xml
-[20:12:40] <hwoarang> ssuominen proposed to allow extra arguments to default
-src_configure and src_install for EAPI5
-[20:12:44] <hwoarang> if I understand correctly.
-[20:13:17] <grobian> to "default" in src_configure and src_install
-[20:13:50] <hwoarang> yes
-[20:13:52] <ulm> I'm against it. phase functions don't take arguments
-[20:14:07] <grobian> I've already expressed my feelings, and it hasn't changed
-much
-[20:14:33] <grobian> I don't like things like "default -j1"
-[20:14:47] <hwoarang> if everyone has a clear head in the topic, this seems
-like a straight yes/no voting
-[20:14:54] <a3li> same for me (and chainsaw). it doesn't feel right to call it
-'default' and then make it parametrized
-[20:14:56] <grobian> without proper specification I'm against it anyway
-[20:15:05] <hwoarang> I am in favor of samuli's proposal fwiw
-[20:15:27] <hwoarang> grobian: what do you mean by proper specification?
-[20:15:32] <hwoarang> i think it is pretty clear
-[20:15:40] <hwoarang> make default understand $@
-[20:15:44] <grobian> hwoarang: do default -j1 is ok to you?
-[20:15:51] <hwoarang> so whatevery you pass to default it will be appended
-[20:16:12] <ulm> it's not natural what would be the meaning of $@ e.g. in
-src_install
-[20:16:13] <grobian> what do the arguments mean in the future when src_install
-and src_configur change?
-[20:16:25] <grobian> ^^ what ulm said
-[20:16:29] <hwoarang> grobian: i will save some bytes than having to
-re-implement src_install { emake -j1 install } for example
-[20:16:33] <ulm> $@ could be passed to emake, or to dodoc
-[20:16:45] <Betelgeuse> I would solve the problem with additional variables
-[20:16:54] <ulm> Betelgeuse: yeah
-[20:16:57] <jmbsvicetto> I agree with Betelgeuse
-[20:17:05] <hwoarang> ulm: i think it is obvious that the arguments would be
-passed to emake calls
-[20:17:05] <grobian> hwoarang: just make it explicit, don't introduce lots of
-vagueness because of saving a few bytes
-[20:17:07] <hwoarang> and econf 
-[20:17:21] <grobian> hwoarang: then why not call it emake and econf?
-[20:17:30] <hwoarang> becaue you like the default bits
-[20:17:34] <hwoarang> you just need some extra stuff
-[20:17:35] <jmbsvicetto> instead of allowing anything to be passed to the
-phase function, create some sensible variables that can be used to alter the
-default behaviour
-[20:17:41] <grobian> anyway, enough, this is discussion that should go on ML
-[20:18:03] <grobian> now jmbsvicetto is going to get to something which gets
-closer to a spec
-[20:18:07] <hwoarang> yeah but we need to give some hints what to discuss
-[20:18:17] <hwoarang> to from what I can tell $@ is not acceptable
-[20:18:23] <hwoarang> and the majority wants new variables
-[20:18:24] <grobian> hwoarang: honestly, the whole initial thread was full of
-hints
-[20:18:26] <hwoarang> is that correct?
-[20:18:51] <jmbsvicetto> hwoarang: econf_opts / emake_opts / einstall_opts ?
-[20:18:58] <hwoarang> grobian: yes but i believe we need to give a direction
-[20:19:04] <hwoarang> of what *we* think it is appropriate
-[20:19:06] <hwoarang> as a solution
-[20:19:10] <hwoarang> jmbsvicetto: that looks ok to me
-[20:19:14] <ulm> EMAKE_INSTALL_EXTRA_ARGS ;)
-[20:19:14] <_AxS_> would it make sense at this point to vote (down) the
-allowance of $@ (aka parameters) in src_compile/src_install ?
-[20:19:41] <hwoarang> _AxS_: no because $@ does not make sense anyway at this
-point
-[20:19:48] <_AxS_> ah ok.
-[20:19:50] <hwoarang> default does not understand $@ from what I can tell
-[20:19:55] <hwoarang> so doesnt matter if you use it
-[20:20:34] <hwoarang> fair enough. I will make a comment on the bug and ML
-thread, that using suitable variables is preferred
-[20:20:38] <hwoarang> everybody ok with this ^^
-[20:20:39] <grobian> hwoarang: perhaps it would help if there was a strong
-usecase that really showed the use of allowing arguments
-[20:21:20] <a3li> hwoarang: personally, I guess I'd go with "don't use default
-if you need to change things"; but that's better than default <stuff>
-[20:21:36] <grobian> hwoarang: perhaps you/samuli is just looking for an extra
-phase to be introduced
-[20:22:05] <grobian> src_makeinstall + src_install
-[20:22:10] <Betelgeuse> a3li: Experience with java eclasses showed that it's
-bitter if all similar logic goes through eclasses
-[20:22:24] <Betelgeuse> a3li: It was a big pain to introduce anything new when
-all was copy pasted
-[20:22:28] <jmbsvicetto> hwoarang: anyway, it's something for the next council
-to decide
-[20:22:33] <ulm> Betelgeuse: "bitter"?
-[20:22:39] <hwoarang> grobian: i dont think so. Jus trying to use "default"
-for weird build systems that DESTDIR alone may not make sense
-[20:22:40] <Betelgeuse> better
-[20:22:43] <Betelgeuse> sorry
-[20:23:01] <_AxS_> ulm: everything is bitter when talking about java pkgs :)
-[20:23:17] <a3li> Betelgeuse: so if you have a common digression from the
-'default', you have an eclass to abstract it there. or do I miss the point?
-[20:23:27] <grobian> hwoarang: yeah, so just override it with src_makeinstall
-to emake install bla=foo, then src_install does the dodoc stuff etc.
-[20:23:45] <hwoarang> grobian: and what about src_configure?
-[20:23:58] <Betelgeuse> a3li: There's been variables and hooks to provide for
-that
-[20:24:15] <grobian> that usecase is even weaker, and I really think you
-should be just typing econf again
-[20:24:43] <ulm> hwoarang: src_configure calls econf only, so you say "econf
-<foo>" instead of "default <foo>"
-[20:24:52] <ulm> it's even shorter
-[20:24:58] <a3li> and has better semantics
-[20:25:01] <hwoarang> ok
-[20:25:02] <ulm> and much clearer if you read it
-[20:25:05] <grobian> yup
-[20:25:10] <grobian> no magic implied
-[20:25:14] <grobian> s/no/less/
-[20:25:57] <jmbsvicetto> So are we ready to move on?
-[20:26:06] <hwoarang> ok to sum up: no $@ for default, push back to ML and
-give "new variables" or "new phase between src_configure and src_install"
-[20:26:17] <hwoarang> and let discussion goin
-[20:26:25] --> nimiux (~nimiux@gentoo/developer/nimiux) has joined
-#gentoo-council
-[20:27:00] <hwoarang> moving on
-[20:27:09] <hwoarang> *Open floor*
-[20:27:16] <hwoarang> anyone want to discuss something?
-[20:27:32] -*- hwoarang looks around
-[20:27:37] <Betelgeuse> I want to know why there's still no ice craem machine?
-[20:28:08] <jmbsvicetto> I just want to thank you guys. It was a pleasure to
-work with all of you
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120724-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20120724-summary.txt
deleted file mode 100644
index 1082c0fa77..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120724-summary.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Summary of Gentoo council meeting 24th July 2012
-
-Roll call
-=========
-betelgeuse (via sms)
-chainsaw
-grobian
-ulm
-scarabeus
-
-absent
-------
-dberkholz
-williamh (isp trouble)
-
-
-Introduction for new council members
-====================================
-A brief introduction for the new members on the council meetings.
-Standard ingredients council meeting: roll call, open bugs, open
-actions, open floor.
-Council members can introduce themselves to the others if they like to,
-and possibly outline their their goals and intentions for this term
-briefly.
-
-Chainsaw presented his general targets.
-
-
-Votes for modus operandi of this council
-========================================
-- vote for holding meetings every 2nd Tuesday of the month at 2000 UTC
-  (or 1900 UTC depending on daylight savings)
-  5 votes in favour (betelgeuse, chainsaw, grobian, ulm, scarabeus)
-- vote for continuing last council's workflow considering sending call
-  for agenda items (2 weeks in advance), sending the agenda (1 week in
-  advance) and have the meeting focussed, e.g., have major discussions
-  on -project ML prior to the meeting
-  4 votes in favour (chainsaw, grobian, ulm, scarabeus)
-- appoint chairman for this term's meetings, for continuity grobian
-  volunteers to fill up a few slots in a row
-  14th August     grobian
-  11th September  ulm
-   9th October    grobian
-  13th November   grobian
-  11th December   grobian
-  4 votes in favour (chainsaw, grobian, ulm, scarabeus), the next chairs
-  should be picked at the December meeting
-
-
-Open floor
-==========
-No issues were brought up to the council.
-
-
-Next meeting date
-=================
-14 August 2012, 19:00 UTC
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120724.txt b/xml/htdocs/proj/en/council/meeting-logs/20120724.txt
deleted file mode 100644
index 0637fc32ab..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120724.txt
+++ /dev/null
@@ -1,189 +0,0 @@
---- Log opened Tue Jul 24 19:45:10 2012
-19:45 -!- grobian [~grobian@gentoo/developer/grobian] has joined #gentoo-council
-19:45 -!- Irssi: #gentoo-council: Total of 42 nicks [2 ops, 0 halfops, 1 voices, 39 normal]
-19:45 -!- mode/#gentoo-council [+o grobian] by ChanServ
-19:45 -!- Irssi: Join to #gentoo-council was synced in 34 secs
-19:46 <@  grobian> I hope freenode won't keep disconnecting me on ipv6
-20:00 -!- ulm [~ulm@gentoo/developer/ulm] has joined #gentoo-council
-20:00 -!- mode/#gentoo-council [+o ulm] by ChanServ
-20:01 -!- grobian changed the topic of #gentoo-council to: meeting today: 2012-07-24 19:00 UTC | Meeting chair: grobian | agenda: http://dev.gentoo.org/~grobian/agenda-20120724.txt | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
-20:13 -!- WilliamH [~william@gentoo/developer/williamh] has quit [Ping timeout: 240 seconds]
-21:00 <@  grobian> anyone here?
-21:01 <@  grobian> Betelgeuse ulm ulm_ dberkholz scarabeus
-21:01 <@      ulm> here
-21:01 <@  grobian> I'm not sure if my correction came through correctly with everyone
-21:02 <@  grobian> I sent 20:00 UTC originally
-21:02 *** ulm has received it
-21:02 <@  grobian> williamh is trying to get here too
-21:03 <@  grobian> don't know about tony, he said it was fine with him
---- Log closed Tue Jul 24 21:05:36 2012
---- Log opened Tue Jul 24 21:06:42 2012
-21:06 -!- grobian [~grobian@gentoo/developer/grobian] has joined #gentoo-council
-21:06 -!- Irssi: #gentoo-council: Total of 42 nicks [3 ops, 0 halfops, 1 voices, 38 normal]
-21:06 -!- mode/#gentoo-council [+o grobian] by ChanServ
-21:06 <@  grobian> bah
-21:06 <@  grobian> got disconnected myself
-21:07 -!- Irssi: Join to #gentoo-council was synced in 35 secs
-21:07 <@  grobian> did anyone but you show up ulm?
-21:09 <@      ulm> nope :(
-21:09 <@  grobian> ok, good start then :/
-21:10 *** ulm is searching for phone numbers
-21:13 < scarabeus> i had a lag
-21:13 < scarabeus> sorry
-21:13 <@  grobian> ah, cool
-21:13 -!- Chainsaw [~chainsaw@gentoo/developer/chainsaw] has joined #gentoo-council
-21:13 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
-21:13 <@      ulm> I've phoned tony
-21:13 <@  grobian> and another one
-21:14 <@ Chainsaw> Argh.
-21:14 <@  grobian> nice!
-21:14 <@ Chainsaw> So sorry.
-21:15 <@      ulm> Petteri tells me that he can answer stuff by sms only
-21:15 <@      ulm> whatever that means
-21:15 <@  grobian> lol
-21:15 <@  grobian> ok
-21:15 < scarabeus> no net i suppose
-21:15 < scarabeus> :D
-21:15 < scarabeus> so ask him for votes on the items at least :P
-21:16 <@  grobian> we basically vote for doing the stuff the same as last term
-21:16 <@ Chainsaw> Agreed for second tuesday of every month.
-21:16 <@ Chainsaw> That works well for me.
-21:16 < scarabeus> wfm too
-21:16 <@ Chainsaw> Workflow, that's a yes, it seemed to work well last term.
-21:17 <@  grobian> Chainsaw: you're on the agenda now?
-21:17 <@  grobian> http://dev.gentoo.org/~grobian/agenda-20120724.txt
-21:17 < scarabeus> he is FAST :D
-21:17 <@      ulm> only mailbox for dberkholz
-21:17 <@ Chainsaw> grobian: Yeah. Just looking what you need votes for.
-21:17 <@ Chainsaw> I can do an introduction if anyone doesn't know me of course.
-21:17 <@ Chainsaw> (If you haven't all gone "oh it's the anti-systemd dude")
-21:17 <@  grobian> ulm: no number either
-21:17 <@  grobian> let's give william some more minutes?
-21:18 <@  grobian> I think we can do the rest quite quick
-21:18 *** Chainsaw nods
-21:18 <@      ulm> grobian: four council members are present, so at least we avoid a re-election :-/
-21:19 < scarabeus> that would be pretty lame start we can say
-21:19 <@  grobian> is there anyone who wants to do chairing in upcoming meetings?
-21:19 <@  grobian> ulm: yeah...
-21:20 <@      ulm> I could do august or september
-21:20 <@ Chainsaw> We need jmbsvicetto and his address book.
-21:20 <@ Chainsaw> He seemed to have numbers for everyone.
-21:20 <@ Chainsaw> (Although... fair play for knowing my landline number. I didn't give that out much)
-21:21 <@  grobian> ulm: I'm likely not available 1th of september, so I'd need replacement for that one
-21:22 <@  grobian> so, to conclude: betelgeuse is unavailable at the moment, dberkholz unknown, williamh has no internet
-21:22 <@      ulm> Chainsaw: I have this ...18 number from you and another ...15 (work?)
-21:22 <@ Chainsaw> ulm: Yeah, both work numbers end in 15.
-21:23 <@ Chainsaw> ulm: And 18 is the landline I actually use. There's another, but I need an Asterisk server before I can use that in earnest.
-21:23 <@  grobian> shall we just start?
-21:24 <@ Chainsaw> Could wait 6 more minutes and start 20:30?
-21:24 <@  grobian> sure
-21:24 <@  grobian> let's do that
-21:25 <@      ulm> yes, let's give williamh a few more minutes
-21:25 <@  grobian> would be nice indeed, he's the real newbee, if I'm not mistaken
-21:27 <@      ulm> grobian: above, by "1th of september" you mean 11th?
-21:27 <@  grobian> yeah
-21:27 <@  grobian> sorry
-21:27 <@      ulm> I could take the chair for that one
-21:28 <@  grobian> next dates are 14th August, 11th September, 9th October, 13th November, 11th December
-21:28 <@  grobian> as it looks now, I could take them all, except september
-21:28 <@  grobian> that should give a proper start
-21:29 <@  grobian> so we can reevaluate next year
-21:30 <@      ulm> shouldn't we rotate the chair as we used to do?
-21:30 <@      ulm> grobian: not that I would mind you doing all the work ;-)
-21:30 <@  grobian> I suggested to have a couple in a line, because that makes it easier
-21:30 < scarabeus> i think it is better to have one guy do it or switch them after few
-21:30 <@  grobian> I think it's easier to fo it properly
-21:30 <@  grobian> easier to do it proper if you do it a couple of times in a row
-21:31 <@  grobian> I think four should be ok
-21:32 <@  grobian> ok, let's start?
-21:33 <@ Chainsaw> Okay, go.
-21:33 <@      ulm> yep
-21:33 <@  grobian> scarabeus: do you want an introduction?
-21:33 <@  grobian> see agenda http://dev.gentoo.org/~grobian/agenda-20120724.txt
-21:33 < scarabeus> nah
-21:33 < scarabeus> i was already council :-)
-21:34 <@  grobian> ok, is there anyone that wants to say something, announce some goals or whatelse?
-21:34 <@ Chainsaw> I aim to keep breakage out of the tree where I can.
-21:34 <@ Chainsaw> And stand up for those that run production servers on Gentoo.
-21:35 <@ Chainsaw> (My dislike of overlays & systemd remains firmly in place, yes)
-21:35 <@  grobian> lol
-21:35 <@  grobian> ok, so we can finish the introduction thing, right?
-21:35 <@ Chainsaw> Think so, unless you want my life story?
-21:35 <@  grobian> nope
-21:36 <@  grobian> please
-21:36 <@  grobian> no!
-21:36 <@  grobian> ok, I'd like some quick votes now
-21:36 <@ Chainsaw> Aw, and I had the full powerpoint loaded up.
-21:36 <@ Chainsaw> Okay then.
-21:36 <@ Chainsaw> Second tuesday of every month? In favour!
-21:36 < scarabeus> '+1
-21:36 <@      ulm> yes
-21:36 <@  grobian> please vote for 2nd tuesday, 19:00 UTC
-21:37 <@ Chainsaw> grobian: I vote yes.
-21:37 <@  grobian> brilliant
-21:37 <@      ulm> betelgeuse has texted to me that 19 UTC is fine for him on every day
-21:38 <@  grobian> ok, now please vote for sending call for agenda 2 weeks in advance, agenda 1 week, and (new) the summary afterwards to -project
-21:38 <@ Chainsaw> grobian: Yes on workflow.
-21:38 <@      ulm> yes
-21:38 < scarabeus> +1
-21:38 <@  grobian> do we all agree, we include betelgeuse via sms/text?
-21:38 < scarabeus> it is fine if it does not violate the glep
-21:38 <@  grobian> questionable
-21:39 <@  grobian> ok, sorry, back to the workflow vote
-21:39 <@ Chainsaw> I don't think it says anything about an attendee also proxying.
-21:39 <@  grobian> ok workflow: all yes
-21:39 *** ulm is not sure if he can actually follow
-21:39 <@  grobian> let me restart
-21:39 <@      ulm> s/he/betelgeuse/
-21:39 <@  grobian> ah
-21:39 <@ Chainsaw> Yes, from scratch. Introductions?
-21:40 <@  grobian> Chainsaw: NO! I won't let you do your powerpoint thing!
-21:40 <@  grobian> Chainsaw: :P
-21:40 <@ Chainsaw> Aw :(
-21:40 < scarabeus> "Hello, I am Tom and I am adddicted to..."
-21:40 <@  grobian> sorry guys
-21:40 <@  grobian> back to votes
-21:40 <@  grobian> I recorded betelgeuse's vote vor 2nd tuesdays
-21:40 <@  grobian> I have 4 votes in favour for the workflow
-21:41 <@  grobian> so what's left is the chairing, I volunteered to do the first bit
-21:41 <@  grobian> result is in the updated agenda
-21:41 <@  grobian> is that ok with you?
-21:42 < scarabeus> yup enjoy your post
-21:42 <@      ulm> fine
-21:42 < scarabeus> next chair should be picked on your last one
-21:43 <@  grobian> Chainsaw: ?
-21:44 <@ Chainsaw> grobian: I am fine with you chairing meetings. You seem quite good at it :)
-21:44 <@  grobian> thank you for the trust :)
-21:44 <@  grobian> ok, can we conclude this topic then?
-21:44 <@ Chainsaw> By all means. Do we have any open bugs left?
-21:44 <@  grobian> I thought we closed
-21:44 <@      ulm> who's going to update the list of chairs on the council's web page?
-21:44 <@  grobian> but I'd have to check
-21:45 <@      ulm> bug 383467 is still open
-21:45 < willikins> ulm: https://bugs.gentoo.org/383467 "Council webpage lacks results for 2010 and 2011 elections"; Website www.gentoo.org, Projects; CONF; hwoarang:jmbsvicetto
-21:45 <@  grobian> I suggest we go through the normal cycle of bugs and open issues at next meeting
-21:46 <@  grobian> ulm: I'll update it
-21:46 <@      ulm> good
-21:46 <@      ulm> it's currently commented out in the xml source
-21:46 <@  grobian> saw that
-21:47 <@  grobian> ok, open floor, anyone wants to raise some issue?
-21:47 <@ Chainsaw> Not everyone at once please.
-21:47 < scarabeus> (that apply to you non-council guys too)
-21:47 < scarabeus> :P
-21:47 <@ Chainsaw> Form an orderly queue. The microphone is now on.
-21:48 <@  grobian> ok, gentlemen
-21:48 <@  grobian> please reload the agenda once again, and tell me if you agree with its contents
-21:49 <@  grobian> then I'll shoot it in right away
-21:49 <@ Chainsaw> I'm mentioned. Neat!
-21:49 < scarabeus> Chainsaw: be happy there aint no photos
-21:49 <@ Chainsaw> scarabeus: Probably for the best.
-21:49 <@  grobian> Chainsaw: I removed the "the chair denied Chainsaw to present his life by powerpoint slides"
-21:49 <@ Chainsaw> grobian: Approved as a true record of what was discussed.
-21:49 <@ Chainsaw> grobian: Your loss.
-21:50 <@      ulm> grobian: agenda is fine
-21:50 < scarabeus> grobian: it is perfect
-21:50 <@  grobian> very nice
-21:50 <@  grobian> then thank you all for being here
-21:50 <@  grobian> let's close this meeting
-21:50 <@ Chainsaw> I would like to thank ulm for my reminder phone call.
-21:50 <@      ulm> yw
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120814-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20120814-summary.txt
deleted file mode 100644
index 5baaa99757..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120814-summary.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Summary of Gentoo council meeting 14th August 2012
-
-Roll call
-=========
-betelgeuse
-chainsaw
-grobian
-scarabeus
-ulm
-williamh
-
-absent
-------
-dberkholz (receives slacker mark)
-
-
-EAPI5 features
-==============
-Due to holidays, the list of features for EAPI5 was announced only 2
-days in advance of the meeting.  This gave little time for Council
-members to prepare for votes.
-Therefore a vote was conducted if voting on EAPI5 features in this
-meeting was deemed suitable.
-
-The Council voted unanimously to postpone voting on EAPI5 features.
-
-The list of features for EAPI5 were outlined by ulm in
-http://thread.gmane.org/gmane.linux.gentoo.project/2101/focus=2115
-Since many of these features appear not to be implemented in Portage, a
-discussion on their implementation is called for by the Council.  The
-Council stressed that it prefers to vote on EAPI5 features that can and
-will be implemented within a short timeframe, say 1 month.
-
-
-Open bugs with Council involvement
-==================================
-There are currently no open bugs.
-
-
-Open floor
-==========
-scarabeus suggested the change "dev should use latest eapi when bumping"
-to "dev must use latest eapi when bumping if not forbidden by eclasses".
-He was asked to bring it up on the mailing lists, to get a better
-definition of when what EAPI should be used.
-
-ulm raised deprecation of EAPI 1 on request of patrick.  Arfrever argued
-that backwards compatability is not an issue here, and that it can
-greatly reduce code size/maintenance of eclasses when EAPI0 and EAPI1
-are removed.  It was questioned whether removal of an EAPI really brings
-that much benefits.  It seems eclasses can drop support for EAPIs, if
-all consumers don't use them, which does not require complete removal of
-the EAPI.  It appears some packages use build-systems that require
-EAPI1.
-
-
-Next meeting date
-=================
-11 September 2012, 19:00 UTC
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120814.txt b/xml/htdocs/proj/en/council/meeting-logs/20120814.txt
deleted file mode 100644
index 3ce8b450ff..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120814.txt
+++ /dev/null
@@ -1,172 +0,0 @@
-21:00 <@  grobian> dah, ok, I started roll call
-21:00 -!- grobian changed the topic of #gentoo-council to: meeting now | agenda: http://dev.gentoo.org/~grobian/agenda-20120814 | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
-21:01 <@Betelgeus> \o/
-21:01 <+scarabeus>   |
-21:01 <+scarabeus> damn
-21:01 <  WilliamH> I'm here.
-21:01 <@ Chainsaw> Present.
-21:01 <@  grobian> yeah, only ulm and dberkholz are missing
-21:01 <@  grobian> so let's wait a bit
-21:01 <@ Chainsaw> ulm was here earlier.
-21:01 <@ Chainsaw> Perhaps we can give him a call?
-21:02 <@Betelgeus> I can
-21:02 <@ Chainsaw> It is appreciated.
-21:02 <@      ulm> here
-21:02 <@  grobian> good
-21:02 <@ Chainsaw> Just dberkholz then.
-21:02 <@Betelgeus> then call donny
-21:03 <@  grobian> right
-21:03 <@  grobian> let's wait 2 more minutes
-21:03 <@ Chainsaw> I don't have numbers I'm afraid.
-21:03 <@Betelgeus> Went into some weird google voice answering machine
-21:03 <@ Chainsaw> Just the ones that replied to the posting this year.
-21:04 <@ Chainsaw> Betelgeuse: Well, thanks for trying all the same.
-21:04 <@  grobian> yeah, much appreciated
-21:05 <@Betelgeus> donnie gets a slacker mark right?
-21:05 <@  grobian> yup
-21:05 <@  grobian> ok, people, we have only one item
-21:05 <@ Chainsaw> EAPI5?
-21:05 <@  grobian> if you haven't yet, please load the agenda (see topic)
-21:06 <@  grobian> so, there's two things from my point of view
-21:06 <@  grobian> the original idea was to vote on items for EAPI5 that are ready to go NOW
-21:06 <@ Chainsaw> I am opposed to having EAPIs in flux. So we can vote now on making what's ready EAPI5.
-21:06 <@  grobian> however, the extensive list that ulm sent out needs some thorough research, of which I did a bit, included in the agenda
-21:06 <@ Chainsaw> Or we can postpone.
-21:06 <@  grobian> so, point one is, do we want to discuss any of it this meeting
-21:07 <@ Chainsaw> Looking at the list, what's ready is... not a long list.
-21:07 <@  grobian> 1 or two entries
-21:07 <@  grobian> with my not-so-thorough research
-21:07 <@  grobian> point 2 would be to vote on the features to be in or out
-21:07 <  WilliamH> My vote would be to postpjone.
-21:07 <@  grobian> but honestly, I'd like to defer
-21:07 <@      ulm> some of the things marked as not implemented are trivial
-21:07 <  WilliamH> postpone
-21:07 <@  grobian> ok
-21:08 <@  grobian> let's vote for postponing the EAPI5 thing
-21:08 <@ Chainsaw> Postpone please.
-21:08 <+scarabeus> I agree we should only pick from those that are ready
-21:08 <@      ulm> yeah, let's postpone it to September
-21:08 <@ Chainsaw> And if the trivial things could then be implemented and marked so that there is a more impressive list...
-21:08 <@ Chainsaw> That would be great.
-21:08 <@  grobian> scarabeus: Betelgeuse what do you vote for?
-21:09 <@  grobian> postpone or handle it now?
-21:09 <@Betelgeus> grobian: postpone but we can use the time to talk about things
-21:09 <+scarabeus> it can be postproned by all means; but we can talk about it
-21:09 <@  grobian> ok
-21:09 <@ Chainsaw> *nod* Sounds fair.
-21:10 <@  grobian> well, that is fine, although I don't feel much need to discuss it here
-21:10 <@  grobian> because it needs some more research  from my side
-21:10 <@  grobian> I'd prefer good follow up's on ML
-21:10 <  WilliamH> Same here.
-21:10 <  Arfrever> You can discuss things already implemented in Portage.
-21:10 <@  grobian> so I suggest to continue the agenda, and then you lot can chat what you want
-21:10 <@  grobian> Arfrever: I'm going to ignore your suggestion here
-21:10 <@  grobian> sorry
-21:11 -!- ulm_ [~ulm@gentoo/developer/ulm] has quit [Ping timeout: 244 seconds]
-21:11 <@  grobian> So, there are no open bugs with council involvement
-21:11 <@  grobian> done
-21:11 <@  grobian> open floor
-21:11 <+scarabeus> I was asked by johu for one thing
-21:11 <@  grobian> anyone (everyone) who wants to raise some issue
-21:11 <@  grobian> Arfrever: if you want, go ahead here
-21:11 *** Chainsaw activates the microphone
-21:12 *** grobian listens
-21:12 <+scarabeus> if we could change "dev should use latest eapi when bumping" to "dev must use latest eapi when bumping if not forbidden by eclasses"
-21:12 <@  grobian> deafening silence
-21:12 <@      ulm> patrick has asked me to bring up deprecation of EAPI 1
-21:12 <@ Chainsaw> scarabeus: I have ebuilds where that's unworkable.
-21:12 <@  grobian> scarabeus: rationale?
-21:12 <@ Chainsaw> scarabeus: Example: net-misc/bird
-21:12 <@      ulm> what's the general opinion about it?
-21:12 <@ Chainsaw> scarabeus: Reason: awkward build sequence.
-21:12 <@ Chainsaw> ulm: Rationale?
-21:12 <@  grobian> ulm: again? wasn't that horse beaten to death already?
-21:12 <@ Chainsaw> ulm: Again, I have ebuilds where it simply can't be done.
-21:12 <@Betelgeus> Chainsaw: new phases could always be no-ops?
-21:13 <@ Chainsaw> Betelgeuse: That sounds incredibly awkward to me.
-21:13 <@ Chainsaw> Betelgeuse: I will, where feasible, bump EAPI on my ebuilds.
-21:13 <@      ulm> he gave no rationale
-21:13 <@ Chainsaw> Betelgeuse: Where it isn't, I don't see adding empty phases as a particularly acceptable workaround.
-21:13 <@      ulm> only a plan
-21:14 <+scarabeus> problem is that quite few devs just cp without checking on it
-21:14 <@      ulm> <bonsaikitten> my plan would be: deprecate eapi1 "now", add repoman warning, make repoman warning fatal in 3 months (not many ebuilds anyway)
-21:14 <@      ulm> <bonsaikitten> then plan to deprecate eapi2 in, say, 6 months
-21:14 -!- kallamej [~kallamej@gentoo/developer/kallamej] has quit [Quit: leaving]
-21:14 *** Chainsaw wonders where this obsession to remove backward compatibility comes from
-21:14 <+scarabeus> -    if( !pResultBitmapEx )
-21:14 <@ Chainsaw> Upgrade paths are going to *suck*.
-21:14 <+scarabeus> http://qa-reports.gentoo.org/output/eapi_usage.txt
-21:14 <+scarabeus> this
-21:15 <+scarabeus> it is 550 pkgs
-21:15 <+scarabeus> and you can see eapi3 is more candidate for killing than eapi2
-21:15 <@ Chainsaw> scarabeus: Yes, net-misc/bird is one of the EAPI1s listed there.
-21:15 <  Arfrever> Let's discuss deprecation of EAPI="0". Any opinions?
-21:15 <@      ulm> was about 800 few months ago
-21:15 <@      ulm> Arfrever: upgrade path
-21:15 <@  grobian> all EAPI=2 can be sedded to EAPI=3
-21:16 <+scarabeus> they are mostly killed with stabilisations
-21:16 <  Arfrever> ulm: All sys-apps/portage ebuilds already use EAPI="2" or EAPI="3".
-21:16 <@  grobian> Arfrever:you can't, so not really a fruitful suggestion , is it?
-21:16 <+scarabeus> I am all for kiling it but it must forbid adding new ebuilds of such eapi, not just stop commit if it is in the folder
-21:16 <@ Chainsaw> Arfrever: Again, obsession with the eradication of backward compatibility. Why?
-21:16 <  Arfrever> Chainsaw: Simplification of eclasses.
-21:17 <@      ulm> Arfrever: not true
-21:17 <  Arfrever> ulm: What is not true?
-21:17 <@      ulm> <Arfrever> ulm: All sys-apps/portage ebuilds already use EAPI="2" or EAPI="3".
-21:18 <@  grobian> scarabeus: I think it would help if you'd flesh this proposal out a bit more, it doesn't sound too bad to me to have a policy to only add new stuff of the latest EAPI, for as long as EAPIs don't have orthogonal features
-21:18 <@      ulm> portage-2.1.6.7_p1.ebuild is still EAPI 0
-21:18 <  Arfrever> ulm: There is no such ebuild in gentoo-x86.
-21:18 <  Arfrever> ulm: OK. grep failed to find it.
-21:19 -!- kallamej [~kallamej@gentoo/developer/kallamej] has joined #gentoo-council
-21:20 <  Arfrever> ulm: Another rationale: Upgrade path is required only for 1 year. EAPI="2" was added long time ago.
-21:20 <@  grobian> scarabeus: and a ML discussion would be a good thing too
-21:21 <+scarabeus> you are right
-21:21 <+scarabeus> johu: start a chat on -project :-)
-21:21 <+scarabeus> delegation at its best
-21:22 <@Betelgeus> no -project?
-21:22 <@Betelgeus> on -dev?
-21:22 <+scarabeus> ah right
-21:22 <  Arfrever> Another item for discussion: What happens when profiles/eapi uses EAPI >=2. I noticed that nothing happens in overlays which use new EAPI.
-21:23 <@  grobian> Arfrever: that sounds like something that should be discussed with people into the subject first
-21:23 <+scarabeus> grobian: about that sed, I would ask diego to run it through tinderbox to see nothing really exploded, ie python eclass change behaviour with each eapi and such tiny funny things
-21:23 <+scarabeus> also I am all hands for blocking additions of new eapi1 ebuilds
-21:23 <@  grobian> scarabeus: I don't see the use of removing EAPIs
-21:24 <@ Chainsaw> scarabeus: Great. Will you be porting my EAPI=1 net-misc/bird then?
-21:25 <@ Chainsaw> scarabeus: And yes, that is a challenge. And no, QA warnings are not acceptable.
-21:25 <@  grobian> I can imagine python eclass not supporting EAPI 0,1,2
-21:26 <@  grobian> but that doesn't mean those eapi's should be banned
-21:26 <@  grobian> an eclass can require its consumers to be using an up-to-date eapi
-21:26 <@  grobian> it's one herd anyway
-21:26 <@ Chainsaw> They were EAPI=4 holdouts for a long time. Seems fine.
-21:28 <@  grobian> ok, can we conclude the open floor with this?
-21:28 <@ Chainsaw> grobian: Just waiting for scarabeus to see the EAPI=1 net-misc/bird conundrum.
-21:28 <@  grobian> Chainsaw: does it matter for the summary?
-21:28 <@  grobian> I guess it does
-21:28 <+scarabeus> Chainsaw: i will ask nic guys to fix build system, simple
-21:29 <@ Chainsaw> scarabeus: Perhaps you speak their language, that may help. I did try.
-21:29 <  Arfrever> Any opinions about handling of icons (*.ico) in dohtml?
-21:29 <@ Chainsaw> scarabeus: (Just like we asked for a Quagga-style telnet multiplexer)
-21:30 <@  grobian> Chainsaw: I did my best to summarise that one
-21:30 <@ Chainsaw> grobian: Okay, thanks :)
-21:31 <@  grobian> good, then I'd like to close the open floor
-21:31 <@ Chainsaw> grobian: Please proceed.
-21:31 <@  grobian> next meeting 11 september
-21:31 <@  grobian> most likely I won't make it
-21:31 <@  grobian> so ulm will be your chairmaster
-21:31 <@      ulm> grobian: your summary says 14 september
-21:32 <@  grobian> sorry, 14 september
-21:32 <@  grobian> yeah
-21:32 <@  grobian> will fic
-21:32 <@  grobian> fixed
-21:32 <@  grobian> 11 ot is
-21:32 <+scarabeus> ack
-21:32 <@  grobian> ok, everybody happy?
-21:32 <@      ulm> 11 is a tuesday, right
-21:32 <@  grobian> I'll send out the editted agenda for review
-21:32 <@  grobian> ulm: yes
-21:33 -!- ivan\ [~ivan@unaffiliated/ivan/x-000001] has joined #gentoo-council
-21:33 <@      ulm> grobian: thank you for chairing
-21:34 <@  grobian> ok, let's close the meeting then
-21:34 -!- Chainsaw [~chainsaw@gentoo/developer/chainsaw] has left #gentoo-council ["Thanks grobian."]
-21:35 -!- grobian changed the topic of #gentoo-council to: next meeting: 2012-09-11 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
-21:35 <@  grobian> thanks all for your delightful input ;)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120911-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20120911-summary.txt
deleted file mode 100644
index 05c16ad222..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120911-summary.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-Summary of Gentoo council meeting 11 September 2012
-
-Roll call
-=========
-betelgeuse
-chainsaw
-dberkholz
-blueness (proxy for grobian)
-scarabeus
-ulm
-williamh (40 minutes late)
-
-EAPI 5 features
-===============
-The council voted on the list of EAPI 5 features. A detailed list was
-sent to the gentoo-project mailing list before the meeting:
-<http://article.gmane.org/gmane.linux.gentoo.project/2140>
-
-Chainsaw remarked that in future a short plain text summary for each
-item should be provided.
-
- * Slot operator dependencies (bug 229521)
- * Sub-slots (bug 424429)
- * Profile IUSE injection (bug 176467)
- * At-most-one-of operator for REQUIRED_USE (bug 354219)
- * EBUILD_PHASE_FUNC variable (bug 390765)
- * Mandate GNU find (bug 384157)
- * new* commands can read from standard input (bug 263565)
- * Parsing of the EAPI assignment is mandatory (bug 402167)
- * src_test support for parallel tests (bug 363005)
- * Stable use forcing and masking (bug 431078)
- * Option --host-root for {has,best}_version (bug 401239)
- * usex helper function (bug 382963)
-
-   - These have been accepted unanimously.
-
- * doheader helper function (bug 21310)
-
-   - Accepted unanimously.
-
- * econf --disable-silent-rules (bug 379497)
-
-   - Accepted unanimously for EAPI 5.
-   - Rejected applying it retroactively to EAPI 4 (0 yes, 4 no, 1 abstain).
-     Therefore, no vote necessary for EAPIs 0 to 3.
-
- * User patches
-
-   - Rejected unanimously for EAPI 5.
-   - Several council members remarked that this is a controversial
-     feature and that it should at least be postponed to a later EAPI.
-
- * License groups in ebuilds (bug 287192)
- * EJOBS variable (bug 273101)
- * Source eclasses only once (bug 422533)
- * Extended default list of extensions in dohtml (bug 423245)
- * REPOSITORY variable (bug 414813)
- * Repository dependencies (bug 414815)
- * Cross-compile support (bug 145737)
- * Directories for use.* and package.* in profiles (bug 282296)
- * make.defaults etc. in ${repository_path}/profiles (bug 414817)
- * HDEPEND: host dependencies for cross-compilation (bug 317337)
-
-   - No support from any council member for any of these in EAPI 5.
-
-Open bugs with council involvement
-==================================
-Bug 383467 "Council webpage lacks results for 2010 and 2011 elections"
-Action: scarabeus will try to make jmbsvicetto do it after next meeting.
-
-Open floor
-==========
-Arfrever suggested weekly meetings of the council. This was met with
-scepticism by council members.
-
-Next meeting date
-=================
-9 October 2012, 19:00 UTC
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20120911.txt b/xml/htdocs/proj/en/council/meeting-logs/20120911.txt
deleted file mode 100644
index f744102352..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20120911.txt
+++ /dev/null
@@ -1,418 +0,0 @@
-<ulm> let's start?						        [21:00]
-*** willikins (~rbot@gentoo/bot/Willikins) has quit: Ping timeout: 245 seconds
-<Chainsaw> Okay!
-<dberkholz> i'm here this time!
-<blueness> yes
-<dberkholz> was on a 3-week vacation during the last one, forgot all about it
-<ulm> anyone logging?
-<Chainsaw> You've been missed Donnie. Glad you made it.
-<blueness> i will be proxying for fabian
-<dberkholz> nothing interesting was happening anyways =)
-<Chainsaw> dberkholz: More fireworks expected for this one, yes. EAPI 5.
-								        [21:01]
-<ulm> betelgeuse, scarabeus, williamh?
-<Chainsaw> scarabeus was here earlier.				        [21:03]
-<scarabeus> i am here
-<Betelgeuse> here
-<ulm> does someone have the phone number of williamh?
-<Chainsaw> Not posted to council ML, sorry. Don't have it.	        [21:04]
-* ulm will try to keep an online summary at
-  http://dev.gentoo.org/~ulm/council-20120911.txt		        [21:05]
-<dberkholz> cool, thanks ulm
-<dberkholz> maybe we should find someone to be a secretary so you don't have
-	    to do that?						        [21:06]
-<ulm> dberkholz: shouldn't be a problem today
-<ulm> I hope so, at least ;)
-<ulm> should we proceed?					        [21:07]
-<blueness> yes
-<ulm> EAPI 5 features						        [21:08]
-<ulm> list is here: http://article.gmane.org/gmane.linux.gentoo.project/2140
-								        [21:09]
-<dberkholz> before we get into the details..
-<ulm> dberkholz: yes?
-<dberkholz> i'd like to propose that anything we can't agree on by the next
-	    meeting should get pushed to 6, and whatever's left on the list,
-	    and implemented in portage, is 5.
-<dberkholz> in the interests of actually getting this out there
-<ulm> dberkholz: o.k., but let's see how it goes		        [21:10]
-<dberkholz> just speaking from past experience with some other EAPIs that have
-	    dragged on for more than a year =)			        [21:11]
-<ulm> I suggest that we vote about the features in the first group en-bloc,
-      and do the rest one by one
-<ulm> except if someone wants to single out additional things from the first
-      group
-<ulm> in fact, I'd like to vote on "econf --disable-silent-rules" and
-      "doheader" separately ;)					        [21:12]
-<blueness> ulm what defines "the first block"?			        [21:13]
-<Chainsaw> I like the --disable-silent-rules for EAPI 5. Just not
-	   retroactively. That is moving the goal posts and invites arbitrary
-	   breakage on remerge.
-<scarabeus> blueness:
-	    http://www.blesk.cz/clanek/zpravy-udalosti/181196/to-je-ale-zradlo-poslanec-radl-ods-ji-rizek-primo-z-lavice-ve-snemovne.html
-<scarabeus> Chainsaw: yeah eapi5+
-<ulm> blueness: see list of eapi 5 features, link in agenda
-<Chainsaw> ulm: What that list is *sorely* missing is... plain text summaries
-	   of the feature.
-<Chainsaw> ulm: I have unified diffs of LaTex (do you expect me to render that
-	   in my head?) or long bug reports.			        [21:14]
-<Chainsaw> ulm: Not ideal.
-<blueness> okay: i'd like to vote for user-patches and licence groups
-	   separately
-<blueness> (or that's in the second group i guess)		        [21:15]
-<Betelgeuse> Also for future reference is the motivation for features listed
-	     somewhere yet?					        [21:16]
-<Chainsaw> Betelgeuse: Vaguely implied in the bug if you're lucky.
-<dberkholz> that should probably go into the devmanual		        [21:17]
-<ulm_> sorry, I had lost connection
-<Chainsaw> Welcome back.					        [21:18]
-*** ulm (~ulm@gentoo/developer/ulm) has quit: Ping timeout: 240 seconds
-*** ulm (~ulm@gentoo/developer/ulm) has joined channel #gentoo-council
-*** ChanServ (ChanServ@services.) has changed mode for #gentoo-council to +o
-    ulm
-<Chainsaw> ulm: Are you able to scroll back or would you like me to repeat my
-	   earlier concern with the list?			        [21:19]
-*** spiros (~andyspiro@gentoo/developer/spiros) has joined channel
-    #gentoo-council
-* ulm is catching up
-<Chainsaw> Okay.
-<ulm> the first vote would be for inclusion of the 12 items listed in
-      http://dev.gentoo.org/~ulm/council-20120911.txt
-<ulm> blueness: user patches and license groups are in the second group
-								        [21:20]
-<blueness> ulm: yes i see that,  i can vote for all of part 1 as a block
-<blueness> when we are ready for the vote
-<ulm> anyone wants to discuss items (out of these 12) separately?       [21:21]
-<ulm> both spec and Portage implementation are ready for all of them
-<ulm> please vote on inclusion of these 12 items in EAPI 5	        [21:22]
-* ulm votes yes
-* blueness votes yes
-<dberkholz> no objections					        [21:23]
-* Chainsaw approves and votes yes
-* scarabeus yep
-<Betelgeuse> yes
-<Chainsaw> (Next time a ~2 sentence summary per item in the list please, so I
-	   don't have to open 12 tabs to find all this out on the day...)
-<Betelgeuse> although can someone repeat what the sub slot stuff is for?
-<ulm> I count 6 yes						        [21:24]
-<ulm> Betelgeuse: most ingenious feature of all of them ;)
-<ulm> will allow us to get rid of revdep-rebuild and preserved libs     [21:25]
-<Arfrever> ulm: You might paste list of features on IRC so that future readers
-	   of log of meeting have no problem with finding what was voted.
-	   (council-20120911.txt might not exist in the future.)
-<ulm> Arfrever: good point
-<Chainsaw> Arfrever: It will. ulm is extremely organised.
-<ulm> * Slot operator dependencies
-<ulm> * Sub-slots
-<ulm> * Profile IUSE injection					        [21:26]
-<dberkholz> only took 3 hours to read through all the emails about it =)
-<ulm> * At-most-one-of operator for REQUIRED_USE
-<ulm> * EBUILD_PHASE_FUNC variable
-<ulm> * Mandate GNU find
-<ulm> * new* commands can read from standard input
-<ulm> * Parsing of the EAPI assignment is mandatory
-<ulm> * src_test support for parallel tests
-<ulm> * Stable use forcing and masking
-<ulm> * Option --host-root for {has,best}_version
-<ulm> * usex helper function
-<ulm> ^^ all accepted unanimously
-<Betelgeuse> ulm: seems I missed part of the diff when reading it previously.
-	     It was clearer reading it again.			        [21:27]
-<ulm> OK, next one is "doheader helper function"
-<ulm> spec and implementation exist
-<ulm> however, this was already proposed for EAPI 3 (then called doinclude)
-<ulm> and the council had rejected it				        [21:28]
-<ulm> link to previous council summary is here:
-      http://www.gentoo.org/proj/en/council/meeting-logs/20090423-summary.txt
-<Chainsaw> Good name, seems clear what it's for. I see no reason not to have
-	   it.							        [21:29]
-<dberkholz> i'll be back in a few ... in case the votes come up, i'm against
-	    retroactively applying anything and the repository stuff (which
-	    may need further discussion)			        [21:30]
-<ulm> Chainsaw: it certainly won't harm :)
-<ulm> the former argument against it was that to many do* functions would
-      confuse new devs
-<Chainsaw> ulm: May have been the inclusion of doexample in the same item that
-	   did it in?
-<ulm> Chainsaw: that's possible					        [21:31]
-<ulm> anyway
-<ulm> please vote on inclusion of doheader in EAPI 5
-* Chainsaw votes Yes
-* ulm votes yes
-<Chainsaw> Betelgeuse?
-* scarabeus ++							        [21:32]
-<ulm> Betelgeuse, blueness?
-<blueness> grobian had some issues with block 2			        [21:33]
-<ulm> blueness: your vote about "doheader"?
-<blueness> oh doheader: yes
-<Betelgeuse> yes
-<Chainsaw> With dberkholz having stepped out, I think that's as many votes as
-	   we are going to get.					        [21:34]
-<ulm> 5 yes 0 no
-<ulm> accepted
-<Betelgeuse> but should note that a common use case in the tree is to install
-	     headers to a subdirectory
-<Betelgeuse> so the usage will probably be marginal
-<ulm> Betelgeuse: yeah
-<ulm> same as for dolib
-<blueness> ulm sorry an emergency just came up, i have to go help my wife
-<blueness> can i give you grobians' wishes?
-<ulm> blueness: yes, please					        [21:35]
-<blueness> i'm so sorry
-<blueness> her car broke down
-<blueness> this is for part 2 -> http://dpaste.com/799573/
-<Chainsaw> blueness: Family always comes first.
-<blueness> please do not count this against him, it was a pure emergency
-<blueness> thank you gentlemen
-<ulm> blueness: so, all no for part 2 from grobian		        [21:36]
-<scarabeus> thats straight
-<scarabeus> :D
-<ulm> and for part 3, in fact
-<ulm> OK, next one
-<ulm> econf --disable-silent-rules
-<Chainsaw> Okay for EAPI 5. *Nothing* gets applied retroactively. *EVER*
-<ulm> I suggest that we vote for this one in EAPI 5 first
-<scarabeus> ^^what Chainsaw  said				        [21:37]
-<ulm> then discuss the retroactive stuff
-* Chainsaw votes Yes for --disable-silent-rules in EAPI 5
-<ulm> please vote for "econf --disable-silent-rules" in EAPI 5
-<Betelgeuse> yes
-* ulm votes yes
-<ulm> 4 yes
-<ulm> and that's all votes we get, I fear			        [21:38]
-<Chainsaw> Sounds unanimous then.
-<ulm> yes, accepted for EAPI 5
-<scarabeus> (quite redux from 7 to 4 :-/)			        [21:39]
-<Chainsaw> scarabeus: Four is more exciting. With an even number of votes you
-	   can deadlock.
-<ulm> do we want to apply this retroactively to EAPI 4?
-<Chainsaw> ulm: NO.
-<Betelgeuse> no
-* ulm abstains
-<Chainsaw> scarabeus?						        [21:40]
-<ulm> scarabeus?
-<scarabeus> what i said
-<scarabeus> above
-<scarabeus> so no
-<Chainsaw> Excellent. Reason prevails.
-<Chainsaw> Next?
-<ulm> rejected for EAPI 4
-<ulm> we don't have to vote for EAPIs 0 to 3 then		        [21:41]
-<scarabeus> yea
-<ulm> next: "user patches"
-<Chainsaw> ulm: You could, but I'm just going to say no louder and more often.
-<ulm> no working implementation in Portage so far
-<Chainsaw> Controversy as well. Push to EAPI 6.			        [21:42]
-<ulm> and IMHO the spec is incomplete too
-<Chainsaw> It's simply not ready, agreed.
-<scarabeus> eapi6 to speed things up, other than that idea is good, it needs
-	    to be speced better
-* WilliamH thought the time was 3 my time... I'm here late... probably most
-  everything is done now. :(
-<ulm> WilliamH: welcome
-<Chainsaw> WilliamH: Please e-mail a phone number to the council list if at
-	   all possible.					        [21:43]
-<ulm> some of the controversial stuff still left
-<WilliamH> Chainsaw: no problem.
-<ulm> so, please vote on "user patches" for EAPI 5
-* ulm votes no
-* scarabeus nacks						        [21:44]
-* Chainsaw votes No (suggests postponing to EAPI6)
-* WilliamH votes no
-<Chainsaw> Betelgeuse?
-<Betelgeuse> later
-*** NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has joined channel
-    #gentoo-council
-<Chainsaw> Hey Ned.						        [21:45]
-<ulm> Betelgeuse: that is, no for 5 and include it in later EAPI?
-<Betelgeuse> ulm: yes
-<Chainsaw> ulm: That's how I read it, yeah.
-<ulm> rejected for EAPI 5
-<NeddySeagoon> hi Chainsaw
-<ulm> next: "License groups in ebuilds"				        [21:46]
-<ulm>  
-<ulm> see my alternative proposal
-<scarabeus> i like the alternative that works everywhere
-* Chainsaw votes No on license groups and Yes on the ulm approach of GPL2+
-<scarabeus> so no for the point
-* ulm votes no
-<Betelgeuse> ulm: should we ask if there is any item that gets support from
-	     someone on the list for EAPI 5?
-<Chainsaw> From the blueness list of grobian opinions, that is a "no".  [21:47]
-<ulm> Betelgeuse: yeah, that could speed up things
-<Chainsaw> I see nothing remaining that I would vote in.
-<Chainsaw> I would say gather it up, polish it for EAPI6 until it shines, and
-	   resubmit.						        [21:48]
-<ulm> no support from me for any of the remaining ones
-<scarabeus> actually the only thing i like is EJOBS because I implemented lots
-	    of interesting hacks in scons eclass and similar and this would
-	    ease stuff in future
-<Chainsaw> scarabeus: Needs a rationale, a summary, etc.	        [21:49]
-<WilliamH> I don't have an issue with ejobs either.
-<Betelgeuse> agreed with Chainsaw, ulm
-<Chainsaw> scarabeus: You okay to have that in EAPI6, or do you need it now?
-<scarabeus> Chainsaw: it is not needed now, but it should not be forgotten
-<Chainsaw> scarabeus: Oh sure, but there are more like that.	        [21:50]
-<ulm> so I see nobody speaking up for any of the remaining items
-* WilliamH agrees with scarabeus  on this... as long as we don't forget about
-  it for later...
-<ulm> I guess proponents won't forget
-<ulm> if they do, it wasn't important ;)			        [21:51]
-<WilliamH> heh
-<Chainsaw> Quite :)
-<Arfrever> In case of 423245, I suggest separate voting on each subfeature.
-<ulm> so looks like we're done with EAPI 5
-* WilliamH had a couple of questions about previous eapi 5 issues that I
-  missed since I was late...
-<WilliamH> Should that wait until open floor?			        [21:52]
-<Chainsaw> WilliamH: You can ask us now, if you think it will change anything?
-<Betelgeuse> Also there's time until tagging to change minds
-<WilliamH> I don't know if it will, but I'll throw them out there... about
-	   "parsing of the eapi being mandatory..."
-<ulm> Betelgeuse: right						        [21:53]
-<WilliamH> Did the community ever actually come to a concensus on that?
-<ulm> WilliamH: Portage already does it since a few weeks
-<Betelgeuse> WilliamH: there will never be a concensus
-<ulm> and that was the original plan
-<WilliamH> ulm: Oh ok, I'm fine with it then.
-<WilliamH> For "stable use forcing and masking." Does the current proposal for
-								        [21:54]
-<Betelgeuse> ulm: I think we are done with items to vote on?
-<Betelgeuse> ulm: I will need to head our for lunch soon
-<WilliamH>  combining e.g. package.use.* and use.* affect anything?
-<WilliamH> I don't have a link but that possibility was discussed on -dev.
-								        [21:55]
-<ulm> WilliamH: that's not on the list so far
-<ulm> and I guess that it will need further discussion
-<WilliamH> ulm: ok						        [21:56]
-<Betelgeuse> off
-<Betelgeuse> thanks people
-<Chainsaw> ttyl Betelgeuse
-<WilliamH> about the "doheader" functions...
-<WilliamH> Shouldn't we also have newheader if we have doheader?
-<ulm> WilliamH: we do
-<Chainsaw> WilliamH: That is listed in the bug.
-<Chainsaw> WilliamH: So yes, that will be included :)
-<WilliamH> Oh ok, I didn't see it in the bug.
-<ulm> Chainsaw: and in PMS and in Portage :)
-* Chainsaw repeats the need for a clear summary in the list
-*** willikins (~rbot@gentoo/bot/Willikins) has joined channel #gentoo-council
-								        [21:57]
-<Chainsaw> 2 sentences per item is all that's needed. You shouldn't have to go
-	   digging like this.
-<ulm> Chainsaw: will do, but give me a few days
-<WilliamH> Ok, that's all I had. :-)
-<ulm> OK
-<ulm> next topic then
-<ulm> Open bugs with council involvement
-<Chainsaw> ulm: Sure, I don't mean "right this minute". I mean "in future".
-<ulm> I see only bug 383467
-<Chainsaw> Not the vote counts still?				        [21:58]
-<Chainsaw> Let me address the elephant in the room.
-<ulm> Chainsaw: what?
-<Arfrever> ulm: You seemed to be not against e.g. *.svg. Each filename
-	   extension needs separate voting.
-<Chainsaw> Can anyone who isn't jmbsvicetto action this?
-*** spiros (~andyspiro@gentoo/developer/spiros) has left channel
-    #gentoo-council: "Konversation terminated!"
-<ulm> Arfrever: we're done with topic 2				        [21:59]
-<ulm> and no council member has spoken up for dohtml extensions
-<scarabeus> Arfrever: that thing is overly complex and even if ulm acked it it
-	    get enough nacks overall
-<Arfrever> ulm: But council failed to properly discuss remaining features.
-<Chainsaw> Arfrever: Council said "no to all" to the block that included
-	   dohtml.
-<scarabeus> so who is member of elections team, could someone of them fix the
-	    bug?
-<Chainsaw> Arfrever: Try in EAPI6.				        [22:00]
-<ulm> who volunteers to ping jmbsvicetto about #383467?		        [22:01]
-<scarabeus> ulm: technically he is staying at my place on the gentoo miniconf,
-	    so i can try to beat him to it :P
-<scarabeus> but it will be done on the meeting after next one :P
-<Chainsaw> scarabeus: Lock him in a room until it's done?
-<scarabeus> Chainsaw: naah, i will tell him the wifi pw only if he agrees to
-	    do it right away					        [22:02]
-<scarabeus> advanced chinese torture
-<ulm> so, we're 10 minutes behind schedule
-<ulm> only :)							        [22:03]
-<Arfrever> I suggest to vote on DEPENDENCIES in EAPI="5", which was not voted
-	   on by council yet.
-<Chainsaw> Arfrever: Council said "no to all" to the block that included
-	   DEPENDENCIES reform.
-<Chainsaw> Arfrever: Try in EAPI6.
-<ulm> Arfrever: it wasn't even on the list
-<Arfrever> Chainsaw: That block did not include DEPENDENCIES.
-<Chainsaw> Arfrever: I am not going to vote "No" all over again just to please
-	   you. It was denied. Try in EAPI 6.			        [22:04]
-<ulm> do you all agree so far with the summary in
-      http://dev.gentoo.org/~ulm/council-20120911.txt ?
-<ulm> before we go to open floor
-<Chainsaw> ulm: Summary approved with no comments.		        [22:05]
-<dberkholz> looks good
-<Arfrever> ulm: Some descriptions are truncated.
-<ulm> of course, I'll scan the log for additional comments that should be
-      included							        [22:06]
-<scarabeus> ulm: ++
-<ulm> Arfrever: only one of them, actually
-<Arfrever> ulm: 2
-<ulm> should be corrected now
-* WilliamH agrees with the summary
-<ulm> Arfrever: right, two					        [22:07]
-<ulm> I'll complete them for the final summary			        [22:08]
-<ulm> next topic
-<ulm> Open floor
-* Chainsaw switches on the microphone
-<Arfrever> ulm: Add {,package.}use.stable.{force,mask} in descriptions of 2
-	   items.
-<ulm> Arfrever: yes ;)						        [22:09]
-<ulm> anything for open floor?
-<Arfrever> I suggest that council change schedule of meetings so that meeting
-	   is in each week.					        [22:10]
-<Chainsaw> I think that grossly overestimates the availability of council
-	   members.						        [22:11]
-<WilliamH> Yeah I don't think weekly meetings would work well for the same
-	   reason.
-<dberkholz> given that there hasn't exactly been a glut of topics, i don't see
-	    the demand
-<scarabeus> we would never join together so often
-<scarabeus> and the councils in past that did it didnt have much fun doing it
-	    either						        [22:12]
-<ulm> we can do an extra meeting between regular ones if there's need
-<ulm> although there wasn't any need during this term, so far
-<WilliamH> Right, there is nothing that stops us from having extra meetings if
-	   we need them.					        [22:13]
-<ulm> anything else for open floor?
-<ulm> seems not							        [22:14]
-<Arfrever> I would like that each council member write rationale for his
-	   voting on each rejected feature.
-<Chainsaw> What is the word limit on this essay?
-<willikins> ulm: https://bugs.gentoo.org/383467 "Council webpage lacks results
-	    for 2010 and 2011 elections"; Website www.gentoo.org, Projects;
-	    CONF; hwoarang:jmbsvicetto
-<scarabeus> ulm: what a fast bot :D				        [22:15]
-<ulm> yeah :)
-<Arfrever> Because it seems that they failed to understand some features
-	   before voting.
-<Chainsaw> Arfrever: Then I would suggest that you do not vote for this
-	   council again next term.
-<ulm> Chainsaw: +1
-<Arfrever> Chainsaw: Several sentences of rationale per feature would suffice.
-<scarabeus> Chainsaw: he is not developer :-)
-<ulm> though he isn't allowed to vote ;)			        [22:16]
-<Chainsaw> I wonder why.
-<ulm> I think it's time to close this meeting
-<Chainsaw> Yes, that would be good.
-<ulm> thank you all for participating
-<scarabeus> bye							        [22:17]
-<Chainsaw> Thanks for hosting ulm.
-<Chainsaw> See you later.
-<chithead> [21:36:50] <Chainsaw> Okay for EAPI 5. *Nothing* gets applied
-	   retroactively. *EVER* << not totally correct, old-style virtuals
-	   were removed retroactively from old EAPIs
-<WilliamH> My appologies for being late.
-<Chainsaw> chithead: During my tenure?
-<chithead> no
-<Chainsaw> chithead: Precisely.
-<Arfrever> chithead: Also retroactive changes are allowed in my EAPIs :) .
-<ulm> next meeting will be October 9th				        [22:18]
-<Chainsaw> ulm: I'll be there.
-* WilliamH will be there
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20121009-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20121009-summary.txt
deleted file mode 100644
index 0691109db3..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20121009-summary.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-Agenda of Gentoo council meeting 09 October 2012
-
-Roll Call
-=========
-betelgeuse
-chainsaw
-dberkholz
-grobian
-scarabeus
-ulm
-williamh
-
-
-Allow using EAPI5 in the tree
-=============================
-Portage supports EAPI 5 since version 2.1.11.19.
-Vote: unanimous yes
-
-EAPI 5 is allowed for ebuilds in the tree.  The Council likes to note
-that EAPI 5 is not allowed to be used for stable ebuilds yet, for as
-long as a Portage supporting it is not marked stable.
-
-
-Package name specification
-==========================
-See [1].
-Vote:
-  a) Drop the limitation entirely (possibly in a future EAPI).
-   -> noone voted for this option
-  b) Make it stricter, i.e. disallow package names ending in a hyphen
-     followed by anything that looks like a valid PVR.  This is current
-     Portage behaviour, and the tree complies with it, too.
-   -> vote by: betelgeuse dberkholz grobian scarabeus ulm williamh
-  c) Leave the spec as it is (and make Portage comply with it).
-   -> vote by: chainsaw
-  d) Require a) for Package managers and b) by tree policy.
-     Practically, this would mean that repoman would reject "foo-1" as
-     package name, but the rest of Portage would accept it.
-   -> noone voted for this option
-
-By majority, option b) was chosen.  This means the specification (PMS)
-has to be adapted to make it stricter on package names, e.g. [2].
-
-
-Open bugs with council involvement
-==================================
-Bug 383467 "Council webpage lacks results for 2010 and 2011 elections"
-
-grobian and scarabeus will try to sort this thing out with jmbsvicetto at
-LinuxDays Prague, which will take place 20th and 21st of October 2012.
-
-
-Open Floor
-==========
-chainsaw and williamh informed us about developments on udev at the
-linux kernel mailing lists, and possible actions that follow up from
-there [3].
-
-_AxS_ requested quasi-consensus on in_iuse functionality, an EAPI6
-feature was suggested.
-
-_AxS_ asked the Council if they knew anything about a git rollout by
-infra, however, since this is infra domain, the Council doesn't know or
-control this.
-
-ferringb wanted to have the Council take a look at the current unified
-dependencies discussion.  It was pushed for the next agenda, to have
-some preparation necessary to discuss the topic in a clear and directed
-manner.
-
-
-Next meeting date
-=================
-13 November 2012, 20:00 UTC
-
-
-[1] http://thread.gmane.org/gmane.linux.gentoo.project/2152
-[2] https://174536.bugs.gentoo.org/attachment.cgi?id=324680
-[3] https://lkml.org/lkml/2012/10/2/303
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20121009.txt b/xml/htdocs/proj/en/council/meeting-logs/20121009.txt
deleted file mode 100644
index 4ac5537e8b..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20121009.txt
+++ /dev/null
@@ -1,290 +0,0 @@
---- Log opened Tue Oct 09 21:09:46 2012
-21:09 -!- Irssi: #gentoo-council: Total of 45 nicks [4 ops, 0 halfops, 1 voices, 40 normal]
-21:09 -!- Irssi: Join to #gentoo-council was synced in 0 secs
-21:09 <   grobian> sorry folks
-21:09 <@      ulm> good :)
-21:09 <@ Chainsaw> Good, that did it.
-21:10 <@ Chainsaw> Good evening grobian.
-21:10 <   grobian> nickserv don't give me identify
-21:10 <+dberkholz> this is beautifully ironic
-21:10 <+dberkholz> anyone got his number?
-21:10 <  WilliamH> dberkholz: All of us should have it; he sent it to the alias.
-21:10 <+dberkholz> ah, there it is.
-21:10 <+dberkholz> i'll shoot him a text
-21:10 <   grobian> thanks all for texting me
-21:10 -!- mode/#gentoo-council [+o grobian] by ChanServ
-21:10 <@ Chainsaw> Excellent. Identified and everything.
-21:10 <@  grobian> really crap, me sending a reminder and stuff
-21:10 <@ Chainsaw> You are not an imposter.
-21:10 <@  grobian> ah
-21:11 <@  grobian> it's jsut incredibly slow
-21:11 <@  grobian> and me too impatient
-21:11 <@      ulm> Chainsaw: sounds unlikely, given his sms reply ;)
-21:11 -!- floppym [~quassel@gentoo/developer/floppym] has joined #gentoo-council
-21:11 < scarabeus> :D
-21:11 < scarabeus> he sent it to the phone numbers
-21:11 < scarabeus> but i cant find MY phone now :/
-21:11 <@  grobian> ok, do you guys prefer me to quickly put the agenda thing on www.g.o?
-21:12 <@ Chainsaw> grobian: ulm linked me to http://article.gmane.org/gmane.linux.gentoo.project/2163
-21:12 <@ Chainsaw> grobian: Which works for me.
-21:12 <@  grobian> Chainsaw: yeah, that is it
-21:12 <+dberkholz> there's the in_iuse thing too
-21:12 <+dberkholz> do you want to talk about that?
-21:12 <@      ulm> and we really need our own archives back in working condition
-21:12 <@  grobian> dberkholz: I shot it ;)
-21:13 <+dberkholz> yes sir chair sir
-21:13 <@  grobian> dberkholz: you or anyone disagree with that? we can put it on
-21:13 -!- radhermit [radhermit@gentoo/developer/radhermit] has joined #gentoo-council
-21:14 <@  grobian> ok
-21:14 <@  grobian> rollcall
-21:14 <@ Chainsaw> I am present and accounted for.
-21:14 <@  grobian> (sorry all for me being late)
-21:14 -!- alexxy [~alexxy@gentoo/developer/alexxy] has quit [Ping timeout: 272 seconds]
-21:14 <@      ulm> \o/
-21:14 <  WilliamH> here
-21:14 <@  grobian> scarabeus: dberkholz seen you two
-21:14 <@  grobian> Betelgeuse: you around too?
-21:14 < scarabeus> here
-21:15 <+dberkholz> yep.
-21:15 <@Betelgeus> grobian: yes
-21:15 <@  grobian> ok, do you want me to report myself as being late?
-21:15 <@  grobian> vote
-21:15 <@      ulm> no
-21:15 *** Chainsaw votes no
-21:15 < scarabeus> no
-21:15 <  WilliamH> no
-21:15 <@Betelgeus> yes but no missing marker
-21:15 <@ Chainsaw> grobian was responsive on SMS.
-21:15 <@ Chainsaw> And promptly appeared. I have done this kind of thing in the past, and not been shot for it.
-21:16 <@  grobian> lol
-21:16 <@  grobian> ok
-21:16 <@  grobian> good, just for the record
-21:16 <@  grobian> thanks
-21:16 <@  grobian> Ok, I'd like to go on to point 2, the EAPI5 usage in tree
-21:16 <@  grobian> are we prepared to vote on that?
-21:16 <@ Chainsaw> I would like for that to proceed with immediate effect please.
-21:16 <@ Chainsaw> Yes.
-21:16 *** Chainsaw votes yes
-21:16 < scarabeus> ^_^
-21:16 <@Betelgeus> fyi there's no late concept in GLEP 39
-21:16 <@  grobian> good, votye for usage of EAPI5 in tree
-21:16 *** ulm votes yes
-21:16 *** scarabeus is for yes
-21:17 *** WilliamH votes yes
-21:17 -!- alexxy [~alexxy@gentoo/developer/alexxy] has joined #gentoo-council
-21:17 <+dberkholz> sure
-21:17 <@Betelgeus>  I don't think a separate vote is required but yes
-21:17 <@      ulm> maybe we should clarify that EAPI 5 isn't allowed for stable yet
-21:17 <@  grobian> grobian: yes
-21:17 <@Betelgeus> ulm: then we should clarify a lot of other QA things as well
-21:17 < scarabeus> Betelgeuse: we actually wrote it to the roll call :D
-21:17 <@      ulm> only when the Portage version supporting it goes stable
-21:17 <@  grobian> ulm: good point
-21:18 <@ Chainsaw> ulm: Does repoman not check for that situation already?
-21:18 <@      ulm> but it was handled like that in the past, so maybe it's obvious
-21:18 <@ Chainsaw> ulm: And if it does not, can that be implemented please?
-21:18 <@      ulm> Chainsaw: I don't think it does
-21:18 <+dberkholz> that should be a technical check, not a policy
-21:18 <@  grobian> ulm: do you want a boundary condition? (e.g. when portage goes stable, or X months after that)
-21:19 <@      ulm> grobian: as soon as portage goes stable
-21:19 <@  grobian> ulm: got that now
-21:19 <@ Chainsaw> The second after, if need be.
-21:19 <@  grobian> http://dev.gentoo.org/~grobian/agenda-20121009.txt
-21:19 <@ Chainsaw> If repoman prevents any accidents... that should do nicely. If devs want to use --force and break the tree, that is when policy can kick in.
-21:19 <@  grobian> "common sense"
-21:20 <@  grobian> ok, shall we move onto point 3?
-21:20 <@  grobian> Package name specification
-21:20 <@  grobian> basically, ulm outlined it pretty clearly, IMO
-21:20 <@ Chainsaw> Option C please. The rules were voted in.
-21:20 <@      ulm> grobian: you've messed up the indentation :p
-21:20 <@ Chainsaw> Portage does not get a free pass here.
-21:21 <@  grobian> ulm: yeah, tabs, I need to fix my .muttrc
-21:21 <@  grobian> ok
-21:21 <@  grobian> let's vote for a, b, c or d
-21:21 *** Chainsaw votes C
-21:21 <@      ulm> b or d
-21:21 <+dberkholz> B
-21:21 <+dberkholz> i prefer fixing docs to code.
-21:21 <@  grobian> ulm: how do I have to interpret that?
-21:21 <@Betelgeus> scarabeus: note for next time
-21:21 < scarabeus> b
-21:22 <@      ulm> grobian: b then ;)
-21:22 <@  grobian> ulm: ok :)
-21:22 <@ Chainsaw> Looks like a majority for B then?
-21:22 *** Chainsaw can live with that :)
-21:22 <@  grobian> WilliamH: your vote?
-21:22 *** WilliamH votes b also
-21:23 <@      ulm> well, both portage and the tree comply with b already
-21:23 <@  grobian> B: ulm, dberkholz, scarabeus, grobian, williamh
-21:23 <@  grobian> C: chainsaw
-21:23 <@  grobian> so, B wins
-21:23 <@Betelgeus> b+c
-21:23 <@ Chainsaw> grobian: Not unanimous for a change. This is good. I have had complaints that meetings were getting boring.
-21:23 <@  grobian> so, ulm, what did you want to do with d?
-21:23 <@Betelgeus> If we only change a future EAPI Portage should comply with the existing ones
-21:24 <@  grobian> Betelgeuse: what does that mean?
-21:24 <@      ulm> grobian: d would have been my second choice
-21:24 <@  grobian> Chainsaw: pardon my faulty spelling
-21:24 <@Betelgeus> grobian: or was b meant to be retroactive?
-21:25 <@  grobian> b means fit the spec to what portage does, IMO
-21:25 <+dberkholz> boring is probably good, because it means most issues were hashed out in advance
-21:25 <     _AxS_> ..so to clarify that means change PMS everywhere applicable ?
-21:26 <@  grobian> Betelgeuse: I'd prefer if you'd choose one option
-21:26 *** ulm understands it in this way
-21:26 <@  grobian> _AxS_: I also understand it that way
-21:26 <@Betelgeus> grobian: b if Portage has always behaved like that
-21:26 <@      ulm> Betelgeuse: it has since 2009 at least
-21:26 <@Betelgeus> grobian: I don't think we should fit PMS if Portage has changed in the recent history
-21:26 <@      ulm> I haven't checked earlier versions
-21:27 <@Betelgeus> ulm: 2009 was when PMS was in effect so they should not go about changing things
-21:27 <@  grobian> ok
-21:28 <@  grobian> do you want to change your vote then, Betelgeuse?
-21:28 <@  grobian> if not, I'd like to finish this topic, and move on to the next
-21:29 <@Betelgeus> grobian: I would like to see how others understood the option
-21:29 <@  grobian> ok, go ahead
-21:29 <@Betelgeus> grobian: b is still fine if we note what I said
-21:29 <@      ulm> apply b to all EAPIs
-21:29 <+dberkholz> +1
-21:30 *** WilliamH is fine with that
-21:30 <@  grobian> ok, shall we move on then?
-21:30 <@Betelgeus> grobian: yes
-21:30 <@  grobian> great
-21:30 <@  grobian> the open bugs
-21:31 <@  grobian> I think the only one is the one we have on the agenda for a while
-21:31 <@  grobian> I'll try to sort it out with jmbsvicetto in prague
-21:31 <@  grobian> no guarantees
-21:31 < scarabeus> thats what i plan to do as he stays at my place
-21:31 <@  grobian> cool]
-21:31 < scarabeus> as i said last meeting :-)
-21:31 <@  grobian> we will both doo it
-21:32 *** grobian updated it
-21:32 <@  grobian> ok, open floor then
-21:32 *** grobian opens the floor
-21:32 <@Betelgeus> Any other people going to Prague?
-21:32 <@      ulm> +1
-21:32 <@Betelgeus> I booked flights yesterday
-21:32 <@  grobian> cool!
-21:32 <@Betelgeus> So good we can get drunk and do a meeting
-21:32 <@  grobian> yeah, hahahaha
-21:32 <@  grobian> ok
-21:32 <@  grobian> Open Floor!
-21:32 <@  grobian> anyone who wants to raise an issue to the council?
-21:33 <@  grobian> I take that as a no
-21:33 <  WilliamH> Not really an issue, but a comment. It is going to definitely be interesting to see what happens with udev... Is everyone aware of the debate on lkml?
-21:34 <@  grobian> no, would you like to share a summary with us?
-21:34 <@ Chainsaw> Go ahead WilliamH. Those last two links I sent you should be rather informative.
-21:34 <  WilliamH> Basically the kernel guys are looking into taking over some or maybe all of the udev functions...
-21:34 <@ Chainsaw> (The initial Linus posting and his response to Kay Sievers)
-21:34 <@ Chainsaw> Perhaps Al Viro's take.
-21:34 <  WilliamH> Chainsaw: can you post the links here again?
-21:35 <@ Chainsaw> WilliamH: That was on a different computer I'm afraid.
-21:35 <@  grobian> interesting, so that means udev will be just kernel built-in?
-21:35 <  WilliamH> ok folks give me a second to find them...
-21:35 <  WilliamH> grobian: I'm not really sure yet.
-21:35 <  WilliamH> grobian: but changes there are definitely happening.
-21:36 <@  grobian> while you're searching
-21:36 <@  grobian> one issue people
-21:36 <     _AxS_> Since in_iuse was mentioned earlier -- i believe there was quasi-consensus on that one that the best way to deal with it will be in a future eapi; is that the take Council has on it too?
-21:36 <@  grobian> next meeting, 20:00 UTC again?
-21:36 <@  grobian> (iso 19:00)
-21:36 <+dberkholz> again?
-21:36 <@  grobian> _AxS_: I would vote yes
-21:36 *** ulm doens't care if it's 19 or 20 UTC
-21:36 <@  grobian> dberkholz: daylight savings thing here in europe
-21:37 <     _AxS_> grobian: ok so work will be done and it can get added to the agenda for eapi=6 whenever that rolls up.
-21:37 <@  grobian> _AxS_: from my point of view, yes.  That ferringb said/suggested
-21:37 <@  grobian> ok, next meeting will then be 13 November 2012, 20:00 UTC
-21:37 <@Betelgeus> the earlier the better for me
-21:38 <  WilliamH> https://lkml.org/lkml/2012/10/2/303
-21:38 <  WilliamH> That's Linus' original post, and the other things follow it in that thread
-21:38 <@  grobian> Betelgeuse: I'd like it too
-21:38 <     _AxS_> Rumour has it that infra will be working on rolling out the git tree; does Council know anything about that?
-21:38 <  ferringb> _AxS_: wrong forum for asking
-21:39 <  ferringb> aka, ask infra, not council
-21:39 *** ferringb sent emails detailing current status of it, and areas people nee dto step up (hooks in particular, a helping hand is needed for)
-21:39 <     _AxS_> ahok.  wasn't sure if it'd be a Council thing to freeze the tree or whatnot while the conversion happens
-21:39 <@ Chainsaw> _AxS_: The council doesn't call the shots on this.
-21:39 <  ferringb> we'll sort that when it comes; if a freeze is necessary, it'll be sub 8 hours
-21:39 <@  grobian> not a council thing, imo
-21:40 <@ Chainsaw> _AxS_: Nothing moves until ferringb says it does.
-21:40 <  WilliamH> What we are going to do is not stabilize udev-18x for a wwhile and monitor the upstream situation.
-21:40 <  ferringb> the plan involves no freeze however, beyond an hour outage or so
-21:40 <  ferringb> Chainsaw: robin moreso.  I'm just his minion
-21:40 <  WilliamH> There is already a commit in the kernel to load firmware directly.
-21:40 <     _AxS_> wonderful!  (Can this be left in the minutes?)
-21:40 <  WilliamH> It looks like that will hit in 3.7
-21:40 <@  grobian> Ok, let's end the meeting here, then you can continue here whatever
-21:40 <  ferringb> with that said
-21:41 <  ferringb> council commentary- subjective commentary- on the rough proposed unified dependencies would be useful.
-21:41 <  ferringb> no, I'm not asking for approval.  I'm after a basic headcount of who says no, and or the potential of a dev vote if folks are particularly divided and no clear majority
-21:42 <  ferringb> (how's that for chucking a grenade into your quiet meeting? :)
-21:42 <@  grobian> I for one would like to be a bit more informed about the issue because I saying anything about it
-21:42 <  ferringb> grobian: what do you need to be better informed?
-21:42 *** WilliamH agrees  with grobian 
-21:42 <  ferringb> glep needs updating, which is on the todo
-21:42 <@  grobian> ferringb: like what you're asking me
-21:42 <@Betelgeus> ferringb: I like the exherbo approach
-21:42 <@  grobian> ferringb: I don't think the git migration thing should EVER be a council topic
-21:42 <  ferringb> I'm just looking to see how to get the details/info to y'all *clearly*, w/ less of the trolling on the ml gumming the info up
-21:42 <@  grobian> because it simply needs to be done
-21:42 <@  grobian> not decided upon
-21:43 <@  grobian> the plan is pretty much laid out clearly, IMO
-21:43 <  ferringb> grobian: err.  I was asking about unified dependencies.
-21:43 <@  grobian> here, see
-21:43 <@  grobian> lol
-21:43 <  ferringb> git tranition isn't a council topic because y'all aren't doing the work, so nothing to talk about. :)
-21:43 <@  grobian> I don't even know what you're talking about
-21:43 < scarabeus> ferringb: I like the unified deps idea, but I didnt get my ass to reply there due to all that noise to real stuff ratio
-21:43 <@  grobian> please just bring it up on -project, with pointers and all
-21:43 <@  grobian> I get lost in the flamewars sometimes
-21:44 <@Betelgeus> sounds like a -dev topic
-21:44 <@  grobian> we can add it to the next agenda
-21:44 <@  grobian> in fact, please do
-21:44 <  WilliamH> Yeah me too. I like the concept, but there was so much in that thread it was difficult to follow.
-21:44 <  ferringb> ehh
-21:44 <@ Chainsaw> I don't think it needs to be on the agenda.
-21:44 <  ferringb> grobian: tbh, I think it's better I identify exactly how to make sure y'all know the details/bits involved here, then adding it to the agenda
-21:45 <@ Chainsaw> If you'd like a private briefing by the stakeholders sent to council@
-21:45 <  ferringb> I don't want discussion w/out understanding in full
-21:45 <@ Chainsaw> I think that is more feasible.
-21:45 <  ferringb> bluntly, the -dev ml already had enough of that
-21:45 <@  grobian> I can read, if I know where to find it, and what's the problem
-21:45 <@ Chainsaw> Even if it's just ferringb sending you his earlier write-up.
-21:45 <  ferringb> grobian: http://dev.gentoo.org/~ferringb/unified-dependencies/
-21:45 <@  grobian> I don't like exercises like that lengthy discussion about the sub-slot bogus
-21:46 <  ferringb> grobian: http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html <-- glep, http://dev.gentoo.org/~ferringb/unified-dependencies/examples/herds/ <-- herd level view of how it would impact deps
-21:46 <     _AxS_> there's some good stuff that came out of the ML arguments too -- like, ome of the primary differences between *DEPEND vars and DEPENDENCIES (that being "authoritative" specification for each phase, i think is the wording?)
-21:46 <  ferringb> re: exherbo labels, I addressed the similarity between the two in an email, and via analysis http://dev.gentoo.org/~ferringb/unified-dependencies/labels/
-21:47 <  ferringb> authoratitive I need to incorporate fully into the glep, since that's implicit, but not explicitly stated
-21:47 <  ferringb> Betelgeuse: presume you're pretty well caught up on the topic, sans potentially my "this is why labels isn't worth it for us" arguments?
-21:47 <     _AxS_> ..and possibly important enough to be dealt with/decided upon separately
-21:47 <  ferringb> _AxS_: can't be, unfortunately, since going authoritative w/out this matching change to metadata makes devs lives worse
-21:48 <     _AxS_> true
-21:48 <  ferringb> when is the next meeting?  date, not time
-21:49 <@ Chainsaw> The second Tuesday in November, presumably?
-21:49 <  ferringb> ok
-21:49 <@  grobian> ferringb: please chuck all those links in a mail on -project, preferably in reply to the next call for agenda items mail
-21:49 <     _AxS_> but it defines the decision of "yes we need a change" vs "no we dont" , separately from the change itself.
-21:49 <  ferringb> will sort the glep, and if necessary, will cc each of your asses (I'm not naming names, but... grobian) to make sure y'all see it :P
-21:49 <@  grobian> ferringb: 13 November 2012, 20:00 UTC
-21:49 <     _AxS_> <grobian> ok, next meeting will then be 13 November 2012, 20:00 UTC  <-- that?
-21:49 <  ferringb> _AxS_: yeah, I'm blind
-21:49 <@  grobian> ferringb: and agenda call is sent 30th of october
-21:50 <  ferringb> yep
-21:50 <@  grobian> agenda is sent out on 6th of november
-21:50 <@  grobian> ok, @council: I'd like to close this meeting
-21:50 <  ferringb> may put it on y'alls agenda.  not looking for necessarily approval (would be nice, but les be realistic), just discussion
-21:50 <  WilliamH> Before anyone takes off, did my link and comment about the kernel commit get lost in the chatter?
-21:50 <     _AxS_> WilliamH: <WilliamH> https://lkml.org/lkml/2012/10/2/303   <-- that one?
-21:50 <@  grobian> WilliamH: you want it in the summary?
-21:51 <  WilliamH> grobian: I'm not sure if it needs to be there or not, It isn't really an issue we decide anything on here, just something to track.
-21:51 <@  grobian> WilliamH: w/e http://dev.gentoo.org/~grobian/agenda-20121009.txt
-21:52 <@  grobian> ok. thank you all for being productive
-21:52 <@  grobian> I'll send out the summary to @council soon
-21:52 <     _AxS_> thanks for chairing, grobian !
-21:52 < scarabeus> grobian: ack on the summary and chairing
-21:52 < scarabeus> s/ack/thanks/
-21:52 <@  grobian> and sorry once again for my problematic arrival
-21:53 <  WilliamH> grobian: ok, that looks good.
-21:54 <  ferringb> WilliamH: fun thread btw
-21:54 -!- grobian changed the topic of #gentoo-council to: Next meeting: 2012-11-13 20:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 |
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20121113-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20121113-summary.txt
deleted file mode 100644
index 549a780507..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20121113-summary.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-Summary of Gentoo council meeting 13 November 2012
-
-
-Roll Call
-=========
-betelgeuse
-Chainsaw
-rich0 (proxy for dberkholz)
-graaff (proxy for ulm)
-grobian
-scarabeus
-WilliamH
-
-
-Handling separate /usr support
-==============================
-WilliamH requested approval for two methods to support separate /usr
-systems[2].  The discussion is closely related to recent opinons on udev, such
-as e.g. [1], because the main reason to force a system without separate /usr
-during boot is to allow newer versions of udev to be used.
-The originally announced item of discussing the removal of gen_usr_ldscript
-has been retracted[4].
-- approve/disapprove plan (forcing everyone to take action, and
-  implement one of the two "supported" solutions)
-
-WilliamH requests a council vote to allow migrating everyone after bugs
-[5,6,7] are resolved.  He proposes a news item to announce this that allows to
-assume after a given period of time that everyone who is using split /usr is
-using a method to mount /usr before boot.  The focus is purely on this topic.
-
-rich0 prefers to move on until suport for separate /usr becomes a
-barrier, and handle things from there.  This allows for alternative
-solutions to be developed and put forward.  He favours waiting somewhat
-to see developments of the udev fork.
-
-Chainsaw is a strong proponent for waiting a month and see how the new
-udev fork develops itself.  If within a month no solution is provided by
-the udev fork, things need to be moved forward in WilliamH's proposed
-way.
-
-scarabeus approves the plan.
-
-betelgeuse likes to ensure users won't be caught off guard, but has no
-preference for any direction taken in particular.
-
-graaff's main concern is how the problem is tied to udev, or not.  A fork of
-udev may not change the situation regarding separate /usr, hence delaying a
-decision now is not sensical.  Opt-in system for people to ensure they can
-boot is pre-requisite.  If this cannot be ensured, we have to wait.
-
-grobian disapproves the plan, since there will be systems that cannot easily
-be changed to ensure /usr being mounted at boot, and it is no good to expel
-users of (security) updates just because of that.  With the use of a special
-profile (masks/unmasks, variables and/or use-flags), users that want to move
-on, can opt-in to getting packages that require non separate /usr.
-
-
-
-Policy on "<" versioned dependencies
-====================================
-chithahn requested the council to clear up confusion around "<" versioned
-dependencies[3].  This issue seems to combine:
-1) notorious behaviour from the usual suspects
-2) QA policies whether or not they are properly documented/advertised
-3) the technical problem of "<" dependencies causing downgrades
-
-The council sees no rule that makes it illegal to use < dependencies, but
-strongly discourages their use.  It must be noted that for some
-packages, a downgrade is very undesirable.  This has triggered package
-removals in the past.  However, the council requests the teams responsible for
-that removal to act reasonably and in good cooperation with the maintainers of
-the packages in question.
-
-
-Open bugs with council involvement
-==================================
-Bug 383467 "Council webpage lacks results for 2010 and 2011 elections"
-- ulm has done the work here, waiting for a confirmation that we can really
-  close the bug
-Bug 438338 "Please update devmanual with EAPI5 info"
-- no progress and/or actions planned for this
-
-
-Open Floor
-==========
-No issues were brought up to the council.
-
-
-Next meeting date
-=================
-11 December 2012, 20:00 UTC
-
-
-[1] https://lkml.org/lkml/2012/10/2/303
-[2] http://thread.gmane.org/gmane.linux.gentoo.project/2208
-[3] http://thread.gmane.org/gmane.linux.gentoo.project/2213
-[4] http://article.gmane.org/gmane.linux.gentoo.project/2235
-[5] https://bugs.gentoo.org/411627
-[6] https://bugs.gentoo.org/435756
-[7] https://bugs.gentoo.org/441004
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20121113.txt b/xml/htdocs/proj/en/council/meeting-logs/20121113.txt
deleted file mode 100644
index 3695fa16ba..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20121113.txt
+++ /dev/null
@@ -1,273 +0,0 @@
-20:26 <@  grobian> Betelgeuse, Chainsaw, grobian, scarabeus, WilliamH, graaff, rich0: ready now?
-20:26 <+   graaff> yes
-20:26 <+    rich0> aye
-20:26 <@  grobian> dberkholz: thanks! (by the way)
-20:27 <@ Chainsaw> I'm here.
-20:27 <@Betelgeus> yes
-20:27 <@ WilliamH> here
-20:27 <@  grobian> scarabeus?
-20:27 *** NeddySeagoon manages to be here too
-20:28 <@scarabeus> herw
-20:28 <@  grobian> complete!
-20:28 <@  grobian> let's start the meeting
-20:28 <@  grobian> agenda is : http://dev.gentoo.org/~grobian/agenda-20121113.txt
-20:28 -!- grobian changed the topic of #gentoo-council to: Council meeting now | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | agenda: http://dev.gentoo.org/~grobian/agenda-20121113.txt
-20:28 <@  grobian> ok, topic one
-20:29 <@  grobian> WilliamH: do you want to say anything on the matter
-20:30 <@ WilliamH> Yes, I do actually, thanks. :-)
-20:30 <@  grobian> please go ahead
-20:30 <@ WilliamH> Our  tracker for udev stabilization also includes tasks for separate usr support bug 411627
-20:30 < willikins> WilliamH: https://bugs.gentoo.org/411627 "[TRACKER] tasks to complete before >=sys-fs/udev-188 can be stabilized"; Gentoo Linux, Core system; CONF; williamh:udev-bugs
-20:31 <@ WilliamH> For separate usr support, we need bug 435756
-20:31 < willikins> WilliamH: https://bugs.gentoo.org/435756 "sys-apps/openrc-0.11.5 stable request"; Gentoo Linux, Keywording and Stabilization; CONF; williamh:openrc
-20:31 <@ WilliamH> and bug 441004
-20:31 < willikins> WilliamH: https://bugs.gentoo.org/441004 "sys-kernel/genkernel: we need a stable version that mounts /usr"; Gentoo Hosted Projects, genkernel; CONF; williamh:genkernel
-20:31 <@ WilliamH> The non-initramfs method for separate usr support is already stable, that is busybox with the sep-usr use flag.
-20:32 <@ WilliamH> Basically you emerge it with that flag then use the init= kcl parameter to run ginit which hands over to your real init after mounting /usr.
-20:33 <@ WilliamH> What I'm asking the council to do is, vote that after we get the other bugs stable we need, we can start migrating everyone to one of those methods.
-20:33 <@ WilliamH> I propose a newsitem, then after a time window, we
-20:33 <@ Chainsaw> What I would ask is that we postpone this decision by one month, as I expect an alternate udev to be available by that time.
-20:34 <@ WilliamH> can assume that everyone who is using split /usr is on one of these methods. Also, our qa lead has a blog article from a few years ago
-20:34 <@ Chainsaw> At which point we may well have three options to consider.
-20:34 <@ WilliamH> Chainsaw: udev is irrelivent
-20:34 <@ Chainsaw> WilliamH: It really isn't.
-20:34 <@ WilliamH> Sure it is.
-20:34 <+    rich0> When do we think all the blockers will be closed anyway?
-20:34 <@ Chainsaw> WilliamH: As much as I would pray that udev would become irrelevant, it is the wedge that is being driven between my working systems and linux.
-20:34 <+    rich0> Will delaying a month make any practical difference?
-20:35 <@ WilliamH> Well, I'm going to move for stabilization of the new openrc in the next week.
-20:35 <@ Chainsaw> WilliamH: I don't propose that you stop the preparation work.
-20:35 <@ WilliamH> Chainsaw: hang on a sec, I'm pulling up something
-20:35 <@ Chainsaw> WilliamH: I just ask that we do not make the decision on the main udev stabilisation until next month's meeting, when we'll in all likelihood have more choice.
-20:35 <+   graaff> rich0: a fork was created in the last few days, so a month would make a difference with that
-20:36 <@ WilliamH> We aren't talking about udev stabilization.
-20:36 <@ Chainsaw> WilliamH: If it is that tired "oh but separate /usr was always a little bit broken" page again, I shall scream.
-20:36 <+    rich0> Chainsaw, my thinking is that if waiting a month won't actually delay anything, then it only makes sense to make the decision with more info.
-20:36 <     _AxS_> stabilization of packages and such won't be affected by this, though, will it?  the only thing that is affected is the ability to declare "/ and /usr are essentially always available now, no need to work around it" , ?
-20:36 <@ WilliamH> http://blog.flameeyes.eu/2010/04/useless-legacies
-20:37 <@ Chainsaw> _AxS_: Things like openrc can be stabilised, sure. Just not udev itself.
-20:37 <@ WilliamH> No, I'm not proposing stabilizing udev.
-20:37 <@ Chainsaw> _AxS_: I don't want the breakage to be unleashed mere weeks before a more effortless solution is ready.
-20:38 <+    rich0> Well, I think that there would be a 30-90 day window anyway after everything is stable.
-20:38 <     _AxS_> Chainsaw: *nod*, i'm more getting at, that these fixes can get into stable regardless of the decision made here, so that the release media can get fixed
-20:38 <+    rich0> So, breakage will not immediately follow all those blockers being closed.
-20:38 <@ WilliamH> _AxS_ is correct about what I'm proposing. I'm just saying that / and /usr will always be available.
-20:38 <@  grobian> WilliamH: may I summarise your request as only focussing on getting people out of the split /usr setup during boot?
-20:38 <@ WilliamH> grobian: yes.
-20:39 <@ WilliamH> grobian: Stablizing udev has nothing to do with that.
-20:39 <@  grobian> right
-20:39 <@  grobian> we've had this discussion on the ML already
-20:39 <@  grobian> and I think we shouldn't penalise people who can't easily effectuate this
-20:39 <@scarabeus> i agree here with will :)
-20:40 <@ WilliamH> grobian: I don't think there is a major penalty involved.
-20:40 <@  grobian> so I'm not in favour of "assuming that everyone who is using split /usr is 
-20:40 <@  grobian> using a method to mount /usr before boot"
-20:40 <@  grobian> WilliamH: I once maintained 3000 Gentoo systems, and I think there is
-20:40 <+    rich0> question - I had assumed this was about being able to eventually stabilize the next udev.  If not, then what exactly is the motivation behind this?  What happens if people don't migrate?
-20:41 <@ Chainsaw> rich0: It does feel like we get to have the breakage now anyway, with or without udev.
-20:41 <@  grobian> rich0: udev is not in the picture now, see my previous question to WilliamH and his answer
-20:41 <@ WilliamH> rich0: The issue is anything that crosses the /->/usr barrier.
-20:41 <@ WilliamH> rich0: Basically if you have binaries in / that link to things in /usr/lib, or,
-20:42 <@ WilliamH> read things from /usr/share,
-20:42 <+   graaff> The relation is that having /usr available at boot time is a precondition for stabilizing newer udev, right?
-20:42 <+    rich0> My thinking is that if somebody doesn't have plans that are being blocked, then waiting a month to let the new udev effort have a shot makes the most sense.
-20:42 <@ WilliamH> they are broken if /usr is not available when / is.
-20:42 <     _AxS_> graaff: more specifically would be 'kmod'
-20:43 <@  grobian> my thinking is that we can easily create a profile where we unmask some udev version, and hence allow the eager users to opt-in
-20:43 <@ WilliamH> graaff: Not just udev. Udev is related, but that's not the issue with / and /usr.
-20:43 <     _AxS_> graaff: which sits in /usr/[s]bin but has symlinks like /sbin/modprobe -> /usr/whatever/kmod
-20:43 <@ WilliamH> kmod is part of it too.
-20:43 <@ Chainsaw> WilliamH: Udev is at the centre of the /usr merge plans. The upstream authors put it there.
-20:43 <+   graaff> WilliamH: I understand, I was trying to clarify how udev fits in this dicussion.
-20:44 <@ Chainsaw> WilliamH: It is as related to the /usr merge as a boat to water.
-20:44 <@ WilliamH> Chainsaw: /usr merge isn''t what I'm discussing right now.
-20:44 <@ Chainsaw> _AxS_: Sounds like kmod needs a few fixes.
-20:44 <+   graaff> grobian: how do you see the plan forward in that case?
-20:44 <@  grobian> stick to the original agenda ;)
-20:44 <+    rich0> It seems like the smoothest path is to just keep moving forward with the tracker, and then when having support for a separate /usr becomes a barrier then we take the step of deprecating things.
-20:45 <@  grobian> I disapprove the plan, I think it's not ok for all types of consumers of our userbase
-20:45 <+    rich0> That gives alternative solutions the most opportunity to move foward, and it gives our users the most options.
-20:47 <+    rich0> So, I tend to agree with Chainsaw - if there isn't anything pressing that we're blocking, why not wait a month and make the decision "just in time?"
-20:47 <@ WilliamH> rich0: I'm just seeing your last msg right now, what  was the previous one again?
-20:48 <@  grobian> Betelgeuse, graaff, scarabeus: do you have inputs (that I should record)
-20:48 <@scarabeus> i said i agreed with wills idea
-20:48 <@Betelgeus> No matter what we do users should not be caught off guard
-20:48 <@ WilliamH> Betelgeuse: I agree, that's why I want to publicize everything as we go with newsitems etc.
-20:49 <@ WilliamH> When things start to happen my plan is to announce everything with newsitems as we go.
-20:49 <@Betelgeus> Otherwise I agnostic :)
-20:49 <@Betelgeus> +am
-20:49 <+    rich0> WilliamH, in theory the communications don't have to wait for all the blockers to be done, though we might have to be vauge about the udev fork since that is immature.
-20:49 <@ Chainsaw> rich0: So that's why we could wait a month and do this right.
-20:50 <+   graaff> I don't think a forked udev will make a lot of difference to the split /usr situation, so I don't see how waiting a month will help.
-20:50 <@ WilliamH> rich0: The problem with the udev fork is, we don't know when it will be ready.
-20:50 <@ Chainsaw> WilliamH: Within a month, so in time for the next meeting.
-20:50 <@ WilliamH> rich0: it could be next month or they could keep coming back saying we need more time etc...
-20:50 <     _AxS_> ..what's the summary of the decision so far?  2 for "wait" , 1 for "dont do it", 2 for "do it", and one for "users come first no matter what" ..?
-20:50 <@ Chainsaw> WilliamH: You can quote me on this. If it isn't ready, we move on and I have failed.
-20:50 <+    rich0> WilliamH, Agree, and if waiting for the fork actually delayed things by much I'd be more concerned.  However, we're not at the point where this is on the critical path, so I think we can afford to wait.
-20:50 <+    rich0> I'm for wait.
-20:51 <+    rich0> Unless somebody can show me something that waiting is actually holding up.
-20:51 <@ Chainsaw> WilliamH: I have blueness working on this. I am very confident that we will hit that date.
-20:51 <@ WilliamH> rich0: this isn't really the topic for this meeting, but
-20:51 <     _AxS_> rich0: kmod stabilization will be held by this, unless that one is patched.
-20:51 <@ WilliamH> give me a second to get a bug number
-20:52 <@Betelgeus> _AxS_: If someone can formulate a clear item to vote on then I have no problem casting one
-20:52 <@ Chainsaw> _AxS_: Then let's patch it to do the right thing and *then* stabilise it.
-20:52 <     _AxS_> (i dont know if that's a big deal or not tho)
-20:52 <@ WilliamH> bug 417451 can happen on linux once we make the switch.
-20:52 < willikins> WilliamH: https://bugs.gentoo.org/417451 "toolchain-funcs.eclass:gen_usr_ldscript - make no-op on non-bootable systems"; Gentoo Linux, Library; CONF; yrusinov:toolchain
-20:52 <     _AxS_> Betelgeuse: my count seems to still be missing someone ..
-20:53 <     _AxS_> ..except that bug is something we're specifically leaving out of this debate.
-20:53 <@ WilliamH> Right, I'm just siting something since rich0  wanted to know something that we are holding back.
-20:53 <+   graaff> I would prefer to move on but make sure that people need to opt-in their systems, so we can be sure they've made preparations and won't end up with unbootable boxes.
-20:53 <+    rich0> WilliamH, does it really amount to much delay - it seems like it will take a week or two at least to get the other blockers resolved anyway.
-20:54 <     _AxS_> graaff: i think i missed you.  So that makes three for wait.
-20:54 <@ Chainsaw> You counted my "wait" answer, right?
-20:54 <     _AxS_> Chainsaw: yes.
-20:54 <@ WilliamH> Ok, I'm lost, and it is hard  for me to scroll.
-20:54 <+   graaff> _AxS_: uhm, "I prefer to move on"...
-20:55 <@  grobian> gen_usr_ldscript is NOT a topic of concern now
-20:55 <     _AxS_> 'k sorry
-20:55 <@ WilliamH> I prefer to move on as soon as the blockers are cleared.
-20:55 <@ WilliamH> let me clarify what move on means.
-20:56 <@ WilliamH> publish a news item, then give users maybe 14-30 days to migrate then assume everyone has after that window.
-20:56 <@ Chainsaw> Yes, introduce the breakage quickly, before the fix is ready.
-20:56 <@ WilliamH> Chainsaw: no once the blockers are closed the fix is there.
-20:57 <+   graaff> WilliamH: if that is the plan then I am against it, because I don't want to make that assumption. I want to ensure that a user has actually migrated.
-20:57 <@  grobian> _AxS_: do your findings match my agenda?
-20:57 <+    rich0> If the window were longer - say 60-90 days that might be a compromise for waiting - it would give the udev efforts more opportunity to catch up.
-20:57 <@ WilliamH> graaff: you can't guarantee anything.
-20:58 <+   graaff> Find a way.
-20:58 <      ryao> As far as I can tell, there is nothing that any of our users actually want that will be harmed even if we were to keep using udev-171 until next year.
-20:58 <     _AxS_> grobian: yep. except graaff i think just switched
-20:58 <@  grobian> WilliamH: use a profile, it requires an explicit step by the user
-20:58 <@ WilliamH> graaff: That's impossible. You are asking something like finding a way to make sure that everyone has migrated to OpenRC.
-20:58 <@  grobian> _AxS_: indeed
-20:58 <+   graaff> _AxS_: I'm still for 'moving on', but I have a nasty precondition for it.
-20:58 <@ Chainsaw> WilliamH: I have already given you ironclad guarantee. Ready by the next meeting.
-20:59 <@ Chainsaw> WilliamH: In a public channel, in a public meeting, which is logged and observed. I can't back out of that.
-20:59 <     _AxS_> graaff: I concurr, but since that precondition doesn't exist that effectively turns you into a 'wait' :)
-20:59 <@  grobian> graaff: think I got that now
-20:59 <+   graaff> WilliamH: I haven't looked at this problem at all, but isn't it possible to do this with a profile switch, option set somewhere, file added to flie system?
-20:59 <     _AxS_> graaff: there was such a proposal made to -dev@
-20:59 <@  grobian> it's called masks, and special variables
-21:00 <@ Chainsaw> WilliamH: Moving ahead now, and saying "the hell with the udev fork" sounds very scorched earth to me.
-21:00 <@  grobian> I would like to finish on this topic
-21:00 <@ WilliamH> graaff: maybe a  use flag could be added?
-21:00 <@  grobian> I think we've had a lot of feedback now
-21:01 <@ WilliamH> Chainsaw: I can go along with what you said about waiting for a month.
-21:01 <@ Chainsaw> WilliamH: That's all I ask. If we're not ready by next meeting, we have failed.
-21:01 <@ WilliamH> Chainsaw: if the fork isn't ready and the blockers are cleared, we move on though...
-21:01 <@ Chainsaw> WilliamH: Yes. I will sign that ultimatum.
-21:01 <@  grobian> right
-21:01 <+    rich0> Tend to agree, I think that in practice a month delay won't actually hold anything up by much, since the blockers are still ongoing.
-21:02 <@ Chainsaw> grobian: I think we can move on with that on record?
-21:02 <@  grobian> I'm affraid I'll have to record it, tes
-21:03 <@ WilliamH> Chainsaw: you might want to look at the bug I sited earlier for gen_usr_ldscript in the next month as well.
-21:03 <@  grobian> ok, I want to close this topic now
-21:03 <@  grobian> and move on to the second topic
-21:03 <@  grobian> Policy on "<" versioned dependencies
-21:04 <@ WilliamH> I don't know of one.
-21:04 <@  grobian> did anybody do something ont that one?
-21:04 <@  grobian> if you haven't, I did, and put it in the agenda as gentle help
-21:05 <@  grobian> with that said, I'd like to suggest in this case for devrel to have a look at it
-21:06 <@  grobian> and next to that, I'd suggest that the issue clearly is nasty from a package perspective
-21:06 <+    rich0> afaik there is no policy against < dependencies.  They're reasonably common in my experience.
-21:06 <     _AxS_> grobian: ... specifically what is it devrel would be looking at?  the usage of < deps , or the non-usage of them?  or just a general "get back to us with a policy" ?
-21:06 <+    rich0> But obviously there needs to be some level of cooperation.
-21:06 <@  grobian> which indeed leads to "common sense" + case by case judgment
-21:07 <+    rich0> I think common sense makes more sense than forced policy - if an issue comes up, then we deal with it.
-21:07 <@  grobian> _AxS_: read the bugs
-21:07 <+    rich0> They're obviously discouraged, like ignoring CFLAGS/etc.
-21:07 <@  grobian> rich0: unfortunately we've seen in the past that common sense doesn't really exist
-21:07 <@  grobian> in particular the common part
-21:07 <     _AxS_> grobian: Ah, missed that link, sorry
-21:08 < NeddySeag> Common sense is much rarer than you may suppose.  Its only found in people who agree with the particular PoV
-21:08 <+    rich0> Sure, but rules can be even worse sometimes.  They won't be applied using common sense either.
-21:08 <@  grobian> rich0: I agree with you
-21:08 <+    rich0> I guess the issue is, what's broken here?
-21:08 <@  grobian> hence my suggestions
-21:09 <@  grobian> rich0: for that you'd have to have done your homework
-21:09 <@  grobian> anyone else having something to say here?
-21:09 < NeddySeag> A policy is not a rule, or set of rules.  Its top level guidence
-21:09 <+   graaff> I hate these dependencies in ruby packages, but I love that I can use them to at least provide some llvm support in rubinius.
-21:10 <+   graaff> I hope a policy will reflect that …
-21:10 <@  grobian> can we agree on something like "The council sees no rule that makes it illegal to use < dependencies, and suggests QA to reconsider its behaviour towards other developers that use them."
-21:11 <+   graaff> I would still like to strongly discourage these dependencies
-21:11 <@  grobian> + base-system
-21:11 <@  grobian> fine with mee
-21:11 <+   graaff> Downgrades like these can be very nasty.
-21:12 <@ Chainsaw> As long as it isn't glibc that you're downgrading, life goes on.
-21:12 <@ Chainsaw> These < dependencies sound like a necessary evil to me.
-21:12 <+   graaff> Chainsaw: I don't want to watch up/downgrade fights between different packages
-21:12 <  chithead> if I may add, packages where it leads to serious problems already have checks in place against downgrades
-21:13 <@ Chainsaw> They should be used responsibly and sparingly. But outlawed? Sorry, that seems a bridge too far.
-21:13 <+   graaff> Also, if others use < dependencies for packages it becomes very hard to clean up package revisions and not break the tree.
-21:13 <     _AxS_> it's more the preventing-known-to-break-upgrades that makes these dependencies attractive
-21:13 <@ Chainsaw> And if your consumers keep using < dependencies for your library... think for a minute.
-21:13 <@  grobian> The council sees no rule that makes it illegal to use < dependencies, but strongly discourages the use of them.  It must be noted that for some packages, a downgrade is very undesirable.  This can make some teams to step up.  However, the council requests those teams to act reasonably and in good cooperation with the maintainers of the packages in question.
-21:13 <@ Chainsaw> Who is at fault here?
-21:14 <+   graaff> grobian: I can go with that.
-21:14 <+    rich0> grobian, ++
-21:14 <@scarabeus> i agree
-21:14 <+   graaff> Chainsaw: in my case usually the consumers, but let's discuss that another time :-)
-21:14 <@ Chainsaw> "This can make some teams to step up" is not grammatically correct.
-21:14 <@ Chainsaw> Please adjust.
-21:14 <     _AxS_> grobian: it might possibly be of note here that the package managers might be able to handle the < deps a bit better, too, as portage right now doesn't handle downgrades or prevented-upgrades due to < deps particularily well
-21:14 <@  grobian> Chainsaw: please suggest
-21:14 <@ Chainsaw> grobian: It's not apparent to me what you wanted to say.
-21:15 <@  grobian> ok
-21:15 <@ Chainsaw> grobian: "the use of them" -> "their use"
-21:15 <@ Chainsaw> grobian: Same meaning, lot shorter.
-21:15 <@  grobian> Using a < dependency can trigger some teams to remove a package.
-21:15 <     _AxS_> (note is for the minutes, rather than the statement)
-21:16 <@  grobian> Chainsaw: ^^^ that sentence, would it be clear to you?
-21:16 <@ Chainsaw> graaff: "This has triggered package removals in the past."
-21:17 <@  grobian> ok
-21:17 <@ Chainsaw> That seems to be what you meant?
-21:17 <@  grobian> yeah
-21:17 <@  grobian> However, the council requests the teams responsible for 
-21:17 <@  grobian> that removal to act reasonably and in good cooperation with the maintainers of
-21:17 <@  grobian> the packages in question.
-21:18 <@  grobian> like that?
-21:18 <@Betelgeus> Is there anything new in that?
-21:18 <@  grobian> no, but apparently QA doesn't know
-21:18 <@ Chainsaw> Betelgeuse: Looks like it is our turn to be the voice of reason.
-21:19 <@  grobian> ok. if we all agree please move on to the open bugs
-21:19 <@ Chainsaw> I'm happy to sign off on the revised wording, yes.
-21:19 <@ Chainsaw> Is the jmbsvicetto bug handled?
-21:19 <@ WilliamH> Same here.
-21:19 <@  grobian> can't ask ulm, but apparently he did it
-21:19 <@Betelgeus> it should be easy to verify
-21:19 <@  grobian> I'll send it around for your review anyway, but thanks
-21:19 <@Betelgeus> open the council page and look
-21:20 <@  grobian> seems to me they are there
-21:20 <@  grobian> http://www.gentoo.org/proj/en/elections/council/
-21:20 <@scarabeus> chainsaw the bug is done
-21:20 <+   graaff> ulm didn't specifically mention anything about this to me
-21:21 <@  grobian> ok, let's give him the final ack on it
-21:21 <@ Chainsaw> scarabeus: Excellent.
-21:21 <@  grobian> next, that devmanual update with EAPI5
-21:21 <@  grobian> is there anything we can/should do here
-21:21 <@  grobian> ?
-21:22 <@  grobian> I consider that as a no ;)
-21:22 <@  grobian> ok
-21:22 <@  grobian> Open Floor
-21:22 <@  grobian> anyone who likes to raise an issue?
-21:23 *** Chainsaw turns on the microphone
-21:23 <@ Chainsaw> An orderly queue please. Single file.
-21:23 <     _AxS_> i'd like to commend grobian on the live-summary-writing , which was very effective this meeting
-21:23 <@  grobian> ok, great, so that finishes this meeting
-21:23 <@  grobian> _AxS_: I do that each meeting I chair...
-21:23 <@ Chainsaw> grobian: But it works well, and not all of us can do that.
-21:24 <@  grobian> Next meeting is 11 December 2012, 20:00 UTC, is that ok?
-21:24 <@ Chainsaw> grobian: I freely admit that chairing a meeting takes all my time. I use a note-taker.
-21:24 <@ Chainsaw> grobian: That works for me, yes.
-21:24 <@  grobian> please check the date/time
-21:24 <@ WilliamH> That's good for me also
-21:24 <@  grobian> I don't want to make the same mistake again!
-21:24 <@ Chainsaw> My calendar tells me that is the second Tuesday of December in week 50.
-21:25 <@  grobian> OK!
-21:25 <@  grobian> thank you all
-21:25 <@ WilliamH> Chainsaw: query?
-21:25 -!- grobian changed the topic of #gentoo-council to: Next meeting: 2012-12-11 20:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | http://www.gentoo.org/proj/en/council/
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20121211-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20121211-summary.txt
deleted file mode 100644
index 78bf66cc21..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20121211-summary.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Summary of Gentoo council meeting 11 December 2012
-
-
-Roll Call
-=========
-betelgeuse
-chainsaw
-dberkholz
-grobian
-ulm
-williamh
-
-absent
----------
-scarabeus (1 hour late)
-
-
-Handling separate /usr support
-==============================
-After the discussion on [1] during the previous meeting, a delay of one
-month due to a new fork of udev was requested.  We need an update on
-what's happened.
-
-Chainsaw reported udev and eudev have moved on, and for both it is now
-possible to have a separate /usr.  The follow-up discussion related to
-the /usr-merge is necessary.
-
-
-Define meeting chairs for 2013
-==============================
-For the council meetings taking place in 2013, chairs have to be
-appointed.  grobian will no longer volunteer.
--  8 January   Chainsaw
-- 12 February  Chainsaw
-- 12 March     ulm
--  9 April     ulm
-- 14 May       betelgeuse
-- 11 June      betelgeuse
-
-
-Open bugs with council involvement
-==================================
-Bug 383467 "Council webpage lacks results for 2010 and 2011 elections"
-- ulm has done some work here, but master ballots for 2011 and 2012 are still
-  missing
-
-
-Open Floor
-==========
-gen_usr_ldscript() vs --libdir=/lib.  Questions on why, and if it makes
-sense to remove gen_usr_ldscript in favour of --libdir.  WilliamH will
-open a discussion on gentoo-dev ML.
-
-
-Next meeting date
-=================
-08 January 2012, 20:00 UTC
-
-
-
-[1] https://lkml.org/lkml/2012/10/2/303
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20121211.txt b/xml/htdocs/proj/en/council/meeting-logs/20121211.txt
deleted file mode 100644
index df927d3c89..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20121211.txt
+++ /dev/null
@@ -1,243 +0,0 @@
-20:59 -!- grobian changed the topic of #gentoo-council to: Meeting now |  http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | http://www.gentoo.org/proj/en/council/ | agenda: http://dev.gentoo.org/~grobian/agenda-20121211.txt
-21:00 <@  grobian> yay, ceremony is about to begin
-21:00 *** Chainsaw reports in for a meeting
-21:00 <@  grobian> Betelgeuse: Chainsaw: ulm: dberkholz: WilliamH: scarabeus: ping
-21:00 <+dberkholz> yo
-21:00 <@ Chainsaw> grobian: Good evening. I am present.
-21:01 <@  grobian> cool, prompt responses :)
-21:01 <@      ulm> I'm here
-21:01 < promethea> ok
-21:01 <+dberkholz> now that i've added 3 different reminders, hoping i won't miss any by accident.
-21:01 <@ Chainsaw> dberkholz: The system works!
-21:01 <@  grobian> ohw man, what time is it for you?
-21:01 <@  grobian> luchtime?
-21:01 <+dberkholz> it's 2pm, just tend to get lost in my work
-21:01 -!- sera [~quassel@gentoo/developer/sera] has joined #gentoo-council
-21:02 <@ Chainsaw> dberkholz: Yes, when you're in the zone... I know how it is. Three reminders sounds about right.
-21:03 -!- kmacleod [~ken@mail.trafficware.com] has joined #gentoo-council
-21:04 <@ Chainsaw> Do we have numbers for WilliamH & scarabeus please?
-21:05 <@  grobian> Betelgeuse: scarabeus: WilliamH: re-ping
-21:05 <+dberkholz> while we're waiting, who's going to fosdem?
-21:05 <@ Chainsaw> Oh, and Betelgeuse.
-21:05 <@ Chainsaw> When is that again? Feb?
-21:05 <+dberkholz> yeah first weekend in feb.
-21:05 <+dberkholz> just so happens redmonk's running a conf in london right beforehand too. if you like good beer.
-21:06 <@  grobian> ok, I guess we need to poke some people by phone
-21:08 <@ Chainsaw> dberkholz: "Industrial analysts"?
-21:08 <@      ulm> grobian: you're doing that?
-21:09 <@  grobian> ulm, I'm searching numbers
-21:09 <@  grobian> can use some help
-21:09 <@      ulm> I can text Betelgeuse
-21:09 <+dberkholz> Chainsaw: well, industry analyst. analyzing an industry. in this case that of software development infrastructure.
-21:09 <@  grobian> think I just found scarabeus' number
-21:10 <+dberkholz> Chainsaw: think gartner or forrester but not 5 years behind.
-21:10 <@ Chainsaw> dberkholz: Ah, quite. Just not sure if it's my crowd or not.
-21:11 <+dberkholz> Chainsaw: check out talks from our fall conf in the US, monktoberfest, here: http://redmonk.com/tv/
-21:12 <@      ulm> I've texted WilliamH
-21:12 <@  grobian> oh, cool
-21:12 <@  grobian> I managed to do scarabeus
-21:12 <@  grobian> I'll give it about 5 mins
-21:12 <@      ulm> o.k. Betelgeuse has replied
-21:13 <@Betelgeus> sorry everyone
-21:13 *** WilliamH is here
-21:13 <@  grobian> nice
-21:13 <@      ulm> good :)
-21:13 <@ Chainsaw> No worries. I was fairly sure neither of you would want to miss out on a good controversial subject.
-21:13 -!- blueness [~hnsctq40@gentoo/developer/blueness] has joined #gentoo-council
-21:13 <@ Chainsaw> Evening blueness.
-21:13 <@  grobian> hehe
-21:13 <  WilliamH> heh
-21:13 <  blueness> plop!
-21:13 <@Betelgeus> Should the Gentoo calendar gain notifications?
-21:14 <@Betelgeus> Granted it could be annoying for some
-21:14 <  blueness> afternoon Chainsaw
-21:14 <@Betelgeus> dberkholz: I will be in Fosdem
-21:14 <@Betelgeus> dberkholz: trip is already booked
-21:14 <  WilliamH> I've been here just distracted by researching a personal matter.
-21:15 <@ Chainsaw> Shall we make a start then?
-21:15 <@  grobian> I think so yes
-21:15 <@  grobian> ok
-21:15 <@  grobian> agenda is online :)
-21:15 <@ Chainsaw> The handling of separate /usr support.
-21:15 <@  grobian> start with topic no 1?
-21:16 <@  grobian> Chainsaw: grab the mic
-21:16 <@ Chainsaw> So last month, I asked for a delay on deciding so that eudev had a chance to materialise.
-21:16 <@ Chainsaw> It was called udev-ng at the time, and it has been through a little publicity stunt that udev upstream organised for us.
-21:16 <@ Chainsaw> As promised last meeting, there is an ebuild in the tree that you can look at.
-21:17 <@ Chainsaw> There's a bug tracker and there's a plan.
-21:17 <@ Chainsaw> I feel that udev upstream can no longer hold us hostage, and that we have multiple choices now.
-21:18 <@ Chainsaw> This way, even a newer udev can be moved towards stable and I have my exit strategy.
-21:18 <  WilliamH> The other side is moving forward also.
-21:18 *** WilliamH waits, I didn't mean to interrupt
-21:18 <@ Chainsaw> I am happy with our original stance on separate /usr support, in that it has to work. I think both udev & eudev can now do that.
-21:19 <@ Chainsaw> With & without an initrd. Especially the latter is important to me.
-21:20 <@ Chainsaw> So, I don't think we actually need to change anything here. Except I will now drop any concerns I had with udev.
-21:20 *** Chainsaw passes the microphone to WilliamH 
-21:21 <  WilliamH> I still want to look into the gen_usr_ldscript issue and why we are splitting up where we install libraries.
-21:21 <@  grobian> isn't that sort of separate from this issue?
-21:21 <@ Chainsaw> WilliamH: I remain a firm disbeliever of the /usr merge.
-21:22 <  WilliamH> We are forcing shared libraries to /lib* but not moving static libraries along with them.
-21:22 <@ Chainsaw> grobian: But agreed, that is wholly separate of the separate /usr matter and of the udev stabilisation.
-21:22 *** WilliamH isn't talking about the /usr merge.
-21:22 <@ Chainsaw> WilliamH: It really sounds like you are.
-21:22 <      ryao> So... Chainsaw asked me to add a comment of mine here. With regard to separate /usr, we should mandate that rules that depend on /usr go into /usr instead of /, which can be handled inside the ebuild.
-21:22 <  WilliamH> Chainsaw: give me a second.
-21:23 <     _AxS_> grobian: gen_usr_ldscript is separate from this issue, but it is the key motivator for why WilliamH tabled the issue last meething
-21:23 <  WilliamH> I'm going to refer to an actual ebuild, let me get the info
-21:23 <      ryao> That would make it possible to support a separate /usr in both sys-fs/eudev and sys-fs/eudev. The simplest way would be to have a udev-post-umount script that would do `udevadm trigger` after the /usr mount. That is all that we need to make it work.
-21:23 <@  grobian> ryao, _AxS_: I'd like to focus on the udev/eudev topic for now
-21:24 <  WilliamH> util-linux-2.22.ebuild.
-21:24 <      ryao> s:sys-fs/eudev and sys-fs/eudev:sys-fs/eudev and sys-fs/udev:
-21:24 <      ryao> That ignores the fact that sys-fs/udev is installing into /usr, although sys-fs/eudev does not do that.
-21:24 <  WilliamH> Lines 103-104. That moves the shared libraries to /lib* but leaves the static libraries in /usr/lib*
-21:25 <  WilliamH> Shouldn't we just use --libdir= when we configure the package and move all of the libraries to / if that's what we are going to do?
-21:25 <@  grobian> WilliamH: yeah, that's because of this bug that;s referenced from the func about the linker searching and doing static linking first or something
-21:26 <      ryao> Bug #4411
-21:26 < willikins> ryao: https://bugs.gentoo.org/4411 "sys-devel/gcc uses static libs in /usr/lib before it will use a dynamic lib in /lib"; Gentoo Linux, Core system; RESO, FIXE; drobbins:toolchain
-21:26 <  WilliamH> grobian: but why did we split up the libs to begin with and not use --libdir= on the configure call?
-21:26 <@  grobian> WilliamH: I'm willing to discuss that, but I'd like to split that off from here
-21:27 <@  grobian> we can talk about it in the open floor
-21:27 <@ Chainsaw> grobian: Can we do that as AOB?
-21:27 <  WilliamH> aob?
-21:27 <@ Chainsaw> WilliamH: Any Other Business
-21:27 <  WilliamH> oh
-21:27 <  WilliamH> ok. :)
-21:27 <@  grobian> although I think this is excellent material for more than just council peeps to contribute to (i.e. mailing list)
-21:28 <@  grobian> ok, so do we agree on that this is it for this topci then?
-21:29 <@  grobian> good., meeting chairs then
-21:29 <@  grobian> who wants
-21:29 <@  grobian> we have this nice list
-21:29 <@ Chainsaw> Full of empty places.
-21:29 <@  grobian> why don't you all do a bid for a date
-21:29 <@      ulm> I could do feb or march
-21:29 <@ Chainsaw> Happy to do January 8.
-21:30 <+dberkholz> i'd like to see people do 2 or 3 in a row
-21:30 <@  grobian> if you reload frequently, you should see change
-21:30 <@  grobian> dberkholz: +1
-21:30 <@ Chainsaw> Jan & Feb for me then.
-21:30 <@  grobian> ulm can you do april?
-21:30 <@      ulm> just looking
-21:31 <@      ulm> yeah, should be fine. March 12 and April 9 for me then
-21:31 <@  grobian> Chainsaw: feel free to assign someone to do the summary stuff, or whatever
-21:31 <@  grobian> ok, then we have two slots left
-21:31 <@  grobian> shall we give them to scarabeus? :P
-21:32 <+dberkholz> unfortunately may-june will likely suck with my travel schedule or i would offer.
-21:32 <@ Chainsaw> All in favour of assigning scarabeus to the two remaining slots, say aye.
-21:32 <@  grobian> haha
-21:32 <@  grobian> WilliamH: ?
-21:32 <@  grobian> Betelgeuse: ?
-21:32 *** WilliamH would offer but I just  got some news that may affect things for me by that time frame.
-21:33 <@  grobian> alternative: we'll leave them open, for later meetings to decide
-21:33 <@Betelgeus> grobian: I can take the rest of slots
-21:33 <@  grobian> ok
-21:33 <@  grobian> splendid
-21:33 <  WilliamH> I'll still be here I'm sure but I don't know about having time to chair then.
-21:33 <@  grobian> that's all set then
-21:33 <@  grobian> cool
-21:33 <@  grobian> open bugs
-21:33 <@  grobian> ulm, is bug 383467 sufficiently closed for you?
-21:33 < willikins> grobian: https://bugs.gentoo.org/383467 "Council webpage lacks results for 2010 and 2011 elections"; Website www.gentoo.org, Projects; CONF; hwoarang:jmbsvicetto
-21:34 <@      ulm> master ballots for 2011 and 2012 are still missing
-21:35 <@  grobian> can you update the bug, please
-21:35 <@      ulm> yeah, will do
-21:35 <@  grobian> ok, cool
-21:35 <@  grobian> then we're ready for open floor
-21:36 <@  grobian> anyone who wants to grab the mic?
-21:36 *** Chainsaw passes the mic to WilliamH 
-21:36 <  WilliamH> I just wanted to talk about the use of gen_usr_ldscript vs --libdir=
-21:36 *** grobian plugs the chord into the amplifier
-21:36 <@  grobian> yeah
-21:37 <  WilliamH> I don't know why we split libs up and install static libs in /usr/lib then force shared libs to /lib.
-21:37 <@  grobian> I think its partly legacy
-21:37 <@  grobian> not all build-systems understand that
-21:37 <  WilliamH> If we are going to support separate /usr, shouldn't we just use --libdir= and be done with it?
-21:37 <@  grobian> I'd say not
-21:38 <  WilliamH> I don't know of any build systems that separate shared vs static libs.
-21:38 <@  grobian> because gen_usr_ldscript can be a noop, while --libdir would require some argument like $(get_libdir_for_usr_merge)
-21:38 <  WilliamH> No, I'm not talking about the  /usr merge.
-21:38 <@  grobian> which means, we already have it in place now, with almost zero cost
-21:38 <@  grobian> instead of having to change each ebuild
-21:38 <     _AxS_> grobian: i think his point would be that anything necessary for when /usr is unmounted gets a libdir=/lib for all items (.so, .a, .la, etc)
-21:39 <@  grobian> yeah, but you only want those libs there that you need
-21:39 <  WilliamH> or
-21:39 <@  grobian> like for curses
-21:39 <  WilliamH> maybe a use flag, sep-usr
-21:39 <  WilliamH> busybox has a use flag like that.
-21:39 <@  grobian> in Prefix I solved it with a special variable
-21:40 <@  grobian> new installs have gen_usr_ldscript as noop
-21:40 <  WilliamH> Actually it is solved in gen_usr_ldscript already in prefix.
-21:40 <  WilliamH> It uses the prefix use flag to test
-21:40 <  WilliamH> hang on
-21:41 <@  grobian> I think it is more important to decide on the direction than the implementation here
-21:41 <  WilliamH> give me a second to look, that's how it was when I looked last.
-21:41 <@  grobian> I'd prefer to keep gen_usr_ldscript
-21:41 <     _AxS_> might it be pertintent to know why gen_usr_ldscript and/or the status-quo is so undesirable?
-21:41 <     _AxS_> from a technical perspective?
-21:41 <@  grobian> WilliamH: http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/eclass/toolchain-funcs.eclass#L623
-21:42 <  WilliamH> grobian: look at toolchain-funcs.eclass, the case statement starting on line 621.
-21:42 <@  grobian> _AxS_: I don't understand
-21:42 <@  grobian> WilliamH: the one in gx86 is random/wrong
-21:42 <@  grobian> look at the version prefix people use
-21:42 <@  grobian> the link above
-21:44 <     _AxS_> grobian: WilliamH is significantly opposed to the current resolution for bug 4411 (usage of gen_usr_ldscript to manage shared libs in / with static libs etc in /usr) , i was wondering if it would be pertinent to this forum to mention the technical reasons why this method is so undesireable and needs to change
-21:44 < willikins> _AxS_: https://bugs.gentoo.org/4411 "sys-devel/gcc uses static libs in /usr/lib before it will use a dynamic lib in /lib"; Gentoo Linux, Core system; RESO, FIXE; drobbins:toolchain
-21:44 <@  grobian> _AxS_: linking statically iso shared?
-21:45 <@  grobian> that sounds obvious to me, but is that what you're asking?
-21:45 <     _AxS_> grobian: i think you answered why we need gen_usr_ldscript.  I want to know why we need to get rid of it, in favour of say using --libdir=/lib instead
-21:46 <@  grobian> _AxS_: I'd say people see it as the reason /lib is necessary, and hence want to remove it
-21:46 <     _AxS_> are there any other technical reasons for it being bad?
-21:46 <@  grobian> I don't  think it's bad at all
-21:46 <     _AxS_> WilliamH: ?  your motivations?
-21:46 <  WilliamH> grobian: so what's wrong with how g-x86 does this?
-21:46 <@  grobian> well, it's odd of course ;)
-21:47 <@  grobian> WilliamH: it's not being used in practice (the prefix bits)
-21:47 <@  grobian> _AxS_: I think for systems that have /lib, gen_usr_ldscript currently does what it should do, in the tree, so it's good as it is
-21:48 <  WilliamH> Bug 4411 was caused hit because we started splitting things, I'm just trying to figure out why we started splitting things to begin with.
-21:48 < willikins> WilliamH: https://bugs.gentoo.org/4411 "sys-devel/gcc uses static libs in /usr/lib before it will use a dynamic lib in /lib"; Gentoo Linux, Core system; RESO, FIXE; drobbins:toolchain
-21:48 <@  grobian> _AxS_: in that sense, killing it just for the sake that what it does looks weird looks wrong to me
-21:48 <  WilliamH> I don't know why we started splitting up where libs go to begin with.
-21:49 <@  grobian> WilliamH: if you want to run a binary (/bin/bash) from your / mounted partition that needs a shared library, it needs to be on that / mounted partition too
-21:49 <@  grobian> so, libcurses is in /lib
-21:49 <  WilliamH> Right, but shouldn't we also put the static library there too?
-21:49 <@  grobian> no, because we'll never need it
-21:49 <  WilliamH> libncurses.a in /lib as well?
-21:49 <@      ulm> WilliamH: it's not needed at runtime
-21:49 <@      ulm> so no reason to keep it in /
-21:50 <@  grobian> you're not going to compile ever when you're in the crisis of not being able to mount your /usr
-21:50 <@  grobian> and / was space-constrained
-21:50 <  WilliamH> Wouldn't it be worth writing a patch to autotools to support separate library directories then?
-21:50 <@  grobian> so you're not going to put any more in there than you need
-21:50 <@  grobian> WilliamH: hard to define what is necessary in /lib and what not
-21:50 <@  grobian> depends on what you install in /bin
-21:51 <@  grobian> if you are happy with busybox (which is one big statically linked blob), you don't need much in /lib
-21:51 <  WilliamH> I mean make it support something like --static-libdir= --shared-libdir= ...
-21:52 <  WilliamH> Autotools only supports one libdir. should it support two, one for shared and one for static libs?
-21:52 <@  grobian> the thing is, the static lib is only interesting for certain people these days
-21:52 <@  grobian> I guess autotools upstream would say you just build twice, once shared, once static
-21:52 <@  grobian> (works fine for binary distros)
-21:53 -!- Philantrop [Philantrop@exherbo/developer/philantrop] has joined #gentoo-council
-21:55 <  WilliamH> grobian: Do you know if anyone has proposed separate libdirs to them though?
-21:55 <  WilliamH> I think autotools builds both library types in the same pass doesn't it?
-21:56 <@  grobian> WilliamH: no, but given how long UNIX systems are doing this ....
-21:56 <@  grobian> really depends on the build-system
-21:56 <@  grobian> libtool knows that it can repackage the objects in an archive, or link them in a shared object
-21:56 <     _AxS_> WilliamH: autotools is very dependent on just one libdir -- other installation types are fairly easy to change the install location of, libraries is not one of them.
-21:57 <@  grobian> some upstreams first build the archive, then tell the linker to create a shared object
-21:57 <@  grobian> other makefiles only support one of the two, so you have to call it twice with a different target, and reuse the coincidentally still available built objects
-21:58 <     _AxS_> still, what would doing this at configure time rather than install/pkg_postinst time gain us?
-21:59 <@  grobian> I guess in effect it gains us nothing, because we're just doing the work in another way
-21:59 <@  grobian> and we shove more stuff in /lib
-21:59 < scarabeus> ah fuck
-21:59 < scarabeus> i thought the meeting starts now
-22:00 <@  grobian> lol
-22:00 <     _AxS_> scarabeus: :)  did you want to chair some meetings in 2013?
-22:00 <     _AxS_> you might have to bump someone...
-22:01 <@  grobian> WilliamH: _AxS_: shall we close the meeting?
-22:01 < scarabeus> grobian: also seems it was not mine number :P (i have only one since i bought phone so that one aint workign)
-22:01 <  WilliamH> go ahead and close it for now.
-22:01 <@  grobian> I used the one you emailed
-22:01 <  WilliamH> I may bring up gen_usr_ldscript on -dev.
-22:01 <@  grobian> ok, meeting closed, thanks all
-22:01 <@  grobian> WilliamH: good
-22:01 <@      ulm> grobian: thank you for chairing
-22:01 -!- grobian changed the topic of #gentoo-council to: Next meeting: 2013-01-08 20:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | http://www.gentoo.org/proj/en/council/
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130108-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20130108-summary.txt
deleted file mode 100644
index 576de301d8..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130108-summary.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-Roll Call
-=========
-betelgeuse
-Chainsaw
-dberkholz
-grobian
-scarabeus
-ulm
-WilliamH
-
-
-Stable USE masks in the main Portage tree
-=========================================
-Vote on proposal "Stable USE masks in the main portage tree" by
-Michał Górny [1].  There are three suggested approaches:
-1) by adding new profiles requiring EAPI=5, requiring all users to
-   change, and then deprecating the older profile trees [if chosen; a
-   subsequent vote on the timeframes involved will follow]
-2) by adding new profiles and using USE-flag masking to keep current
-   profiles functional
-3) defining use.stable.mask features such that they only apply to EAPI>5
-   ebuilds
-
-Note: option 1) requires a decision on the deprecation timeframe.
-
-The council agreed unanimously to vote between the three proposed solutions. 
-Solution #1 won with 7 votes.
-A remark was made by grobian that BSD and Prefix profiles are unversioned as
-noted by the initial email [1] introducing the solutions, and that they need
-some care and consideration, best dealt with directly with BSD and Prefix
-teams.
-The deprecation timeframe for pre-EAPI-5 profiles was voted 6 to 1 to be 1
-year.
-There was no agreement on whether this is a minimum or maximum of waiting time.
-Some even argued that this was a matter of standard deprecation policies.
-This period is bound to a possible deprecation of older EAPIs, and influenced
-the duration of the timeframe, for some council members to be at least 1 year,
-instead of maximum.
-
-
-Open bugs with council involvement
-==================================
-Bug 383467 "Council webpage lacks results for 2010 and 2011 elections"
-- For bug #383467 to be closed, the master ballots for 2011 & 2012 will
-  need to be uploaded & linked.
-  jmbsvicetto uploaded some missing data, but the 2012 results and rank 
-  are still missing. The bug remains open.
-
-
-Any Other Business
-==================
-No issues were raised by council members.
-
-Open Floor
-==========
-User johu asked who would document the "one year end of support" decision and
-where.  The council documents the decision in the summaries, which are
-binding.
-Zero_Chaos wanted to know the opinion of Council on micro EAPIs, to work
-around the relatively high amount of time necessary to complete a full new
-EAPI.  The council replied that EAPI features simply should be in PMS, and that
-the most work goes in there. Assistance is welcomed.
-
-
-Next meeting date
-=================
-12 February 2013, 20:00 UTC
-
-
-
-[1] http://www.gossamer-threads.com/lists/gentoo/dev/263988
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130108.txt b/xml/htdocs/proj/en/council/meeting-logs/20130108.txt
deleted file mode 100644
index 0b9c9bd6a7..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130108.txt
+++ /dev/null
@@ -1,313 +0,0 @@
-19:34 -!- Chainsaw [~chainsaw@gentoo/developer/chainsaw] has joined #gentoo-council
-19:35 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
-19:50 -!- willikins [~rbot@gentoo/bot/Willikins] has quit [Quit: seeya]
-20:43 -!- willikins [~rbot@gentoo/bot/Willikins] has joined #gentoo-council
-20:43 -!- Zero_Chaos [~zero@gentoo/developer/pentoo/zerochaos] has joined #gentoo-council
-20:46 *** WilliamH is here just working on udev
-20:46 *** Chainsaw ensures that the champagne carriers are at the entrance doors
-20:46 *** grobian wonders about all the whispering
-20:46 < Zero_Chao> darnit, they weren't there when I walked in
-20:47 -!- Zero_Chaos [~zero@gentoo/developer/pentoo/zerochaos] has left #gentoo-council []
-20:47 -!- Zero_Chaos [~zero@gentoo/developer/pentoo/zerochaos] has joined #gentoo-council
-20:47 < Zero_Chao> oh yeah, champagne
-20:47 -!- mgorny [~mgorny@gentoo/developer/mgorny] has joined #gentoo-council
-20:47 <  WilliamH> Sounds good to me. :-)
-20:47 <@ Chainsaw> Evening mgorny.
-20:47 <    mgorny> Chainsaw: evening to you too
-20:47 <@ Chainsaw> mgorny: Since your proposal is the main agenda item, I would like for you to be here.
-20:47 <    mgorny> btw it's usually better to ping me
-20:48 <    mgorny> invites are hardly distinguished
-20:48 <@ Chainsaw> mgorny: As always... proud to be different.
-20:48 <  WilliamH> Chainsaw: This udev thing is going to be able to be done w/o a use flag I think.
-20:48 <@ Chainsaw> WilliamH: _AxS_ provided a convincing argument, yes.
-20:48 <  WilliamH> Chainsaw: I can drop a file in /etc/udev/rules.d and leave it there... tell you to remove it when you are ok with it.
-20:49 <@ Chainsaw> WilliamH: Indeed. It looks like udev upstream implemented an opt-in change. Forgive my surprise. This is out of character.
-20:49 <  WilliamH> What they are doing is giving you a default if you don't have something else already set up.
-20:50 <  WilliamH> I'm not that much of a kernel guy, but I guess that if you have multiple interfaces messing with the eth* names can be a mess.
-20:51 < scarabeus> so what shall we broke this time
-20:51 <+dberkholz> can this udev stuff go back to #-dev unless it's currently relevant to the council?
-20:51 <  WilliamH> scarabeus: nothing by default.
-20:51 < scarabeus> I checked hard to ensure getting here on right time :P
-20:51 <  WilliamH> scarabeus: we get to prepare for this one.
-20:52 <@ Chainsaw> Betelgeuse is here as well. That's good.
-20:52 <  WilliamH> scarabeus: This is what is coming for network interface names. http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
-20:52 <  WilliamH> scarabeus: but we can prepare for this.
-20:53 <@ Chainsaw> Wait, Betelgeuse has been parked there for 28 hours. He's going to get a ticket...
-20:54 <@ Chainsaw> Looks like ulm is around though.
-20:54 <@      ulm> here
-20:54 <@ Chainsaw> Excellent.
-20:54 <@      ulm> did we start early?
-20:54 <@ Chainsaw> I wouldn't dare.
-20:55 <@ Chainsaw> Just making sure everyone is lined up, so we can start on time.
-20:55 <@ Chainsaw> If there's a number for Betelgeuse... can we send him a quick 5 minute warning?
-20:55 <@  grobian> I'm working on a pot of tea here, should be ready in time
-20:55 < scarabeus> grobian: btw remember your sms? it arrived next morning (i just recalled i wanted to tell ya)
-20:56 <@  grobian> scarabeus: COOL! so it DID work
-20:56 <@  grobian> scarabeus: so sorry to hear, at least proves I didn't lie
-20:57 <@ Chainsaw> Did someone text Betelgeuse please?
-20:59 <@ Chainsaw> If not, now is a great time.
-20:59 <@ Chainsaw> Or an outright phone call perhaps.
-21:00 <@ Chainsaw> Okay. Zero hour.
-21:00 <+dberkholz> hi
-21:00 <@      ulm> Chainsaw: I'm going to text him
-21:00 <@ Chainsaw> Good evening.
-21:01 <@ Chainsaw> ulm: It is appreciated. Let's give him 5 minutes to surface.
-21:01 <@  grobian> here
-21:01 *** ulm still here
-21:01 <@  grobian> scarabeus: you're here too now, right?
-21:01 <@ Chainsaw> According to my calculations, we have everyone except Betelgeuse.
-21:01 *** WilliamH still here just testing udev.
-21:01 <@  grobian> ps, I'm doing the agenda/summary thing online, Chainsaw is chairing
-21:01 <+dberkholz> whoa. duncan had a good, short email.
-21:01 <+dberkholz> totally didn't even see it till now
-21:02 <@Betelgeus> ulm: thanks
-21:03 <@ Chainsaw> Betelgeuse: Excellent. Welcome :)
-21:03 <@      ulm> Betelgeuse: np :)
-21:03 <@ Chainsaw> Now that we have everyone, to the order of the day.
-21:03 <@ Chainsaw> mgorny has a proposal to implement stable USE masks.
-21:03 < scarabeus> yep yep
-21:03 <@ Chainsaw> mgorny: Did you agree with my summary on the agenda please?
-21:04 <  WilliamH> Can someone link the agenda real quick?
-21:04 <@  grobian> it's in topic
-21:04 <@ Chainsaw> WilliamH: http://dev.gentoo.org/~grobian/agenda-20130108.txt
-21:04 < scarabeus> WilliamH: http://dev.gentoo.org/~grobian/agenda-20130108.txt
-21:04 <@  grobian> http://dev.gentoo.org/~grobian/agenda-20130108.txt
-21:04 <@  grobian> so
-21:04 < scarabeus> :D
-21:05 <@Betelgeus> for the summary a link to the mailing list would be good
-21:05 <@ Chainsaw> So to confirm, we have three possible approaches.
-21:05 <    mgorny> Chainsaw: hmm, yes
-21:05 <@ Chainsaw> mgorny: I'm glad.
-21:05 <+dberkholz> here's the thread: http://www.gossamer-threads.com/lists/gentoo/dev/263988
-21:05 <    mgorny> i'd just like to make clear that 3) would mean that not profiles EAPI but ebuild EAPI would matter
-21:05 <+dberkholz> there's probably a version on archives.g.o but it didn't pop up in google as quickly
-21:06 <@      ulm> I think that option 3 is a no-go
-21:06 <@ Chainsaw> So first things first, does the council want to vote in stable USE masks? This is a yes/no; in case of "no" we push back -dev for further discussion.
-21:06 < scarabeus> 3 is bad idea
-21:06 <@  grobian> dberkholz: archives is disabled for months now
-21:06 <@ Chainsaw> If we agree we want to vote it in, we can discuss the 3 different options.
-21:06 *** grobian agrees with ulm
-21:07 <+dberkholz> that's still broken? no wonder i haven't been using it.
-21:07 <@  grobian> Chainsaw: doesn't it already exist (EAPI 5)
-21:07 <+dberkholz> indeed. http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-580005.2.11
-21:07 <@ Chainsaw> grobian: Even if it already exists, you need to vote "yes" to this list of three so we can pick one.
-21:07 <@      ulm> grobian: it's in EAPI 5, but profiles are at lower EAPIs
-21:08 <@ Chainsaw> grobian: Because "none of the below" is an answer too, and saves me taking you to three options.
-21:08 <@  grobian> Chainsaw: then I vote for actually voting for a solution to this problem
-21:08 *** Chainsaw records grobian as "yes"
-21:08 < scarabeus> record mine too
-21:08 <@Betelgeus> yes
-21:08 <+dberkholz> yes.
-21:08 <@      ulm> yes
-21:08 *** Chainsaw votes "yes"
-21:08 <@ Chainsaw> Excellent.
-21:09 *** WilliamH votes yes
-21:09 <@ Chainsaw> I do like unanimous votes.
-21:09 <@ Chainsaw> So, option 3 seems unpopular.
-21:09 <@ Chainsaw> Do we scrap it as unworkable?
-21:09 < scarabeus> i feel particulary fond of #1
-21:09 <@      ulm> Chainsaw: please do
-21:09 <+dberkholz> i'm for 1.
-21:09 <@ Chainsaw> I am strongly leaning towards option 1 myself.
-21:09 <  WilliamH> Option 3 is what w already have isn't it?
-21:10 <@  grobian> option 3) can be removed
-21:10 <@      ulm> 1, with sufficiently long transition time
-21:10 <@ Chainsaw> Voting is between options 1 & 2.
-21:10 <@ Chainsaw> Let's try a yes/no vote for option #1.
-21:10 <+dberkholz> yes
-21:10 <@  grobian> I have wee problem with Prefix and BSD profiles
-21:10 <@  grobian> they are unversioned
-21:10 <@ Chainsaw> grobian: Can you not address that in the proposed sweeping change?
-21:10 <@ Chainsaw> grobian: Option #1 mandates action for all users.
-21:10 <@  grobian> my personal take was to actually just up the eapi to 5 for Prefix
-21:11 <@  grobian> but I don't know what BSD wants to do
-21:11 <@ Chainsaw> grobian: Should I read that as an abstention or a negative vote?
-21:11 <@  grobian> Chainsaw: what would you propose for the sweep change then?
-21:11 <@Betelgeus> It used to be the case that users regularly had to switch profiles
-21:11 <@  grobian> nah, in general I'm for 1), but I'd like to put a note here that not all profiles are versioned
-21:12 < scarabeus> you can create new versioned profiles?
-21:12 <@  grobian> I guess we can
-21:12 <@  grobian> in Prefix we won't
-21:12 *** WilliamH doesn't see a problem with upping the eapi for *bsd or prefix
-21:12 <@  grobian> so BSD is left
-21:12 <@ Chainsaw> scarabeus: That is what I suggested, yes. Now that user action is needed, implement it there and then.
-21:12 <@Betelgeus> any way with Display-If-Profile it's easy to bug peopleas many times as we want
-21:12 <@  grobian> WilliamH: no problem indeed, just a matter of timeframe, as ulm pointed out
-21:12 < scarabeus> yes we can show them news item
-21:12 <@ Chainsaw> grobian: So. This is a yes/no vote. I have a yes from dberkholz. Are you an abstain, no or yes?
-21:13 < scarabeus> Chainsaw: yes for me
-21:13 <@  grobian> Chainsaw: my vote goes to 1)
-21:13 *** ulm notes that until few years ago, we used to update profile much more often
-21:13 *** scarabeus would actually preffer per year basis
-21:13 <@      ulm> I vote yes for 1, too
-21:13 *** WilliamH votes yes for 1
-21:13 < scarabeus> so users wont forget :P (with each eapi it can be bond)\
-21:13 *** Chainsaw votes yes on #1
-21:13 <@Betelgeus> yes
-21:14 <@ Chainsaw> That looks unanimous.
-21:14 <  WilliamH> When you deprecate a profile users start getting warnings to move away from it right?
-21:14 <@ Chainsaw> WilliamH: Yes.
-21:14 <  WilliamH> You depricate by adding a file to the profile directory.
-21:14 <  WilliamH> afaik
-21:14 <@ Chainsaw> WilliamH: At the end of every emerge --sync cycle, from what I recall.
-21:14 < scarabeus> does it show timeframe?
-21:14 <@ Chainsaw> Now that option #1 has been chosen, we will need to put a timeline together.
-21:15 < scarabeus> ege deprecated will be removed  in <countdown>
-21:15 <  WilliamH> scarabeus: I think it is just a txt file so you can put what you want in there.
-21:15 < scarabeus> WilliamH: excelent
-21:15 <@ Chainsaw> The deprecation marks are easy enough to insert. However, the old profiles will need to be kept around.
-21:15 < Zero_Chao> When a profile is deprecated you get a warning every time emerge runs. It simply says your profile is deprecated and to move to a new one.
-21:15 <+dberkholz> indefinitely?
-21:15 < scarabeus> i would go with 1-2years
-21:15 <@ Chainsaw> dberkholz: I wouldn't say until the end of time, no.
-21:15 <+dberkholz> our support period is 1 year at best for anyone who isn't a super expert
-21:15 <@ Chainsaw> But a year seems reasonable.
-21:16 <@      ulm> one year sounds good to me
-21:16 *** Chainsaw proposes a yes/no vote for a 1 year deprecation period for current EAPI<5 profile trees
-21:16 <  WilliamH> I think we can go less than a year. How long do we keep old profiles around for releases?
-21:16 < scarabeus> yes
-21:16 <@  grobian> not less than a year
-21:16 *** grobian votes for 1 year
-21:16 *** Chainsaw votes "yes" on 1 year
-21:16 <@      ulm> yes
-21:16 <@  grobian> at least
-21:16 <@ Chainsaw> And indeed, that is a minimum, not a maximum.
-21:17 *** WilliamH votes yes for a year I guess...
-21:17 <+dberkholz> can/should we add a commit lock to the old profiles then?
-21:17 <@  grobian> no
-21:17 <@  grobian> this also fuels the discussion of deprecation of EAPIs of course
-21:18 <@ Chainsaw> grobian: Provided we can agree on a timeline, that becomes more feasible at a later time.
-21:18 <+dberkholz> Zero_Chaos: it also recommends a specific new profile, iirc
-21:18 <@Betelgeus> I don't think this needs a separate timeline the general upgrade support timelines are enough
-21:18 <@  grobian> yup, just saying as it's tied to the timeline, IMO
-21:18 <@ Chainsaw> dberkholz: Vote for 1 year? Yes/no/abstain?
-21:18 <+dberkholz> i guess my vote would be for 1 year as a max.
-21:18 <@      ulm> we can always reconsider things at the end of the transition period
-21:19 <@ Chainsaw> dberkholz: That's a yes really.
-21:19 <@      ulm> and extend it if necessary
-21:19 <+dberkholz> Chainsaw: it was till you started changing the wording halfway through =)
-21:19 <@ Chainsaw> dberkholz: A no then?
-21:20 <+dberkholz> well, frankly i'm confused
-21:20 < Zero_Chao> dberkholz: I couldn't specifically recall that.
-21:20 <  WilliamH> Are we voting for deprecation of eapis now?
-21:20 <+dberkholz> is your vote what you originally proposed? or is it "And indeed, that is a minimum, not a maximum."
-21:21 <+dberkholz> i can't tell if that's part of the proposal or appended to your individual vote
-21:21 <@ Chainsaw> WilliamH: Removal of the old EAPI<5 profile trees.
-21:21 <@ Chainsaw> WilliamH: Still.
-21:21 <  WilliamH> Chainsaw: ok...
-21:21 <@ Chainsaw> dberkholz: That's a clarification of my individual position.
-21:21 <+dberkholz> ok.
-21:22 <+dberkholz> in that case, my vote is yes.
-21:22 <+dberkholz> i would prefer 6 or even 3 months, but i'm ok with a year.
-21:22 <@ Chainsaw> dberkholz: That's compromise for you.
-21:22 *** WilliamH thinks a year is long enough to keep them around
-21:22 <@ Chainsaw> Unanimous then?
-21:22 <+dberkholz> can bundle up old profiles with a rescue portage or something, if we need more.
-21:23 *** WilliamH agrees with dberkholz  too; there isn't really reason to keep them a year.
-21:23 <@      ulm> dberkholz: a shorter transition period will likely break the upgrade path for users
-21:23 <@Betelgeus> Chainsaw: I still think this doesn't need a special policy
-21:23 <@ Chainsaw> Betelgeuse: Abstain? Okay.
-21:23 <@      ulm> if no profile with eapi < 5 is present, they canot update portage to eapi 5
-21:23 <@      ulm> *cannot
-21:24 <@Betelgeus> Chainsaw: I would record a no.
-21:24 <+dberkholz> ulm: for anyone syncing less than once every three months and also not reading -announce? perhaps they're in need of rescuing =)
-21:24 <@ Chainsaw> Betelgeuse: As you wish.
-21:24 <  WilliamH> ulm: they will be getting messages every time they
-21:24 <@ Chainsaw> grobian: That's 6 in favour and 1 against. The motion carries.
-21:24 <  WilliamH> ulm: emerge --sync telling them a profile is deprecated.
-21:24 <@Betelgeus> Chainsaw: Technically it would be closer to a competing measure.
-21:24 <@      ulm> dberkholz: we previously decided that we would provide an upgrade path for 1 year
-21:24 <@      ulm> for stable systems
-21:24 <@Betelgeus> indeed
-21:24 <@ Chainsaw> On the open bugs with council involvement, I'm pleased to report that the two missing master ballots have been located & uploaded.
-21:25 <+dberkholz> that's why i mentioned a rescue portage.
-21:25 <@      ulm> Chainsaw: finally!
-21:25 <+dberkholz> freeze the profiles and throw 'em in a tarball.
-21:25 <@ Chainsaw> ulm: As such, could you please close the bug as FIXED?
-21:25 *** WilliamH agrees with dberkholz 
-21:25 < scarabeus> dberkholz: actually we could provide it for any nuts with no-longer-sync tree, could releng do such things?
-21:25 <@  grobian> Chainsaw: can the bug be closed then?
-21:25 < scarabeus> jmbsvicetto: mate, you around? read this ^
-21:25 <@ Chainsaw> grobian: Yes.
-21:26 <@  grobian> DOIT
-21:26 <@  grobian> :P
-21:26 <@ Chainsaw> grobian: ulm was the last to post, I would like for him to confirm he is happy that all is resolved.
-21:27 <@      ulm> Chainsaw: results and rank still missing
-21:27 <@      ulm> for 2012
-21:27 <@  grobian> haha
-21:27 <@      ulm> but maybe we should close it nevertheless
-21:27 <+dberkholz> bbiab
-21:27 <@      ulm> it's on the table way too long
-21:27 <@ Chainsaw> ulm: Okay. Could you post the new status to the bug and leave it open then please?
-21:27 <@ Chainsaw> ulm: It stays on the table until it is sorted.
-21:28 <@      ulm> will do
-21:28 <@ Chainsaw> Any other business from the council?
-21:28 <@ Chainsaw> Or shall we open the floor to the community at this point?
-21:29 <@  grobian> I have nothing to raise
-21:29 <@ Chainsaw> Okay, thank you.
-21:29 <@ Chainsaw> Anyone wishing to raise issues with the council at this point? The floor is open.
-21:30 < Zero_Chao> I would like to seek the councils advice on something.
-21:30 <      johu> who is responsible to document the "one year end of support" decision and where?
-21:30 *** Zero_Chaos yields to johu 
-21:31 < scarabeus> johu: it will be written on council summary and then in the deprecation file, so no need to stamp it more
-21:31 <@ Chainsaw> johu: grobian will add it to the summary, and that will be binding.
-21:31 <@  grobian> refresh ;)
-21:31 <@ Chainsaw> johu: grobian has added it to the draft summary, which will soon be binding.
-21:31 <@ Chainsaw> johu: If you are happy with that answer, Zero_Chaos is next in line.
-21:31 <      johu> thanks all for this wonderfull news ;)
-21:32 < Zero_Chao> I'd like to try to get more qa added directly to portage. For the most part this is not really a council choice, however, one of the things I have found is we seem to have no policy on relative symlinks. I'd like to officially require relative symlinks.
-21:32 <@ Chainsaw> Zero_Chaos: Could you raise that on -dev please?
-21:32 <@ Chainsaw> Zero_Chaos: Provided there is no resulting riot, it can be tabled for the next meeting, in February.
-21:32 < Zero_Chao> Chainsaw: I can and will, but I wanted to see if the council thought that was worthwhile to raise or if I was wasting time.
-21:33 <@  grobian> Zero_Chaos: I vaguely recall having this seen again
-21:33 <@  grobian> s/again/before/
-21:33 < Zero_Chao> secondarily, I have one more. Also will be sent to -dev but wanted to get some feedback.
-21:33 <@  grobian> and that there was somethign impossible to do relatively
-21:34 < Zero_Chao> I'd like to raise the idea of micro-eapis. So we can have a new 5.1 or whatever with just one feature, instead of bikeshedding all the features at once we can approve each at a time.
-21:34 <@ Chainsaw> Zero_Chaos: Provided you can generate some semblance of agreement on -dev, I am happy to put it to a vote.
-21:34 < scarabeus> Zero_Chaos: hahum, that would be nuts in tree, what for would you need it?
-21:34 <@ Chainsaw> Zero_Chaos: You'd have to get that approved by zmedico and the authors of other package managers, as you would significantly increase their workload.
-21:35 <@ Chainsaw> Zero_Chaos: On personal title, it seems unlikely to succeed.
-21:35 < Zero_Chao> scarabeus: I notice a very long time between eapis due to ONE controversial feature being bikeshedded.
-21:35 <@      ulm> Zero_Chaos: I for my part am not willing to draft PMS versions more often
-21:35 <@ Chainsaw> Zero_Chaos: With my council hat on... you're welcome to raise it on -dev.
-21:35 < Zero_Chao> Chainsaw: zmedico already does it
-21:35 <@  grobian> Zero_Chaos: I think this is a misconception
-21:35 <@  grobian> Zero_Chaos: EAPI6 could just contain one single feature
-21:35 <@ Chainsaw> Zero_Chaos: We have been speedy with EAPI5.
-21:35 <@      ulm> Zero_Chaos: but if you would volunteer, go ahead ;)
-21:35 <@ Chainsaw> Zero_Chaos: By picking all the non-controversial features and voting them in at a rapid pace.
-21:35 <@  grobian> Zero_Chaos: the work is still the same, it needs to make sense, have PMS stuff, etc.
-21:36 < Zero_Chao> each new changes often has a EAPI 5-some-new-feature already implemented in portage
-21:36 < Zero_Chao> so that much isn't really new
-21:36 <@ Chainsaw> Zero_Chaos: So that seems to be punishing us for past results, rather than the current situation.
-21:36 < Zero_Chao> Chainsaw: it's not an attempt to punish anyone, merely to make it harder to stall development as a whole.
-21:36 <@ Chainsaw> Zero_Chaos: Overworking ulm is also risky business.
-21:36 <@  grobian> Zero_Chaos: it's always easier to work on your own, not caring about anyone else (re EAPI 5-some-new-feature)
-21:36 < Zero_Chao> if the only reason this is a bad idea is overworking ulm then I'll just have to start helping him :-P
-21:37 <@  grobian> I'll record that in the summary :P
-21:37 <@      ulm> another aspect is that dev need to remember features of all eapis
-21:37 < Zero_Chao> With respect, the focus of this question is fading, and I have the input that I desired. Thank you for sharing your experiences
-21:37 <@      ulm> *devs
-21:38 <@ Chainsaw> Then we will move on Zero_Chaos, thank you.
-21:38 <@ Chainsaw> Any other questions please?
-21:38 < Zero_Chao> ulm: I'll officially write it up for -dev later. we can chat at another time.
-21:38 <@      ulm> so unless we have a deprecation scheme, more than one or two per year isn't feasible IMHO
-21:38 <@ Chainsaw> If not, then I propose that we hold our next meeting on February 12, 2013 at 20:00 UTC.
-21:38 <@ Chainsaw> Does that work for everyone please?
-21:39 < scarabeus> wfm
-21:39 <@      ulm> fine
-21:39 <  WilliamH> Chainsaw: that's fine for me.
-21:39 < scarabeus> btw just offtopic question: anyone knows if there is some progress on the unified dependencies concept?
-21:39 <@ Chainsaw> dberkholz: Does Feb 12 20:00 UTC work for you please?
-21:39 <@ Chainsaw> grobian: And you?
-21:40 <@Betelgeus> scarabeus: do you mean exherbo style?
-21:40 <@  grobian> yes, I think it does
-21:40 <@Betelgeus> scarabeus: I remember it being put to Portage some years back but then I never had the time to push it more
-21:40 <@Betelgeus> feb 12 is fine
-21:41 <@ Chainsaw> Betelgeuse: Excellent. That's nearly everyone.
-21:41 < scarabeus> Betelgeuse: brian was talking about it few months ago, but i dont remember how it ended :-)
-21:41 *** Chainsaw closes the meeting
-21:41 <@ Chainsaw> Thank you everyone.
-21:41 <@      ulm> thanks for chairing
-21:41 <@ Chainsaw> See you in February.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130212-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20130212-summary.txt
deleted file mode 100644
index c4653328c1..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130212-summary.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Summary for the February 12 Gentoo council meeting 2013
-
-
-Roll Call
-=========
-betelgeuse
-Chainsaw
-dberkholz
-grobian
-scarabeus
-ulm
-WilliamH
-
-
-Open bug(s) with council involvement
-====================================
-For bug #383467 to be closed, the master ballots for 2011 & 2012 will
-need to be uploaded & linked.
-
-ulm reports that all should be done by now, jmbsvicetto has uploaded all
-files.  The bug will be closed.
-
-
-Any other business from council members
-=======================================
-grobian:
-- forcing/pressing gpg usage with repoman FEATURES=sign in anticipation for
-  git migration where gpg signing will be mandatory
-  * send mail to -dev-announce what/why and how to do it, keylength and
-    more of that
-    action: WiliamH, draft + send the message
-- change of GLEP 39 only to allow devs to be council members
-  * discussion on whether such restriction is necessary, grobian noted that
-    foundation is legally responsible for council, hence nice to have those be
-    developers.  betelgeuse noted that the GLEP is written to imply council
-    members to be devs.  ulm pointed out non-dev proxies have been a problem
-    in the past (20090625 meeting).
-    betelgeuse suggested to effectuate this in the next council election.
-    Calchan aired his intentions to replace the Council completely which lead
-    to a discussion on when he will present those ideas.
-
-
-Open floor
-==========
-no issues were raised
-
-
-Next meeting is March 12 2013 20:00 UTC
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130212.txt b/xml/htdocs/proj/en/council/meeting-logs/20130212.txt
deleted file mode 100644
index 33b9e8abf4..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130212.txt
+++ /dev/null
@@ -1,236 +0,0 @@
-20:49 -!- grobian changed the topic of #gentoo-council to: Meeting today (2013-01-08 20:00 UTC) | http://dev.gentoo.org/~grobian/agenda-20130212.txt | http://www.gentoo.org/proj/en/council/utctolocal.html?time=2000 | http://www.gentoo.org/proj/en/council/
-20:57 <+dberkholz> good timing, grobian. was just looking for that to make sure i didn't miss something
-20:57 <@  grobian> :)
-20:58 <+dberkholz> besides you, at fosdem..
-20:58 <@  grobian> oh, I was in the back, and at the side
-20:58 <@  grobian> when you were still with your head with website redesign ;)
-20:59 *** WilliamH is here
-20:59 <+dberkholz> i mean during the important part.
-20:59 <+dberkholz> beer.
-20:59 <@  grobian> I was there :)
-21:00 <@  grobian> mostly outside, though
-21:01 <@  grobian> it's 20:00 UTC, isn't it?
-21:01 <+dberkholz> yep
-21:01 <@  grobian> where's that chairman of ours
-21:02 <@      ulm> who's going to chair? chainsaw?
-21:02 <@  grobian> at least I thought so
-21:02 <@  grobian> don't mind doing it in case he is MIA
-21:02 <@  grobian> but it seemed he had a plan
-21:02 <@  grobian> so I'd prefer waiting a bit for him
-21:03 <+dberkholz> someone got his # handy? i would check but i'm mobile atm
-21:03 < scarabeus> hello
-21:04 <@  grobian> w00t, even scarabeus is on time!
-21:04 <@  grobian> :P
-21:04 -!- TomJBE [~tb@gentoo/developer/tomjbe] has joined #gentoo-council
-21:04 < scarabeus> hey, i usually do not forget
-21:04 -!- mode/#gentoo-council [+v scarabeus] by grobian
-21:04 <+scarabeus> i only once fuckup the conversion utf->local
-21:04 <+scarabeus> :-)
-21:04 <@  grobian> yeah
-21:04 <@  grobian> you should try utc instead
-21:04 <+scarabeus> s/utf/utc/
-21:04 *** scarabeus sobs
-21:04 <@  grobian> :)
-21:05 -!- mode/#gentoo-council [+v WilliamH] by grobian
-21:05 <@      ulm> grobian: I've sent a text message to chainsaw
-21:05 <@  grobian> Betelgeuse: ping
-21:05 <@  grobian> ulm: thanks
-21:05 -!- Chainsaw [~chainsaw@gentoo/developer/chainsaw] has joined #gentoo-council
-21:06 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
-21:06 <@ Chainsaw> Well that's a great start. Thank you ulm, and I do apologise for that poor show.
-21:06 <@      ulm> hi :)
-21:06 <@  grobian> cool
-21:06 *** grobian hands over keys to Chainsaw again
-21:06 <@ Chainsaw> Thank you grobian. Have you done the roll call already?
-21:07 <+dberkholz> missing Betelgeuse
-21:07 <@  grobian> Chainsaw: nope
-21:07 <@  grobian> ^^^ what dberkholz said
-21:07 <+dberkholz> everyone else has spoken in the past 6 min
-21:07 <@ Chainsaw> ulm: Could you do Betelgeuse the same service?
-21:07 <@  grobian> WilliamH: still present?
-21:07 <+dberkholz> actually WilliamH was 2 min early but i presume he didn't disappear.
-21:08 *** WilliamH is still here
-21:08 <@      ulm> Chainsaw: will do
-21:08 <@  grobian> Chainsaw: I've put up http://dev.gentoo.org/~grobian/agenda-20130212.txt for online editing
-21:09 <@Betelgeus> hello
-21:09 <@  grobian> complete
-21:09 <@Betelgeus> all thanks to ulm
-21:09 <@ Chainsaw> Excellent. Now that we're all here (thanks again ulm), we shall begin.
-21:09 <@      ulm> Betelgeuse: yw
-21:09 <@ Chainsaw> Do we have any news from jmbsvicetto on bug #383467 please?
-21:09 <@ Chainsaw> I gave a courtesy ping about a week ago.
-21:10 <@  grobian> ask ulm ;)
-21:10 <@      ulm> should be all done by now
-21:10 <@      ulm> jmbsvicetto has uploaded all files
-21:10 <@ Chainsaw> ulm: Excellent. Could you officially close that bug please?
-21:10 <@      ulm> and I've just fixed the last missing link 10 minutes ago
-21:11 <@ Chainsaw> grobian: You have the floor for your two items.
-21:11 <@  grobian> ok, these are FOSDEM discussions of me, Betelgeuse and graaff
-21:11 <@  grobian> mainly
-21:11 <@      ulm> bug 343467 closed. finally.
-21:11 <+scarabeus> yay
-21:11 <@      ulm> 383467 that is
-21:11 <@  grobian> first, we think that with the lookout for git, we shoudl start requiring devs to commit with gpg
-21:12 <@  grobian> as in, get their systems setup so they know how to get it working
-21:12 <@  grobian> as with git it will be mandatory
-21:12 <@  grobian> and getting it right isn't really trivial, if you don't know where to begin
-21:12 <+dberkholz> so we might want to set up a commit hook with a warning now, then a cutover date where it's mandatory
-21:12 <@  grobian> so getting everyone on siginig their commits should be a good preparation for the git migration
-21:12 <@      ulm> grobian: "commit with gpg" means FEATURES=sign?
-21:12 <@  grobian> ulm: yes
-21:13 <@  grobian> so, any questions on that?
-21:13 <+scarabeus> nope i agree with the requirement
-21:13 <@  grobian> like dberkholz says, we probably have to go through infra at some point
-21:13 <@      ulm> it's long overdue that we require this
-21:13 <@  grobian> we can start with officially poking/encouraging people to do it
-21:14 <@ Chainsaw> I already sign my commits, yes.
-21:14 *** WilliamH agrees, but we can't really force it without git.
-21:14 <@  grobian> ulm: it's a bit pointless to be honest
-21:14 <+ WilliamH> I sign mine also.
-21:14 <@ Chainsaw> The main thing you should do is not try and overregulate.
-21:14 <@  grobian> WilliamH: exactly, but those people will be in a shitty position if they don't invest now
-21:14 <@  grobian> so, let's just try to push people
-21:14 <@  grobian> not forcing anything
-21:14 <@ Chainsaw> The last time mandatory signing was suggested, there was key length between X and Y, must be a subkey, blah this, blah that.
-21:14 <@  grobian> I don't like that
-21:15 <@  grobian> Chainsaw: indeed, and we should sort that out, help that discussion, but at least get people to have the setup ready
-21:15 <@  grobian> I don't care how many bits people sign with
-21:15 <@ Chainsaw> grobian: Main thing I'm missing is a discussion on -dev.
-21:15 <@  grobian> or what key
-21:15 <@  grobian> Chainsaw: yes, but this isn't a vote, so it's an action point for us (council)
-21:15 <+dberkholz> i don't think anyone will really care how complex the requirements are as long as there's a couple of simple one-liners to check your existing key and make a new one that fits them.
-21:16 <@ Chainsaw> grobian: But from the floor, it's looking like a "keep it simple, yes, put it on the next agenda".
-21:16 <@ Chainsaw> I for one use my main key.
-21:16 <@  grobian> Chainsaw: nono, not for the next agenda
-21:16 <@  grobian> this can be done now
-21:16 <+ WilliamH> I use my main key also.
-21:16 <@  grobian> I think dberkholz is completely right
-21:16 <@  grobian> we just have to create awareness
-21:17 <@  grobian> is there someone who wants to take the lead on this process?
-21:17 *** WilliamH would rather not have to make a new key unless it is absolutely necessary...
-21:17 <+dberkholz> so why doesn't someone interested write up a -dev-announce post that quickly and easily summarizes what and why, and send it out
-21:17 <@  grobian> dberkholz: you just volunteered?
-21:17 <+dberkholz> i didn't put the topic on the agenda.
-21:18 <@ Chainsaw> WilliamH: Agreed. By just saying "all devs, please sign your commits. no complex requirements, no draconic rules. Pretty please"
-21:18 <@  grobian> hah
-21:19 <@      ulm> Chainsaw: would be a good point for people to reconsider their key length, though
-21:19 <@      ulm> but still, I wouldn't enforce anything at this point
-21:19 <@ Chainsaw> ulm: I have had this key since 1/1/2004. I am rather attached to it.
-21:19 <@  grobian> ulm: agreed
-21:19 *** WilliamH agrees with Chainsaw on this one... I don't want to be forced to make a new key.
-21:20 <@ Chainsaw> The less red tape you put up, the more likely people are to agree with it.
-21:20 <+dberkholz> i'm fine with incremental advances in security
-21:20 <@  grobian> ok
-21:20 <@  grobian> done with this topic then?
-21:21 <@ Chainsaw> WilliamH: Would you like to draft & send it?
-21:21 <@ Chainsaw> WilliamH: To make sure it stays simple and nobody sneaks anything complicated in?
-21:22 <@ Chainsaw> grobian: Just about, trying to volunteer someone.
-21:22 <+ WilliamH> Chainsaw: Ok, I can do that... Does repoman protest if you try to commit something that isn't signed?
-21:22 <@ Chainsaw> WilliamH: Not yet. We need to get the rating of signed commits up before that's feasible.
-21:22 <@  grobian> yup, no changes on repoman/cvs side
-21:22 <@ Chainsaw> WilliamH: First we ask politely, then we ask, then we plead and then we make binding rules.
-21:23 <+ WilliamH> Chainsaw: ok, so something like, "from this point forward, please sign your commits." Is there a guide somewhere that tells how to set up to do that?
-21:23 <@ Chainsaw> WilliamH: Yes, I think there's a document on gentoo.org that you can link to.
-21:24 <@ Chainsaw> grobian: Now we can move on. The task has been assigned.
-21:24 <@  grobian> ok, cool
-21:24 <@  grobian> second point
-21:24 <@  grobian> we figured that glep 39 doesn't really say council members need to be gentoo devs
-21:24 <@  grobian> we might want to have that
-21:24 <@  grobian> (at least the foundation will)
-21:25 <@ Chainsaw> If a non-dev is vocal and has the popular vote, why should we put barriers in their path?
-21:25 <@  grobian> but we can't vote, so we have to suggest changes and organise a vote 
-21:25 <@  grobian> well, I disagree on that
-21:25 <@ Chainsaw> Go on...
-21:25 <+scarabeus> it should not be a problem
-21:26 <@  grobian> anyway
-21:26 <+scarabeus> if they add themselves to the list it is fine
-21:26 <+scarabeus> they still have to get majority of voters to vote for them
-21:26 <+scarabeus> and if devs pick somebody out of the project we have way bigger problem
-21:26 <@      ulm> we had the issue once with a non-dev as proxy
-21:26 <@ Chainsaw> If a majority of the developers votes in ciaranm because he has good points and voices them politely...
-21:26 <+scarabeus> ulm: hm, refresh me about that?
-21:26 <@  grobian> fair enough
-21:26 <@ Chainsaw> Then he gets to be on the council. I don't see this as a problem.
-21:27 <+dberkholz> Chainsaw: we can absolutely warn before the rate of signing goes up. can't error, sure.
-21:27 <+dberkholz> re repoman.
-21:27 <@  grobian> I see a problem in terms of foundation
-21:27 <@ Chainsaw> Essentially... if you have lost trust in the majority vote of the developer community... why try to restrict what that untrusted community can vote in?
-21:27 <@ Chainsaw> grobian: I'm listening.
-21:28 <@  grobian> foundation is legally responsible for us ;)
-21:28 <@  grobian> no fun to have random $JOE in there
-21:28 <@  grobian> regardless how good they are
-21:28 <+ WilliamH> grobian: I don't think the foundation requires its members to be devs does it?
-21:28 <@Betelgeus> WilliamH: it doesn't
-21:29 <@Betelgeus> And neither are devs required to join the Foundation
-21:29 <+dberkholz> it's really implied in the glep that the council members are developers
-21:29 <@      ulm> scarabeus: I cannot find it atm, I think it was in 2009
-21:29 <+dberkholz> through the statement that they represent all developers
-21:29 <+dberkholz> so this is more about fixing a bug
-21:30 <+ WilliamH> I would tend to think that the council members should be devs because of the council's role.
-21:30 <@Betelgeus> ulm, scarabeus: yeah there was a long discussion and I think the council then was of the opinion that proxies should be devs
-21:30 <+scarabeus> actually proxies should not be non-devs as only the council member can pick that one
-21:30 <+scarabeus> but electees should be anyone
-21:31 <+scarabeus> otoh council member should be able to pick anyone in his place, and as he is already in council he should show up some brain to pick someone good :-)
-21:32 <@      ulm> scarabeus: 2009-07 meeting, dev-zero had appointed ciaranm as proxy
-21:32 <@      ulm> and there was a long discussion per e-mail
-21:34 -!- NeddySeagoon [~NeddySeag@gentoo/developer/NeddySeagoon] has joined #gentoo-council
-21:35 <@Betelgeus> Any way I think this is best bundled with a vote on council.
-21:35 <@Betelgeus> So if grobian wants to proceed this then next summer is best.
-21:36 <@  grobian> ok
-21:36 <@Betelgeus> (vote meaning elections)
-21:36 <@  grobian> right
-21:36 <+scarabeus> Betelgeuse: that is good point, to bond those
-21:37 <@Betelgeus> grobian: Some years back Calchan did rounds for larger changes
-21:37 <@Betelgeus> grobian: We could brainstorm some more to see what else is useful
-21:37 <@  grobian> now, or next meeting?
-21:38 <@Betelgeus> grobian: next meeting or outside meetings is better to check what all was on the table
-21:38 <@  grobian> -project discussions are fine
-21:39 <@Betelgeus> I still have to kick the ml discussions but I could mention the EAPI opinion gathering from my talk
-21:39 <   Calchan> Betelgeuse: say my name another two times and I will appear before you
-21:40 <@Betelgeus> Most devs there agreed that it would be a good idea to mandate using new EAPIs with the exception of security bumps
-21:40 <@  grobian> Calchan: wanna run for some changes to glep 39? :)
-21:40 <@Betelgeus> Calchan, Calchan
-21:40 <   Calchan> grobian: you mean run for council again?
-21:40 <@  grobian> Calchan: no, adapt the text
-21:41 <   Calchan> grobian: I do have a project, partly on paper, but it involves getting rid of you guys
-21:41 <@  grobian> Calchan: lol
-21:41 <   Calchan> I'm being very serious here
-21:42 <@  grobian> Calchan: feel free to open up the discussion on -project?
-21:42 <   Calchan> been there done that, years ago
-21:42 <@Betelgeus> Calchan: The Calchan appoints the supreme leader plan? :D
-21:42 <   Calchan> although the idea has evolved a lot towards simplicity since then
-21:44 <+ WilliamH> Calchan: I'm interested in seeing what you are working on. :-)
-21:44 <@  grobian> good, is that open floor, chairman?
-21:46 <@ Chainsaw> Yes, it is.
-21:46 <@ Chainsaw> The microphone is on folks.
-21:46 <   Calchan> WilliamH: I may blog about it, I've been slacking on this for about 3 years
-21:47 <   Calchan> WilliamH: I actually wanted to do it during that week off when I was not supposed to spend watching my wife in a coma in the ICU
-21:47 <+ WilliamH> how is http://bpaste.net/show/76870 for the key signing announcement?
-21:47 <+ WilliamH> s/key signing/commit signing/
-21:48 <@  grobian> WilliamH: requesting -> strongly suggesting ?
-21:49 <+ WilliamH> grobian: fixed
-21:50 <@Betelgeus> WilliamH: typo in your name
-21:50 <+ WilliamH> hehok I'll fix it.
-21:50 <@      ulm> WilliamH: s/sign commits/sign manifests/
-21:50 <@      ulm> otherwise there will be confusion after the git migration
-21:51 <@      ulm> where the two are different
-21:52 <+ WilliamH> http://bpaste.net/show/76874
-21:52 <@  grobian> WilliamH: terrific
-21:53 <+ WilliamH> grobian: ok cool.
-21:54 <@  grobian> ok, so no open floor items?
-21:56 <@  grobian> Chainsaw: can we close the meeting?
-21:56 <@ Chainsaw> grobian: Please proceed. Who chairs the next one?
-21:56 <+ WilliamH> Should this just go to dev-announce, or to dev as well?
-21:57 <@Betelgeus> Chainsaw: ulm
-21:57 <+dberkholz> hasta luego
-21:57 <@ Chainsaw> WilliamH: Just dev-announce with reply-to dev.
-21:57 <+ WilliamH> Chainsaw: ok
-22:00 <@  grobian> later all, thanks Chainsaw for chairing
-22:00 <@ Chainsaw> And thanks ulm for texting!
-22:00 <@Betelgeus> WilliamH: both with reply-to
-22:00 <@Betelgeus> WilliamH: the archives for gentoo-dev should have the full thread
-22:00 <@      ulm> grobian: small correction to the summary, 2009-07 should actually read 20090625
-22:01 <@      ulm> whose log is not on the council page, whatever that means
-22:01 *** ulm will file a bug
-22:01 <@Betelgeus> ulm: you don't have it?
-22:01 <@  grobian> ulm: fixed
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130312-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20130312-summary.txt
deleted file mode 100644
index ebc4034781..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130312-summary.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Summary of Gentoo council meeting 12 March 2013
-
-Agenda
-======
-1. Introduction and roll call
-
-2. Open bugs with council involvement
-
-     - Bug 457000 "Missing log and summary for 20090122 and 20090625
-       council meetings"
-     - Bug 447566 "x11-drivers/nvidia-drivers-{173.14.36,304.64,310.19}
-       fails to build with kernel {3.7,3.8}"
-
-3. Open floor
-
-Roll call
-=========
-betelgeuse
-chainsaw
-dberkholz
-grobian
-scarabeus (49 minutes late)
-ulm
-williamh
-
-Open bugs with council involvement
-==================================
-- Bug 457000 "Missing log and summary for 20090122 and 20090625
-  council meetings"
-  Logs for both meetings have been verified and uploaded.
-  Approval of 20090625 summary [1] with 6 yes votes and 1 abstention.
-  Action: Betelgeuse will look into writing the 20090122 summary.
-
-- Bug 447566 "x11-drivers/nvidia-drivers-{173.14.36,304.64,310.19}
-  fails to build with kernel {3.7,3.8}"
-  After long discussion, this issue was postponed without a decision.
-  Projects and/or QA should resolve the matter.
-
-Open floor
-==========
-No issues were brought up to the council.
-
-Next meeting date
-=================
-9 April 2013, 19:00 UTC
-
-
-[1] http://archives.gentoo.org/gentoo-council/msg_6523793dd018ea42b4d28e97f8d1b731.xml
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130312.txt b/xml/htdocs/proj/en/council/meeting-logs/20130312.txt
deleted file mode 100644
index ee1b1fb707..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130312.txt
+++ /dev/null
@@ -1,407 +0,0 @@
-<ulm> hi all							        [21:00]
-<dberkholz|mob> Hi
-<ulm> agenda of the meeting is here:
-      http://dev.gentoo.org/~ulm/council-20130312-agenda.txt
-<ulm> so, roll call						        [21:01]
-<grobian> here
-<WilliamH> here
-<ulm> betelgeuse, chainsaw, scarabeus?				        [21:02]
-<ulm> *sigh* it shouldn't become a habit that we must call several council
-      members by phone for every meeting			        [21:04]
-<Zero_Chaos> *cough* slacker marks *cough*			        [21:05]
-<Zero_Chaos> actually to be fair, the time change in the US may have messed
-	     some people up
-<WilliamH> Zero_Chaos: if they do get here they don't get slacker marks. ;-)
-<Betelgeuse> hello everyone
-<dberkholz|mob> None of those are American			        [21:06]
-<Betelgeuse> I am in US though
-<WilliamH> Zero_Chaos: That happens if you don't attend or your proxy doesn't
-	   attend a meeting.
-<Zero_Chaos> WilliamH: I'm familiar, it was a jest
-<WilliamH> But, yes, I agree.
-<ulm> o.k., I've texted chainsaw and scarabeus, too
-*** Chainsaw (~chainsaw@gentoo/developer/chainsaw) has joined channel
-    #gentoo-council
-*** ChanServ (ChanServ@services.) has changed mode for #gentoo-council to +o
-    Chainsaw
-<ulm> welcome :)						        [21:07]
-<Chainsaw> Thank you ulm.
-<Betelgeuse> ulm: thanks!					        [21:08]
-<ulm> let's wait until 20:10 for scarabeus
-<ulm> I expect the meeting to be short
-<ulm> online summary: http://dev.gentoo.org/~ulm/council-20130312-summary.txt
-								        [21:09]
-<ulm> let's start then						        [21:10]
-<ulm> Open bugs with council involvement
-<ulm> Bug 457000 "Missing log and summary for 20090122 and 20090625 council
-      meetings"
-<ulm> I've found and uploaded logs for both			        [21:11]
-<grobian> ok
-<ulm> anyone wants to comment on the accuracy of these logs?
-<grobian> robbat2 acked them, right?				        [21:12]
-<ulm> I've double checked them with the willikins logs
-<grobian> I'm fine with them
-<ulm> the question is what we should do about the summaries	        [21:13]
-<Betelgeuse> Sounds good. If someone disputes I have logs too.
-*** AndChat-9081 (~dberkholz@gentoo/developer/dberkholz) has joined channel
-    #gentoo-council
-*** ChanServ (ChanServ@services.) has changed mode for #gentoo-council to +v
-    AndChat-9081
-<ulm> should we still add them, as far as they're available?
-<Betelgeuse> Summaries have previously been drafted long after the fact too.
-* grobian points at http://dev.gentoo.org/~grobian/agenda-20130212.txt  [21:14]
-<ulm> for the 20090625 meeting, there's a summary at
-      http://archives.gentoo.org/gentoo-council/msg_6523793dd018ea42b4d28e97f8d1b731.xml
-<ulm> which we could approve
-<Betelgeuse> ok for me						        [21:15]
-*** AndChat-9081 (~dberkholz@gentoo/developer/dberkholz) has quit: Client Quit
-<Betelgeuse> There are no texts for which exact words would matter
-<ulm> yeah, so shall we just vote on it?
-*** dberkholz|mob (~dberkholz@gentoo/developer/dberkholz) has quit: Ping
-    timeout: 252 seconds					        [21:16]
-<grobian> ok for me too
-<WilliamH> ok for me too
-<ulm> also ok for me						        [21:17]
-<ulm> we're in perfect position to approve these old meetings
-<Chainsaw> Approved.
-* ulm has looked it up in Robert's Rules of Order
-<ssuominen> dberkholz dropped? his other client is 2hrs idle
-<ulm> s/meetings/minutes/
-<dberkholz> ssuominen: i'm here.				        [21:18]
-<dberkholz> the AndChat* was me					        [21:19]
-<ssuominen> k
-<ulm> dberkholz: we're voting on approval of the 20090625 meeting summary
-<dberkholz> i'm just terribly apathetic about this
-<dberkholz> sure, add it, not sure why we even care enough to vote on
-	    something that stale at this point
-* Zero_Chaos hands dberkholz some red tape			        [21:20]
-<ulm> dberkholz: you have a point, let's simply finishh this topic quickly
-<ulm> anyway, I count 5 yes votes, so it's approved		        [21:21]
-<ulm> dberkholz: should I count you as abstention?
-<dberkholz> fine with me					        [21:22]
-<dberkholz> since i didn't actually read the whole log to verify it's an
-	    accurate summary of the meeting
-<ulm> for 20090122 there's no complete summary			        [21:23]
-<ulm> I suggest that we just leave it open
-<ulm> unless someone would volunteer to write one ;)		        [21:24]
-<Betelgeuse> Since I was present I could also look into writing one
-<ulm> Betelgeuse: thanks
-<ulm> there are some notes from donnie already:
-      http://dev.gentoo.org/~dberkholz/20090122_summary.txt	        [21:25]
-<ulm> so let's postpone it till next meeting
-<ulm> move on?
-<Betelgeuse> yes
-<ulm> Bug 447566 "x11-drivers/nvidia-drivers-{173.14.36,304.64,310.19} fails
-      to build with kernel {3.7,3.8}"
-<grobian> interesting bug
-<ulm> meanwhile, it's been closed as wontfix
-<ulm> and council removed from cc				        [21:26]
-<WilliamH> It sounds to me like those kernel versions were released after the
-	   nvidia drivers.
-<Zero_Chaos> I still respectfully request discussion of this matter
-<Zero_Chaos> WilliamH: they were
-<Zero_Chaos> That bug is long, and tedieous, but the pain from the users is
-	     very very obvious
-<WilliamH> Zero_Chaos: comment #70 sums it up pretty well then since this is a
-	   closed source driver.				        [21:27]
-<ssuominen> I'd like to point out back in 2011 we were in same situation,
-	    vapier patched it and there were no issues
-<ssuominen> Then 2012 I patched it in same situation and talked with Cardoe
-	    and I patched it
-<ssuominen> Now in 2013 we are in same situation, and we no longer can patch
-	    nvidia-drivers trivially? What changed? Nothing.
-<Chainsaw> Main concern I have with the council CC is that we are supposed to
-	   be the appeals process for devrel.
-<Chainsaw> Has devrel been involved?				        [21:28]
-<dberkholz> is this an HR issue?
-<Zero_Chaos> It would seem to me that if we are going to mark a package as
-	     stable, we should at least attempt to keep things buildable.  The
-	     current maintainer feels that if it's not buildable it's nvidia's
-	     problem and he refused to accept (in my opinion) trivial patches
-<Zero_Chaos> Chainsaw: with respect, I'm looking for a guideline not a
-	     moderation session or for the council to order anyone to do
-	     anything.
-<dberkholz> my understanding is that we were copied for a technical issue
-<ssuominen> Cardoe mailed me about nvidia-drivers, I reminded him of our
-	    discussion from 2012, and I never got reply after that, no devrel
-	    far as I know
-<dberkholz> so devrel would not be pertinent
-<Chainsaw> It still seems to be a condemnation of rej's maintainership of the
-	   package.						        [21:29]
-<ulm> right, I see it as a technical issue too
-<WilliamH> nvidia doesn't support that version of the driver with the newer
-	   kernels.
-<dberkholz> in actuality it should be going to whoever the X lead is
-<ssuominen> The patches that went in this time for nvidia-drivers were only
-	    related to the build
-<Chainsaw> If rej is unwilling to budge, and it is felt that this is unjust,
-	   devrel is where you should go. Not the council.
-*** Arfrever (~Arfrever@apache/committer/Arfrever) has joined channel
-    #gentoo-council
-<ssuominen> No code changes
-<Zero_Chaos> I would like for the council to provide their guidance on the
-	     fact that if it is marked stable, we should make reasonable
-	     effort to make it buildable. If we are not going to make any
-	     effort to keep something buildable, it shouldn't be marked
-	     stable.
-* dberkholz coughs
-<dberkholz> http://www.gentoo.org/proj/en/desktop/x/
-<ssuominen> kernel stabilization have lately been a bit off, it's not only
-	    nvidia-drivers that weren't ready, also udev got broken with
-	    path-by-id ATA symlinks				        [21:30]
-<WilliamH> Zero_Chaos: it is buildable with the version of the kernel it is
-	   supposed to be buildable with.
-<WilliamH> kernel stabilizations should not be affected by external drivers.
-								        [21:31]
-<Zero_Chaos> WilliamH: yes, but that means that stable users aren't buildable
-	     right now and that rather defeats the point of having stable at
-	     all in my eyes.
-<Betelgeuse> As a general point I agree that other bodies are more suited to
-	     handle technical issues than devrel.
-<ulm> scarabeus just texted back
-<ulm> he forgot and he's giving a talk about gentoo		        [21:32]
-<ssuominen> WilliamH: we used to block kernel stabilizations with the
-	    nvidia-drivers stablereq, not this time, but I still agree, it
-	    shouldn't be a blocker but like Zero_Chaos pointed out, reasonable
-	    effort should be made
-<Zero_Chaos> I'm completely fine with nvidia-drivers NOT blocking kernel
-	     stablization.					        [21:33]
-<WilliamH> ssuominen: The problem is that we could get our users into an
-	   unsupported situation.
-<Zero_Chaos> WilliamH: a "vanilla" use flag was introduced to avoid that
-<Zero_Chaos> WilliamH: it was refused by the maintainer. he is happy to have a
-	     stable ebuild that doesn't work on stable systems
-<Betelgeuse> devrel was cced to the bug at one point as you can see in
-	     https://bugs.gentoo.org/show_activity.cgi?id=447566        [21:34]
-<Zero_Chaos> that is the part I find unacceptable. things that can't build on
-	     stable shouldn't be marked stable
-<Betelgeuse> search for hwoarang or devrel
-<ssuominen> WilliamH: nothing unsupported by adding missing -I flag when
-	    kernel moves a header and the header stays same, and nothing
-	    unsupported about fixing trivial script to parse the kernel
-	    version correctly
-<grobian> so this pretty much sounds like maintainer isn't reasonably
-	  cooperating
-<dberkholz> what's unsupported is whether upstream will laugh in your face if
-	    you encounter a bug
-<ssuominen> WilliamH: in fact, it's propably why nvidia took it's time this
-	    time to release new drivers, the solutions were all around in
-	    their forums
-<Zero_Chaos> dberkholz: again, a USE=vanilla solution was offered to
-	     accomodate that situation				        [21:35]
-<ulm> to get this back on track: are we at the point where we should decide on
-      the issue?
-<WilliamH> ssuominen: ok, so the solutions were known to nvidia then.   [21:36]
-<ulm> or should projects try to resolve it first?
-<dberkholz> Zero_Chaos: that will be immensely confusing to users in the case
-	    where they can upgrade a kernel, attempt to go vanilla, and it
-	    doesn't build.
-<Chainsaw> ulm: Developer, herd/project, devrel, council.
-<Zero_Chaos> dberkholz: it was properly explained in the ebuild based on if
-	     the use flag was set and the current kernel versions, etc. it was
-	     actually quite nice
-<ulm> Chainsaw: yes, that's the usual way			        [21:37]
-<ssuominen> dberkholz: vanilla causing build failures is a resolved, invalid,
-	    it's what the user asked and the normal policy of
-	    toolchain/base-system
-<Zero_Chaos> Chainsaw: imho this isn't a relations issue, this is a technical
-	     issue.
-<Chainsaw> ulm: It's the only way.
-<Chainsaw> Zero_Chaos: You've tried step 1, why are you now at step 4?
-<WilliamH> So should we send this to the project lead for a ruling then?
-<Chainsaw> WilliamH: He's in the channel. Yes. *That* is step 2.
-<Zero_Chaos> Chainsaw: forgive me, I'm new here, I thought policy decisions
-	     came from council.					        [21:38]
-<ulm> I'm all for sending this to the project(s) first
-<Betelgeuse> the ebuild is not part of any herds
-<Betelgeuse> So what project(s) would that be?
-<Chainsaw> Betelgeuse: herd/project; I think dberkholz has a stake here.
-<grobian> ulm: +1
-<Chainsaw> Betelgeuse: The "X11" project.
-<WilliamH> Zero_Chaos: they do, but the project gets a say first.
-<dberkholz> here's the thing
-<Zero_Chaos> WilliamH: that's fair
-<dberkholz> if you're looking for a policy specific to X drivers, then i'm
-	    your guy
-<dberkholz> but if you want something global regarding what kinds of things
-	    are and are not supported, then council is the right place
-								        [21:39]
-<Chainsaw> Still trying to skip a step.
-<Zero_Chaos> dberkholz: that is what I'm looking for, although if the correct
-	     channel is going through the project leader first I am fine with
-	     that
-<Zero_Chaos> Chainsaw: I really don't understand how devrel has any stake at
-	     all in a technical issue.
-<Chainsaw> Zero_Chaos: It is a disagreement over packaging style, with a
-	   maintainer.						        [21:40]
-<WilliamH> Zero_Chaos: they really don't.
-<Chainsaw> Zero_Chaos: That's developer relations for an inter-developer
-	   conflict.
-<Zero_Chaos> Chainsaw: no sir, it isn't. it's a disagreement over what gentoo
-	     thinks "stable" should mean.
-<WilliamH> Chainsaw: True, it is, but it is a technical disagreement as
-	   opposed to a personnel disagreement.
-<Chainsaw> This is a disagreement between people.		        [21:41]
-<WilliamH> Chainsaw: My understanding of devrel is it is for inter-personal
-	   conflicts.
-<dberkholz> Chainsaw: devrel explicitly says "conflicts of a non technical
-	    nature" (http://www.gentoo.org/proj/en/devrel/policy.xml)
-<ulm> I suggest that we send the issue back to projects		        [21:42]
-<ulm> we can come back to it in the next meeting if necessary
-<WilliamH> This is a technical conflict about an x driver, so it should go to
-	   dberkholz
-<dberkholz> while there were some personal issues entering the discussion, the
-	    core issue here is what the support policy should be for stable,
-	    proprietary drivers
-<Chainsaw> "Any conflicts that are purely technical should be addressed to QA
-	   and they will be handled according to GLEP 48."
-<Chainsaw> Very well. Ask Flameeyes.
-<Zero_Chaos> with the councils permission, may I confer with the head of the X
-	     project for 5 minutes to see if this is quick enough to not
-	     postpone?
-<Chainsaw> At *no* point does one go directly to the council with a matter
-	   like this.
-<ulm> Zero_Chaos: go ahead
-<Chainsaw> Please do.
-<Betelgeuse> ok
-<Zero_Chaos> Chainsaw: as there is no herd to address I did not know where to
-	     go, I apologize					        [21:43]
-* Chainsaw remains of the firm opinion that this goes to developer relations,
-  but if you wish to pursue this "technical" avenue, you get Flameeyes from QA
-<Zero_Chaos> dberkholz: I feel it is hurting our users to allow nvidia-drivers
-	     to have stable keywords and not patch it with (again, imho)
-	     trivial patches to keep it buildable. If we are going to make no
-	     effort at all (as the maintainer suggests) then we really
-	     shouldn't allow it to be stable.
-<dberkholz> i would concur re escalation to QA if needed to determine how it
-	    might fit in w/ existing policy			        [21:44]
-<Zero_Chaos> dberkholz: I am open to any solution that you want to provide but
-	     the current "it's stable but I don't care if it builds" is
-	     embarassing.
-<WilliamH> may I ask a question?				        [21:45]
-<ssuominen> flameeyes is running tinderbox with stable packages too, and he
-	    WILL reopen any bugs closed prematurely, as experienced
-<ssuominen> when package is not yet stable
-<dberkholz> our approach to proprietary drivers has generally been one that we
-	    can't be held back by them and will continue to stabilize OSS
-	    stuff even if it breaks closed things
-<Chainsaw> WilliamH: Always.
-<WilliamH> We have stable kernels the nvidia drivers build with right?  [21:46]
-<Zero_Chaos> dberkholz: Just for reference, the most common suggestion for
-	     solving this has been to have an nvidia-drivers-unsupported (or
-	     some such) ebuild added to the tree that will get patches and
-	     remain functional
-<Zero_Chaos> WilliamH: yeah just not any of the recent ones
-<Chainsaw> Zero_Chaos: That seems like a rather elaborate way to sidestep the
-	   current maintainer.
-<Zero_Chaos> Chainsaw: it was not my suggestion and I have been fighting it as
-	     I don't wish to fork it. This was simply the suggested solution
-	     provided to me by no less than 4 devs.
-<dberkholz> hasn't the current maintainer expressed a desire to step down?
-								        [21:47]
-<Zero_Chaos> Chainsaw: and yes, it is a rather elaborate way to sidestep the
-	     current maintainer.
-<dberkholz> if so, there's room for a new one to do whatever he or she wants.
-<Chainsaw> dberkholz: Cardoe has, rej hasn't.
-<Zero_Chaos> dberkholz: the previous maintainer did step down, the current
-	     maintainer is also unwilling to patch
-<Chainsaw> dberkholz: That's what all this boils down to. A disagreement with
-	   rej.
-<Zero_Chaos> *sigh*
-<Zero_Chaos> Chainsaw: this isn't personal			        [21:48]
-<grobian> so, someone needs to talk to him and see if we can resolve the
-	  problem?
-<ssuominen> How can any developer change the meaning of stable on his own?
-<Zero_Chaos> ssuominen seems to have my point.
-<grobian> as in, take over in a friendly way
-* WilliamH would suggest that dberkholz talk with rej about it...
-<Chainsaw> Zero_Chaos: I honestly don't care if it is personal or not. You
-	   have a problem with rej's maintainership of nvidia-driver. If
-	   devrel is a bridge too far, then yes, have someone mediate.
-<ssuominen> grobian: undoable, got called "Moron." and other not worth
-	    replying
-<ulm> ok folks, I don't see us decide on the issue during this meeting  [21:49]
-<Chainsaw> Zero_Chaos: But if devrel is a bridge too far, the council is even
-	   further away.
-<Zero_Chaos> ulm: agreed, and fair.
-<ulm> let's postpone it
-<Chainsaw> ulm: Okay.
-<ssuominen> I don't want to file revrel bug for rej for calling me an moron
-	    for not agreeing, and escalating this.
-<scarabeus> hello guys do you have som e required votes from me? i have non
-	    working droid irc but i just sshed from the beamer and can give
-	    some votes really fast :-)
-<dberkholz> i think this is a question of what stable really means, and it
-	    can't be the opinion of any single maintainer.
-<dberkholz> nor a project lead.					        [21:50]
-<ulm> Zero_Chaos: we can come back to it next month
-<dberkholz> should go to QA
-<ulm> but I'd hope that it'll be resolved by then
-<Betelgeuse> Sounds like something that in the end should be GLEPped
-<Chainsaw> dberkholz: Sure. QA or devrel. Pick one, and let's move on. Out of
-	   our jurisdiction.
-<Zero_Chaos> dberkholz: that is why I had asked for council involvement
-	     originally, but if QA is the right place you can I can discuss
-	     after the meeting officially closes if you still have a few
-	     minutes.
-<dberkholz> however much i'd like to just go put the smack down on people =)
-<grobian> I'd just like this not to end up at people doing a lot for gentoo,
-	  leaving the project
-<ssuominen> this issue will likely be moot in ~2-3 weeks when new drivers go
-	    stable and everyone will forget, until next time
-<Zero_Chaos> ssuominen: those drivers have already been released, and I'm not
-	     letting this go.					        [21:51]
-<Zero_Chaos> so let's all let the council meeting move on and address this
-	     after.
-<ulm> scarabeus: only approval of the summary for the 20090625 meeting
-<scarabeus> ulm: that seems fine :-) and again sorry for the lag, i completely
-	    forgot
-<ulm> ok, open floor then					        [21:52]
-<dberkholz> on a maintainer level, seems like this should just be an issue of
-	    fiddling with blockers
-<dberkholz> so at least stuff doesn't break, even if incompatible upgrades
-	    aren't offered.
-<WilliamH> dberkholz: that's a good point too.
-<Chainsaw> dberkholz: There was the global condemnation of < deps a while
-	   back, which may have kept strict dependencies from being applied.
-<ulm> any topic for open floor?					        [21:53]
-<Chainsaw> dberkholz: But yes, that needs to happen. Portage needs a decent
-	   chance to present a working combination.
-* Chainsaw makes sure the microphone is on
-<Zero_Chaos> Chainsaw: it is
-* ulm doesn't see any request to speak				        [21:54]
-<dberkholz> it is always the wrong choice to present users with a broken
-	    build, so that should be avoided.			        [21:55]
-<ulm> next meeting will be at 2013-04-09
-<WilliamH> ulm: sounds good to me.
-<Chainsaw> ulm: I shall aim to appear unprompted.		        [21:56]
-<ulm> should we move to 19:00 UTC because of daylight saving time?
-<ssuominen> dberkholz: not always, for ~arch setting unnecessary < deps or
-	    blockers will only hinder the effort of fixing the newer package,
-	    in worst case, downgrade a library with changed soname that other
-	    packages use too
-<ssuominen> dberkholz: for stable, true
-<ssuominen> dberkholz: even worse, no soname changed and api changed and
-	    downgrade breaks even worse				        [21:57]
-<ssuominen> (typoes)
-*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
-    "next meeting 2013-04-09 |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 |
-    http://www.gentoo.org/proj/en/council/"
-<grobian> ulm: I opt for 21:00 western-europe time
-<ulm> grobian: western-europe as in britain?			        [21:58]
-<Chainsaw> ulm: No, as in CEST. Your time.
-<ulm> or central europe as in germany, france?
-<grobian> ulm: as in Europe/Amsterdam
-<grobian> :)
-<dberkholz> ssuominen: sorry? must be missing something. if i'm maintainer and
-	    already know something is broken, how is masking/changing deps
-	    going to change that?
-<ulm> grobian: that's 19:00 UTC then				        [21:59]
-<grobian> fine with me
-<WilliamH> fine with me.
-<ulm> the meeting is closed then
-<ulm> thanks to everyone for participating			        [22:00]
-<grobian> thanks for chairing ulm
-<dberkholz> nice short meeting as promised =P
-<Zero_Chaos> ulm: thanks
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130409-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20130409-summary.txt
deleted file mode 100644
index 7e4615b629..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130409-summary.txt
+++ /dev/null
@@ -1,97 +0,0 @@
-Summary of Gentoo council meeting 9 April 2013
-
-Agenda
-======
-1. Introduction and roll call
-
-2. Change to newer Bash version in ebuilds
-
-   Take an initial look, and possibly vote on switching to a newer
-   Bash version (e.g. 4.2) for the next EAPI [1,2].
-
-3. EAPI deprecation
-
-   Should we have stricter rules, in order to limit the number of
-   EAPIs that are in active usage? [3]
-
-4. Open bugs with council involvement
-
-     - Bug 457000 "Missing log and summary for 20090122 and 20090625
-       council meetings"
-     - Bug 464250 "Encourage developers to use the latest EAPI"
-
-5. Open floor
-
-A proposal to add another agenda topic "Patch policy" did not pass.
-
-
-Roll call
-=========
-Present: chainsaw, dberkholz, grobian, scarabeus, ulm, williamh
-Absent: betelgeuse
-
-Change to newer Bash version in ebuilds
-=======================================
-Several options were discussed:
-- Change of bash version to 4.2 could be a regular item for EAPI 6.
-- The bash update could be put into its own EAPI, to appear at least
-  one year after the date (2012-07-01) of EAPI parsing being supported
-  by stable portage.
-- Updating the bash version could be a problem for bootstrapping on
-  some Prefix architectures (e.g., Solaris). According to grobian, it
-  should be possible to handle the issue.
-
-No action is taken for now.
-
-EAPI deprecation
-================
-In the discussion, there was neither consensus if EAPI 0 should be
-considered deprecated, nor what should be the oldest EAPI that still
-needs to be supported for the upgrade path of users' system.
-
-Three votes were taken:
-- "EAPIs 0 to 2 are no longer required for the upgrade path of users'
-  systems."
-  Accepted unanimously.
-
-- "EAPIs 1 and 2 are discouraged. Repoman should warn about this."
-  Accepted unanimously.
-
-- Change wording in the first question from "0 to 2" to "0 to 3".
-  Tie vote (3 yes, 3 no), therefore the motion did not pass.
-
-Open bugs with council involvement
-==================================
-- Bug 457000 "Missing log and summary for 20090122 and 20090625
-  council meetings"
-  No progress since last meeting.
-
-- Bug 464250 "Encourage developers to use the latest EAPI"
-  Accepted in 2011-03-08 meeting, but not in the devmanual yet.
-  Action: grobian will prepare a patch.
-
-- Bug 447566 "x11-drivers/nvidia-drivers-{173.14.36,304.64,310.19}
-  fails to build with kernel {3.7,3.8}"
-  Short status update from Zero_Chaos. Discussion will be per e-mail.
-
-Open floor
-==========
-- Q: Was the dodocs/edocs proposal [4] voted upon?
-  A: There was no vote on any EAPI 6 features yet.
-
-- Gentoo participates in the Google Summer of Code, for the 8th year.
-
-- Further discussion about EAPI deprecation.
-
-- Sub-slots and slot operators are overused, and used in the wrong way
-  in some packages, in spite of the feature being well documented.
-
-Next meeting date
-=================
-14 May 2013, 19:00 UTC
-
-
-[1] http://article.gmane.org/gmane.linux.gentoo.project/2371
-[2] https://bugs.gentoo.org/431340
-[3] http://article.gmane.org/gmane.linux.gentoo.project/2377
-[4] https://bugs.gentoo.org/459692
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130409.txt b/xml/htdocs/proj/en/council/meeting-logs/20130409.txt
deleted file mode 100644
index cc220e07a0..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130409.txt
+++ /dev/null
@@ -1,530 +0,0 @@
-<ulm> 19 UTC
-<grobian> bash-42
-<dberkholz> looks like your patchset policy thing didn't make it into the
-	    agenda yet
-<ulm> let's start
-<ulm> roll call
-* scarabeus aroundy
-<ulm> agenda is here: http://article.gmane.org/gmane.linux.gentoo.project/2381
-<grobian> here
-<ulm> Chainsaw: still here? :)					        [21:01]
-<Chainsaw> ulm: Yes :)
-<ulm> Betelgeuse, WilliamH?					        [21:02]
-<ulm> can someone phone/text them?
-<ulm> and not always me, I've done this for the last four meetings      [21:06]
-<grobian> sorry							        [21:07]
-<grobian> did anyone already take action?			        [21:08]
-<jmbsvicetto> Do you need me to call Petteri?
-<jmbsvicetto> I don't have William's number
-<ulm> jmbsvicetto: yes, please
-<ulm> I'll text WilliamH then					        [21:09]
-<jmbsvicetto> hmm, I got some automated reply as soon as I called Petteri
-<jmbsvicetto> and as you can imagine, finish == chinese to me :P
-* WilliamH is here						        [21:10]
-<ulm> welcome :)
-<WilliamH> I was just working on an email I'm about to send out, sorry folks.
-<ulm> 10 minutes passed, so let's move on			        [21:11]
-<scarabeus> ook
-<ulm> Change to newer Bash version in ebuilds
-<ulm> see references in the agenda
-<grobian> what exactly do you want to do on the subject?	        [21:12]
-<grobian> vote?
-<ulm> too early to vote, I think				        [21:13]
-<Chainsaw> Last time this came up, it was a problem for prefix.
-<scarabeus> nothing to vote there
-<scarabeus> it can be nominated for the eapi and voted then
-<grobian> ok, well, I think EAPI6 could have bash-4.2, but that we need to
-	  have a portage that reads EAPI line (as opposed to sourcing the
-	  ebuild) for at least a year stable
-<Chainsaw> Because they had older bash versions on their "main" OS.
-<ulm> the main problem is with the upgrade path			        [21:14]
-<grobian> that sums up basically what you wrote in the email thread, ulm
-<dberkholz> i'd defer to grobian on that one.
-<grobian> Chainsaw: can't imagine that was prefix
-<ulm> there's two dates, EAPI parsing was in stable portage in June 2012
-<grobian> Chainsaw: only can be a problem if we go for deprecation of EAPI0
-	  and stuff
-<ulm> and bash 4.2 went stable in March 2012 already
-<dberkholz> i would suggest we put a bash update into its own EAPI, or if
-	    there's anything else ready to go then we add that, so we can have
-	    it stabilized on or shortly after july 1 (1 yr since stable
-	    EAPI=5)						        [21:15]
-<Chainsaw> grobian: The OS X one, from what I remember.
-<scarabeus> grobian: eapi 0 is too big, everything in between can start to die
-<ulm> we'll come to eapi deprecation later
-<grobian> Chainsaw: yeah, that's a bootstrapping problem
-<grobian> e.g. on solaris					        [21:16]
-<ulm> let's stay with bash version
-<grobian> scarabeus: agreeed
-<grobian> scarabeus: I didn't want to jump ahead to the next agenda item
-<dberkholz> don't want to delay this another 6 months or longer in convoluted
-	    EAPI discussions
-<Chainsaw> grobian: Would it still be a problem, or can it be managed?
-<Chainsaw> grobian: That's really the only argument against that I remember
-	   from last round.
-<grobian> well, I don't think it's much of a problem, as we manually compile
-	  bash prior to the bootstrap				        [21:17]
-<grobian> unless I forgot something myself
-<ulm> dberkholz: I'd rather go for longer time than one year here
-<ulm> not shorter
-<dberkholz> who said shorter?
-<ulm> <dberkholz> i would suggest we put a bash update into its own EAPI
-								        [21:18]
-<ulm> or was the intention to delay bash update until after EAPI 6?
-<dberkholz> i'm assuming you also read that to the end, where i said 1 year
-	    since stable EAPI=5
-<WilliamH> when was eapi=5 stable?				        [21:19]
-<dberkholz> not shorter than 1 year
-<ulm> WilliamH: July 2012
-<ulm> sorry, that was EAPI parsing
-<WilliamH> ok so we are almost at a year then.
-<WilliamH> ulm: ok...						        [21:20]
-<ulm> WilliamH: 2012-12-11 for EAPI 5
-<WilliamH> ulm: ok						        [21:21]
-<dberkholz> bah, what i meant was 1 yr since EAPI parsing.
-<ulm> so, we see how preparation for EAPI 6 goes, and then come back to bash
-      version depending how long it takes?			        [21:22]
-<WilliamH> Why not put the bash update in eapi 6?
-<grobian> hmmm, you want to apply it outside of eapi?
-<dberkholz> personally i'd prefer the other way around
-<ulm> grobian: not outside of EAPI
-<grobian> I'd go for EAPI6
-<ulm> EAPI 6 makes perfect sense
-<grobian> put it on the list
-<ulm> and we could always fall back to mgorny's suggestion, namely forbid bash
-      4.2 features in global scope for some transition time	        [21:23]
-<grobian> if it delays, we can always scratch it
-<dberkholz> delays till when?
-<dberkholz> let's do something real here
-<grobian> because next month we want to approve EAPI6
-<grobian> not really likely of course
-<grobian> so, seems like it should be just an EAPI6 item	        [21:24]
-<ulm> grobian: +1
-<grobian> nothing transition or something, because portage will barf more
-	  errors if you don't have EAPI-parsing
-<ulm> ok, no action for the time being				        [21:25]
-<ulm> move on?
-<grobian> yes please
-<ulm> oops, I forgot one point					        [21:26]
-<ulm> additional agenda point for patch policy
-<ulm> should we add it to today's agenda?
-<grobian> I'm against
-<grobian> didn't prepare					        [21:27]
-<WilliamH> grobian: +1
-<ulm> doesn't look so urgent to me, and the agenda is already packed
-<grobian> did we discuss eapi deprecation yet?
-<dberkholz> i do have an opinion on the policy, but don't mind delaying for
-	    others
-* scarabeus can talk about it, but basically i can recommend looking on
-  fedora/suse patching, more restrictive the better
-<ulm> so, just vote: agenda item to be added?			        [21:28]
-* ulm votes no
-<grobian> no
-* WilliamH votes no
-* scarabeus indiferent
-<ulm> ok, 3 times no and one indifferent means that it's not approved   [21:29]
-<ulm> next point, EAPI deprecation
-<ulm> we can come back to patch policy next month		        [21:30]
-<grobian> ok, where do you want to start :)
-<ulm> I'm a bit worried that we have 6 different EAPIs in active use
-<scarabeus> we should look on the qa-reports page where is the eapi listing
-	    and hard-deprecate those with low numbers
-<ulm> soon it will be 7						        [21:31]
-<WilliamH> Me too.
-<scarabeus> 0 is out of question for now but others should be phased out
-<ulm> http://qa-reports.gentoo.org/output/eapi_usage.txt
-<ulm> scarabeus: it makes no sense to start with anything but 0
-<grobian> why?							        [21:32]
-<ulm> because largest difference in features is from newest EAPI to EAPI 0
-<WilliamH> We could have repoman start complaining if you try to commit
-	   something with an old eapi setting.
-<grobian> frankly, I've built a toolchain, and I don't want to mess with it
-<ulm> e.g. src_prepare and src_configure
-<grobian> imo, it's legacy that we need to accept		        [21:33]
-<grobian> moving away from it as much as possible
-<grobian> I like deprecation, four years, or four sensical EAPIs
-<ulm> I'd suggest that we start differently: there's still the myth that EAPI
-      0 needs to be kept for system packages for upgrade path
-<WilliamH> grobian: the thing is that some people won't move  ebuilds away
-	   from it if we don't start at least complaining about it.
-<grobian> WilliamH: yeah, but I'm not against that		        [21:34]
-<dberkholz> i'd just start with a repoman warning on anything but latest
-	    stable
-<ulm> so the first step would be that we make a statement like "EAPI 0 and 1
-      are not required for upgrade path, you can move everything to 2."
-<dberkholz> encourage people to move by bugging them
-<ulm> or 3 even
-<scarabeus> ulm: i would go for 3
-<grobian> ulm: yeah, probably could say that
-<scarabeus> actually we are bugging them			        [21:35]
-* WilliamH agrees with dberkholz 
-<scarabeus> the rule is use new eapi no?
-<scarabeus> but they happily ignore it
-<WilliamH>  We always encourage the latest eapi so we should start complaining
-	   when people aren't using it.
-<grobian> scarabeus: if the new eapi doesn't add anything?
-<Chainsaw> grobian: Then the EAPI bump should be uneventful.	        [21:36]
-<WilliamH> grobian: then just bump the eapi= setting and be done with it.
-<Chainsaw> grobian: That argument works both ways :)
-<scarabeus> grobian: that is moot now, as eapi5 has the subslots which should
-	    be used almost everywhere
-<grobian> no no
-<Chainsaw> I think a case can be made for EAPI 1 to 4 to emit a
-	   EAPI.discouraged warning.
-<grobian> you can't just bump eapi without looking
-<Chainsaw> IT should not be fatal.
-<Chainsaw> s/IT/It/
-<ulm> Chainsaw: why no for 0?					        [21:37]
-<Chainsaw> EAPI 0 is a toolchain requirement.
-<ulm> *not
-<WilliamH> grobian: no, but it is up to you to test before you commit. :p
-<dberkholz> in case anyone else wants to see EAPI use visually ...
-	    http://www.chartgo.com/create.do?chart=bar&dimension=2d&width=500&height=400&orientation=vertical&title=EAPI+usage&subtitle=&xtitle=EAPI&ytitle=Ebuilds&source=&fonttypetitle=bold&fonttypelabel=normal&labelorientation=horizontal&chrtbkgndcolor=gradientblue&max_yaxis=&transparency=1&labels=1&min_yaxis=&roundedge=1&shadow=1&border=1&xaxis1=0%0D%0A1%0D%0A2%0D%0A3%0D%0A4%0D%0A5&yaxis
-<Chainsaw> The Y data field is empty. Y data cannot be empty.
-<dberkholz> or http://monk.ly/10PKS76
-<WilliamH> Chainsaw: ?						        [21:38]
-<grobian> the discussion always revolves around who is doing the work and why
-<ulm> dberkholz: heh, can you plot this against time? ;)
-<grobian> I still don't see problems, other than maintenance and cosmetics
-<dberkholz> sure i could. obviously everything is easier in git but can always
-	    update my conversion
-<grobian> yet people suggest maintainers should forcefully upgrade their
-	  packages
-<grobian> we can't make them do thay
-<grobian> and it makes little to no sense to me either		        [21:39]
-<grobian> hence, deprecating eapis, warning about 1,2,3 seems ok to me
-<Chainsaw> dberkholz: Based on your graph, EAPI 1 to 3 is the soft spot that's
-	   easy to hit.
-<grobian> 4 seems rather new
-<WilliamH> grobian: why not? it would just be part of a revbump or version
-	   bump.
-<grobian> WilliamH: hehe, src_unpack is not supposed to have epatch in it in
-	  EAPI 1+
-<ulm> it makes no sense to warn about EAPI 3
-<ulm> EAPI 3 still is needed for the upgrade path		        [21:40]
-<WilliamH> grobian: right, but you fix that as part of the eapi migration.
-<WilliamH> ulm: why is that?
-<grobian> WilliamH: yeah, which is a lot of work, which is not giving ANY
-	  benefit
-<grobian> especially when using PATCHES array becomes mandatory for some EAPI
-<grobian> because someone thinks that's "cleaner"
-<grobian> and it changes NOTHING from the user's point of view	        [21:41]
-<grobian> so why waste scarce developer time?
-<WilliamH> grobian: eapis are not relevant to the user anyway.
-<grobian> what problem are we solving?
-<grobian> yes
-<Chainsaw> ulm: In the interest of building consensus...	        [21:42]
-<ulm> guys, it looks like this discussion is going nowhere
-<Chainsaw> ulm: EAPI.discouraged for 1 & 2.
-<WilliamH> grobian: moving away from legacy eapis that we do not need. like
-	   was pointed out, we have 6 now, soon to be 7.
-<grobian> I'm all for encouraging people (including myself) to get fluent with
-	  latest EAPIs
-<Chainsaw> ulm: To at least make progress and reduce the total count.
-<WilliamH> grobian: but if repoman doesn't complain people will not do it.
-<Chainsaw> ulm: I'd rather make weak progress than a strong stand-still.
-<grobian> WilliamH: yeah, and I believe the solution is more in folding, like
-	  2 can be removed, as 3 is a drop-in replacement	        [21:43]
-<grobian> and perhaps we can do 4-5 at some point
-<grobian> and deprecate 1 as a whole
-<ulm> I'd start with a statement "EAPIs 0 to 2 are no longer required for
-      upgrade path"
-<grobian> ^^^^ agreed
-<dberkholz> ulm: which upgrade path are you referring to?	        [21:44]
-<dberkholz> we only support 1 year back, as i recall
-<ulm> dberkholz: upgrade path for outdated users' systems
-<ulm> dberkholz: minimum of 1 year
-<WilliamH> ulm: but we only support one year back.
-<ulm> with longer support to be discussed, but that discussion never took
-      place							        [21:45]
-<dberkholz> therefore it does not exist
-* ulm has looked it up in the old meetings' summaries
-* WilliamH agrees with dberkholz 
-<Chainsaw> Anyhow. EAPI 0 is a toolchain requirement. 1 & 2 seem a valid
-	   "EAPI.discouraged" target. 3 and above remain untouched for now.
-								        [21:46]
-<Chainsaw> Can we vote on that?
-<WilliamH> How is eapi0 a requirement?
-<Chainsaw> WilliamH: Because toolchain has reported that they need it.
-<ulm> Chainsaw: I'd rather grant an exception for toolchain packages
-<dberkholz> it's a requirement until someone talks the toolchain team into
-	    updating its eclass or does it for them
-<Chainsaw> WilliamH: The matter did not seem negotiable.
-<WilliamH> dberkholz: what would it take to do that?		        [21:47]
-<Chainsaw> ulm: I'd prefer a simpler rule and simpler code in repoman.
-<dberkholz> lots of beer?
-<grobian> well, I'm not sure we'd want someone to replace it for them
-<grobian> we'd need lots of years to confirm that the new stuff is
-	  stable/correct
-<ulm> ok, let's do two votes					        [21:48]
-<WilliamH> wrt repoman,
-<ulm> first vote: "EAPIs 0 to 2 are no longer required for the upgrade path of
-      old systems"
-<WilliamH> I wasn't saying it should be a fatal error in there, just a
-	   warning.
-* WilliamH votes yes
-<ulm> and second vote "EAPIs 1 and 2 are discouraged, repoman check to be
-      added"
-<ulm> first vote, please					        [21:49]
-<dberkholz> can you define old please
-<grobian> ulm: first vote: yes
-<dberkholz> i think that's important to our discussion/vote
-<grobian> ulm second vote: yes
-<ulm> dberkholz: strike the word "old"
-<dberkholz> if you defined it at our current support window of 1 year, EAPI=3
-	    would also be true
-<ulm> dberkholz: in principle, yes				        [21:50]
-<ulm> but I see no reason to deliberately kill off old systems
-* WilliamH votes that eapi 3 should also be added
-<Chainsaw> ulm: Sadly, yes. EAPI0, EAPI1 & EAPI2 are unusable due to python.
-	   (First vote)
-* ulm votes yes on first vote					        [21:51]
-<WilliamH> Are we adding eapi 3 to the statement for the first vote?
-<ulm> WilliamH: let's decide on that afterwards			        [21:52]
-<ulm> otherwise it gets too confusing
-<WilliamH> ok
-<ulm> dberkholz: scarabeus: WilliamH: your first vote please
-<WilliamH> http://article.gmane.org/gmane.linux.gentoo.project/2381/me votes
-	   yes
-<Arfrever> Chainsaw: Other system packages use higher EAPI than is used in
-	   Python.
-* WilliamH votes yes						        [21:53]
-<WilliamH> sorry about the paste.
-<scarabeus> ok sound sane, yes
-<ulm> dberkholz?
-<dberkholz> yes on both.
-<dberkholz> also, my head hurts from banging it into the table.	        [21:54]
-<ulm> unanimous then
-<ulm> second vote
-<ulm> I already have a yes from grobian and dberkholz
-* ulm votes yes							        [21:55]
-* WilliamH votes yes
-<ulm> vote is: "EAPIs 1 and 2 are discouraged, repoman check to be added"
-<scarabeus> yes							        [21:56]
-<dberkholz> i would like to propose the same for for EAPI 3.
-<ulm> Chainsaw: I guess it's yes from you too? since you suggested it?  [21:57]
-<ulm> anyway, it's 5 yes votes out of 6, so it's accepted	        [21:58]
-<ulm> so WilliamH's suggestion, third vote: "EAPIs 0 to 3 are no longer
-      required for the upgrade path of systems"
-<ulm> i.e. "0 to 3" instead of "0 to 2"
-<grobian> ulm third vote: no					        [21:59]
-* ulm votes no
-<scarabeus> 3 is too new i think
-<ulm> scarabeus: this is a "no"?
-<WilliamH> scarabeus: ok no problem there...
-*** mpagano (~mpagano@gentoo/developer/mpagano) has quit: Read error:
-    Connection reset by peer
-<WilliamH> what about adding the discouraged warning to eapi 3?
-<dberkholz> too new? it's 3 years old				        [22:00]
-<Chainsaw> ulm: Yes.
-<Chainsaw> ulm: My apologies for the delayed response.
-<ulm> Chainsaw: that's for the second vote?
-<dberkholz> on the vote, yes
-<Chainsaw> ulm: That is for the second vote: "EAPIs 1 and 2 are discouraged,
-	   repoman check to be added"
-<ulm> second vote unanomously accepted then			        [22:01]
-<ulm> *unanimously
-<dberkholz> EAPI 4 is 2 years old. that's still double our existing support
-	    window
-<scarabeus> dberkholz: you are maybe right, even from the graphs t is second
-	    least used eapi...
-<ulm> dberkholz: it doesn't hurt to be a little conservative there      [22:02]
-<dberkholz> a "discouragement" and repoman warning is pretty conservative
-* WilliamH agrees with dberkholz 
-<WilliamH> I understand that code has to be kept around, but we should
-	   encourage forward movement otherwise it doesn't happen.
-								        [22:03]
-<ulm> Chainsaw: scarabeus: WilliamH: your vote on 3, please
-<scarabeus> vote: extend to eapi 3				        [22:04]
-<ulm> scarabeus: that's a "yes"?
-<scarabeus> thats a yes						        [22:05]
-<ulm> ok :)
-* WilliamH votes yes and extend to eapi 4... given what dberkholz  just said
-  about the age of eapi 4
-<ulm> WilliamH: that would mean that everyone must move to 5	        [22:06]
-<Chainsaw> That's a no. EAPI3 can be upgraded to a current system.
-<ulm> I count 3 yes and 3 no votes
-<scarabeus> awesome1
-<scarabeus> !
-* WilliamH is ok with extending to eapi 3.
-<ulm> that's a tie, so it doesn't pass
-* WilliamH votes yes						        [22:07]
-<dberkholz> guess we'll have to get Betelgeuse's input later.
-<grobian> can we wrap this up, please?
-<ulm> we can come back to it in a few months, deprecating 1 2 is already a
-      start
-<Chainsaw> Agreed, make a start with a simple unambiguous proposal.     [22:08]
-<Chainsaw> And build on that later.
-<ulm> grobian: will be in the summary and you can comment on it ;)
-<ulm> move on?
-<grobian> move on yes						        [22:09]
-<dberkholz> i'm getting short on laptop battery
-<ulm> Open bugs with council involvement
-<ulm> bug 457000
-<willikins> https://bugs.gentoo.org/457000 "Missing log and summary for
-	    20090122 and 20090625 council meetings"; Doc Other,
-	    Project-specific documentation; IN_P; ulm:council
-<ulm> betelgeuse had volunteered to look into writing the missing summary for
-      20090122, but he isn't here				        [22:10]
-<ulm> so I think we should skip this bug
-<grobian> ok
-<ulm> bug 464250						        [22:11]
-<willikins> https://bugs.gentoo.org/464250 "Encourage developers to use the
-	    latest EAPI"; Doc Other, Devmanual; CONF; ulm:devmanual
-<ulm> that was decided in 2011
-<dberkholz> and yet we seem to have just voted against that
-<grobian> huh?
-<dberkholz> assuming encouragement also includes things like discouraging
-	    other options
-<ulm> not yet implemented in the devamnual
-<ulm> dberkholz: encourage != repoman forcing it		        [22:12]
-<grobian> who is responsible for devmanual these days?
-<dberkholz> i am wildly confused how a warning is a forcing
-<WilliamH> ulm: no one said anything about repoman forcing it.
-<ulm> grobian: hwoarang is taking care of it
-<scarabeus> grobian: i think markos
-<grobian> prod him?
-<ulm> well, someone should prepare a patch			        [22:13]
-<ulm> any volunteers?
-<ulm> should be easy, just insert these two sentences
-<grobian> are they in the bug?					        [22:14]
-<ulm> grobian: yes :)
-<WilliamH> ulm: how is a repoman warning forcing an issue?
-<grobian> I'll give it a try then
-<ulm> grobian: thanks						        [22:15]
-<grobian> and I'd like to wrap up
-<ulm> grobian: ok
-<grobian> I have to go
-<jmbsvicetto> ulm: open floor?
-<ulm> jmbsvicetto: status update form Zero_Chaos
-<jmbsvicetto> ok						        [22:16]
-<dberkholz> i'm totally blocking on that
-<scarabeus> just a note new nvidia drivers are released with the support few
-	    hours back
-<dberkholz> so i'll give Zero_Chaos a whip to flog me with
-<Zero_Chaos> I am here as well.
-<Zero_Chaos> short version of the update, blocked on dberkholz, he is going to
-	     become magically responsive :-)			        [22:17]
-<Zero_Chaos> and/or I'll involved QA and revisit next month
-<ulm> we discussed bug 447566 last month, and there should be  status update
-      in the nect meeting
-<ulm> *next
-<dberkholz> i just got your 2nd email, totally forgot about the first.
-<willikins> ulm: https://bugs.gentoo.org/447566
-	    "x11-drivers/nvidia-drivers-{173.14.36,304.64,310.19,313.18} fails
-	    to build with kernel {3.7,3.8}"; Gentoo Linux, Applications; VERI,
-	    WONT; vaeth:jer
-<Zero_Chaos> as of yet, the bug is still an issue.
-<dberkholz> ping me like you're playing pinball
-<Zero_Chaos> at least 6 duplicates tagged since last
-<ulm> Zero_Chaos: so, go ahead please, but make it short
-<scarabeus> actually best would be to block the darn kernels? (eg state in
-	    ebuild what kernels are supported?)			        [22:18]
-<Zero_Chaos> other than that I know people are short on time, I wanted to give
-	     an update that's it. "Still an issue, not being dropped, I am
-	     pushing this till there is a resolution" you may all move on or
-	     engage me after the meeting close.
-<scarabeus> btw iirc nvidia ignores bugs where the kernel patches are applied
-	    (if you are lucky enough and they even care)
-<jmbsvicetto> About the fork, I just want to remind that there are more
-	      packages going into (already went into) the tree. So if the
-	      issue of having multiple ebuilds to provide the same package
-	      interests you (council), you should start paying close attention
-	      to this topic
-<ulm> we're already over time, so I suggest that we move any discussion on
-      this to e-mail						        [22:19]
-<ulm> considering how long and how heated the discussion was last month
-<Zero_Chaos> I will be here after meeting closes if people want to discuss.
-	     I'm defering till after the official meeting for anything more
-	     than the status I already provided. thanks, please move on.
-								        [22:20]
-<ulm> k
-<ulm> open floor
-<ssuominen> was the dodocs/edocs/... voted?
-<dberkholz> Zero_Chaos: sorry about the delay, been kinda swamped in gsoc
-	    stuff w/ deadlines etc. keep pinging and i will make something
-	    happen
-<ulm> ssuominen: nope
-<ssuominen> why is that? time ran out?				        [22:21]
-<dberkholz> Zero_Chaos: be the squeaky wheel
-<dberkholz> oh, btw. now that it's open floor, if you haven't heard, we are in
-	    the google summer of code again
-<dberkholz> for our 8th straight year
-<ulm> ssuominen: hm, there was no voting on any eapi 6 features yet     [22:22]
-<jmbsvicetto> About the "warning" or repoman checks, I think reality has
-	      proven that developers won't change EAPI because of that
-<dberkholz> i'm admin with the help of calchan, antarus, g2boojum. so let
-	    one/all of us know if you want to help
-<ssuominen> oh... I thought that was supposed to happen in next meeting... I
-	    guess not then. my bad
-<jmbsvicetto> either people have time and will to change the EAPI of package
-	      or they don't - warnings aren't likely to increase the
-	      conversion rate - imho				        [22:23]
-<dberkholz> you'd be amazed how OCD people are. especially gentoo users.
-<Chainsaw> Must... fix... repoman... warning.
-<jmbsvicetto> dberkholz: users might annoy a developer about it, but I think
-	      most developers aren't likely to react to that - or at least to
-	      react in a "positive manner"			        [22:24]
-<dberkholz> why would users be running repoman?			        [22:25]
-<Chainsaw> dberkholz: For ebuild submissions? I tell them that's how I'd grade
-	   their work.
-<dberkholz> i'm talking about the developer as a gentoo user, of whom many
-	    tend to be very picky about having things absolutely perfect
-<dberkholz> anyway i'm at 3% battery so i need to power down	        [22:26]
-<Chainsaw> jmbsvicetto: For new repoman warnings my initial response tends to
-	   be "son of a..." followed by an immediate fix. I can't stand
-	   committing builds that warn. It's sloppy.
-<Chainsaw> dberkholz: Talk later.
-<dberkholz> somehow managed to discharge rather than charge last night for my
-	    day at a conference
-<jmbsvicetto> dberkholz: even though we might like perfect, many of us are
-	      getting too little free time to deal with EAPI bumps
-<jmbsvicetto> dberkholz: or we rather prefer to spend our time on other issues
-								        [22:27]
-<Chainsaw> jmbsvicetto: But you have a life now. It's different :)
-<ulm> jmbsvicetto: it's a time scale of several years, so eapi bumps don't
-      have to happen very often					        [22:29]
-<ulm> if version bumps are always to the newest eapi, then it's very little
-      additional work
-<ulm> because the old ebuilds just go away			        [22:30]
-<jmbsvicetto> ulm: sure, but I think in reality most bumps are only done when
-	      their benefit outweights their cost
-<jmbsvicetto> ulm: so a developer needs an incentive on the newer EAPI
-	      (required feature, ease of use, etc), before considering bumping
-	      the EAPI when doing a simple package bump
-<ulm> let's see if EAPI 5 will change that			        [22:31]
-<ulm> with killer feature of subslots				        [22:32]
-<jmbsvicetto> btw, about the "subslot" argument, I think that is starting to
-	      backfire
-<jmbsvicetto> We're getting too many packages using that in the wrong way and
-	      causing everyone to do tons of unnecessary rebuilds
-<scarabeus> jmbsvicetto: it is not backfiring, it is problem of people not
-	    reading how it works :/
-<scarabeus> and what should we do there, we expect the devs to study how it
-	    works, it is described quite well			        [22:33]
-<ssuominen> deja vu. happens everytime new feature comes along, people overuse
-	    them
-<ulm> jmbsvicetto: I sure that people will learn how to use it correctly
-<ulm> scarabeus: it's one of the best documented features we have
-<ulm> at least in devmanual, portage man pages, eapi cheat sheet        [22:34]
-<jmbsvicetto> Oh and as someone that looks at a few logs of stage building,
-	      lately we seem to be going in the wrong direction - the amount
-	      of failures, blocks and scary output in portage has increased
-	      exponentially!!
-<ulm> and quite extensive in each
-<ssuominen> just dropped libpng16 to ~arch, we'll see how subslotting helps ;)
-<ulm> folks, we're 35 minutes over time				        [22:35]
-<Chainsaw> We've already run one laptop down, yes.
-<ulm> anything very important for the open floor?
-<ulm> otherwise, I'd like to close the meeting
-<Chainsaw> I'm ready to move on, yes.
-* Chainsaw plans to turn the laptop off and just read a (paper!) book   [22:36]
-<ulm> next meeting 14 May, 19:00 UTC
-<ulm> betelgeuse will be your chair
-<ulm> meeting is closed, thanks everybody
-<Chainsaw> Thanks ulm.
-* Chainsaw waves						        [22:37]
-*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
-    "next meeting 2013-05-14 |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 |
-    http://www.gentoo.org/proj/en/council/"
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130514-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20130514-summary.txt
deleted file mode 100644
index db156b6a45..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130514-summary.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Summary of Gentoo council meeting 14 May 2013
-
-Agenda
-======
-
-1. Introduction and roll call (5 minutes)
-
-2. econf arguments (5 minutes)
-http://article.gmane.org/gmane.linux.gentoo.pms/751
-
-3. enabling preserve-libs by default in stable Portage (10 minutes)
-http://news.gmane.org/gmane.linux.gentoo.project
-
-4. EAPI 6 items (20 minutes)
-http://thread.gmane.org/gmane.linux.gentoo.devel/84704
-
-5. Open bugs with council involvement (10 minutes)
-
-6. Open floor
-
-Roll call
-=========
-Present: betelgeuse, chainsaw, dberkholz, grobian, scarabeus, ulm, williamh
-Absent: 
-
-econf arguments
-===============
-passed unanimously
-
-enabling preserve-libs by default in stable Portage
-===================================================
-The council voted unanimously that Portage maintainers can turn the feature
-on when they so choose.
-
-EAPI 6 items
-============
-The council noted that EAPI 6 will be approved by the next council due to
-upcoming elections. Ulrich (ulm) will start a wiki page for EAPI 6 items.
-
-The wiki page was started after the meeting and can be found at:
-https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_6_tentative_features
-
-Open bugs with council involvement
-==================================
-Council closed the only open bug (457000)
-
-Open floor
-==========
-Hosting devmanual on github was discussed.
-
-Next meeting date
-=================
-11 June 2013, 19:00 UTC
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130514.txt b/xml/htdocs/proj/en/council/meeting-logs/20130514.txt
deleted file mode 100644
index b483f7b096..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130514.txt
+++ /dev/null
@@ -1,210 +0,0 @@
-<14.05.2013 19:00> -!- Betelgeuse changed the topic of #gentoo-council to: Council meeting NOW. Agenda: http://article.gmane.org/gmane.linux.gentoo.project/2462 | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
-<14.05.2013 19:00>  * scarabeus eeee
-<14.05.2013 19:01> <@Betelgeuse> let's start the rollcall
-<14.05.2013 19:01> <@ulm> here
-<14.05.2013 19:01> <@grobian> here
-<14.05.2013 19:01>  * scarabeus here
-<14.05.2013 19:02> -!- mode/#gentoo-council [+v dberkholz] by ChanServ
-<14.05.2013 19:02> <+dberkholz> back from netsplit-land
-<14.05.2013 19:03> <@Betelgeuse> so chainsaw only one missing?
-<14.05.2013 19:03>  * WilliamH here
-<14.05.2013 19:04> <@Betelgeuse> I can text Tony.
-<14.05.2013 19:04> < scarabeus> maybe he netsplitted too
-<14.05.2013 19:05> -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
-<14.05.2013 19:05> <@Betelgeuse> there we go
-<14.05.2013 19:06> <@Chainsaw> There's always one isn't there.
-<14.05.2013 19:06> <@Chainsaw> Drinks on me tonight.
-<14.05.2013 19:06> <@Betelgeuse> Didn't make it to press send on the SMS either.
-<14.05.2013 19:06> <@Betelgeuse> ok let's start with the agenda then
-<14.05.2013 19:06> <@Betelgeuse> ulm: the first item is yours
-<14.05.2013 19:06> <@ulm> clarification of PMS wording
-<14.05.2013 19:07> <@Betelgeuse> I assume everyone has checked the patch so we can just vote.
-<14.05.2013 19:07> <@ulm> $@ should go after default args for econf
-<14.05.2013 19:07> <+dberkholz> can you link to more info for anyone catching up on the logs later
-<14.05.2013 19:07> <@ulm> http://article.gmane.org/gmane.linux.gentoo.pms/751
-<14.05.2013 19:07> <@Chainsaw> The clarification does not seem to introduce a major behaviour change. This is good.
-<14.05.2013 19:07> <@ulm> plus the rest of that thread
-<14.05.2013 19:08> < scarabeus> ulm: your proposed patch is fine i dont see any reason why this should be in eapi so I agree with this fix
-<14.05.2013 19:08> < WilliamH> Tht behaviour always seemed obvious to me. ;-)
-<14.05.2013 19:08> <@ulm> Chainsaw: it matches portage and paludis behaviour
-<14.05.2013 19:08> < WilliamH> s/tht/that/
-<14.05.2013 19:08> <@Betelgeuse> doesn't hurt to be explicit
-<14.05.2013 19:08> <@Chainsaw> WilliamH: You can not rely on common sense I am afraid.
-<14.05.2013 19:08> <@Betelgeuse> ok votes please:
-<14.05.2013 19:08> <@Betelgeuse> I vote yes
-<14.05.2013 19:08>  * Chainsaw votes yes
-<14.05.2013 19:08>  * ulm votes yes
-<14.05.2013 19:08>  * WilliamH votes yes
-<14.05.2013 19:08> <@grobian> votes yes
-<14.05.2013 19:09> <+dberkholz> yes
-<14.05.2013 19:09> <@Betelgeuse> scarabeus: 
-<14.05.2013 19:09>  * scarabeus votes yes
-<14.05.2013 19:09> <@Betelgeuse> Ok accepted. Next item.
-<14.05.2013 19:09> <@ulm> pushed to PMS repo: http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=31a2d63de1b8914063e82957e41de642d11eb092
-<14.05.2013 19:09> <@Chainsaw> Something proper controversial I hope.
-<14.05.2013 19:09> <@Betelgeuse> seems my link was wrong
-<14.05.2013 19:09> <@Chainsaw> All this agreeing is boring.
-<14.05.2013 19:09> < scarabeus> i have 30 seconds lag so dont be suprised a bit by my off replies :-)
-<14.05.2013 19:10> <@Betelgeuse> though no-one called me on it
-<14.05.2013 19:10> <@Chainsaw> I concentrated on the ones that did work.
-<14.05.2013 19:10> <@Betelgeuse> Thread is here http://article.gmane.org/gmane.linux.gentoo.project/2452
-<14.05.2013 19:10> <@Betelgeuse> zmedico: are you present?
-<14.05.2013 19:11> < scarabeus> you don't need zac too much, simply just find out who of us are really not using the preserved-libs feature
-<14.05.2013 19:12>  * scarabeus is for default on as i use it for few years without much fuzz
-<14.05.2013 19:12> < WilliamH> It is on here with no issues.
-<14.05.2013 19:12> <@ulm> on here too, though I don't have a string opinion if it should be the default
-<14.05.2013 19:12> <@Chainsaw> Since it has a potential to save my systems from breakage rather than introduce breakage...
-<14.05.2013 19:12> <@grobian> there are issues, imo, but it solves more than it causes harm
-<14.05.2013 19:12> <@Chainsaw> I'd actually be in favour of making that the default.
-<14.05.2013 19:12> <+dberkholz> i'm for it
-<14.05.2013 19:13> <@Betelgeuse> We can first decide on if we leave the switching to zac or require it
-<14.05.2013 19:13>  * WilliamH doesn't have a strong opinion on this
-<14.05.2013 19:13> <@ulm> I see it as zac's decision
-<14.05.2013 19:14> <@Chainsaw> ulm: Recommendation to enable it, if zac feels it is ready?
-<14.05.2013 19:14> <@ulm> yeah
-<14.05.2013 19:14> <@grobian> IMO it's a portage feature, but the question is if we want to formalise it in pms at some point?
-<14.05.2013 19:14> < WilliamH> Betelgeuse: that's a good point, should we just leave this to zac?
-<14.05.2013 19:14> <@Chainsaw> ulm: To make it not seem like an edict.
-<14.05.2013 19:14> <@Chainsaw> WilliamH: Well, he asked for our opinion.
-<14.05.2013 19:15> <@Betelgeuse> Chainsaw: Which I think is good.
-<14.05.2013 19:15> <@grobian> do we ever have to rely on this feature from ebuilds or something
-<14.05.2013 19:15> < WilliamH> Chainsaw: so what if we just tell him we are ok with him enabling it when he feels it is ready?
-<14.05.2013 19:15> < scarabeus> so yea, lets tell zac to turn it on if he wants
-<14.05.2013 19:15> <@Chainsaw> WilliamH: That is what I am suggesting.
-<14.05.2013 19:15> <@Betelgeuse> Chainsaw: Especially as I remember there being something about it going against EAPIs
-<14.05.2013 19:15>  * ulm has no objections against making it the default
-<14.05.2013 19:15> <@Betelgeuse> But don't count on my memory fully on that :)
-<14.05.2013 19:15> <@Chainsaw> Betelgeuse: EAPI applies to all package managers, this is a portage-specific default change.
-<14.05.2013 19:16> <@Chainsaw> Betelgeuse: Seems out of EAPI jurisdiction to me.
-<14.05.2013 19:16> <@Betelgeuse> Chainsaw: features might not be implemented strictly following EAPI
-<14.05.2013 19:16> <@Betelgeuse> implementable
-<14.05.2013 19:16> <@Betelgeuse> Any way lets vote: zmedico can turn on preserve-libs when he so chooses:
-<14.05.2013 19:16>  * WilliamH agrees with chainsaw, this has nothing to do with eapis
-<14.05.2013 19:16> <@Chainsaw> Betelgeuse: I vote yes.
-<14.05.2013 19:17>  * WilliamH votes yes
-<14.05.2013 19:17>  * grobian votes yes
-<14.05.2013 19:17>  * scarabeus yes
-<14.05.2013 19:17>  * ulm votes yes
-<14.05.2013 19:18> <@Betelgeuse> dberkholz: 
-<14.05.2013 19:18> <+dberkholz> didn't i already vote?
-<14.05.2013 19:18> <@Betelgeuse> I didn't see
-<14.05.2013 19:18> <+dberkholz> i guess i will say it again, i'm for it
-<14.05.2013 19:18> <@Betelgeuse> yes
-<14.05.2013 19:18> <@Betelgeuse> ok passed
-<14.05.2013 19:18> <@Betelgeuse> next item
-<14.05.2013 19:19> <@Betelgeuse> There was a request for EAPI 6 items
-<14.05.2013 19:19> <@Betelgeuse> We really only approve final wording
-<14.05.2013 19:19> <@grobian> yes
-<14.05.2013 19:19> <@Betelgeuse> ulm: can you give a status update?
-<14.05.2013 19:20> <+dberkholz> it would be useful to provisionally approve features, so PM implementers don't feel like they're potentially wasting time
-<14.05.2013 19:20> <@grobian> some of the ideas sound ok, but I don't feel we can do anything on this
-<14.05.2013 19:20> <@ulm> not really, as I haven't looked into things in detail
-<14.05.2013 19:20> <@grobian> dberkholz: that's hard if things like the final name of the function are unknown ;)
-<14.05.2013 19:20> <@ulm> mgorny's initial list seems o.k.
-<14.05.2013 19:20> <@Betelgeuse> I have my doubts this council will be approving it any way
-<14.05.2013 19:20> <@ulm> except maybe for #449806
-<14.05.2013 19:20> <@Chainsaw> https://bugs.gentoo.org/show_bug.cgi?id=449806
-<14.05.2013 19:20> <+dberkholz> i like most of them except for everything related to DOCS and PATCHES. i really see those as legacy of the days before default() made it trivial to modify functions.
-<14.05.2013 19:21> <@grobian> and 273101
-<14.05.2013 19:21> <@Chainsaw> https://bugs.gentoo.org/show_bug.cgi?id=273101
-<14.05.2013 19:21> <@ulm> I suggest to create a wiki page for EAPI 6 candidates
-<14.05.2013 19:21> <+dberkholz> also bug 357561 is pretty tricky
-<14.05.2013 19:21> <@ulm> as it was useful for EAPI 5 items
-<14.05.2013 19:21> <@Chainsaw> https://bugs.gentoo.org/show_bug.cgi?id=357561
-<14.05.2013 19:21>  * grobian agrees
-<14.05.2013 19:22> <+dberkholz> good call ulm.
-<14.05.2013 19:22> <@Betelgeuse> wfm
-<14.05.2013 19:23> <@ulm> ok, make the wiki page an action point
-<14.05.2013 19:23> <@Chainsaw> Yes, that would be good. And then trawl the wiki each meeting to see if anything looks controversial to a majority of the council?
-<14.05.2013 19:23> <@Chainsaw> A fixed agenda point, like the bugs with council involvement.
-<14.05.2013 19:23> <@Chainsaw> That way nobody wastes their time for more than a month.
-<14.05.2013 19:23> <@ulm> sure, that can be done
-<14.05.2013 19:25> <@Betelgeuse> anything else?
-<14.05.2013 19:26> <@ulm> heh, we're ahead of schedule :)
-<14.05.2013 19:27> <+dberkholz> that's a pleasant change.
-<14.05.2013 19:27> < scarabeus> does not happen too often :-)
-<14.05.2013 19:27> <@Betelgeuse> I assume not.
-<14.05.2013 19:27> <@Betelgeuse> Let's move to open bugs.
-<14.05.2013 19:27> <@Betelgeuse> I submitted a proposed summary to that one bug
-<14.05.2013 19:27> <@ulm> https://bugs.gentoo.org/show_bug.cgi?id=457000
-<14.05.2013 19:27> <@Betelgeuse> I can't commit it from this machine but I assume someone else here can
-<14.05.2013 19:27> <@ulm> Betelgeuse: summary lgtm
-<14.05.2013 19:28> <+dberkholz> k
-<14.05.2013 19:28> <@Chainsaw> Betelgeuse: Summary looks accurate, thank you.
-<14.05.2013 19:29> <@Betelgeuse> ulm: can you commit?
-<14.05.2013 19:29> <@grobian> looks ok
-<14.05.2013 19:29> <@ulm> Betelgeuse: yes
-<14.05.2013 19:30> <@ulm> second ...
-<14.05.2013 19:30> <@Betelgeuse> ok next bug
-<14.05.2013 19:31> <@Betelgeuse> that seems to be the only one
-<14.05.2013 19:31> <@Betelgeuse> so I will open the floor for everyone
-<14.05.2013 19:32> < WilliamH> If I am the only one who is concerned about this, that's cool, but I thought I would ask.
-<14.05.2013 19:32> <@Chainsaw> Please assemble in an orderly row. The microphone is on.
-<14.05.2013 19:32> < WilliamH> Am I the only one who is concerned about the reaction on -dev to Markos moving the devmanual repository to github?
-<14.05.2013 19:32> <@grobian> no
-<14.05.2013 19:32> <@grobian> I think it should stay on gentoo hardware
-<14.05.2013 19:32> <@grobian> a mirror is fine
-<14.05.2013 19:33>  * WilliamH is confused about why since we have a lot of packages that have their source trees on github.
-<14.05.2013 19:33> <@Betelgeuse> upstream != Gentoo
-<14.05.2013 19:33> <@Betelgeuse> do you mean Gentoo projects?
-<14.05.2013 19:33> < WilliamH> I'm not sure what the difference is...
-<14.05.2013 19:34> <@ulm> WilliamH: other upstreams are not bound by our social contract
-<14.05.2013 19:34> <+dberkholz> our social contract has traditionally been read as gentoo the distribution, not gentoo the project
-<14.05.2013 19:34> <+dberkholz> we've used proprietary dns providers in the past, for example
-<14.05.2013 19:35> <@grobian> I fail to see the poitn in that statement
-<14.05.2013 19:35> <@Betelgeuse> a wrong does not justify another
-<14.05.2013 19:35> < WilliamH> How do you determin which upstreams are bound by the social contract then?
-<14.05.2013 19:35> < WilliamH> determine *
-<14.05.2013 19:36> <@grobian> do you consider the devmanual a document that is leading for Gentoo?
-<14.05.2013 19:37> <+dberkholz> i would read it as the ones that are required to complete installation according to the gentoo handbook
-<14.05.2013 19:37> <@ulm> github using non-free software is only one small aspect
-<14.05.2013 19:37> <@grobian> since we specify policies in the devmanual, I'd find it weird if we'd put that out of our hands
-<14.05.2013 19:37> <@grobian> we need an authorative copy on our own hardware, imo
-<14.05.2013 19:38> <@ulm> imho, the bigger issue is that it's a wrong signal if we move important ducumentation from our hardware to third-party servers
-<14.05.2013 19:38> <@ulm> documentation*
-<14.05.2013 19:38> <@Betelgeuse> And it's a signal about our distro that we run on Gentoo
-<14.05.2013 19:38> <@Betelgeuse> So I agree with ulm probably :)
-<14.05.2013 19:39> <+dberkholz> a signal that we care about building a linux distro and not maintaining a ton of infrastructure?
-<14.05.2013 19:39> <+dberkholz> s/linux/$OS/
-<14.05.2013 19:40> <@grobian> lol
-<14.05.2013 19:40> < WilliamH> The other thing is,  with git, the dependency on a specific repository is really weak.
-<14.05.2013 19:40> <@grobian> WilliamH: so you mean with CVS that's not the case?
-<14.05.2013 19:40> < WilliamH> you just do git remote origin set-url foobar
-<14.05.2013 19:40> < WilliamH> then you are pushing somewhere else.
-<14.05.2013 19:41> <@grobian> WilliamH: ok, but how does that change what would/should be the authorative location?
-<14.05.2013 19:41> < WilliamH> grobian: That's the advantage of distributed vcs. every repo has all of the history.
-<14.05.2013 19:42> < scarabeus> just as note opensuse has everything on github, because it is easiest to attract contributors
-<14.05.2013 19:42> < scarabeus> even tho it could be hosted
-<14.05.2013 19:42> <@grobian> WilliamH: I'm trying to understand where VCS supports the argument of moving our own policies to an external repo
-<14.05.2013 19:42> < scarabeus> so the point in "we don't have server we are not really caring" is quite moot
-<14.05.2013 19:42> <@grobian> does it mean once we've moved to git, we'll move to github afterwards?
-<14.05.2013 19:43> < WilliamH> grobian: that's not a relevant question really.
-<14.05.2013 19:43> < WilliamH> No one is saying that we have to move everything to github
-<14.05.2013 19:44> <@grobian> I'm trying to understand why we need to move, I thought a DVCS in the first place was easy to keep in many places with full history and so on
-<14.05.2013 19:44> <@grobian> so we can be on both locations, and have all the benefits, don't we?
-<14.05.2013 19:45> <+dberkholz> is the idea here that we were about to end early so we're just going to screw around talking about git/github in yet another location?
-<14.05.2013 19:45> <+dberkholz> if so, why don't we wrap the meeting and you guys can keep going
-<14.05.2013 19:45> < WilliamH> dberkholz: No, I was just trying to understand why we jumped Markos' case for moving the devmanual to github.
-<14.05.2013 19:46> < WilliamH> dberkholz: Just a question...
-<14.05.2013 19:46> <@Betelgeuse> Partly probably because it was not discussed before the move.
-<14.05.2013 19:47> <+dberkholz> these meetings should be for decisions, not further discussions and clarifications in a new forum on an existing and active mailing-list thread
-<14.05.2013 19:47>  * ulm looks at devmanual history with gitk
-<14.05.2013 19:47> < WilliamH> dberkholz: Ok, that's fine with me.
-<14.05.2013 19:47> <@ulm> some pointless merges recently, is that caused by github workflow?
-<14.05.2013 19:48> <@Betelgeuse> ulm: github makes a merge for fast forwards too
-<14.05.2013 19:48> <+dberkholz> i'm gonna head out folks. see ya next time
-<14.05.2013 19:48> <@Betelgeuse> Thanks everyone.
-<14.05.2013 19:48> <@Betelgeuse> I will close the official part of the meeting now.
-<14.05.2013 19:48> <@ulm> Betelgeuse: thanks for chairing
-<14.05.2013 19:48> < WilliamH> Betelgeuse: It shouldn't. No one requires you to use the github web ui.
-<14.05.2013 19:49> <@Betelgeuse> WilliamH: github != git
-<14.05.2013 19:49> <@Betelgeuse> WilliamH: github does the merge
-<14.05.2013 19:49> <@Betelgeuse> WilliamH: and yes you don't have to
-<14.05.2013 19:49> <@ulm> Betelgeuse: next meeting date?
-<14.05.2013 19:49> <@ulm> June 11?
-<14.05.2013 19:49> <@Betelgeuse> ulm: true
-<14.05.2013 19:49> < WilliamH> Betelgeuse: It doesn't have to; you can use git remotes.
-<14.05.2013 19:49> < WilliamH> June 11 sounds good to me.
-<14.05.2013 19:49> <@Betelgeuse> ulm: wfm
-<14.05.2013 19:50> <@ulm> Betelgeuse: well, you'll be chairing ;)
-<14.05.2013 19:50> -!- Betelgeuse changed the topic of #gentoo-council to: Next meeting: 2013-06-11 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130611-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20130611-summary.txt
deleted file mode 100644
index c11e9d8575..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130611-summary.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-Summary of Gentoo council meeting 11 June 2013
-
-Agenda
-======
-1. Introduction and roll call (5 minutes)
-
-2. Adding support files to packages without maintainer consent (10min)
-http://article.gmane.org/gmane.linux.gentoo.project/2487
-
-3. Code of Conduct approval (20min)
-http://article.gmane.org/gmane.linux.gentoo.project/2470
-
-4. Reflection discussion on the term of this council (25min)
-http://news.gmane.org/gmane.linux.gentoo.project
-
-5. Open floor
-
-
-Roll call
-=========
-Present:
-betelgeuse, chainsaw, dberkholz, grobian, scarabeus, ulm, williamh
-
-Adding support files to packages without maintainer consent
-===========================================================
-There was consensus that the existing rules for non-maintainer
-commits (as outlined in the devmanual) are sufficient. No policy
-changes are required.
-
-Code of Conduct approval
-========================
-The council discussed scarabeus's proposal for a new Code of Conduct.
-A vote was then taken to accept, reject, or revisit the issue later.
-- Revisit later (accepted with 4 votes)
-
-Reflection discussion on the term of this council
-=================================================
-General opinion was that the workflow in the past year was efficient.
-Approval of EAPI 5 was an important accomplishment.
-
-Open floor
-==========
-mgorny reported on the progress of the multilib effort: xlibs and
-part of soundlibs are done. There is only slow progress with baselibs;
-some bugs did not get any reply for many months.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130611.txt b/xml/htdocs/proj/en/council/meeting-logs/20130611.txt
deleted file mode 100644
index 5afdd0dc82..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130611.txt
+++ /dev/null
@@ -1,252 +0,0 @@
-<11.06.2013 19:02> -!- Betelgeuse changed the topic of #gentoo-council to: Meeting going on: http://thread.gmane.org/gmane.linux.gentoo.project/2495 | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/
-<11.06.2013 19:02> <@Betelgeuse> Rollcall!
-<11.06.2013 19:02> <@ulm> here
-<11.06.2013 19:02>  * scarabeus up
-<11.06.2013 19:02> <@grobian> here
-<11.06.2013 19:02> <+dberkholz> hi
-<11.06.2013 19:02>  * WilliamH is here
-<11.06.2013 19:03>  * Chainsaw is present
-<11.06.2013 19:03> <@Betelgeuse> good
-<11.06.2013 19:03> <@Betelgeuse> anyone object to the summary I sent?
-<11.06.2013 19:03> <@grobian> nope
-<11.06.2013 19:04> <@Chainsaw> None here.
-<11.06.2013 19:04> <@Betelgeuse> ulm: I will add your link
-<11.06.2013 19:04> <@Betelgeuse> ok thanks
-<11.06.2013 19:04> < scarabeus> nope it reflects what it should
-<11.06.2013 19:04> <@Betelgeuse> First item
-<11.06.2013 19:04> <@Betelgeuse> http://article.gmane.org/gmane.linux.gentoo.project/2487
-<11.06.2013 19:04> < scarabeus> btw guys i have 2secs lag so dont get suprised with my shifted replies
-<11.06.2013 19:04> <@Betelgeuse> rich0: around?
-<11.06.2013 19:05> <@ulm> actually we have a policy for non-maintainer commits
-<11.06.2013 19:05> <@ulm> http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html#touching-other-developers-ebuilds
-<11.06.2013 19:05> < scarabeus> ulm: it was other herd member who added the patch to my knowledge no?
-<11.06.2013 19:05> <+dberkholz> that's ignored issues, not disagreements
-<11.06.2013 19:06> < Zero_Chaos> in the specifically complained about case it was a co-maintainer commit.
-<11.06.2013 19:06> <@Chainsaw> They were both maintainers on the package in this case.
-<11.06.2013 19:06> < WilliamH> It was a co-maintainer iirc that added thefiles.
-<11.06.2013 19:06> < scarabeus> the problem is that too much people are in "kill it its systemd" mood", if you don't have to care about the bugs, there should not be problem if they add pink piggies
-<11.06.2013 19:06> <+dberkholz> assuming that introducing new code doesn't create bugs elsewhere that are hard to diagnose
-<11.06.2013 19:07> < scarabeus> yea but even that falls under the good old "you broke it, fix your shit" which we do with nm-commits and everything else
-<11.06.2013 19:07> <@ulm> I'm strongly opposed against any special rules for systemd
-<11.06.2013 19:07> < WilliamH> ulm: same here.
-<11.06.2013 19:07> <+dberkholz> my philosophy is that maintainer rules, unless superceded by a higher authority
-<11.06.2013 19:07> <@ulm> the current policies are good enough to cover such cases
-<11.06.2013 19:08> <@Betelgeuse> dberkholz: But isn't that what the request is? Asking the higher authority.
-<11.06.2013 19:08> <+dberkholz> it may be that we should actually have a lead maintainer concept vs a committee
-<11.06.2013 19:08> < Zero_Chaos> the issue in this case is one maintainer didn't want systemd support the other one did. no policy covers this afaik aside from general conflict resolution which was ignored in favor of crying on -dev.
-<11.06.2013 19:08> <@Betelgeuse> I can see the point that things like systemd could not never get added if any maintainer could block it
-<11.06.2013 19:09>  * WilliamH tends to agree with Zero_Chaos  on this specific case.
-<11.06.2013 19:10> < WilliamH> It wasn't a case where adding the file would break something.
-<11.06.2013 19:10> <@Betelgeuse> Still I don't think policies necessary need adjusting
-<11.06.2013 19:10> <@Betelgeuse> If you need something system wide with opposition then ask council on a case by case basis
-<11.06.2013 19:10> <@Chainsaw> The existing rules make sense. No change required.
-<11.06.2013 19:11> <@ulm> Chainsaw: +1
-<11.06.2013 19:11> < WilliamH> +1
-<11.06.2013 19:11> <@Chainsaw> And no, even *I* won't advocate for systemd-specific policy. Please give it a rest.
-<11.06.2013 19:11> < scarabeus> i agree policies dont need to change
-<11.06.2013 19:12> <@Betelgeuse> ok that seems to be the majority
-<11.06.2013 19:12> <@grobian> Chainsaw: +1
-<11.06.2013 19:12> <@Betelgeuse> moving on to the next item
-<11.06.2013 19:12> <@Betelgeuse> http://article.gmane.org/gmane.linux.gentoo.project/2470
-<11.06.2013 19:13> <@Betelgeuse> scarabeus: your thread
-<11.06.2013 19:13> < scarabeus> okey guys
-<11.06.2013 19:13> < scarabeus> i hope you guys red the mail and the thread
-<11.06.2013 19:14> <+dberkholz> 5:1 not 3:1 =)
-<11.06.2013 19:14> < Zero_Chaos> I specifically don't like "whenever the
-<11.06.2013 19:14> < Zero_Chaos> project will be judged by our actions"
-<11.06.2013 19:14> < Zero_Chaos> this is an interpersonal code of conduct not just a "lets try not to make gentoo look stupid" policy
-<11.06.2013 19:15> <+dberkholz> scarabeus: can you describe the source of your material or is it all original?
-<11.06.2013 19:15> <@Chainsaw> decission -> decision
-<11.06.2013 19:15> <+dberkholz> scarabeus: i didn't take the time to read through all of your reference to see which was the "biggest" contrib
-<11.06.2013 19:15> < scarabeus> dberkholz: at the bottom, ubuntu coc/suse coc and kde coc
-<11.06.2013 19:15> <+dberkholz> vs which you did yourself
-<11.06.2013 19:15> < scarabeus> possibly kde coc is greatest contrib
-<11.06.2013 19:16> <+dberkholz> and really if we're gonna base on some other one, i might just take the whole thing wholesale instead of a mishmash
-<11.06.2013 19:16> <@Betelgeuse> scarabeus: The thing I am missing is an update based on the thread
-<11.06.2013 19:16> < scarabeus> it was updated in the link
-<11.06.2013 19:16> < scarabeus> http://dev.gentooexperimental.org/~scarabeus/gentoo-coc.txt
-<11.06.2013 19:17> <@ulm> scarabeus: section "examples of inappropriate behavior", could you clarify what is considered as "public accessible areas"? would gentoo mirrors count as such?
-<11.06.2013 19:18> < scarabeus> oh yes, those do count
-<11.06.2013 19:19> <@Betelgeuse> scarabeus: it still lists the language on council that people raised in the thread
-<11.06.2013 19:19> <@ulm> then it's censorship on package content
-<11.06.2013 19:19> <@Betelgeuse> scarabeus: So my point was if it still needs rounds on ml
-<11.06.2013 19:19> < scarabeus> Betelgeuse: yes and i explained why i kept it there
-<11.06.2013 19:19> <@Betelgeuse> scarabeus: true
-<11.06.2013 19:20> < scarabeus> btw typos, i think devrel should be allowed to do minor modifications without council approval
-<11.06.2013 19:21> < scarabeus> rewording for clarity/typos/spells/whateverifuckedupthere :-)
-<11.06.2013 19:21> <@grobian> define minor ;)
-<11.06.2013 19:21> < scarabeus> ^
-<11.06.2013 19:21> <@grobian> clarity is vague
-<11.06.2013 19:21> <@grobian> typos/spells are ok
-<11.06.2013 19:21> <@Chainsaw> I would consider it more like a legal document, and that would require votes to update it.
-<11.06.2013 19:21> <@grobian> what's the problem with getting a little ack on a small diff from council@g.o?
-<11.06.2013 19:22> <+dberkholz> may seem a little weird but i don't like the term enforcers
-<11.06.2013 19:22> <@Chainsaw> You cannot derive much meaning from a document that remains in flux.
-<11.06.2013 19:22> <@Betelgeuse> scarabeus: I agree with rich though
-<11.06.2013 19:22> <@Chainsaw> (And if you want to continue tweaking it that much, why did you submit it for approval?)
-<11.06.2013 19:22> < scarabeus> Betelgeuse: i told there it should be on devrel  to pick what they want didn't I, so whatever you and markos decide :P
-<11.06.2013 19:23> < scarabeus> grobian: okey thats a good point, i just didnt want one ' addition to take 30 days, but to be fair who cares it lacks some '
-<11.06.2013 19:23> <+dberkholz> i also agree with rich on the non-conflict, and with roy on removing specific examples or clarifying that as "some examples" so it doesn't imply that's everything
-<11.06.2013 19:24> < scarabeus> ok removing the non-conflict part
-<11.06.2013 19:24> < scarabeus> also fixed the decisions
-<11.06.2013 19:24> <+dberkholz> and i can come up with references that bad-to-good is more like 5:1 than 3:1 if you like =)
-<11.06.2013 19:24> < scarabeus> ok refresh
-<11.06.2013 19:24> <@Chainsaw> "including but not limited to" is the accepted language for non-exhaustive examples/lists.
-<11.06.2013 19:25> < scarabeus> dberkholz: agree it can be even 5:1
-<11.06.2013 19:26> < scarabeus> dberkholz: i will drop the sentence as whole or just adjust it?
-<11.06.2013 19:26> < scarabeus> 3:1 is minimum as i think
-<11.06.2013 19:26> <+dberkholz> where did you come up with that number?
-<11.06.2013 19:26> < scarabeus> marketing stuff i got from uni, nifty book 4 euros :P
-<11.06.2013 19:26> < scarabeus> scriptum for exam :P
-<11.06.2013 19:27> < scarabeus> Chainsaw: the addition should be to topic?
-<11.06.2013 19:27> <@Chainsaw> scarabeus: Or in a lead-in sentence.
-<11.06.2013 19:28> <@Chainsaw> scarabeus: You could shorten the heading to bad behaviour, that'll make it easier to slot in.
-<11.06.2013 19:29> < scarabeus> shorten?
-<11.06.2013 19:29> < scarabeus> not get it
-<11.06.2013 19:30> <+dberkholz> back in a few, family issue.
-<11.06.2013 19:30> < scarabeus> dberkholz: dropped the line as whole, i was actually not wanting to add it there in the first draft, but others at suse convinced me it sounds good :-)
-<11.06.2013 19:31> <@Betelgeuse> Ok I think we need to see what gets the majority 1) accept 2) reject 3) revisit later
-<11.06.2013 19:31>  * WilliamH votes revisit later
-<11.06.2013 19:31> <@grobian> 3)
-<11.06.2013 19:31> <@ulm> 3
-<11.06.2013 19:32> < scarabeus> you know you could've replied on the list
-<11.06.2013 19:33> < scarabeus> i sent it quite in advance even to -council
-<11.06.2013 19:33>  * grobian feels guilty
-<11.06.2013 19:33> <@Chainsaw> Even if it makes me feel bad, 3.
-<11.06.2013 19:34> <@Chainsaw> (If I'd have had an agenda earlier I would have looked at it)
-<11.06.2013 19:34> <@Betelgeuse> yes, sorry about that
-<11.06.2013 19:35> < scarabeus> Chainsaw: ok i kinda updated the topic for that section for further reference, cant think up better wording
-<11.06.2013 19:35> <@Betelgeuse> The next item is wrapping up the term.
-<11.06.2013 19:35> <@Betelgeuse> I think we can handle rich's request for the elections too
-<11.06.2013 19:36> <@Chainsaw> Are we seconds from netsplit? I am experiencing horrendous lag...
-<11.06.2013 19:37> <@grobian> Betelgeuse: ok
-<11.06.2013 19:37> <@Betelgeuse> So how does everyone think the year went?
-<11.06.2013 19:38> <@Chainsaw> It wasn't perfect, but I think we did rather well in voting on what was actionable and pushing back on what wasn't.
-<11.06.2013 19:38> <@Chainsaw> (The latter is a definite change from the year before, and an important one.)
-<11.06.2013 19:38> < WilliamH> I would agree, I think things have gone pretty well this year.
-<11.06.2013 19:39> <@grobian> overall I'm happy
-<11.06.2013 19:39> < scarabeus> could've been much worse :-)
-<11.06.2013 19:39> <@Chainsaw> scarabeus: Oh, easily :)
-<11.06.2013 19:39> < scarabeus> and we approved eapi! :P (as usual)
-<11.06.2013 19:39> <@Chainsaw> I don't take credit for any EAPI work. That's all ulm.
-<11.06.2013 19:40> <@Chainsaw> All I did was say yes a few times.
-<11.06.2013 19:40> < WilliamH> Chainsaw: heh I know what you mean there.
-<11.06.2013 19:40> < Hello71> when's the log going up?
-<11.06.2013 19:40> <@Chainsaw> Hello71: For tonight's council meeting? When we're done!
-<11.06.2013 19:41> < scarabeus> when the meeting ends as always? :-)
-<11.06.2013 19:41> < Hello71> hehe
-<11.06.2013 19:41> < Hello71> that would make sense
-<11.06.2013 19:41> <@Betelgeuse> scarabeus: minus last time :)
-<11.06.2013 19:41> <@ulm> Chainsaw: thanks, but it's not true that it's all me ;)
-<11.06.2013 19:41>  * Chainsaw escorts Hello71 to the visitors area
-<11.06.2013 19:41> <@ulm> I'm mainly collecting contributions of others
-<11.06.2013 19:41> < scarabeus> ulm: yea but you are mostly knees deep in it so you deserve the credit
-<11.06.2013 19:42> <@Chainsaw> ulm: I rely heavily on your summaries.
-<11.06.2013 19:42> < scarabeus> we just say "yay" "nay"
-<11.06.2013 19:42> < scarabeus> based on what Chainsaw said :P
-<11.06.2013 19:42> < scarabeus> i even read the pms so i dont feel dumb tho
-<11.06.2013 19:42> < scarabeus> but your summaries are great "don't try to sneak somethink evil next time now you know it"
-<11.06.2013 19:42> < mgorny> scarabeus: did you feel dumb afterwards? :P
-<11.06.2013 19:43> <@Betelgeuse> Any practical tips we could leave to the next council?
-<11.06.2013 19:43> < scarabeus> no just numb and could not feel my tongue
-<11.06.2013 19:44> <@grobian> Make sure you (council member) have enough time in your life to properly prepare ;)
-<11.06.2013 19:44> < scarabeus> don't wait for the darn agenda and read up in advance ;-)
-<11.06.2013 19:45> <@Betelgeuse> Something else that most councils wouldn't have said? :D
-<11.06.2013 19:45> <@Betelgeuse> It seems like the format has become quite steady
-<11.06.2013 19:46> < scarabeus> yeah use hardened, its the most coolest thing we have in gentoo right now, and we should promote it
-<11.06.2013 19:46> < scarabeus> :-)
-<11.06.2013 19:47> <@Betelgeuse> Do people plan on running again?
-<11.06.2013 19:47> <@Chainsaw> I will, yes.
-<11.06.2013 19:47>  * WilliamH would like to, yes
-<11.06.2013 19:47> <@ulm> me too
-<11.06.2013 19:48> < scarabeus> might, dunno about time
-<11.06.2013 19:48> <@grobian> in doubt
-<11.06.2013 19:48> <@grobian> I really lack the time
-<11.06.2013 19:49> <@Betelgeuse> If I do, I should aim to chair more. Makes me pay more attention.
-<11.06.2013 19:50> <@Betelgeuse> Hmm it's been fix years.
-<11.06.2013 19:50> <@Betelgeuse> s/fix/six/
-<11.06.2013 19:50> <@Betelgeuse> No wonder much of it blurs together
-<11.06.2013 19:51> <@Betelgeuse> ulm: I committed the summary
-<11.06.2013 19:52> <@Chainsaw> Betelgeuse: Twice as long as me.
-<11.06.2013 19:52> <@Chainsaw> Betelgeuse: This is my third council year.
-<11.06.2013 19:53> <@Betelgeuse> If people decide to not run, the elections people could probably use some help.
-<11.06.2013 19:55> <@Betelgeuse> Let's open the floor the audience
-<11.06.2013 19:55> < mgorny> finally!
-<11.06.2013 19:55> <@Betelgeuse> You can let all your fustrations out now
-<11.06.2013 19:55> < mgorny> while you're still here, i wanted to get a bit of your opinion on our little multilib effort
-<11.06.2013 19:56> <+dberkholz> i'm considering it
-<11.06.2013 19:56> < mgorny> we've switched whole xlibs to the new eclasses, a few soundlibs and i get quite frustrated with base-system
-<11.06.2013 19:56> <+dberkholz> my goal is basically "maintain the gentoo philosophy" vs trying to do anything earth-shatting
-<11.06.2013 19:56> <+dberkholz> shattering, too
-<11.06.2013 19:56> < scarabeus> mgorny: whats with base?
-<11.06.2013 19:56> < scarabeus> mgorny: no new eapi?
-<11.06.2013 19:56> < mgorny> i feel like it's a team of people who intentionally ignore bugs they don't like
-<11.06.2013 19:57> < mgorny> it's irritating to report a bug, ping, query and not get a word of reply for a few months
-<11.06.2013 19:57> < mgorny> that's my frustration
-<11.06.2013 19:57> < scarabeus> !herd base
-<11.06.2013 19:57> < willikins> scarabeus: No such herd base
-<11.06.2013 19:57> < scarabeus> !herd base-system
-<11.06.2013 19:57> < willikins> scarabeus: (base-system) cardoe, chainsaw, flameeyes, hwoarang, radhermit, robbat2, ssuominen, vapier, williamh
-<11.06.2013 19:57> -!- mode/#gentoo-council [+o hwoarang] by ChanServ
-<11.06.2013 19:57> < scarabeus> thats quite few people
-<11.06.2013 19:58> < Zero_Chaos> some of them in this room....
-<11.06.2013 19:58> < mgorny> i think vapier is the person most appropriate for the particular packages
-<11.06.2013 19:58> < mgorny> and he's the person frustrating me most, to be honest
-<11.06.2013 19:59> <@grobian> so where's this going?
-<11.06.2013 19:59> < mgorny> i've already had a bug with him which took him one year to reply
-<11.06.2013 19:59> <@Chainsaw> grobian: Character assassination?
-<11.06.2013 20:00> < mgorny> me? sorry, i focused on frustration :P
-<11.06.2013 20:00> < mgorny> i'm asking for general tips/opinion
-<11.06.2013 20:00> < floppym> It sounds like someone needs to poke the other base-system members to pick up the slack.
-<11.06.2013 20:00> <@grobian> or find a way to progress
-<11.06.2013 20:00> <@Chainsaw> Most of this is about toolchain, not base-system.
-<11.06.2013 20:00> <@Chainsaw> And that set of developers is smaller.
-<11.06.2013 20:00> <@grobian> because it's so easy to say "this works for me", but you don't know what else you break
-<11.06.2013 20:01> < mgorny> well, we intend not to touch toolchain
-<11.06.2013 20:01> <+dberkholz> test suites, test boxen
-<11.06.2013 20:01> <@Chainsaw> mgorny: Generally, the moment you end up faced with vapier, you're well within the toolchain boundary.
-<11.06.2013 20:01> < scarabeus> also in base-system we have quite prob with stabilisations, debian has newer pkgs than us sometimes :P
-<11.06.2013 20:01> < mgorny> i mean, gcc, glibc are built for multilib already and those need not to be fixed
-<11.06.2013 20:01> < mgorny> the packages in question were zlib and bzip2
-<11.06.2013 20:02> <+dberkholz> i would buy lots of beer for anyone who set up pre-mirror CI, at least for stuff in a stage3
-<11.06.2013 20:02> <@grobian> ok, but apart from that those packages aren't to be taken lightly
-<11.06.2013 20:02> <@ulm> mgorny: xlibs should be well tested by now
-<11.06.2013 20:02> <@ulm> so why don't we stabilise them, and then see about the rest
-<11.06.2013 20:02> < WilliamH> scarabeus: afaik anyone can file a stabilization request, you just can't add the arch's.
-<11.06.2013 20:02> < mgorny> ulm: some of them may be stable already
-<11.06.2013 20:03> < mgorny> at least people asked me if it's fine to stabilize them and i said yes
-<11.06.2013 20:03> < scarabeus> WilliamH: i had bug opened for 6 months like that -> motivation to fill more goes to drain
-<11.06.2013 20:03> < mgorny> this is generally something like devrel/userrel issue
-<11.06.2013 20:04> < mgorny> i can understand developers being angry, unwilling and so on with people
-<11.06.2013 20:04> < mgorny> but people reporting bugs and not getting a single answer for one year is something making us look really bad
-<11.06.2013 20:04> <@ulm> mgorny: hm, I see it more as a case where consensus on -dev ml should be reached
-<11.06.2013 20:04> <@hwoarang> you can't just force people to reply can you?
-<11.06.2013 20:04> <@ulm> and if that's not possible, a council decision
-<11.06.2013 20:05> < TomWij> mgorny: Exactly, I'm planning to set up a project on that; but I'm kind of afraid that not enough people are going to chime in to reach the goal.
-<11.06.2013 20:05>  * WilliamH agrees with hwoarang on that, you can't force people to reply to you...
-<11.06.2013 20:05> <@grobian> mgorny: I'm affraid I've ignored some bugs for a long time too, they just disappear in the pile… unfortunately
-<11.06.2013 20:05>  * WilliamH is guilty of the same too
-<11.06.2013 20:05> < TomWij> The goal being dealing with the oldest bugs until the oldest bugs are less than "some acceptable amount of time" old.
-<11.06.2013 20:06> < scarabeus> i have rule to at least reply to the bug when its filled
-<11.06.2013 20:06> < scarabeus> so it should have first reply within a month
-<11.06.2013 20:06> < scarabeus> and then god knows but at least i explain there what is needed if it has not patch
-<11.06.2013 20:06> < mgorny> grobian: me too. but when i get a 'ping' on the bug, i try at least to tell that i can't do anything right now
-<11.06.2013 20:07> < mgorny> ulm: do you mean consensus on multilib or on bugs without reply? because this got a quite sidetracked
-<11.06.2013 20:07> <@ulm> mgorny: multilib
-<11.06.2013 20:07> <@grobian> mgorny: all I try to say, I get those too, and I'm not always in the position to open bugzie and reply (work/firewalls and all that crap)
-<11.06.2013 20:08> <@grobian> even though I want
-<11.06.2013 20:08> <@grobian> when I come home, I forgot
-<11.06.2013 20:08> < mgorny> ulm: i'm not sure if the ml is the place to decide what to do with base-system packages but it's some way
-<11.06.2013 20:08> <@grobian> not that that is an excuse or something
-<11.06.2013 20:08> < mgorny> i didn't really want to set deadlines like 'one month or we are committing it'
-<11.06.2013 20:09> < TomWij> mgorny: But what if that's a bug of 2005, it wouldn't be acceptable to just ditch that away with "no time now" or "later" or "..."; that would've been a bug that has been around for 8 years or so, you can't call that "no time".
-<11.06.2013 20:09> < mgorny> grobian: would be probably useful if bugzie had some kind of default 'unreplied bugs' search
-<11.06.2013 20:09> < TomWij> Relevant bug #88596
-<11.06.2013 20:09> < willikins> TomWij: https://bugs.gentoo.org/88596 "sys-devel/libtool stores gcc-path internally.  sometimes a bad thing due to gcc update"; Gentoo Linux, Core system; IN_P; spider:base-system
-<11.06.2013 20:09> < mgorny> TomWij: ^ that's probably first task for you
-<11.06.2013 20:10> < TomWij> mgorny: Yeah, I'm planning to categorize old bugs; and links to useful searches like that are probably nice too, thanks for the idea.
-<11.06.2013 20:10> < TomWij> One tracker I for instance started is bug #472746
-<11.06.2013 20:10> < willikins> TomWij: https://bugs.gentoo.org/472746 "[TRACKER] Old interesting conceptual, abstract and unimplemented ideas and feature requests."; Gentoo Linux, Unspecified; CONF; tomwij:tomwij
-<11.06.2013 20:11> <@Betelgeuse> I am heading out to bed for the day.
-<11.06.2013 20:11> <@grobian> same here
-<11.06.2013 20:11> <@Betelgeuse> I am calling the meeting officially over. Thanks to everyone!
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130730-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20130730-summary.txt
deleted file mode 100644
index 05db9dc7c3..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130730-summary.txt
+++ /dev/null
@@ -1,99 +0,0 @@
-Summary of Gentoo council meeting 30 July 2013
-
-
-Agenda
-======
-1) Vote for meeting schedule
-2) Vote for continuing last council's workflow
-3) Appoint chairman for this term's meetings
-4) Vote on meeting format 1: "the open floor is the mailing list discussion", 
-   i.e. no open floor during the meeting anymore
-5) Vote on meeting format 2: "shift council votes to mail instead of IRC"
-6) Open floor to council members to introduce themselves
-7) General discussion on the introduction of a "Bikeshed of the month" 
-8) Open bugs with council involvement (currently only #477030)
-9) Open floor
-
-
-Roll call
-=========
-Present:
-blueness, dberkholz, dilfridge, rich0, scarabeus, ulm, williamh
-
-
-1) Vote for meeting schedule
-============================
-Council meetings will be 2nd tuesdays of the month at 19:00 UTC.
-(carried unanimous)
-
-
-2) Vote for continuing last council's workflow
-==============================================
-We will send out a call for agenda items (2 weeks in advance), send the agenda 
-(1 week in advance) and aim to have the meeting focussed, e.g., have major 
-discussions on the -project mailing list prior to the meeting.
-(carried unanimous)
-
-
-3) Appoint chairman for this term's meetings
-============================================
-By general consensus a provisionary list was made: 
-  July - dilfridge
-  August - ulm
-  September - ulm
-  October - dilfridge
-  November - dilfridge
-  December - dberkholz
-  January - dberkholz
-  February - dberkholz
-  March - blueness
-  April - blueness
-Later dates will be decided next year.
-
-
-4) Vote on meeting format 1: "the open floor is the mailing list discussion" 
-============================================================================
-Vote: "Should we discontinue open floor at the end of the meeting?"
-2 yes, 5 no - not carried
-
-
-5) Vote on meeting format 2: "shift council votes to mail instead of IRC"
-=========================================================================
-Vote: "Shift council votes to mail instead of IRC"
-5 no - not carried
-
-Vote: "Allow voting via leaving comments YES/NO/ABSTAIN on a bug for urgent
-issues, with prior notice (at least 3 days earlier) to -project whenever 
-practical"
-4 yes, 1 no, 1 abstention - motion carried
-
-
-6) Open floor to council members to introduce themselves
-========================================================
-See the full log for the detailed statements.
-
-
-7) General discussion on the introduction of a "Bikeshed of the month" 
-======================================================================
-The idea is to pick topics where a decision clearly makes sense, but people 
-could not agree during bikeshedding, put them on the agenda and try to settle 
-things. General agreement was that this does not need to be formalized but can 
-be handled via established Council procedures. 
-
-
-8) Open bugs with council involvement (currently only #477030)
-==============================================================
-We agree to kick Betelgeuse to complete the missing meeting summary 
-whenever we see him. 
-
-
-9) Open Floor
-=============
-williamh asks how having bugzilla involved in Council matters (see point 5) 
-changes how to bring an issue to Council's attention. After some discussion, 
-the following is brought up for vote:
-
-Vote: "For adding an item to the agenda of the next council meeting, please 1)
-assign a bug to council and 2) link to it in a post on -project; the discussion
-should take place on -project"
-A decision was postponed, also for discussion on the mailing lists.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130730.txt b/xml/htdocs/proj/en/council/meeting-logs/20130730.txt
deleted file mode 100644
index 7db9a156de..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130730.txt
+++ /dev/null
@@ -1,502 +0,0 @@
-[21:05:50] <dilfridge> ok
-[21:06:00] <dilfridge> let us officially 
-[21:06:07] <dilfridge> declare this meeting opened
-[21:06:09] <dberkholz> fwiw i wrote up some notes a while back on making these meetings work less poorly -- http://dberkholz.com/2008/05/13/how-to-run-an-effective-meeting-on-irc/
-[21:06:43] <dilfridge> should we do another roll call?
-[21:06:45] <rich0> dberkholz: does that include having everybody stop and read a blog midway?  :)  Seriously though - thanks for the link.
-[21:07:01] <blueness|chromeb> here
-[21:07:03] <dilfridge> here
-[21:07:06] <ulm> here
-[21:07:10] <dberkholz> sure.
-[21:07:12] <WilliamH> here
-[21:07:18] <scarabeus> here
-[21:07:22] <dilfridge> excellent
-[21:07:33] <rich0> here
-[21:07:34] <dilfridge> agenda point 1
-[21:07:44] <dilfridge> - vote for holding meetings every 2nd Tuesday of the month at 2000 UTC (or 
-[21:07:44] <dilfridge> 1900 UTC depending on daylight savings)
-[21:07:57] -*- ulm votes yes
-[21:07:58] <dilfridge> a) general objections?
-[21:08:01] <rich0> aye
-[21:08:02] -*- WilliamH votes yes
-[21:08:02] <dilfridge> b) utc?
-[21:08:06] <dilfridge> aye
-[21:08:09] <scarabeus> ack from me
-[21:08:14] -*- blueness|chromeb votes yes
-[21:08:16] <rich0> Err, let's clarify the utc/dst bit
-[21:08:19] <dberkholz> so 1900 now, and 2000 during US daylight savings? (since we have more US members)
-[21:08:27] <rich0> Is this UTC/BST?
-[21:08:33] <rich0> Or US DST?
-[21:08:55] <WilliamH> Can we just pick a utc time and stick to it all year?
-[21:09:04] <dilfridge> ok we have 5 general yes about the overall plan
-[21:09:06] <blueness|chromeb> WilliamH, that works for me
-[21:09:09] <rich0> FYI - it is 1900 now and we are currently in DST.
-[21:09:13] <dberkholz> i don't really care one way or the other, just pick something
-[21:09:15] <scarabeus> works for me too for utc whole year
-[21:09:15] <dilfridge> now about the dst question
-[21:09:18] <rich0> Ditto.
-[21:09:20] <dberkholz> anything works for me
-[21:09:23] <dilfridge> I'm for same utc always
-[21:09:26] <ulm> works for me either way
-[21:09:44] <rich0> How about 1900 UTC always then.
-[21:09:51] <blueness|chromeb> yes
-[21:09:52] <dilfridge> ok let's have a quick vote, 1b) 19:00 UTC always?
-[21:09:52] <ulm> fine
-[21:10:04] -*- dilfridge yes
-[21:10:08] -*- ulm yes
-[21:10:10] -*- WilliamH yes
-[21:10:14] -*- blueness|chromeb votes yes 
-[21:10:15] <dberkholz> cool. 1900 utc year-round on 2nd tuesdays
-[21:10:22] <dberkholz> i will update the google calendar
-[21:10:36] <dilfridge> ok that was point 1!
-[21:11:00] <dilfridge> 2: "vote for continuing last council's workflow considering sending call for 
-[21:11:00] <dilfridge> agenda items (2 weeks in advance), sending the agenda (1 week in advance) and 
-[21:11:00] <dilfridge> have the meeting focussed, e.g., have major discussions on -project ML prior 
-[21:11:00] <dilfridge> to the meeting"
-[21:11:00] <ulm> council.g.o has to be updated too, it says 2000 UTC
-[21:11:12] -*- ulm will update the council page
-[21:11:16] <dilfridge> thanks!
-[21:11:44] <dilfridge> I guess 2 will also be unproblematic
-[21:11:45] -*- scarabeus looks forward to see that wikified :P
-[21:11:54] <scarabeus> yay for agenda sending from me :-)
-[21:12:15] -*- WilliamH yes
-[21:12:18] <dilfridge> does point 2 need discussion?
-[21:12:18] <rich0> works for me
-[21:12:20] -*- dilfridge yes
-[21:12:24] -*- ulm yes
-[21:12:25] -*- blueness|chromeb yes
-[21:12:45] <rich0> dilfridge: I'm fine with aiming for discussions on-list as much as possible.  Not so much a rule as a principle.
-[21:13:01] <dberkholz> yep
-[21:13:01] <dilfridge> yeah
-[21:13:05] <blueness|chromeb> agreed
-[21:13:06] <rich0> Oh, and ideally not the day before the meeting.
-[21:13:10] <blueness|chromeb> heh yeah
-[21:13:16] <dilfridge> having the discussion on ml first makes sense, also since we may want to prepare
-[21:13:22] <rich0> The whole point is to give topic submitters time to refine before the meeting and cut down on churn.
-[21:13:36] <dberkholz> s/may want/need/
-[21:13:40] <rich0> Instead of showing up and getting shot down.
-[21:13:41] <blueness|chromeb> who can read the list? only concil members or is it public?
-[21:13:46] <blueness|chromeb> and who can post?
-[21:13:55] <rich0> Gentoo-project - open list.
-[21:13:58] <blueness|chromeb> k
-[21:14:00] <WilliamH> -project is public
-[21:14:00] <dberkholz> we're talking about the gentoo-project list in most cases
-[21:14:05] <blueness|chromeb> oh on -project
-[21:14:12] <dberkholz> or gentoo-dev if it's ebuildy
-[21:14:12] <blueness|chromeb> thanks for the clarification
-[21:14:22] <rich0> Or -dev if it makes more sense.  We can always cross-ref the thread in the agenda where appropriate.
-[21:14:57] <dilfridge> the only closed list that we have is -core, and council topic discussions there do NOT make sense.
-[21:15:17] <blueness|chromeb> k
-[21:15:21] <dilfridge> ok anything else about 2?
-[21:15:47] <dilfridge> seems not, I guess this is carried then
-[21:16:05] <dilfridge> 3: "appoint chairman for this term's meetings"
-[21:16:14] <dilfridge> how was this handled in the past?
-[21:16:25] <scarabeus> somebody usually volunteered
-[21:16:28] <scarabeus> or it was rotation
-[21:16:32] <WilliamH> people usually just volunteer to do it.
-[21:16:36] <scarabeus> whatever rocks your chair :-)
-[21:16:39] <ulm> I can do september and october
-[21:16:53] <dberkholz> we've tried to have people do 2-3 in a row to make it a little less awkward
-[21:16:57] <dilfridge> ok... do we need to decide on a full list now? /me does not think so
-[21:17:09] <WilliamH> Not necessarily
-[21:17:13] <ulm> dilfridge: we should decide until end of the year
-[21:17:16] <blueness|chromeb> i'm busy-ish till dec
-[21:17:22] <dberkholz> and last year we just settled on the whole year since that's really just like 6 slots of 2 meetings a piece
-[21:17:30] <dilfridge> ok i can do november and december
-[21:17:41] <dberkholz> anyone taking notes for the summary?
-[21:17:42] <scarabeus> ulm: i would more say we caould appoint one at end of each meeting
-[21:17:46] <scarabeus> *could
-[21:18:22] <dilfridge> dberkholz: I'm logging this anyway... taking notes and typing at the same time is not so easy
-[21:18:23] <rich0> Suggest we appoint for next meeting now and take the rest offline.
-[21:18:31] <scarabeus> also when is next meeting; 13.8.?
-[21:18:44] <rich0> If somebody just wants to toss out a schedule feel free.
-[21:18:45] <dilfridge> yes
-[21:18:51] <rich0> I can volunteer for that if it helps.
-[21:19:25] <blueness|chromeb> rich0, okay
-[21:19:26] <dilfridge> 13.8., 10.9., 8.10., 12.11., 10.12.
-[21:19:44] <dberkholz> whoa, you europeans and your logical dates are confusing me
-[21:19:49] <dilfridge> :)
-[21:20:16] <rich0> That's why I get fired if I don't write them as 13-Aug-2013 at my company.
-[21:20:35] <dilfridge> 2013/08/13 
-[21:20:35] <rich0> Or 01-Aug-2013 - ##-###-####
-[21:20:37] <dberkholz> 20130813
-[21:20:52] <scarabeus> only correct and mandatory is 2013-08-13 :P
-[21:20:54] <rich0> Gotta love lawyers.
-[21:21:00] <scarabeus> but dd.mm.yyyy is our syntax
-[21:21:13] <dilfridge> unset LC_ALL
-[21:21:17] <ulm> in 2014 it's 14-Jan, 11-Feb, 11-Mar, 8-Apr, 13-May, 10-Jun
-[21:21:31] <dilfridge> ok
-[21:21:32] <dilfridge> anyway
-[21:21:35] <dilfridge> we are disgressing
-[21:21:43] <blueness|chromeb> ulm, if we rotate i'll take some of the 2014 days
-[21:21:56] <blueness|chromeb> but next semester is a bit heavy
-[21:22:03] <blueness|chromeb> then i'm on sabattical and very free
-[21:22:07] <dilfridge> I just noticed I probably can't do december, but oct and nov is no problem
-[21:22:11] <dilfridge> so how about 
-[21:22:28] <dilfridge> ulm starts aug sep, I do oct now and the rest will be decided on the way?
-[21:22:32] <ulm> dilfridge: I could take aug and sep as well
-[21:22:35] <ulm> :)
-[21:22:43] <dilfridge> s/now/nov/
-[21:23:01] <blueness|chromeb> works for me
-[21:23:21] <WilliamH> works for me also we don't have to decide all of them now
-[21:23:33] <dberkholz> i can do jan-feb.
-[21:23:57] <blueness|chromeb> i can do mar-apr
-[21:24:04] <dilfridge> ok
-[21:24:07] <dilfridge> fine 
-[21:24:09] <dberkholz> i can also do dec if needed
-[21:24:28] <dilfridge> so we have the next ones and provisorical list for later
-[21:24:43] <dilfridge> that should conclude point 3
-[21:25:02] <dilfridge> now come the first tricky parts
-[21:25:12] <dberkholz> fwiw i would prefer to schedule earlier rather than later, my calendar fills up. so let's do "later" on the council alias post-meeting vs some unspecified time
-[21:25:13] <ulm> dilfridge: it would pay to number items in the agenda already ;)
-[21:25:22] <dilfridge> 4: "vote on meeting format 1: "the open floor is the mailing list discussion", 
-[21:25:22] <dilfridge> i.e. no open floor during the meeting anymore"
-[21:25:25] <dilfridge> ulm: indeed
-[21:25:34] <dilfridge> opinions?
-[21:25:54] <rich0> How long has open floor tended to take in the past?
-[21:25:58] <WilliamH> I tend to agree with Roy on that.
-[21:26:03] <scarabeus> almost 0
-[21:26:05] <blueness|chromeb> dilfridge, with the hardened meetings we do openfloor only at the very end
-[21:26:07] <ulm> dilfridge: I won't dismiss neddyseagoon's argument lightly
-[21:26:09] <scarabeus> molsty people are silent
-[21:26:12] <blueness|chromeb> people are not allowed to interrupt
-[21:26:16] <rich0> I appreciate the value of openness, but honestly I don't think there is much opportunity to actually resolve issues in open floor.
-[21:26:20] <ulm> and open floor tends to be short anyway
-[21:26:21] <dberkholz> when it takes any time, it will just suck up whatever time is leftover
-[21:26:42] <dberkholz> it's kind of a binary thing, because there's usually not much but when there is something, it goes nowhere for 45 minutes
-[21:26:42] <rich0> If it isn't currently a real problem I suggest we leave it alone.
-[21:27:03] <rich0> I'm fine with reining in open floor.  Open floor doesn't mean open rant...
-[21:27:11] <dilfridge> I'm undecided... I dont think we can really decide something because of lack of information, but it never hurts to listen to people
-[21:27:15] <rich0> Open it up, and then recognize when we aren't getting anywhere.
-[21:27:16] <ulm> rich0: it wasn't a problem during last term
-[21:27:45] <rich0> ulm: I was just talking about the 45min example.
-[21:28:02] <dberkholz> last meeting it sucked up 15 minutes, the meeting before it was 20 min
-[21:28:12] <dberkholz> just looking at the logs
-[21:28:16] <dilfridge> yeah but then the chair should probably just call it off at some point
-[21:28:16] -*- WilliamH thinks we should keep the open floor at the endof the meeting like last term
-[21:28:42] <scarabeus> it is up for chair to drive, after all it can be cut off and moved to ml when needed
-[21:28:45] <WilliamH> dilfridge: Yes, that could happen too
-[21:28:47] <dberkholz> the open floor is just an opportunity to spit out unstructured thoughts in a form that's not conducive to thoughtful discussion about them
-[21:28:49] <blueness|chromeb> dberkholz, can't the chairman call an end to ranting and refer it back to the lists
-[21:28:49] <rich0> dilfridge: ++ we don't HAVE to use the full 60 mins just because we end early.
-[21:29:04] <dilfridge> yeah
-[21:29:06] <dilfridge> so
-[21:29:18] <dilfridge> shall we vote? /me will formulate what on
-[21:29:18] <ulm> dilfridge: vote?
-[21:29:28] <dberkholz> so, chairs, don't be afraid to shake your big stick. because it typically takes a while to realize that.
-[21:29:45] <dilfridge> 4: "Should we discontinue open floor at the end of the meeting?"
-[21:29:49] <blueness|chromeb> dilfridge, formalate what we are voting on
-[21:29:55] -*- dilfridge no
-[21:29:57] <blueness|chromeb> s/formalate/formulate/
-[21:30:01] -*- WilliamH votes no
-[21:30:02] -*- ulm no
-[21:30:06] <dberkholz> yes
-[21:30:07] <rich0> no
-[21:30:15] -*- scarabeus nope, chair to handle this
-[21:30:18] -*- blueness|chromeb voites yes
-[21:30:35] <dilfridge> that's 5 no, 2 yes
-[21:30:42] <dilfridge> means things stay as they are
-[21:30:55] <rich0> we can revisit if we regret it.  :)
-[21:31:00] <dilfridge> indeed
-[21:31:02] <dilfridge> next point
-[21:31:14] <dilfridge> 5: vote on meeting format 2: "shift council votes to mail instead of IRC"
-[21:31:28] <dilfridge> I'm not sure I summarized that correctly for the agenda
-[21:31:40] -*- WilliamH is against that
-[21:31:44] <ulm> I'm against it, because actual voting is usually the quickest part of a decision
-[21:31:46] <dberkholz> i should note that i suggested mail or bugzilla. some format where we can respond more quickly than a meeting that's 4-5 weeks out
-[21:31:48] <blueness|chromeb> yeah i don't like this
-[21:31:51] <blueness|chromeb> i like the discussion
-[21:31:56] <ulm> and it's nice having the votes in the log
-[21:32:02] <dilfridge> indeed
-[21:32:06] <scarabeus> voting is okay on irc, we need to chat on mails, not on the meetings
-[21:32:09] <rich0> I'I suggest allowing votes in bugzilla in addition to in meetings, not in place of.
-[21:32:33] <rich0> And not as the default.
-[21:32:51] <dilfridge> ok let's first vote on the version as in the agenda, and then afterwards discuss possible alternatives
-[21:32:57] <dilfridge> 5:  "shift council votes to mail instead of IRC"
-[21:32:59] -*- dilfridge no
-[21:33:00] <blueness|chromeb> rich0, the agenda would have to make it clear where the vote will take place if we us both irc and bugz
-[21:33:03] <rich0> no
-[21:33:05] -*- ulm no
-[21:33:07] -*- scarabeus no
-[21:33:10] -*- blueness|chromeb no
-[21:33:14] -*- WilliamH thinks that what this was about then is finding a way for the council to vote on high priority issues between meetings
-[21:33:36] <rich0> blueness|chromeb: in general when voting in bugzilla it wouldn't be on an agenda at all.  It would be for items that come up that would benefit from resolution prior to the next meeting.
-[21:33:52] <dilfridge> that's already 5 no
-[21:33:57] <blueness|chromeb> rich0, yeah that works, for more urgent issues
-[21:34:00] <rich0> If we're going to always stick it on an agenda might as well just vote in a meeting.
-[21:34:18] <dilfridge> now, about "additions" to irc
-[21:34:33] <rich0> Proposal:  "Allow voting via bugzilla for urgent issues, with prior notice to -project whenever practical."
-[21:34:36] <ulm> rich0: in practice, asking for votes per e-mail never worked well
-[21:34:39] <blueness|chromeb> i like the idea of urgent issues being delt with in bugz
-[21:34:58] <ulm> but maybe bugzilla works better
-[21:34:58] <dberkholz> i like the idea of considering every issue urgent unless we need to defer it to a meeting for some reason
-[21:35:31] <rich0> dberkholz: That is how the trustees generally operated - many issues did get decided in meetings, but if an issue was resolved prior we'd just deal with it.
-[21:35:31] <dberkholz> the default should be getting things done faster
-[21:35:33] <dilfridge> yeah... rich0, how about something like "prior notice at least 3 days earlier"
-[21:35:58] <rich0> dilfridge: fine with the 3 days, but again I'd include "whenever practical" - there could always be emergencies.
-[21:36:01] <WilliamH> dberkholz:  does that mean we just allow bugs to be assigned to council and deal with them there?
-[21:36:31] <rich0> WilliamH: I think that is fine.  Oh, we can always summarize the results in the next meeting summary.
-[21:36:42] <WilliamH> dberkholz: then if we defer things to a meeting those end up on an agenda?
-[21:36:51] <dilfridge> WilliamH: I fear a bit that's the road to micromanagement... but for important stuff, fine
-[21:37:16] <WilliamH> Ok...
-[21:37:16] <dberkholz> i'm not sure i see how communicating in a different forum is micromanagement?
-[21:37:38] <dilfridge> dberkholz: more like "ah well let's cc council quickly"
-[21:37:54] <dilfridge> but then we can always defer to meeting if it's not important / not urgent
-[21:38:09] <dilfridge> ok
-[21:38:13] <dberkholz> oh, yeah i had more in mind that people might specifically file bugs for council agenda items. we could attempt to vote on the bugs, or discuss them at the meeting
-[21:38:46] <dilfridge> 5A: "Allow voting via bugzilla for urgent issues, with prior notice (at least 3 days earlier) to -project whenever practical.
-[21:38:52] <dilfridge> votes for 5A?
-[21:38:58] -*- blueness|chromeb yes
-[21:39:00] -*- ulm no
-[21:39:13] -*- dilfridge abstains
-[21:39:15] <dberkholz> yes
-[21:39:46] <dberkholz> the prior notice is probably a good idea for transparency, so everyone doesn't need to track council bugs
-[21:39:48] <rich0> yes
-[21:39:48] -*- scarabeus yes
-[21:40:29] -*- WilliamH is unsure about this as a separate item
-[21:40:48] <dilfridge> what do you mean?
-[21:40:49] <dberkholz> we've got 4 yes's, vote for posterity if you choose, otherwise let's move on =)
-[21:40:58] <WilliamH> This has sort of ended up confusing...
-[21:41:09] <ulm> voting on bugzilla is lousy
-[21:41:13] <ulm> can you actually vote "no" with its voting system?
-[21:41:25] <ulm> or abstain?
-[21:41:27] <blueness|chromeb> ulm, why not?
-[21:41:29] <rich0> I wasn't suggesting that we actually use the voting feature in bugzilla.
-[21:41:30] <dberkholz> we've always just commented in the past
-[21:41:34] <rich0> You can just do it via comments/etc.
-[21:41:34] <dberkholz> not used actual "votes"
-[21:41:38] <dilfridge> I guess we mean more "leave a comment on a bug saying yes/no/abstain"
-[21:41:46] <dilfridge> not using bugzilla's voting system
-[21:41:56] <dberkholz> if you suggest building a voting engine, i'm going to come to your house and take away your keyboard
-[21:41:56] <blueness|chromeb> dilfridge, that was my understadning, use comments
-[21:42:07] <blueness|chromeb> dberkholz, heh
-[21:42:08] <WilliamH> Ok, use comments to vote...
-[21:42:11] <dilfridge> ok let's clarify this
-[21:42:30] <dberkholz> rich0: can you point to an example of a bug the trustees voted on, so it's perfectly clear
-[21:42:58] <dilfridge> 5B: "Allow voting via leaving comments YES/NO/ABSTAIN on a bug for urgent issues, with prior notice (at least 3 days earlier) to -project whenever practical"
-[21:43:08] <dilfridge> better?
-[21:43:14] -*- blueness|chromeb votes yes
-[21:43:23] -*- dilfridge abstains still
-[21:43:28] -*- ulm no
-[21:43:39] <dberkholz> yes again
-[21:44:01] <dilfridge> scarabeus: WilliamH: ?
-[21:44:03] <rich0> yes
-[21:44:31] <rich0> bug 474774 is an example
-[21:44:33] <willikins> rich0: https://bugs.gentoo.org/474774 "Proposal to purchase parts for Alpha development system"; Gentoo Linux, Unspecified; RESO, FIXE; mattst88:trustees
-[21:45:12] <dilfridge> we have 3 yes, 1 no, 1 abstention so far
-[21:45:54] -*- WilliamH is looking at the bug
-[21:46:06] <dilfridge> ok
-[21:46:11] <dilfridge> any more votes?
-[21:47:07] <ulm> bugzilla is not the right medium, neither for discussion nor for voting
-[21:47:12] <dilfridge> seems not
-[21:47:26] <rich0> True, much discussion ends up in email/lists.
-[21:47:30] <dilfridge> so it's carried with 3 yes, 1 no, 1 abstention
-[21:47:37] <rich0> It is a good medium for openly recording votes.
-[21:47:51] <ulm> rich0: wiki works much better
-[21:48:03] <blueness|chromeb> if we try this at some point and ulm is right, we can revisit the issue and stop the practice
-[21:48:09] <dilfridge> 6: "open floor to council members to introduce themselves to the others, and/or raise issues they would like to deal with"
-[21:48:27] <dilfridge> should we go around so everyone has a chance to say something?
-[21:48:33] <blueness|chromeb> sure
-[21:48:34] -*- scarabeus checked the bug (it looks for yes from me)
-[21:48:46] <dilfridge> blueness|chromeb: how about you start?
-[21:48:51] <blueness|chromeb> okay
-[21:49:16] <blueness|chromeb> about me: i'm mostly working in hardened, alternatie libcs like uclibc and musl, and minor arches
-[21:49:43] <blueness|chromeb> my main current project is migrating pax flags out of elf binaries to xattr so our elfs are more in line with other distros
-[21:50:05] <blueness|chromeb> and one issue i'd like the council to look at is documenting pms's vdb directory
-[21:50:27] <blueness|chromeb> getting things like NEEDED.ELF.2 into pms specs ... more details on that later
-[21:50:37] <blueness|chromeb> okay ... very quick intro
-[21:51:19] <dilfridge> next one, dberkholz :)
-[21:51:19] <blueness|chromeb> next?
-[21:51:46] <dberkholz> hi, i've done lots of stuff. i described most of it in my "manifesto" thing
-[21:52:39] <dberkholz> my main project right now is doing some research into quantifying our community
-[21:52:47] <dberkholz> so we can figure out potential problems more easily
-[21:53:00] <dberkholz> and opportunities, like people who should become devs
-[21:53:22] <dberkholz> also doing the gsoc thing, which is at midterms this week.
-[21:53:24] <dberkholz> that's about it
-[21:53:52] <dilfridge> ok next one in the alphabet is myself
-[21:54:40] <dilfridge> I "grew up" in Gentoo in the KDE team, and am still to a large part active there, in the meantime 
-[21:55:10] <dilfridge> a few other things have been added, I'm taking care of cups and part of printing and generate libreoffice-bin
-[21:55:11] --> NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) hat #gentoo-council betreten
-[21:55:28] <dilfridge> what I'm interested in...
-[21:55:55] <dilfridge> well, one thing I am unhappy about is when discussions about some topic on the mailing lists just branch out and branch out
-[21:56:14] <dilfridge> and noone can make a decision because no real consensus is reached. 
-[21:57:01] <dilfridge> this is one of the reasons why I wanted to join the council, so maybe we can make some well-informed decisions when decisions are needed
-[21:57:12] <dilfridge> that's it
-[21:57:31] <dilfridge> next one -rich0
-[21:57:39] <rich0> I won't take up everybody's time.  I'm happy to be a part of the team, and I've already written most of how I feel in my manifesto.  I'd like to see more indirect influence by the council beyond voting on the lists and out in the community - we have a power to encourage/influence/etc that we should better use.  However, we shouldn't be afraid to settle disputes - sometimes any resolution is better than none.  That said, I'm always willing to
-[21:57:40] <rich0> discuss anything.  As far as who I am goes - I work in IT at a Pharma company with a Biochemistry background.  I'm a tinkerer, and Gentoo is a tinkerer's distro.  As far as things around Gentoo that interest me - I have an interest in the git migration and anything that can be done to help move it along.  next?
-[21:58:13] <dilfridge> ok scarabeus
-[21:58:57] <scarabeus> ok most of you know what i did and what i break on daily basis, apart from that i am now in opensuse team ;-) and I really wish we in gentoo could generate better binary distro to attract more people
-[21:59:27] <scarabeus> apart fromt hat the regular stuff, better communication, more fun, booze, etc, whatever rocks your boat to contribute we as council should provide :-)
-[21:59:30] <scarabeus> thats it
-[21:59:35] <dilfridge> ulm?
-[21:59:43] <ulm> ok, very short intro
-[22:00:08] <ulm> I've started in Gentoo working on GNU Emacs packages and I'm still maintaining them
-[22:00:21] <ulm> and for some reason I've inherited eselect ;)
-[22:00:47] <ulm> one of my priorities for this term is to finalise EAPI 6
-[22:01:04] <ulm> that's about it - next?
-[22:01:10] <dilfridge> WilliamH?
-[22:01:26] <WilliamH> Hi all, I have been a gentoo dev for quite a while.
-[22:01:43] <WilliamH> I started in accessibility, and I'm still the lead there.
-[22:02:04] <WilliamH> I'm also a member of base-system, upstream for OpenRc, and involved in several other things.
-[22:03:07] <WilliamH> I also maintain some things for Releng, particularly livecd-tools
-[22:03:39] <WilliamH> I am interested in making sure that our distro is accessible to users withdisabilities, and also some base-system and distro wide issues.
-[22:04:30] <WilliamH> One thing I want to do this term (I'll be putting this on the next agenda if no one else brings it up) is to settle the separate /usr support issue that has been a hot button for a while.
-[22:05:00] <WilliamH> That's all I can think of right now. :-)
-[22:05:26] <dilfridge> ok excellent
-[22:05:48] <dilfridge> means we can conclude point 6
-[22:06:05] <dilfridge> 7: "general discussion on the introduction of a "Bikeshed of the month" "
-[22:06:10] <dilfridge> that's my baby
-[22:06:21] <dilfridge> more or less for the protocol, 
-[22:06:30] <dilfridge> let me quickly explain what this is about
-[22:07:01] <dilfridge> the idea is to pick topics where a decision clearly makes sense, but people could not agree during bikeshedding
-[22:07:22] <dilfridge> put them on the agenda and try to settle things
-[22:07:31] <dberkholz> i don't really think we need to formalize that
-[22:07:37] <dilfridge> fine with me
-[22:07:46] <dberkholz> but i do agree with the idea, of council members proposing topics from the ML instead of waiting for someone else to do so
-[22:08:24] <rich0> I'm fine with the concept, agree it doesn't need to be formalized.  However, before we step into something we should at least confirm that SOMEBODY wants us to do so.
-[22:08:26] <dilfridge> some of the stuff is so trivial, and a lack of a decision is sometimes just blocking things
-[22:08:27] <blueness|chromeb> yeah we can take more of a leadership roll in resolving contraversial issues
-[22:08:35] <dilfridge> yes
-[22:08:39] <rich0> If all the parties are already fine with where things stand or are working things out, we don't need to interfere.
-[22:08:58] <dilfridge> rich0: true
-[22:09:03] <rich0> We can be proactive though - just suggest we poll the community for whether we should get involved.
-[22:09:22] <rich0> So, put on agenda, and maybe just ask for opinions.  Utter silence might be a reason to not disturb the silence.
-[22:09:31] <blueness|chromeb> rich0, for some of the bikeshedding we already know where they stand
-[22:09:32] <dilfridge> rich0: but we should see that if we put somethign on the agenda and noone cares
-[22:10:03] <dilfridge> ok
-[22:10:23] <dilfridge> to be honest, I dont think we really need to discuss here much... anything else to say?
-[22:10:32] <blueness|chromeb> dilfridge, one closing comment
-[22:10:57] <blueness|chromeb> might i suggest that you pastebin the agenda just before the meeting and put the url in the topic for everyone to see
-[22:11:10] <dberkholz> or perhaps something more editable like an etherpad
-[22:11:13] <dilfridge> yes
-[22:11:15] <dberkholz> or even our wiki
-[22:11:23] <blueness|chromeb> yeah anything like that
-[22:11:32] <dberkholz> then we could do some crowdsourcing of summaries
-[22:11:41] <dilfridge> did not do anything this time because we already had the link but next time, true
-[22:11:47] <WilliamH> question...
-[22:11:50] <blueness|chromeb> people followign the meeting may not have the agenda in front of them ... like even me on my chromebook
-[22:12:04] <WilliamH> separate subject so I'll wait
-[22:12:12] <blueness|chromeb> i'm done
-[22:12:15] <ulm> blueness|chromeb: agenda is in the topic
-[22:12:16] <rich0> I like the idea of live summaries.
-[22:12:19] <rich0> Etherpad or whatever.
-[22:12:26] <dilfridge> ok anyone else?
-[22:12:30] <blueness|chromeb> ulm, oh yeah so it is!
-[22:12:38] -*- WilliamH has something
-[22:12:40] <rich0> I often do this at work - anybody can chime in on errors as they happen, and after meeting you just hit send.
-[22:13:06] <dilfridge> WilliamH: let's finish the agenda points and then do the new thing, ok?
-[22:13:10] <WilliamH> Sure.
-[22:13:23] <dilfridge> 8: "open bugs with council involvement (currently only #477030)"
-[22:13:27] <dilfridge> bug 477030
-[22:13:29] <willikins> dilfridge: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council
-[22:13:47] <dilfridge> who should we kick?
-[22:13:52] <blueness|chromeb> does anyone have that log?
-[22:14:15] <ulm> dilfridge: we should kick betelgeuse, unless we want to do the summary ourselves
-[22:14:25] <ulm> he had chaired that meeting
-[22:14:44] <dilfridge> ok since he's not around, anyone volunteering (for kicking him)?
-[22:15:06] <ulm> blueness|chromeb: log is linked from the council page already, only summary is missing
-[22:15:06] <blueness|chromeb> how about any or all of us when we see him ;)
-[22:15:14] <dilfridge> ok fine
-[22:15:22] <dilfridge> that concludes point 8
-[22:15:26] <dilfridge> WilliamH: your turn
-[22:15:26] <blueness|chromeb> heh
-[22:15:37] <WilliamH> Actually a couple of quick questions...
-[22:16:14] <WilliamH> Since we have added bugs as action items, does that change how we put things on the agenda -- should we respond to the call for agenda items on -project, and open bugs assigned to council?
-[22:16:32] <-- blueness|chromeb (~blueness@gentoo/developer/blueness) hat #gentoo-council verlassen
-[22:16:32] --> blueness|chromeb (~blueness@gentoo/developer/blueness) hat #gentoo-council betreten
-[22:17:15] <dberkholz> i would suggest we document on the council homepage that anyone may file any bugs at any time for council consideration
-[22:17:40] <blueness|chromeb> nice idea
-[22:17:41] <dilfridge> my opinion, let's keep things as they are as much as possible (except if something urgent and important happens)
-[22:17:52] <dberkholz> and also get people to file bugs for agenda items so they don't get lost
-[22:18:02] <dberkholz> (yeah, that happens regularly)
-[22:18:28] <dilfridge> bugs for agenda items are fine, but discussion should still be on mailing list
-[22:18:34] <WilliamH> dberkholz: Ok, so if we file bugs for agenda items should we link to them from -project but ask that discussion stay on the list?
-[22:18:46] <dberkholz> basically what's gonna happen is that you'll have people asking for agenda items all over the place.
-[22:18:58] <dberkholz> council alias, personal email, every list you can imagine, even irc
-[22:19:16] <dberkholz> unless you say this is how you do it
-[22:19:40] <dberkholz> yeah discussion should definitely be on the list.
-[22:19:54] <dberkholz> as ulm pointed out, bugs just aren't a great format for long threads
-[22:19:54] <rich0> dberkholz: ++  for trustees recently that became a problem so we've been trying to log bugs for everything.  Bugs are good for tracking.
-[22:20:04] <rich0> But discussion elsewhere.
-[22:20:34] <NeddySeagoon> dberkholz, you mean -project@ not council@  ?
-[22:20:56] <WilliamH> Ok, so we tell people to 1) assign a bug to council and 2) link to it in a post on -project and the discussion should take place on -project.
-[22:21:10] <dberkholz> when i say list, i'm referring to a mailing list. -project or -dev
-[22:21:17] <dberkholz> i will not say list if i mean alias =)
-[22:21:18] <dilfridge> WilliamH: yes and (NeddySeagoon Iguess that answers the question)
-[22:21:48] <WilliamH> NeddySeagoon: is that how the trustees do it?
-[22:22:04] <NeddySeagoon> dberkholz, I'm not really a techie  :)  I just wanted to ensure discussion was public, as far as possible
-[22:22:17] <dilfridge> ok I suggest we formalize that with a vote, let me write down a proposal
-[22:22:21] <dberkholz> yep that's my preference too. open by default
-[22:22:38] <WilliamH> NeddySeagoon: How are agenda items proposed and discussed by the trustees?
-[22:22:44] <NeddySeagoon> WilliamH Yes, its public as far as possible,
-[22:23:12] <rich0> WilliamH: The trustees just publish agendas on the IRC topic line and add to it whatever comes in via email, lists, bugs, ESP, whatever.
-[22:23:15] <rich0> A very informal process.
-[22:23:28] <rich0> Many end up getting logged as bugs if they aren't handled immediately.
-[22:23:33] <NeddySeagoon> WilliamH, we invite email to trustees@  and post the growing agenda in /topic in -trustees
-[22:23:38] <rich0> The documentation of resolution is more formal.
-[22:23:40] <dilfridge> 9: "For adding an agenda item for consideration by the council we request 1) assign a bug to council and 2) link to it in a post on -project or -dev; the discussion shoudl take place on -project or -dev"
-[22:23:55] <dilfridge> how about this?
-[22:24:10] <ulm> dilfridge: I really think that we should avoid voting on topics that are not on the agenda
-[22:24:22] <dilfridge> yes
-[22:24:25] <dilfridge> sure
-[22:24:26] <NeddySeagoon> ulm++
-[22:24:33] <dberkholz> when they are about how we run the council?
-[22:24:34] <dilfridge> that's not what I mean
-[22:24:43] <ulm> we can try e-mail or bugzie voting for that one ;)
-[22:24:56] <dberkholz> lol. good plan
-[22:25:00] <WilliamH> ulm: in other words you are against voting on topics out side of meetings?
-[22:25:10] <dilfridge> clarification: 
-[22:25:12] <rich0> ulm: in general I think your advice is good, but perhaps overkill on this particular issue.
-[22:25:35] <ulm> WilliamH: no, but I'm against ad-hoc voting on topics that haven't been announced at least a few days in advance
-[22:25:37] <rich0> I'd be more concerned if this were some kind of decision that was beyond administrative in nature
-[22:25:43] <dilfridge> 9A: "For adding an item to the agenda of the next council meeting, please 1) assign a bug to council and 2) link to it in a post on -project or -dev; the discussion shoudl take place on -project or -dev"
-[22:25:48] <dberkholz> heh.
-[22:25:55] <NeddySeagoon> ulm that avoids ill considered 'knee jerk' votes
-[22:26:02] <dberkholz> rich0: should i propose that we restructure glep 39 today? after all, it is open floor
-[22:26:04] <dilfridge> this 9A is what I actually meant
-[22:26:05] <ulm> NeddySeagoon: exactly
-[22:26:17] <blueness|chromeb> i need to go guys, i'm in favor of this direction though
-[22:26:24] <rich0> dberkholz: ok, trivial administrative details
-[22:26:32] <rich0> yikes, we're at 90 minutes already?
-[22:26:35] <dberkholz> rich0: just messin' with ya.
-[22:26:36] <dilfridge> yep
-[22:26:37] <WilliamH> I'm not sure about the two mailing lists. We have always had agenda-related discussions on -project only
-[22:26:45] <dilfridge> ok
-[22:26:50] <blueness|chromeb> dilfridge, may i please be excused?
-[22:26:52] <dilfridge> then let's keep it on project
-[22:26:56] <dilfridge> sure, blueness|chromeb
-[22:27:09] <blueness|chromeb> thank you, i vote yes to 9a and any minor variation
-[22:27:10] <dilfridge> next, hopefully last version
-[22:27:11] <blueness|chromeb> ta ta guys
-[22:27:25] <-- blueness|chromeb (~blueness@gentoo/developer/blueness) hat das Netzwerk verlassen (Remote host closed the connection)
-[22:27:34] <dilfridge> 9B  "For adding an item to the agenda of the next council meeting, please 1) assign a bug to council and 2) link to it in a post on -project; the discussion shoudl take place on -project"
-[22:27:44] <dberkholz> k
-[22:28:10] <dilfridge> votes on this?
-[22:28:22] -*- ulm abstains
-[22:28:26] <ulm> not on the agenda
-[22:28:47] -*- dilfridge abstains
-[22:29:03] <dberkholz> i guess i'm pretty close on that part. but i'd prefer to change the wording so it's not so tied to meetings, since we just agreed on bugs w/ 3 days notice
-[22:29:23] <dberkholz> "For adding an item to the council agenda for consideration, please..."
-[22:29:29] <dberkholz> rather "To add"
-[22:29:38] <dilfridge> ok
-[22:29:44] <ulm> dilfridge: can we send this to the mailing list please?
-[22:30:06] <dilfridge> in my opinion, yes, we can send this to the ml
-[22:30:07] <rich0> Why not hash this out offline, post the final proposal to -project, and vote on bugzilla?  :)
-[22:30:12] <dilfridge> :P
-[22:30:14] <WilliamH> ulm: ah ok, I  see what you are saying, let's propose this for next agenda.
-[22:30:15] <ulm> rich0: ++
-[22:30:29] <dilfridge> ok
-[22:30:37] <WilliamH> sounds reasonable to me.
-[22:30:41] <rich0> We could have it done for the next meeting (well, barely - time to send out the agenda on that now).
-[22:30:41] <dilfridge> this sounds like we won't decide on it now.
-[22:30:49] <dilfridge> that means, 
-[22:30:53] <dilfridge> last agenda item
-[22:31:02] <dilfridge> 10 "open floor to community"
-[22:31:08] <dilfridge> anyone?
-[22:31:57] <dilfridge> seems not
-[22:32:38] <scarabeus> nobody around :P
-[22:32:49] <rich0> Suggest we move on.
-[22:32:50] <dilfridge> then, let me announce that according to our schedule we need to send the call for agenda items for the next meeting out TODAY
-[22:33:01] <dilfridge> and with that said, 
-[22:33:04] <dilfridge> meeting closed
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130813-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20130813-summary.txt
deleted file mode 100644
index 441dbfff7d..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130813-summary.txt
+++ /dev/null
@@ -1,97 +0,0 @@
-Summary of Gentoo council meeting 13 August 2013
-
-Agenda
-======
-1. Introduction and roll call
-
-2. Support for separate /usr partition - williamh [1]
-
-3. Locale for build logs in bugzilla - dilfridge [2]
-
-4. Open bugs with council involvement
-   - Bug 477030 - Missing summary for 20130611 council meeting [3]
-   - Bug 480408 - Autobuilds go to /experimental and to /releases only
-     when actually tested [4]
-
-5. Open floor
-
-
-Roll call
-=========
-Present:
-blueness, dberkholz, dilfridge, rich0, scarabeus, ulm, williamh
-
-Support for separate /usr partition
-===================================
-williamh asked for clarification of the vote about separate /usr
-support taken in the April 2012 meeting [5]. Newer developments in
-some upstream packages make supporting a proper barrier between root
-and /usr filesystems increasingly difficult. A long discussion
-followed. Taking a decision about the question if we should do the
-/usr merge was generally regarded as too early. It was noted the
-latest FHS standard [6] still requires that a system must be able to
-boot off root without /usr, and that we should not remove support
-where it already exists. In setups with an initramfs, some of the boot
-and repair functionality can be moved from the root filesystem to the
-initramfs. It was also observed that we need official documentation on
-how to install a system with an initramfs, although some documentation
-is already in place [7,8].
-
-Two votes were taken:
-
-- "Since that particular setup may already be subtly broken today
-  depending on the installed software, Council recommends using an
-  early boot mount mechanism, e.g. initramfs, to mount /usr if /usr
-  is on a separate partition."
-  Accepted unanimously.
-
-- "The intention is to eventually not require maintainers to support
-  a separate /usr without an early boot mechanism once the Council
-  agrees that the necessary docs/migration path is in place."
-  Accepted with 4 yes votes, 1 no vote, 2 abstentions.
-
-Locale for build logs in bugzilla
-=================================
-dilfridge suggested that we should make build logs English by default,
-by setting an appropriate locale in our profiles. From the previous
-mailing list discussion the conclusion was that LC_MESSAGES=C would be
-an appropriate setting.
-
-Vote:
-
-- "Make a news item, then add LC_MESSAGES=C to the base profile
-  make.defaults."
-  Accepted unanimously.
-
-Open bugs with council involvement
-==================================
-- Bug 477030 "Missing summary for 20130611 council meeting"
-  No progress since last meeting.
-  Action: scarabeus will talk to betelgeuse (who was chairman of the
-  June meeting).
-
-- Bug 480408 "Autobuilds go to /experimental and to /releases only
-  when actually tested"
-  No action to be taken by the council. This should be sorted out
-  within the releng team.
-
-Open floor
-==========
-Q: Does the council favour git migration? (xmw)
-A: The council is in favour of the migration to git, and has expressed
-   its support already in a previous meeting [9].
-
-Next meeting date
-=================
-10 September 2013, 19:00 UTC
-
-
-[1] Message-ID: <20130801003614.GA29807@linux1> (not in archives)
-[2] http://article.gmane.org/gmane.linux.gentoo.project/2926
-[3] https://bugs.gentoo.org/show_bug.cgi?id=477030
-[4] https://bugs.gentoo.org/show_bug.cgi?id=480408
-[5] http://www.gentoo.org/proj/en/council/meeting-logs/20120403.txt
-[6] http://www.linuxbase.org/betaspecs/fhs/fhs.html
-[7] http://wiki.gentoo.org/wiki/Early_Userspace_Mounting
-[8] http://www.gentoo.org/doc/en/initramfs-guide.xml
-[9] http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130813.txt b/xml/htdocs/proj/en/council/meeting-logs/20130813.txt
deleted file mode 100644
index 2c1d9b9239..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130813.txt
+++ /dev/null
@@ -1,893 +0,0 @@
-<ulm> 19:00 UTC, so let's start
-<dilfridge> w00t
-<blueness> k
-<ulm> Agenda is here: http://article.gmane.org/gmane.linux.gentoo.project/2937
-<ulm> dilfridge?
-<dilfridge> yes?                                                        [21:01]
-<ulm> why w00t?
-<dilfridge> just like that
-<dilfridge> :)
-* blueness here
-<ulm> roll call
-* dilfridge here
-* WilliamH here
-<dberkholz> here                                                        [21:02]
-<rich0> here
-<ulm> scarabeus?
-<scarabeus> her
-<scarabeus> e
-<ulm> I've one additional bug for agenda topic 4                        [21:03]
-<ulm> bug 480408
-<willikins> ulm: https://bugs.gentoo.org/480408 "Autobuilds go to
-            /experimental and to /releases only when actually tested"; Gentoo
-            Linux, Unspecified; CONF; mattst88:council
-<dilfridge> k
-<ulm> everyone o.k. if we add it?
-<dilfridge> sure
-<rich0> sure
-<scarabeus> not a prob
-<blueness> okay, but i'm not sure why that came to the council
-* WilliamH thinks that should be a releng decision?                     [21:04]
-<ulm> blueness: let's discuss this later ;)
-<blueness> k
-<ulm> topic 2, support for separate /usr partition
-<ulm> WilliamH: your stage
-<WilliamH> Here's the thing folks. The council's vote in 2012 was ambiguous.
-                                                                        [21:05]
-<WilliamH> The summary said one thing,
-<WilliamH> but looking at the log, the intention was completely different.
-<WilliamH> and, imo, the intention,  mandating support for separate /usr
-           without a preboot mechanism, is a maintenance nightmare.
-<rich0> WilliamH: sorry to interrupt - but I don't think we need to figure out
-        the past intentions so much as define the policy moving forward
-                                                                        [21:06]
-<WilliamH> As you can see from the blog posts I cited from Flameeyes, what is
-           needed in early boot is very difficult to define these days.
-<WilliamH> Going forward, I would like for us to require some kind of preboot
-           mechanism, e.g. initramfs or the sep-usr use flag on busybox, if
-           folks have /usr and / on separate partitions.                [21:07]
-<blueness> (let us know when your done with the presentation and can ask
-           questions)                                                   [21:08]
-<WilliamH> That also eliminates the concern about crossing the / -> /usr
-           barrier, since /usr would always be mounted when / is.
-<WilliamH> Ok, let's open for discussion.
-<rich0> suggest that when we vote we perhaps do it progressively - policy for
-        new pkgs, existing ones, etc.                                   [21:09]
-<dberkholz> for anyone else who wants to quickly read up on busybox[sep-usr],
-            here's a link:
-            http://www.gossamer-threads.com/lists/gentoo/dev/252734
-<WilliamH> rich0: there's not really a way to separate this into new vs
-           existing...
-<dberkholz> basically it's an init wrapper that mounts /usr etc then hands off
-            to real init
-<rich0> My feeling is that long-term we want to stop supporting separate /usr
-        without an early-boot mechanism to mount it.  How we get there I think
-        is open for debate.
-<WilliamH> rich0: as soon as one package changes, everyone will be hit.
-<dilfridge> there is another aspect of this, as far as I understand it, with
-            the current systemd installation in Gentoo, having a separate /usr
-            without early boot mechanism is impossible                  [21:10]
-<WilliamH> rich0: most of tthe changes will be for base-system packages.
-<rich0> For packages that are recent like systemd or such, I think we can just
-        stick them in /usr and not worry about them.
-<ulm> I had tried to summarise a bit and also suggested some successive votes
-      here: http://article.gmane.org/gmane.linux.gentoo.project/2941
-<blueness> rich0, i read the FHS 3.4 standards yesterday, and while there is
-           no mention of early boot mechanism it is clear that a system must
-           be able to boot off of just / without /usr
-<rich0> For stuff that exists the question is when to de-support separate usr,
-        assuming we're Ok with that general direction.
-<WilliamH> rich0: that's a separate issue, sticking whole packages in /usr
-           isn't what I'm talking about.
-<rich0> blueness: I agree 100% that what I'm proposing is not FHS compliant.
-                                                                        [21:11]
-<blueness> there exist configuratons eg nfs mounts of /usr where mounting /
-           and /usr at the same time are not possible
-<rich0> Basically the question is whether we care.
-<dilfridge> blueness: that's true... unfortunately here reality seems to have
-            ignored FHS
-<WilliamH> blueness: no it isn't.
-<blueness> rich0, okay so what do we do about such systems?  i ran an entire
-           lab like that till recently
-<dberkholz> i don't think it should be our job to expend *significant* effort
-            reworking build systems and such to follow fhs. only if it's
-            relatively easy via configure flags, for example
-<WilliamH> blueness: remember that in the latest standards, anything in / can
-           be symlinks.
-<blueness> and chainsaw runs a farm of similar servers
-<ulm> blueness: same here
-<rich0> Re NFS - why can't an initramfs mount both root and /usr?       [21:12]
-<blueness> so i'm okay as long as we have solutions in place
-<blueness> for such systems
-<ulm> dberkholz: but we also shouldn't remove support where it currently
-      exists
-<blueness> rich0, no the / would boot first and hten nfs mount /usr
-<blueness> ulm, agreed
-<blueness> we should not remove support where it already exists
-<ulm> e.g., I wouldn't remove gen_usr_ldscript from util-linux          [21:13]
-<dberkholz> ulm: sure. i don't see that as controversial, to follow fhs
-            wherever reasonable
-<blueness> there is a similar problme with pxeboots
-<rich0> blueness: the question isn't how it worked, but how it could work.
-        Any reason an initramfs would not be possible, or a script that runs
-        early from inittab?
-<WilliamH> ulm: the /usr merge (separate subject) is fhs compliant.
-<ulm> WilliamH: how that?
-<blueness> rich0, okay if we can design an initramfs which can handle that
-           then i'm okay
-<WilliamH> Let's not get into the /usr merge here though, I was just siting it
-           as an example.
-<rich0> blueness: I'd think that dracut would work, but I'd have to see.
-                                                                        [21:14]
-<blueness> WilliamH, but people are worried about a slipper slope here
-<ulm> WilliamH: well, it's the big question for the long term
-<dilfridge> dracut is a documentation mess
-<WilliamH> ulm: because newer fhs says that /{bin,sbin,lib*} can be symlinks
-<rich0> Anybody doing PXE+nfs should know what they're doing in any case.
-        Hardly a handbook install (I run one myself, but not with separate
-        usr)
-<dberkholz> someone wrote up a really small initramfs to do this (robbat2?),
-            last time the discussion came up.
-<ulm> WilliamH: pointer?
-<dilfridge> we really badly need some *official installation documentation* on
-            how to set up a system with an initrd                       [21:15]
-<rich0> dilfridge: no argument there
-<WilliamH> The thing about initramfs is that you can use the tools, or you can
-           roll your own quite easily.
-<blueness> okay so my position in a nutshell: okay to early boot mechanism
-           with / and /usr separate provide we have working initramfs's (via
-           genkernel say) for already existing setups
-<rich0> I think we need to distinguish between where we are going and how we
-        get there.
-<blueness> +1 dilfridge,  we really badly need some *official installation
-           documentation* on how to set up a system with an initrd
-<rich0> If we're not ready to make the jump now, then we don't need to jump.
-        However, a declaration of long-term intent will allow everybody to
-        start migrating.
-<blueness> rich0, yeah that might work too, so people start to work towards
-           athat as a team                                              [21:16]
-<blueness> but like ulm said -> <ulm> e.g., I wouldn't remove gen_usr_ldscript
-           from util-linux
-<WilliamH> rich0: this is the jump -- separate /usr with or without an
-           initramfs... That is the most disruptive part of going forward
-           whether we do the /usr merge or not.
-<rich0> blueness: yup - right now everybody is playing tug of war.  Better to
-        have them focusing on offering various solutions, docs, handbooks,
-        whatever rather than fighting over whether it will happen.
-<WilliamH> rich0: from what i see about it.
-<blueness> it would be a disaster if one day people wok up and
-           gen_usr_ldscript were dropped from util-linux
-<WilliamH> blueness: only if they were not warned.                      [21:17]
-<dilfridge> let me make another point (or repeat it) - systemd, separate usr &
-            no initrd etc right now does already not work
-<blueness> WilliamH, or if they were warned and didn't ahve a solution
-<rich0> blueness, WilliamH: I think that might be the end result, but
-        docs/handbook/etc maybe need to evolve to get there
-<dilfridge> since (with the upcoming gnome) people will be moving to systemd,
-            that makes these questions a bit more urgent
-<WilliamH> blueness: my thought about gen_usr_ldscript is to first make it so
-           you can turn it off in make.conf for testing.                [21:18]
-<blueness> WilliamH, i still need a solution for currently supported
-           configuratons
-<rich0> dilfridge: good point.  One thing we could state is that
-        non-legacy-packages can be /usr-dependent right away.
-<rich0> I think the big concern is over openrc/sysvinit/udev and so on
-<rich0> Anybody running systemd already is past this issue.
-<blueness> rich0, correct                                               [21:19]
-<ulm> rich0: right
-<rich0> So let them just move on
-<WilliamH> blueness: if we turn it off, everywhere, the solution would be to
-           rebuild all affected packages, then before you reboot switch to an
-           initramfs.
-<WilliamH> or sep-usr busybox
-<blueness> WilliamH, okay then we need to doc what needs to be done before the
-           switch is thrown
-<WilliamH> blueness: there would be a list out there of the packages.
-<blueness> because today we'll have it on a use flag
-<ulm> last time I checked, sep-usr busybox was fundamentally broken
-<blueness> but tomorrow we'll want to drop the support
-<ulm> as it didn't fsck /usr
-<rich0> WilliamH: I'd set up the initramfs first before rebuilding half your
-        system to depend on it.  The whole point of an initramfs is that it is
-        smart enough to figure out how to boot your system either way.
-<ulm> has that changed?                                                 [21:20]
-<WilliamH> rich0: yes, that's true too, you could do it either way.
-<blueness> ulm, i haven't check about sep-user busybox, but that it would
-           surprise me
-<blueness> you can build busybox without /usr
-<blueness> everying in /bin and /sbin
-<rich0> Honestly, I'm all for choice but I don't really get the initramfs
-        hate.  I don't think it really matters though - we should document
-        whatever practical choices exist and leave it to the user.
-<WilliamH> sep-usr busybox is not fancy at all. its purpose is to just mount
-           /usr then move on.
-<ulm> blueness: yeah, but it mounts /usr
-<WilliamH> if you want more that is when you need an initramfs.
-<rich0> If you can install grub you can build an initramfs...           [21:21]
-<dilfridge> rich0: I dont like it either, but that is mainly because of
-            missing documentation
-<WilliamH> dilfridge: http://www.gentoo.org/doc/en/initramfs-guide.xml
-<rich0> dilfridge: yup - docs are definitely weak on the initramfs front.
-        Maybe an area to focus on.
-<blueness> rich0, the only argument against initramfs is just a cleaner boot,
-           which might be an issue say on embedded systems
-<dilfridge> rich0: and when I started with Linux, everyone recommended to use
-            a separate /usr , always, everywhere
-<dberkholz> like this? https://wiki.gentoo.org/wiki/Early_Userspace_Mounting
-            http://www.gentoo.org/doc/en/initramfs-guide.xml
-<WilliamH> docs have been out there for a long time.                    [21:22]
-<dilfridge> looks good
-<ulm> trying to keep this somewhat focused, should we take any decisions
-      today?                                                            [21:23]
-<rich0> So how about we propose that non-legacy pacakges (ie stuff that wasn't
-        stable a year ago) don't have to support a separate /usr without an
-        early boot mechanism.  For legacy packages our intent is to not
-        require this support and do the transition over the next six months,
-        with communications/docs/etc in place before we make the change.
-<blueness> FYI, initramfs images can be embedded into a kernel image for one
-           compact file --- this might be an issue in some pxe situations
-<rich0> To whatever extent they already exist it is just a communications
-        problem.
-<blueness> rich0, it might be more than just communication though       [21:24]
-<rich0> At the very least the handbook needs pointers and such
-<blueness> it maybe technically difficult in certain exotic boot situations
-<rich0> blueness: "To whatever extent they already exist..."
-<blueness> yeah
-<WilliamH> rich0: the handbook recommends not mounting with separate /usr.
-<WilliamH> s/mounting/partitioning/
-<ulm> rich0: thist implies that we express our intention to do the /usr merge?
-                                                                        [21:25]
-<WilliamH> The examples do not show doing that.
-<ulm> *this
-<rich0> WilliamH: might want to update this:
-        http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml
-<WilliamH> ulm: not necessarily.
-<rich0> Example there is a separate /usr
-<WilliamH> That could be done in less than 6 months.
-<rich0> (and the doc I followed umpteen years ago)                      [21:26]
-<ulm> well, we should go for consistency
-<rich0> WilliamH: Just suggest that it be sometime in the next six months -
-        not a hard time limit.  We go when we're ready.
-<ulm> so either FHS compliance
-<dilfridge> so, let's say we make a statement of intent now (no sep-usr
-            support required in half a year), strive to consolidate the
-            documentation on initramfs etc, revisit in 2 months to see the
-            status
-<ulm> or /usr merge
-<WilliamH> ulm: /usr merge is fhs compliant though.
-<ulm> WilliamH: it isn't
-<ulm> no way
-<WilliamH> ulm: they aren't mutually exclusive.
-<WilliamH> ulm: wait a sec                                              [21:27]
-<ulm> "The contents of the root filesystem must be adequate to boot, restore,
-      recover, and/or repair the system."
-* WilliamH is getting the link
-<rich0> ulm: I think we really need to think about doing the /usr merge, but I
-        don't see that has having to be a dependency.  Somebody has to be
-        willing to take that on.
-<blueness> what do you mean by merge here -> <WilliamH> ulm: /usr merge is fhs
-           compliant though.
-<blueness> a sym link / -> /usr
-<blueness> ?
-<dilfridge> that would be funny
-<ulm> blueness: moving everything from /bin /sbin /lib* to /usr         [21:28]
-<dberkholz> i think going for consistency wherever feasible is different from
-            requiring 100% consistency. the former is reasonable given the
-            current state of reality, the latter is not.
-<WilliamH> the /usr merg has symlinks in / for bin, sbin, lib* that go to
-           their counerparts in  /usr
-<blueness> ulm, that would be very bad
-<blueness> we have to try to be faithful to this ->  "The contents of the root
-           filesystem must be adequate to boot, restore, recover, and/or
-           repair the system."
-<blueness> as best we can
-<blueness> eg
-<blueness> suppose /usr is corrupt and needs repair                     [21:29]
-<rich0> blueness: I think the issue is that upstream has basically abandoned
-        that entirely.
-<blueness> can we get / up and fsck from it?
-<rich0> At least for upstream=systemd/udev
-<blueness> rich0, which upstream?
-<ulm> blueness: yeah, the question is exactly if we would give that up
-<dberkholz> then you're screwed because you won't be able to boot anyway,
-            unless you boot to busybox.
-<WilliamH> ulm hang on I'm getting the fhs link for you to show what I was
-           talking about.
-<blueness> ulm, we cannot give that up
-<rich0> That is what is driving this.
-<WilliamH> ulm: http://www.linuxbase.org/betaspecs/fhs/fhs.html         [21:30]
-<rich0> root is not sufficient as it stands if you're using something like a
-        bluetooth keyboard, and the sense is that it will only get worse
-<dilfridge> blueness: that exactly is the problem, on one hand people with
-            dated server installations swear that / needs to be
-            self-sufficient
-<ulm> WilliamH: yes, and that says what I've quoted earlier
-<dilfridge> blueness: on the other hand recent software sets do not really
-            follow the constrictions for that anymore
-<blueness> dilfridge, i'm one of them and there are lots of others, it would
-           be bad
-<dilfridge> blueness: meaning things break during upgrades without you
-            noticing                                                    [21:31]
-<blueness> yeah i know, we need to prevent that in so far as it is possible
-<blueness> i'm okay with the initramfs solution but not with the merge
-<rich0> I think we need to leave the merge aside for now.
-<rich0> I think that is really a separate issue.                        [21:32]
-<ulm> rich0: yes
-<blueness> okay merge aside, let me get this clear
-<rich0> There is a difference between allowing dependencies in /usr, and
-        moving everything to /usr en masse.
-<WilliamH> blueness:
-           http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
-<blueness> suppose / is fine and /usr is need of repair, would we be albe to
-           affect the repairs using the proposed initramfs solution?
-*** reavertm (~reavertm@gentoo/developer/reavertm) has joined channel
-    #gentoo-council                                                     [21:33]
-<ulm> blueness: you need your repair utils in the initramfs
-<blueness> WilliamH, i've read it, and i think those guys need to seriously
-           rethink their position
-<rich0> blueness: greatly depends on the nature of the problem.  most
-        initramfs will do basic fsck/etc automatically
-<dberkholz> blueness: good luck on that one.
-<ulm> blueness: busybox provides some of them
-<rich0> most will also drop you to a shell, but what is available varies and
-        is usually very limited
-<blueness> ulm, that work, if the initramfs takes the place of /
-<blueness> with documentation etc etc
-<rich0> I think docs are a sticking point here.
-<blueness> people who run servers need to have a repair path, if that's via
-           initramfs tools  i'm oaky with that                          [21:34]
-<rich0> hence I suggest we agree on intent, but allow some time for doc
-        updates and revisit
-<rich0> Honestly, if your /usr is really hosed the stuff in / isn't going to
-        be sufficient.  You really need a rescue CD for serious work.
-<WilliamH> blueness: that would be the repair path, yes.
-<rich0> Much of the stuff in / is going to be in an initramfs.  Most initramfs
-        allow arbitrary files to be bundled as well.
-<blueness> rich0, i think ulm's idea of repair in intramfs is great
-<WilliamH> The usr merge is a red herring that doesn't affect this vote
-           really.
-<blueness> that might be the point that will satisfy people             [21:35]
-<blueness> like making the initramfs the new /
-<dilfridge> I dont have much experience, but I *think* having fs repair
-            utilities and basic network stuff (e.g. dhcpcd) in an initrd
-            shoudl be possible
-<WilliamH> blueness: you can very easily make your own initramfs too. That is
-           a little bit more advanced but that level of customization is
-           possible.
-<blueness> in general
-<rich0> Might not hurt to put that in the docs too - how to repair from an
-        initramfs, or ensure your initramfs is configured to enable it
-        (sometimes dropping to a shell is a config item for security - it is a
-        root shell)
-<blueness> WilliamH, i know :)
-<blueness> i spend my time building firmware images                     [21:36]
-<blueness> rich0, yeah if we can show how all FHS concerns are met in a
-           slightly different way, then we have a very good middle path
-<blueness> i can agree to the intent
-<dberkholz> so my understanding now is, we will support separate /usr as long
-            as people are using a mechanism to ensure it's mounted early.
-            current methods include initramfs or busybox[sep-usr].
-                                                                        [21:37]
-<rich0> Is there anybody who has issues then with the long-term move, but
-        before we do it we need to agree all docs/etc are in a row?
-<ulm> so shall we do actual voting today, or go back to ML discussion? if we
-      vote, I suggest that we do it in steps, as suggested by rich0
-<dilfridge> ulm: vote today, but in steps                               [21:38]
-<ulm> who wants to vote now?
-<WilliamH> ml discussion is going to be a never-ending bikeshed I think.
-<rich0> I suggest we at least vote on something around intent
-<blueness> we can vote to the intent and get feedback on the mechanism
-<blueness> the community make bring up tech issues we ahve not thought of
-<WilliamH> If we are going to vote on intent, what does that mean in terms of
-           base-system and toolchain working on legasy issues... like
-           gen_usr_ldscript...                                          [21:39]
-<ulm> WilliamH: I'd rather avoid micro-management
-<WilliamH> ulm: ok, that's fine with me.
-<rich0> Suggest we also vote that stuff that wasn't stable a year ago (eg
-        systemd) can depend on /usr now.
-<WilliamH> I would rather avoid micro-management as well.
-<dilfridge> ok here's a suggestion for a vote:
-<blueness> yeah me neither, because people will figure out what to do just
-           knowing the goal                                             [21:40]
-<WilliamH> One thing I think needs to be in the statement of intent is
-<dilfridge> 1 "Since that particular setup may already be subtly broken today
-            depending on the installed software, Council strongly suggests to
-            use an early boot mount mechanism, e.g. initramfs, if /usr is on a
-            separate partition."                                        [21:41]
-<ulm> strike "strongly"
-<WilliamH> dilfridge: go ahead...
-<WilliamH> ulm: no
-<dberkholz> s/strongly suggests to use/recommends using/
-<ulm> dberkholz: +1
-<blueness> dberkholz, yep
-<WilliamH> dberkholz: ok
-<dilfridge> ok
-<blueness> strongly is overkill                                         [21:42]
-<rich0> ++ - in general I've learned at work that any word ending in ly
-        probably isn't necessary.  LIke the probably in my last sentece.
-<dilfridge> 1a "Since that particular setup may already be subtly broken today
-            depending on the installed software, Council recommends using an
-            early boot mount mechanism, e.g. initramfs, if /usr is on a
-            separate partition."
-<rich0> seems good so far
-<ulm> o.k., please vote on 1(a) as suggested                            [21:43]
-<dilfridge> 1b "Since that particular setup may already be subtly broken today
-            depending on the installed software, Council recommends using an
-            early boot mount mechanism, e.g. initramfs, to mount /usr if /usr
-            is on a separate partition."
-<dilfridge> sorry
-<dilfridge> 1b please
-<dilfridge> clearer
-<dilfridge> (added "to mount /usr")
-* WilliamH votes yes
-* dilfridge yes
-* scarabeus goes for yes
-* blueness yes
-<rich0> yes
-* ulm yes on 1b
-<WilliamH> Now there is one more thing.                                 [21:44]
-<rich0> WilliamH: a few more things actually
-<rich0> That's just part 1
-<dberkholz> sure. although i'd go with "the council" vs "Council" as a proper
-            noun
-<WilliamH> If we start changing software based on that recommendation and bugs
-           are opened wanting us to change it back...
-<ulm> dberkholz: your vote?
-<WilliamH> as I"m sure there will be...
-<rich0> WilliamH: we haven't gotten that far
-<dilfridge> dberkholz: is that yes?
-<dberkholz> sure == yes                                                 [21:45]
-<ulm> k
-<rich0> 1b just is a recommenation to users, not green light to maintainers
-<ulm> unanimous
-<blueness> rich0, right thanks for that clarification
-<ulm> dilfridge: any further suggestion for a vote?
-<dilfridge> well
-<rich0> 2a - "Over the next few months the intent is to not require
-        maintainers to support a separate /usr without an early boot
-        mechanism, once the Council agrees that the necessary docs/migration
-        path is in place.                                               [21:46]
-<dilfridge> something like that would be the next question, indeed
-<mattst88_> what happened to scarabeus? doesn't seem to have said anything
-            since 19:03 UTC.
-<scarabeus> why council, when the docs are in place can be checked by anyone
-<mattst88_> ah :)
-<WilliamH> Yes, the docs are already there.
-<scarabeus> mattst88_: i voted, i just don't do much about the /usr :;-)
-                                                                        [21:47]
-<ulm> rich0: shouldn't we ask the inverted question?
-<dilfridge> ulm: means what?
-<ulm> i.e. maintainers are required to still support separate /usr for
-      existing packages                                                 [21:48]
-* WilliamH would vote no for that.
-<ulm> (ones that are stable for at least one year)
-<WilliamH> That's getting into micro-management.
-<rich0> 2b - Once the Council agrees the necessary docs/migration path is in
-        place maintainers will not be required to support booting with a
-        separate /usr without an early boot mechanism (eg initramfs).
-<ulm> until we revisit the issue
-<blueness> rich0, can i suggest: 2a - "The intention is to eventually not
-           require maintainers to support a separate /usr without an early
-           boot mechanism once the Council agress that the necessary
-           docs/migration path is in place."
-<WilliamH> What is there to revisit?
-<ulm> WilliamH: documentation mainly
-<rich0> I'm fine with blueness's wording as well
-<dilfridge> blueness: new wording -> new number please, otherwise things get
-            confused                                                    [21:49]
-<blueness> dilfridge, okay sorry
-<dilfridge> s/number/letter/
-<rich0> I don't think we'll get agreement that docs are in place now in the
-        next 10 min
-<blueness> 2c - "The intention is to eventually not require maintainers to
-           support a separate /usr without an early boot mechanism once the
-           Council agress that the necessary docs/migration path is in place."
-<WilliamH> What docs can we even agree on? there are many ways to build an
-           initramfs...
-<rich0> unless we force a divided vote - and I'm not certain that is a great
-        idea.  In any case, we need communications/etc to users before doing
-        anything.
-<ulm> any further changes to 2c wording?                                [21:50]
-<WilliamH> There were docs sited in the meeting earlier...
-<rich0> Suggest we vote on 2c
-<dilfridge> yes vote on 2c
-<ulm> please vote on 2c then
-* blueness yes on 2c
-<rich0> WilliamH: agree docs were cited, not sure they're sufficient.
-<scarabeus> i would actually say that council should not need to agree on when
-            to start migrate, we don't dicate when to put new stuff or remove
-            old one; we can leave that to openrc/systemd guys when they are
-            sattisfied
-* rich0 yes on 2c
-<WilliamH> paste 2c again?
-<blueness> 2c - "The intention is to eventually not require maintainers to
-           support a separate /usr without an early boot mechanism once the
-           Council agress that the necessary docs/migration path is in place."
-<rich0> scarabeus: only suggest council reviews due to the extreme sensitivity
-        of the issue                                                    [21:51]
-<dberkholz> s/agress/agrees
-<rich0> normally I'd agree with you on that.
-<ulm> dberkholz: already noted
-* WilliamH votes yes
-<scarabeus> its base system, the same applies for genkernel or kernel guys,
-            who started to change genpatches to huge stuff
-* ulm abstains on 2c
-<WilliamH> I would like to say something though.                        [21:52]
-* dilfridge abstains on 2c
-<WilliamH> wait, I withdraw my vote
-* WilliamH abstains
-<ulm> dberkholz: scarabeus: ?
-<WilliamH> The problem is that is too subjective.
-<WilliamH> That's why I abstain
-<rich0> Nothing subjective about it.  When the council votes, it votes.
-                                                                        [21:53]
-<scarabeus> nope from me for this, unless the docs are exactly listed (you can
-            easily say its fine or otherwise)
-<rich0> Intent is to end debate over direction and direct efforts to how we
-        get there.
-<ulm> WilliamH: it's a design decision, it will always be subjective
-<dberkholz> i vote yes
-<WilliamH> Which docs are we talking about though?
-<ulm> I cound 3 yes, 1 no, 3 abstains
-<blueness> i don't think we should overly define this actually that could be
-           worse
-<rich0> WilliamH: suggest we take the docs discussion to the lists/etc.
-<ulm> *count
-<WilliamH> the dracut docs, the genkernel docs, a how to roll your own doc?
-<ulm> motion passed                                                     [21:54]
-<rich0> WilliamH: whatever docs gives the council the warm fuzzies.  :)  I
-        intend to pitch in though.
-<blueness> WilliamH, you can always bring that up when we discuss the docs,
-           right now its just to have the goal stated ... and 2c does that
-<WilliamH> ok
-* WilliamH votes yes then change my vote
-<dberkholz> the key docs thing will be the handbook, mainly checking to make
-            sure
-            http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=7
-            has everything we need.
-<rich0> Suggest voting on 3a - "Packages not stable 1 year ago need not
-        support a separate /usr without an early boot mechanism immediately."
-<ulm> 4 yes, 1 no, 2 abstains
-<ulm> rich0: what about package splits?                                 [21:55]
-<dilfridge> strike "immediately"
-<ulm> like netifrc
-<WilliamH> ulm: irrelivent to this
-<WilliamH> netifrc doesn't care about initramfs
-<ulm> WilliamH: just an example ;)
-<WilliamH> ;-)
-<dilfridge> I guess there common sense applies... if part of something was
-            stable a year ago, it counts as stable a year ago
-<dberkholz> that double negative is killing me                          [21:56]
-<rich0> 3b - Packages that were not stable on Aug 1st 2013 do not need to
-        support a separate /usr.  No further council vote is needed for these
-        packages."
-<rich0> s/2013/2012
-<blueness> rich0, i'm confused with respect to the intent/issue this is
-           addressing
-<scarabeus> Packages that did not have stable versions
-<scarabeus> somebody could for sure get there "this version was not stable" :D
-                                                                        [21:57]
-<rich0> blueness: intent is that systemd/etc which already do not support a
-        separate /usr can stay as they are
-<rich0> Maybe just drop that issue entirely.
-<rich0> Clearly we're not going to migrate that stuff to / only to migrate it
-        back.
-* WilliamH thinks this is getting into micromanagement.
-<dilfridge> rich0: yes
-<dberkholz> i would reword it
-<dilfridge> but we should be wary that people interpret 2c as "it is required
-            now"                                                        [21:58]
-<ulm> we're over time already, I suggest we conclude the issue at this point
-<ulm> continue next month if there's need for it
-<rich0> ulm: I'm fine with that.
-<blueness> ulm, i'm okay with ending now, let's just leave the two points
-<blueness> that'll be enough
-<dilfridge> ok, at least we have a nice policy statement
-<dberkholz> more like 3c "Packages with any stable version on 1 Aug 2012
-            should support a separate /usr if feasible."
-* blueness puts on his fire proof vest
-<dilfridge> dberkholz: nope                                             [21:59]
-<ulm> topic 3, locale for build logs in bugzilla
-<dilfridge> yep
-<dilfridge> my baby
-<ulm> http://article.gmane.org/gmane.linux.gentoo.project/2926
-<dilfridge> actually the discussion on the list was pretty much helpful
-<chithead> bug 478382
-<willikins> chithead: https://bugs.gentoo.org/478382 "Please set LC_MESSAGES=C
-            in make.conf"; Gentoo Hosted Projects, Catalyst; CONF;
-            chithanh:catalyst
-<dilfridge> I would like to immediately propose a vote                  [22:00]
-<dilfridge> but I have a slightly different suggestion
-<rich0> dilfridge: ++ - suggest something
-<ulm> dilfridge: just a comment from me
-<ulm> https://wiki.gentoo.org/wiki/Bugzilla_HOWTO#Evaluating_emerge_Errors
-      currently suggests LC_ALL=C                                       [22:01]
-<ulm> so maybe we have to take care of this, too
-<dilfridge> 4: "Make a news item, then add LC_MESSAGES=C to the base profile
-            make.defaults"
-<dilfridge> (this means anyone can override in make.conf easily, and still it
-            goes into effect everywhere now)                            [22:02]
-<blueness> this seems pretty straight forward, i see no problems here   [22:03]
-<blueness> are we voting?
-<ulm> not sure if make.defaults is the right place for it
-<dilfridge> ulm: where else?
-<ulm> bug reporting guide?
-* WilliamH is wondering about forcing the setting too.
-<scarabeus> people ignore that                                          [22:04]
-<rich0> ulm: the intent is to have it someplace so that it becomes a default
-        behavior.  I think it is either a profile or make.globals or the
-        default make.conf
-<dilfridge> well it's not really forcing it, it is just setting a sane default
-<WilliamH> If I got a bug with logs in a language I couldn't read I would
-           probably just close the bug as needinfo and explain that I couldn't
-           read the logs.
-<rich0> the profile is the simplest option I think
-<dilfridge> if people insist to have russian gcc error messages, well, ...
-<scarabeus> i read german and russian so i don't have to care, but i have half
-            half bugs; localized/english
-<scarabeus> and most will ignore you for the request to compile ie libreoffice
-            for next 16 hours again... :-)                              [22:05]
-<dilfridge> ulm: the intent is that the default will make your logs "bugzilla
-            capable", and you need to actively do something to get away from
-            that
-<rich0> Oh, and I would also be willing to propose that maintainers are free
-        to close bugs with non-english logs at their discretion.
-<TomWij> ulm: That guide (https://gentoo.org/doc/en/bugzilla-howto.xml -->
-         https://wiki.gentoo.org/wiki/Bugzilla_HOWTO) already lists LC_ALL=C.
-<rich0> But we can still change the defaults
-<dilfridge> rich0: that's a different item, we can talk about it afterwards
-                                                                        [22:06]
-<ulm> TomWij: yeah, that's why I've posted this URL above :p
-<dilfridge> LC_ALL causes pain for the python guys
-<scarabeus> most people don't even realize they override the locale until it
-            is too late, so why not have some default to keep us happy
-<chithead> if it is in make.conf, it will become default for all new installs.
-           jer (who complained most in the past) was fine with it
-<ulm> ok, let's vote on dilfridge's proposal then
-<TomWij> dilfridge, ulm: Ah, I see the issue now; just the messages (for build
-         logs) makes a lot more sense.                                  [22:07]
-<ulm> LC_MESSAGES=C in make.defaults
-* dilfridge yes
-* rich0 yes
-<dberkholz> k
-* WilliamH yes
-* ulm yes
-* blueness yes
-<ulm> 6 yes                                                             [22:08]
-<ulm> scarabeus?
-<scarabeus> yes
-<ulm> unanimous
-<ulm> docs need to be updated, too
-<ulm> but that's self evident, no vote required I guess                 [22:09]
-<ulm> next topic
-<ulm> topic 4, open bugs with council involvement
-<ulm> bug 477030
-<willikins> https://bugs.gentoo.org/477030 "Missing summary for 20130611
-            council meeting"; Doc Other, Project-specific documentation; CONF;
-            ulm:council
-<ulm> anyone has talked to betelgeuse?                                  [22:10]
-<blueness> i looked for him but i never saw him
-<scarabeus> didn't see him, just assign one guy to talk with him on the bug
-<scarabeus> it is not something that needs to be fixed with upmost importance
-<ulm> scarabeus: you've just volunteered? ;)
-<ulm> and since we're at it                                             [22:11]
-<scarabeus> fancy do i get a beer for it? :-)
-<ulm> dilfridge: when do we get the summary for July?
-<chithead> regarding topic #3 do note that vapier spoke out against having it
-           in make.defaults
-           http://archives.gentoo.org/gentoo-dev/msg_0cd6b1f0e0b0c156e51b498362ec96f2.xml
-<dberkholz> 10. Customs and Border Patrol knows of any time you have been
-            arrested. I had read that the CBP’s background check is highly
-            exhaustive, but I got the chance to witness the extent of their
-            scrutiny. The applicant who had his appointment before mine began
-            the process cordially, but their conversation quickly became
-            heated. Apparently, this gentleman had his application denied due
-            to an arrest 40 years ago. And according to him, the 
-<ulm> scarabeus: when I see you next :)
-<dberkholz> 10. Customs and Border Patrol knows of any time you have been
-            arrested. I had read that the CBP’s background check is highly
-            exhaustive, but I got the chance to witness the extent of their
-            scrutiny. The applicant who had his appointment before mine began
-            the process cordially, but their conversation quickly became
-            heated. Apparently, this gentleman had his application denied due
-            to an arrest 40 years ago. And according to him, the        [22:12]
-<dberkholz> woops, sorry!
-<dberkholz> middle click gone wild.
-<blueness> dberkholz, what are you reading!
-<dilfridge> hmm
-<ulm> chithead: the post says that he's indifferent?                    [22:13]
-<dberkholz> i was attempting to copy the link to vapier's thing and apparently
-            failed with my two-button mouse
-<chithead> ulm: indifferent to having it in make.conf, against having it in
-           make.defaults
-<dilfridge> ulm: soon
-<ulm> ah, right
-<rich0> chithead: not sure we want to re-open.  I'm on the fence about that,
-        but make.conf doesn't impact existing users at all.
-<ulm> that vote is closed for now                                       [22:14]
-<blueness> chithead, i wish he'd given a reason
-<dilfridge> chithead: dberkholz: if vapier does not bother to explain why,
-            then we can't bother to take him serious
-<rich0> I'd be fine with actually putting it in both places, to make it easy
-        for new users to edit, have a comment to explain why it is set and not
-        to submit bugs that are non-english, etc.
-<ulm> we can revisit next month if there are good arguments
-<rich0> sure
-<ulm> next
-<ulm> bug 480408
-<willikins> ulm: https://bugs.gentoo.org/480408 "Autobuilds go to
-            /experimental and to /releases only when actually tested"; Gentoo
-            Linux, Unspecified; CONF; mattst88:council
-<mattst88_> (I'm here if anyone has questions)                          [22:15]
-<blueness> ulm, why is this on the floor?
-<mattst88_> I can answer that.
-<blueness> shoot
-<ulm> should we discuss this today, given that we're way behind schedule?
-<blueness> ulm, let's start
-<ulm> jmbsvicetto: are you here?
-<dilfridge> who cares about schedule...
-<mattst88_> I'd be happy to have someone else engage jmbsvicetto on the bug.
-*** NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has quit: Quit:
-    what, what, what, what, what, what, what, what, what, what.  Only 10 Watts
-    Neddy ?  Thats not very bright!!                                    [22:16]
-<mattst88_> I've been unsuccessful it seems, and have apparently insulted him.
-            :\
-<mattst88_> anyway, I thought this proposal was uncontroversial (it received
-            only positive comments on gentoo-dev), but jmbsvicetto objects.
-<scarabeus> i dont get whats the problem, jorge tries hard, and we could put
-            anything automatic there too (if somebody is interested) otherwise
-            it is pointless, hand testing is weird                      [22:17]
-<mattst88_> and I haven't been able to understand what he disagrees with.
-<blueness> mattst88_, i'm on the bug cc, i'm just not sure why he's taken the
-           position he has, but i don't feel comfortable bringing it to the
-           council before its been discussed with releng lead (who is that?)
-<mattst88_> blueness: I don't think we have one.
-*** xmw (~michael@gentoo/developer/xmw) has joined channel #gentoo-council
-<WilliamH> That is jmbsvicetto  (acting lead)
-<mattst88_> the releng page doesn't say that.                           [22:18]
-<blueness> mattst88_, i spoke with him briefly about it, but just to thank him
-           for his hard work, and he *does* work  very hard
-<blueness> i'd like to table this pending my having a discussion with him
-<blueness> jmbsvicetto, ^^^^
-<ulm> there's obviously a social problem in addition to the technical one, and
-      we cannot solve this without further information
-<mattst88_> blueness: could we do it in public?
-<blueness> mattst88_, are you okay with that
-<mattst88_> blueness: if we do it in the bug -- yes.
-<rich0> I would like to hear jmbsvicetto explain his position.
-<blueness> mattst88_, i'm not against public debate                     [22:19]
-<ulm> rich0: yes, we shouldn't take a decision without that
-<dberkholz> just a guess, but i'm thinking it may be manual vs automated
-            testing
-<WilliamH> mattst88_: No, it doesn't, that's what I was told personally
-           though...
-<rich0> I've run into build issues a few times in the last year.  They have
-        been improving, and I'm sure it is hard work.  Would love to see build
-        issues addressed, but would like releng's input as far as best way to
-        accomplish that.
-<WilliamH> but I do find it odd that agaffney is still there.
-<dberkholz> if we could come up with an automated test suite, that would be
-            probably go over well
-<WilliamH> maybe just the page hasn't been updated in a while?
-<blueness> mattst88_, he may need help                                  [22:20]
-<blueness> testing etc
-<dberkholz> we used to do manual testing, fixes, etc and it was incredibly
-            effort-intensive
-<ulm> so, let's refer this back to bugzilla?
-<WilliamH> right.
-<mattst88_> fine by me.
-<scarabeus> agree                                                       [22:21]
-<rich0> Somebody want to volunteer with the inquiry?
-<rich0> I don't mind
-<ulm> rich0: k
-<scarabeus> dberkholz: writting that openqa thing is quest for one afternoon
-<rich0> I have some interest in this.
-<ulm> topic 5, open floor
-<blueness> yeah back to bugzilla, and since i'm part of releng i'll try to
-           nudge this foward
-<rich0> blueness: I'm fine with you taking the lead on that.            [22:22]
-* ulm listening for open floor topics
-<dberkholz> scarabeus: does it run on gentoo?                           [22:23]
-<scarabeus> dberkholz: i said on the bug
-<xmw> does the council favor git migration?
-<scarabeus> dberkholz: it does
-<blueness> scarabeus, i've never used openqa is that something you can easily
-           set up?
-<blueness> automate etc
-<scarabeus> dberkholz: i did use gentoo at work to run it (without the web
-            interface it is lame) that is bit rougher
-<ulm> xmw: seriously?
-<WilliamH> xmw: it isn't council that is stopping that; it is infra issues.
-                                                                        [22:24]
-<scarabeus> blueness: you basically say write x write z; enter; and then at
-            specific points you say do_screenshot() later in web interface you
-            just create "needle" which is part of the screen you compare to
-<scarabeus> if it match test passed
-<scarabeus> otherwise, problem is in place
-<xmw> ulm: so, can you repeat your position, for us to nag infra, please?
-<dberkholz> not a huge fan of things that require a web interface, really.
-            they tend to fail hard in gentoo
-<scarabeus> blueness:
-            http://openqa.opensuse.org/results/openSUSE-Factory-GNOME-Live-i686-Build0658-live
-                                                                        [22:25]
-<scarabeus> blueness: the green squared ones are the tested parts
-<scarabeus> (you can test even sounds if you are nuts like opensuse :D)
-<ulm> xmw: not sure how the council should accelerate this
-<blueness> scarabeus, looks like serious setup though                   [22:26]
-<rich0> I'm all for the git migration, and robbat2 actually stepped down from
-        trustees to give it more attention
-<dberkholz> xmw: we definitely favor it, it's more of a matter of people doing
-            the work
-<rich0> I intend to help with docs, and xmw if you want to help out we can try
-        to work with you.
-<xmw> ulm: just eliminate any doubt, aka "there isn't even a clear standpoint
-      from/of the council".
-<rich0> infra has to do some back-end work though - on stuff that generally
-        isn't accessible
-<dilfridge> xmw: definitely in favour, but dont really know how to help since
-            the rest is "work inside infra stuff"                       [22:27]
-<blueness> xmw, yeah totally in favor of a git migration
-<blueness> cvs is killing me, its such a resource hog
-<TomWij> ulm: Even s/should/could/, because it still depends on people doing
-         work and you can't really do much about that (and as pointed out
-         robbat2 makes more time free for it); unless you put more people to
-         the work, but then again, I doubt if the amount of people is really
-         the problem (and it is known that adding people slows things down due
-         to lack of knowledge and extra communication).
-<ulm> xmw: I'm in favour of course, but as others said, statements of
-      intention won't help much
-<blueness> i think this has always been about resources                 [22:28]
-<blueness> i don't know anyone who is against a git migration
-<xmw> thanks for the statement.
-<dberkholz> xmw:
-            http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt
-<dberkholz> "The council also urges individual developers to join the effort
-            to move the tree to git.
-<dberkholz> "
-<xmw> it's hard to get the semi-public infra code, maybe another attempt may
-      help.
-<ulm> dberkholz: there we go
-<ulm> thanks :)
-<blueness> dberkholz, i don't see how individual developers outside of infra
-           could help here                                              [22:29]
-<ulm> I see no further topics brought forward to the council
-<rich0> Well, there are other things that can be done in terms of docs/etc.
-                                                                        [22:30]
-<blueness> who's chair next time?
-*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
-    "Next meeting: 10 Sep 2010 at 19:00 UTC |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 |
-    http://www.gentoo.org/proj/en/council/"
-<ulm> blueness: me again
-<scarabeus> blueness: note that the frontend is not technically needed, it is
-            just easier to write result comparison that way, but you can do it
-            without frontend and just execute the os-autoinst in loop
-<dberkholz> blueness: check the tracker, there's opportunities to help:
-            https://bugs.gentoo.org/show_bug.cgi?id=333531
-<blueness> ulm, okay i have an issue
-<ulm> the meeting is closed
-<ulm> thank you everybody                                               [22:31]
-<WilliamH> ulm: ^^
-<mattst88_> does the /topic say 2010, or is my irc client confused?
-<dilfridge> ulm: blueness wanted to say something
-<ulm> oops
-<xmw> thanks. affirmative on the 2010.
-<WilliamH> ulm: should we re-open?
-*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
-    "Next meeting: 10 Sep 2013 at 19:00 UTC |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 |
-    http://www.gentoo.org/proj/en/council/"
-<rich0> ulm: thank you!                                                 [22:32]
-<TomWij> blueness: Issue for council discussion or not?
-<ulm> next meeting 10th of september
-<blueness> dilfridge, its okay i'll just email him
-*** Hawk777 (~Hawk777@ritchie.cs.ubc.ca) has left channel #gentoo-council:
-    #gentoo-council
-<scarabeus> i liked the 2k10
-<blueness> ulm, i'll email you an issue
-<ulm> blueness: sorry
-<blueness> np
-<ulm> missed your line :(
-*** TomWij (~TomWij@gentoo/developer/tomwij) has left channel #gentoo-council:
-    "WeeChat 0.4.1"                                                     [22:33]
-<blueness> ulm, really no problem, its easier via email
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130910-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20130910-summary.txt
deleted file mode 100644
index 267e947335..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130910-summary.txt
+++ /dev/null
@@ -1,118 +0,0 @@
-Summary of Gentoo council meeting 10 September 2013
-
-Agenda
-======
-1. Introduction and roll call
-
-2. Install functions, default src_install [1,2,3] - ulm
-
-3. einstalldocs() pre-approval for next EAPI [4,5] - mgorny
-
-4. Minor architectures stabilisation policy [6,7] - hwoarang
-
-5. Specification of /var/db/pkg contents [8,9] - blueness
-
-6. GLEP draft "Prefix with libc" [10,11,12] - heroxbd
-
-7. Drop support for separate /usr partition [13] - williamh
-
-8. Open bugs with council involvement
-   - Bug 481202 - Tracker - Documentation or implementation issues
-     for dropping of separate /usr support [14]
-   - Bug 477030 - Missing summary for 20130611 council meeting [15]
-   - Bug 480408 - Add /releases/${arch}/verified tree for tested
-     autobuilds [16]
-
-9. Open floor
-
-
-Roll call
-=========
-Present:
-   blueness
-   calchan (proxy for dberkholz)
-   dilfridge (32 minutes late)
-   rich0
-   scarabeus
-   ulm
-   williamh
-
-Install functions, default src_install
-======================================
-Two votes were taken:
-
-Calling the do*() install commands without a filename parameter is
-an error. Vote for approval of updated PMS wording, as in ref. [2].
-- Accepted unanimously (6 yes votes).
-
-Retroactively change default src_install() in EAPIs 4 and 5 such
-that the DOCS variable is allowed to be empty.  Vote for approval
-of updated PMS wording, as in ref. [3].
-- Rejected with 4 no votes and 2 abstentions.
-
-einstalldocs() pre-approval for next EAPI
-=========================================
-mgorny shortly presented the einstalldocs() function proposed for
-EAPI 6. The purpose of this is to split off the doc-install part from
-default src_install and make it available to ebuilds as a function.
-For existing EAPIs, a function of the same name would be added to
-eutils.eclass. Vote for approval of the einstalldocs() implementation,
-as shown in Ref. [5].
-- Accepted unanimously (6 yes votes).
-
-(Note added in proof: The implementation should use double quotes
-instead of single quotes around "declare -a" [17].)
-
-Minor architectures stabilisation policy
-========================================
-The council was asked to vote if alpha, ia64, m68k, s390, sh, and
-sparc should be dropped to unstable keywords. Alternatively, only the
-packages pulled in by the system set could be stable for these
-architectures. In the council's discussion it was argued that arch
-testing is a lot of work and that some arch teams cannot keep up.
-It was also pointed out that dropping keywords to unstable is an
-action that is hard to revert, because restoring a consistent stable
-dependency tree will require retesting of many packages.
-- Decision deferred to next meeting.
-
-Specification of /var/db/pkg contents
-=====================================
-The council discussed if the contents of the VDB should be specified
-for interoperability between utilities, either in the PMS or possibly
-in a separate document. Alternatively, package managers could provide
-an abstraction layer to make some of the VDB's information available.
-Finally, the following vote was taken:
-"The council recommends that package managers export the NEEDED.ELF.2
-information for interoperability between utilities."
-- Accepted with 6 yes votes and 1 abstention.
-
-[At this point, time had passed the one hour that was allocated for
-the meeting. Therefore, agenda topics 6 to 8 were skipped and another
-meeting was scheduled for the following week.]
-
-Open floor
-==========
-No issues were brought up to the council.
-
-Next meeting date
-=================
-17 September 2013, 19:00 UTC
-
-
-[1] http://article.gmane.org/gmane.linux.gentoo.project/2976
-[2] http://article.gmane.org/gmane.linux.gentoo.pms/764
-[3] http://article.gmane.org/gmane.linux.gentoo.pms/766
-[4] http://article.gmane.org/gmane.linux.gentoo.project/2978
-[5] http://thread.gmane.org/gmane.linux.gentoo.devel/87642/focus=87803
-[6] http://article.gmane.org/gmane.linux.gentoo.project/2984
-[7] http://thread.gmane.org/gmane.linux.gentoo.devel/87741
-[8] http://article.gmane.org/gmane.linux.gentoo.project/2995
-[9] https://bugs.gentoo.org/show_bug.cgi?id=458866
-[10] http://article.gmane.org/gmane.linux.gentoo.project/3022
-[11] http://thread.gmane.org/gmane.linux.gentoo.devel/87466
-[12] http://git.heroxbd.z.tuna.tsinghua.edu.cn/?p=doc.git;a=blob;f=glep-gap.rst;hb=HEAD
-[13] http://thread.gmane.org/gmane.linux.gentoo.project/2946
-[14] https://bugs.gentoo.org/show_bug.cgi?id=481202
-[15] https://bugs.gentoo.org/show_bug.cgi?id=477030
-[16] https://bugs.gentoo.org/show_bug.cgi?id=480408
-[17] http://thread.gmane.org/gmane.linux.gentoo.devel/87642/focus=87804
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130910.txt b/xml/htdocs/proj/en/council/meeting-logs/20130910.txt
deleted file mode 100644
index c40508eaa8..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130910.txt
+++ /dev/null
@@ -1,589 +0,0 @@
-<ulm> let's start then                                                  [21:00]
-*** dastergon (~dastergon@gentoo/developer/dastergon) has joined channel
-    #gentoo-council
-<ulm> agenda is here:
-      http://article.gmane.org/gmane.linux.gentoo.devel.announce/1978
-<ulm> roll call
-<rich0> here
-<Calchan> here
-<blueness> here
-<Calchan> proxing for dberkholz
-<WilliamH> here
-* scarabeus here
-<scarabeus> dilfridge: pling                                            [21:01]
-<blueness> start without him?                                           [21:02]
-<ulm> let's see if I have his phone number
-<ulm> I've sent a text message                                          [21:03]
-<blueness> ulm, any response?                                           [21:04]
-<ulm> no
-<ulm> let's start then                                                  [21:05]
-<blueness> k
-<ulm> 2. Install functions, default src_install
-<ulm> http://article.gmane.org/gmane.linux.gentoo.project/2976
-<ulm> it's all in that message, so I've nothing to add here
-<ulm> I suggest that we discuss and vote about the two parts separately
-                                                                        [21:06]
-<rich0> ulm: my sense from the discussion is that there is no real need to
-        make it retroactive.  Is there somebody seeking that who I missed?
-<rich0> Ie, nothing in-tree depends on the portage-specific behavior.
-<ulm> first would be clarification of PMS wording for do* functions:
-      http://article.gmane.org/gmane.linux.gentoo.pms/764               [21:07]
-<ulm> rich0: right, we'll come to this in a minute
-<ulm> anyone wants to discuss the first part?                           [21:08]
-<blueness> ulm, the clarification would say that do* without arguments die?
-<ulm> blueness: exactly
-<ulm> portage could keep it's current behaviour for at least a transition time
-      though, i.e. dodoc has only a QA warning                          [21:09]
-<ulm> *its
-* scarabeus agree with making it fatal :-)
-<rich0> Your wording seems fine to me.
-<blueness> i'm for it
-<rich0> If nothing in-tree now depends on this behavior suggest we keep it
-        that way...                                                     [21:10]
-<ulm> ok, then please vote for the wording in
-      http://article.gmane.org/gmane.linux.gentoo.pms/764
-* ulm yes
-<rich0> yes
-<Calchan> yes                                                           [21:11]
-<WilliamH> yes
-*** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 240
-    seconds
-<blueness> yes
-<ulm> scarabeus?
-*** jcallen (~quassel@gentoo/developer/jcallen) has joined channel
-    #gentoo-council
-* scarabeus yes
-<ulm> unanimously
-<ulm> second part is a bit more tricky
-<ulm> http://article.gmane.org/gmane.linux.gentoo.pms/766               [21:12]
-<ulm> that would change default src_install for EAPI 4 and 5 retroactively
-<ulm> but AFAIK it's not used in the tree                               [21:13]
-<ulm> so I'm indifferent
-<blueness> i'm not sure we need this retroactive
-<rich0> I suggest not doing any retroactive changes if there isn't a need.
-<rich0> But by all means keep this undocumented behavior out of portage.
-* WilliamH isn't sure about this either
-<blueness> well what if someone tries this at EAPI=0.  they would only get the
-           QA warning.  then later when bumping to EAPI=5 the ebuild would
-           die.  doesn't sound that bad to me.                          [21:14]
-<scarabeus> if it is not used in main tree we can even do retroactive fix; but
-            i would leave it to ulm to decide as it is his patch        [21:15]
-<WilliamH> scarabeus: that sounds reasonable...
-<ulm> let's just vote then                                              [21:16]
-<blueness> k
-<ulm> approve wording of http://article.gmane.org/gmane.linux.gentoo.pms/766
-      yes/no                                                            [21:17]
-<WilliamH> ulm: what is the vote?
-<ulm> I abstain from the vote
-<Calchan> retroactively changing an EAPI defeats the purpose of EAPIs, so I
-          vote no
-<blueness> i vote no to retroactively changing
-<ssuominen> while src_install() is being discussed, I should have suggested
-            looking at bug 459692 at the same time. i'm late as usual. :/
-                                                                        [21:18]
-<willikins> https://bugs.gentoo.org/459692 "[Future EAPI] Provide a function,
-            like dodocs(),  to process DOCS= without calling `default`";
-            Gentoo Hosted Projects, PMS/EAPI; CONF; ssuominen:pms-bugs
-<scarabeus> ok if we have 2 and rest indiferent it is no
-<ulm> ssuominen: that's agenda topic 3
-<rich0> ulm: that link points to code, not a policy.  If you're asking whether
-        or not it should be retroactive, I say no for the stated reasons.
-<ssuominen> ulm: cool!
-*** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 264
-    seconds                                                             [21:19]
-* WilliamH votes no
-<ulm> scarabeus: not sure what your vote was?
-<ulm> so far I count 4 no votes, so it doesn't pass                     [21:20]
-<scarabeus> indiferent
-<ulm> thanks
-<ulm> next topic                                                        [21:21]
-<ulm> 3. einstalldocs() pre-approval for next EAPI
-<ulm> http://article.gmane.org/gmane.linux.gentoo.project/2978
-<ulm> http://thread.gmane.org/gmane.linux.gentoo.devel/87642/focus=87803
-<ulm> mgorny: are you here?
-<mgorny> yes
-<ulm> mgorny: can you shortly summarise it?                             [21:22]
-<mgorny> sure
-<mgorny> EAPI 4 default src_install() calls 'make install' and installs docs
-<mgorny> we'd like to split the doc-install part in EAPI 6 to a separate
-         function                                                       [21:23]
-<mgorny> it'd likely be called einstalldocs and fix most of the issues that
-         were pointed out
-*** pacho2 (~pacho@gentoo/developer/pacho) has joined channel #gentoo-council
-<mgorny> however, since a lot of eclasses reimplement that doc-install in
-         different ways already
-<mgorny> we'd like to also the same function to eutils.eclass for older EAPIs
-                                                                        [21:24]
-<mgorny> (and use that consistently in all eclasses)
-<mgorny> so I'd like the Council to vote on the code i presented that would go
-         into future EAPI 6, and into eutils.eclass
-*** pacho2 (~pacho@gentoo/developer/pacho) has quit: Quit: Leaving.
-<ulm> that's the code in the second link that I've posted above         [21:25]
-<blueness> mgorny, eutils.eclass would have intelligence to know if
-           eisntalldocs() is defined (ebcause of EAPI 6)?
-*** pacho2 (~pacho@gentoo/developer/pacho) has joined channel #gentoo-council
-<WilliamH> mgorny: why not just make it part of src_install for EAPI>=6 and
-           add it to utils.eclass for older eapis?
-<scarabeus> blueness: we already did it with something so yea we can do that
-*** pacho2 (~pacho@gentoo/developer/pacho) has quit: Read error: Connection
-    reset by peer
-<mgorny> blueness: we already have some backports like this, the functions are
-         inside 'if has $EAPI ...'
-<blueness> WilliamH, i think that's what he's saying so i just wanted to be
-           sure                                                         [21:26]
-<scarabeus> WilliamH: to clean up most of the using eclasses, otherwise you
-            would have to keep lots of stuff in eclasses
-<mgorny> WilliamH: that's what i said :)
-<scarabeus> this makes quite lot of sense so I like it
-<blueness> works for me, i'm for it
-<WilliamH> mgorny: Oh, I thought you said make it a separate function in eapi
-           6. ;-)
-<mgorny> yes, there will be a separate function
-<mgorny> so people could use it in eclasses without calling 'make install'
-<scarabeus> only one nitpick for the code as i read it now, you should detect
-            the default files and warn if you put them manually to the
-            array/list so we avoid duplication maybe?                   [21:27]
-<ulm> implementation looks sane, and it makes sense to add it to eutils now,
-      but preapprove the implementation for EAPI 6
-<mgorny> scarabeus: sounds out of scope of PMS IMO
-*** pacho2 (~pacho@gentoo/developer/pacho) has joined channel #gentoo-council
-<scarabeus> mgorny: yea, but for the feature implementation which you want to
-            put to eutils anyway... :P
-<mgorny> scarabeus: sure
-<scarabeus> and i said nitpick, not critical stopper                    [21:28]
-<ulm> I'd test for [[ ${#DOCS[@]} -gt 0 ]] not for [[ ${DOCS[@]} ]] but it's
-      probably a matter of taste                                        [21:29]
-<ulm> so also not a stopper
-<scarabeus> yea that is just taste ;-)
-<ulm> so, just vote?
-* blueness yes
-* ulm yes                                                               [21:30]
-<Calchan> yes
-<rich0> yes
-* WilliamH yes
-* scarabeus yes
-<ulm> unanimous
-* scarabeus throws cookie on mgorny ;-)
-<mgorny> thanks
-<ulm> yw :)
-<ulm> next topic
-<ulm> 4. Minor architectures stabilisation policy
-<ulm> http://article.gmane.org/gmane.linux.gentoo.project/2984
-<ulm> http://thread.gmane.org/gmane.linux.gentoo.devel/87741
-<ulm> hwoarang: here?                                                   [21:31]
-<dilfridge> /&%(/&%)/&%)(/&                                             [21:32]
-<blueness> i'm on many arch teams and imho, arch testing is a lot of work
-<dilfridge> sorry
-<blueness> lot of busywork
-<ulm> dilfridge: hello
-<Calchan> the question is very simple: why would we not do it?
-<blueness> so without the manpower, its hard to say if "stable" even means
-           anything with that low a level of manpower
-<blueness> also
-<scarabeus> yea most stable on exotic archs is now "compilation tested" which
-            beats me... is useless                                      [21:33]
-<blueness> mips is ~arch and yet hwoarang and mattst88 and I are doing a lot
-           with mips
-<rich0> blueness: agree - it just seems like keeping archs that can't keep up
-        just weighs down everybody else, and doesn't really do any service to
-        users of those archs.
-<blueness> i spent a whole month last summer trying to get ppc and ppc64 up to
-           date, and it nearly killed me and yet those are in "decent" shape
-<ulm> do we have statements from the respective arch teams?             [21:34]
-<WilliamH> I've had experiences in the past (not recent past) where arch teams
-           refuse to stabilize something unless users of that arch want the
-           newer version stable.
-<ulm> or is that only ago for all of them?
-<scarabeus> WilliamH: wich is also bad
-<Calchan> ulm: isn't the respective arch teams just ago?
-<rich0> ulm: I'm certainly interested in that - I believe I called for that in
-        -dev and didn't hear anything.
-<dilfridge> seems I arrived when the interesting stuff started
-<blueness> scarabeus, correct because then packages deps get out of sync
-<dilfridge> some arch team members commented                            [21:35]
-<dilfridge> but noone from s390 or m68k
-<dilfridge> which are the most critical points
-<Calchan> dilfridge: last I knew m68k was just vapier                   [21:36]
-<dilfridge> (at least according to the metrics provided by hwoarang (I
-            think)?)
-<scarabeus> yea it is just mike afaik
-<dilfridge> well even if it is just mike, he didnt comment
-<Calchan> and you're going to have a hard time interesting him in
-          stabilizations                                                [21:37]
-<blueness> my only concern with minor arches is embedded systems, so maybe
-           m68k is used in embedded
-<scarabeus> blueness: still we have testing
-<blueness> but its just a question of what we mean by "stable"
-<scarabeus> and if there are not enough people to stable it, then...
-<blueness> scarabeus, right
-<scarabeus> i am all in favor of puting all of them to testing-only unless 4
-            people team is behind them                                  [21:38]
-<Calchan> I'm going back to my question above:
-<Calchan> 19:32 < Calchan> the question is very simple: why would we not do
-          it?
-<Calchan> any reasons?
-<ssuominen> armin76 just blogged on planet.gentoo.org howto use m68k emulator
-            as a arch build host and about stage3's for m68k for the purpose
-<blueness> Calchan, that's hard to answer because we don't know what the user
-           base is
-<ulm> alpha and sparc are still supported by security
-<dilfridge> not do what?
-<ulm> at least that's what
-      http://www.gentoo.org/security/en/vulnerability-policy.xml says
-<rich0> scarabeus: I don't care how many are in the team - just that they keep
-        up.  If users of some arch hire a full-time dev to stabilize things,
-        more power to them.
-<Calchan> blueness: true and not true at the same time, this kind of
-          stabilization work doesn't bring any value                    [21:39]
-<scarabeus> rich0: but it must not end like ago doing everything, he will
-            eventually burn out...
-<blueness> yes he will
-<dilfridge> at some point for sure
-<blueness> i'm surprised he hasn't yet
-<blueness> i've also wondered if we can't automate stabilizations       [21:40]
-<blueness> ie create a tinderbox with a stabilization queue
-<scarabeus> thats different topic
-* dilfridge spent a negligible time as amd64 arch tester and felt the pain
-  quickly
-<blueness> scarabeus, true
-<dilfridge> yes but that is only good for build testing
-<blueness> call the question?
-<scarabeus> so should we vote to kill them and announce it and see the
-            opposition that it rises to revisit it?
-<dilfridge> I still believe that stable testing should be more          [21:41]
-<rich0> in any case, I agree with scarabeus - I'm inclined to yank them all
-        since nobody really has committed to doing anything to keep them
-        going.
-<Calchan> scarabeus: who's talking about "killing" them?
-<ulm> so, do we vote on it?
-<scarabeus> marking them testing
-<dilfridge> how about, yank m68k and s390 stable and give the others warning?
-<blueness> nah
-<blueness> yank em all
-<Calchan> scarabeus: that's the kind of wording which will indeed rais trouble
-<dilfridge> blueness: it's hard to reverse                              [21:42]
-<WilliamH> s/yank/mark testing/
-<ulm> drop to testing
-* scarabeus agrees
-<Calchan> yes, mark them testing
-* blueness yes
-<WilliamH> yes
-<dilfridge> mark testing = "no stable keyword"
-<WilliamH> which arch's though?
-<ulm> let's vote on them separately?                                    [21:43]
-<dilfridge> ?
-<rich0> let's be clear on which ones.
-<ssuominen> why not leave them be and just change wording/policy to not list
-            those arch's officially supported.  the road from ~ to stable
-            after testing they build/work on m68k and others has been long, so
-            reverting that should not be taken lightly...
-<blueness> s390 sh ia64 alpha m68k sparc
-<dilfridge> separate votes
-<ulm> yeah
-<ulm> in alphabetical order ;)
-<ulm> alpha: no more stable keyword?                                    [21:44]
-* scarabeus yes
-* blueness yes
-<dilfridge> guys please be careful, we're about to do something irreversible
-* dilfridge no
-<WilliamH> yes
-* ulm abstains
-* WilliamH withdraws...
-<scarabeus> dilfridge: it is revetable quite easily; you can later on pick
-            them up
-<rich0> yes
-<WilliamH> folks, I want a way to do something as a maintainer...       [21:45]
-<Calchan> yes
-<ssuominen> easily? not
-<WilliamH> dilfridge: how is this irreversable?
-<scarabeus> it is if you do scrapper for deleted ebuilds too and just parse
-            max subset of keywords and put them back as it compiles, and if
-            you want to get stable arch you have to test it, not just stamp
-            back what it had                                            [21:46]
-<ulm> WilliamH: it's hard to get an arch back into consistent state
-<dilfridge> versions will progress after the stable keywords have been
-            removed, everything will have to be retested to get a functioning
-            deptree
-<ulm> once you start dropping keywords
-<ulm> dilfridge: exactly
-<Calchan> btw, has anybody tried to get feedback form users on this? not just
-          devs?
-<dilfridge> it helps if you use an arch where compiling is fast :D      [21:47]
-<dilfridge> Calchan: would you like to adopt the gentoostats project?
-<WilliamH> AS a maintainer, I would like a policy like this:
-<Calchan> dilfridge: what's your point?
-<WilliamH> if I have a stable request for a new version of a package and it
-           has been open for 30-60 days or so and minor arch's do not respond
-           or have any blockers on my stablereq,                        [21:48]
-<dilfridge> knowing how many people really use an arch... we have e.g. ppc64
-            keywords on whole kde and I know of one user
-<WilliamH> then I want to remove  the older versions.
-<ulm> looks like the topic needs more discussion                        [21:49]
-<rich0> I don't really care how many users there are - only how
-        well-maintained the stable keywords are.
-<dilfridge> WilliamH: good point.
-<ulm> as we've envisaged another meeting for this month anyway
-<dilfridge> WilliamH: full agreement
-<ulm> how about postponing the vote by a week?
-<ssuominen> It's not just kids in basement -users, but actual production ...
-<rich0> Should we vote on deferral vs immediate resolution?
-*** jcallen (~quassel@gentoo/developer/jcallen) has joined channel
-    #gentoo-council
-<blueness> dilfridge, if we can't maintain a stable set of stabilized ebuilds,
-           we're worse off then dropping to testing
-<ulm> and discuss in the mailing lists
-<blueness> let's table it
-<dilfridge> well
-<scarabeus> ssuominen: so they can give back some resources or do something
-            against it otherwise it is tough luck                       [21:50]
-<dilfridge> ulm: it was already discussed
-* WilliamH agrees with blueness
-<rich0> personally I would rather not table.
-<dilfridge> ulm: but that's why I suggested "giving warning" for some arches,
-            i.e. next month we drop if nothing changes
-<Calchan> it looks lie we don't have a clear view of the actual impact of
-          dropping those to ~arch, so it is clearly premature to vote on this
-<rich0> however, up to the majority - I suspect that nothing will happen if we
-        table beyond two more weeks going by
-<ulm> ok                                                                [21:51]
-<WilliamH> we shouldn't table for long.
-<ulm> please vote: defer the decision to next meeting
-<rich0> no
-* blueness yes
-* dilfridge no
-<ulm> which likely will be in september
-<scarabeus> no
-* ulm yes
-* WilliamH yes as long as it is this month.
-<Calchan> yes to defering the vote to when we get enough informaiton to mak
-          ethe decision                                                 [21:52]
-<WilliamH> This should not go on forever.
-<ulm> I count 4 yes and 3 no
-<dilfridge> Calchan: that's as good as saying "never"
-<rich0> forever = infinity times two weeks.  :)
-<ulm> so, vote will be in next meeting
-<rich0> agree
-<dilfridge> which means the alpha decision is scrapped?
-<blueness> k
-<ulm> next topic                                                        [21:53]
-<Calchan> dilfridge: no, no reply to a request for information is information
-<ulm> 5. Specification of /var/db/pkg contents
-<ulm> http://article.gmane.org/gmane.linux.gentoo.project/2995
-<rich0> Calchan: that is a data point we already have then.
-<ulm> https://bugs.gentoo.org/show_bug.cgi?id=458866
-<ulm> blueness: your topic
-<blueness> thanks
-<blueness> so this came up because i wrote a utility called revdep-pax
-<dilfridge> Calchan: if no arch team member replies to the discussion on the
-            dev ml, that means it's already dead
-<Calchan> rich0: I'd disagree, to me it look slike no reasonable attempt at
-          contacting users has been made
-<Calchan> and that's users we're interested in here, not devs           [21:54]
-<blueness> i needs a complete linkage map (ie what exes link against what
-           libraries) of the whole system
-<rich0> Calchan: speak for yourself, unless we're talking about users who want
-        to be devs.  :)
-<blueness> this information is constructed by portage and saved in
-           /var/db/pkgs in NEEDED.ELF.2
-<rich0> Caring about users won't help them - only fixing keywords.
-<blueness> one can re-generate that info on the fly but it is very very long
-                                                                        [21:55]
-<blueness> there's lots of other utilities that can make use of NEEDED.ELF.2
-           info
-<Calchan> rich0: what I'm saying is we're speculating on the impact of a
-          decision when we should actually research it, I'm not siding one way
-          or the other
-<rich0> Calchan: we're off-topic
-<Calchan> no
-<blueness> and so we should probably expose the contents of  /var/db/pkgs to
-           other utilities that could use package info
-<dilfridge> rich0: Calchan: please continue later                       [21:56]
-<blueness> zac's comment says it all ->
-           https://bugs.gentoo.org/show_bug.cgi?id=458866#c18
-<dilfridge> ok
-<dilfridge> we have a couple of fundamental questions here
-<blueness> so we need a PMS requirement that /dev/db/pkg information be made
-           available to other usitilites that can use it
-<dilfridge> A) we should decide whether (generically) database information of
-            locally installed packages is within the scope of pms       [21:57]
-<blueness> the motion would be something like "document and add the contents
-           of /var/db/pkg specified to the PMS specs for interoperability
-           between utilities that need portage information"
-<rich0> blueness: I'd say that we need to provide NEEDED.ELF.2 info to
-        packages, not that we need to provide /var/db/pkg info.
-<rich0> The latter is one particular implementation of a PM, not a
-        specification.                                                  [21:58]
-<blueness> rich0, okay we can start with NEEDED.ELF.2
-<blueness> that is the critical body of information
-<dilfridge> because Ciaran claims this is not PMS business, and we can say yes
-            or no
-<rich0> Seems to me that what is needed is an API.
-<blueness> eg you want to ask a question like "what executables link against
-           this library" ... that's in NEEDED.ELF.2
-<ulm> blueness: I'd rather split it: 1. should we document /var/db/pkg, and 2.
-      should it be in the scope of PMS
-<blueness> in a rolling distro like gentoo, that info is critical       [21:59]
-<dilfridge> 0. should this be in pms at all?
-<blueness> dilfridge, yes
-<blueness> all package managers must provide this info for interoperability of
-           utilities
-<blueness> so the question does belong in pms, you might say no, but it does
-           belong here
-<rich0> I think that having a spec that is reasonable is fine - some kind of
-        API.  Call it PMS or not - that is just a title.
-<ulm> PMS should really be called "EAPI specification", because that's its
-      intent
-<dilfridge> hehe                                                        [22:00]
-<dilfridge> let's vote about renaming pms
-<ulm> not now ;)
-<dilfridge> the name is silly anyway
-<blueness> ulm, regarding the split: i'm mostly interested in NEEDED.ELF.2
-           info                                                         [22:01]
-<blueness> consider revdep-rebuild ... that takes forever because i
-           recalculates this mapping on the fly
-<blueness> the same can be done in seconds if NEEDED.ELF.2 info is read
-<blueness> emerge @preserve-libs uses it
-<dilfridge> ulm: but there is no connection between EAPI and database format,
-            so renaming it eapi-specs does not cover what we want to add now
-                                                                        [22:02]
-<blueness> so if we want to write other utilities outside of portage that need
-           the same info, we need to expose it in all package managers
-<ulm> dilfridge: yes, that's exactly the point
-<blueness> ulm, i would be happy with an abstraction layer to free up the db
-           formate
-* WilliamH thinks the database format would be a completely separate document
-                                                                        [22:03]
-<WilliamH> not pms
-* scarabeus dont care about what document to put it to, but it should be
-  documented and expected by all package managers and thats it
-<ulm> so, how about a first vote if we want the VDB documented at all?
-<blueness> ulm, the way you phrase it above pulls in too much           [22:04]
-<ulm> and a second vote if it should be part of PMS or a separate document
-      (e.g. a GLEP)
-<Calchan> ulm: is having the VDB documented in PMS the only possiblity?
-<blueness> can i try again?
-<Calchan> ah ok, sorry
-<rich0> blueness: ++  agree on abstraction layer
-<dilfridge> ulm: how about first a vote whether vdb information (independent
-            of format) should be documented?
-<dilfridge> (in pms)
-<ulm> dilfridge: or that
-<rich0> dilfridge: not so much documented, as made available
-<rich0> (in a documented manner)
-<dilfridge> yep
-<dilfridge> better
-<rich0> Ie, direct parsing of PM files isn't the interface
-<blueness> motion: all package managers should export NEEDED.ELF.2 information
-           for interoperability between utilities and portage
-<ulm> k                                                                 [22:05]
-<blueness> how does that sound?
-<dilfridge> blueness: like skipping ahead :)
-<blueness> i'm not that worried about documenting all of vdb            [22:06]
-<dilfridge> ok other suggestion
-<blueness> so i'd like the vote to concentrate on export NEEDED.ELF.2 info
-<rich0> Coulda, woulda, shoulda.  :)  We can certainly suggest intended
-        direction, but implementation will be up to the PMs to carry out.
-                                                                        [22:07]
-<blueness> rich0, exactly
-<dilfridge> vote on "Making VDB information (independent of database format
-            and package manager) available is within the scope of PMS"
-<blueness> i'll live with whatever makes the maintainer's life easy
-<blueness> dilfridge, no that is not the issue
-<blueness> as i said it pulls in too much, NEEDED.ELF.2 is the critical piece
-                                                                        [22:08]
-<dilfridge> blueness: I know that, but let's squash possible resistance
-            against the inclusion into specs first
-<blueness> it doesn't squash the resistance
-<dilfridge> anyway
-<rich0> Are the portage/whatever maintainers willing to implement some kind of
-        interface?  I'm fine with saying that the council encourages this, but
-        nothing will happen unless somebody is willing to do the work.
-<dilfridge> how about we vote on blueness motion?
-<blueness> rich0, zac is                                                [22:09]
-<blueness> and i'm okay with an intended direction without burdoning people
-<rich0> blueness: thanks - then I'm all for encouraging the creation of a
-        PM-neutral API for providing VDB info available to utilities.
-*** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 246
-    seconds
-*** jcallen (~quassel@gentoo/developer/jcallen) has joined channel
-    #gentoo-council
-<rich0> I think quite a bit of info is already available in APIs for both
-        portage and paludis - just without any standardization between them,
-        and I can't speak to NEEDED.ELF.2 in particular.                [22:10]
-<blueness> rich0, should it be all of VDB or just NEEDED.ELF.2, we can always
-           revisit other vdb elements
-<blueness> rich0, let's stick to my motion first and then see if there are
-           other vdb elements that need exposure
-<rich0> Suggest that we let the PM teams cooperate and expose what they can.
-        agree to start with that one field.                             [22:11]
-<ulm> how about this: "the council recommends that package managers export
-      information NEEDED.ELF.2 information for interoperability between
-      utilities"
-<blueness> rich0, sure
-<rich0> Would love to see a well-documented PM-neutral API for this stuff.
-<ulm> oops
-<blueness> ulm, works for me
-<ulm> "the council recommends that package managers export the NEEDED.ELF.2
-      information for interoperability between utilities"
-<blueness> rich0, so would i but that's a lot of work!
-<ulm> blueness: vote on this?
-<blueness> ulm, okay i accept that as a friendly amendment let's vote
-* blueness yes                                                          [22:12]
-* dilfridge yes
-<Calchan> can I votre "meh"?
-<Calchan> s/votre/vote/
-<dilfridge> (but I think it it's too soft a statement)
-<ulm> well, it would be easier if there was a draft spec already        [22:13]
-<rich0> yes
-<ulm> like a GLEP
-<rich0> ulm: agree that really it needs a spec - this is more about
-        intent/direction
-<dilfridge> ok let's finish the vote
-<WilliamH> yes
-<rich0> but we're not going to bikeshed a spec on irc here
-* ulm yes
-* scarabeus yes                                                         [22:14]
-<scarabeus> rich0: but we could try!
-<ulm> Calchan: "meh" is an abstention? ;)
-<scarabeus> the fact nobody ever done that should not stop us :D
-<rich0> scarabeus: you can try - I have someplace to leave for in 5min :)
-* WilliamH doesn't think it is up to us to come up with the spec
-<Calchan> ulm: take it as what you want, but meh it is
-<ulm> anyway, 6 yes votes
-<ulm> so it's accepted                                                  [22:15]
-<blueness> the intention could be fulfilled by a glep
-<blueness> yippy!
-<ulm> blueness: anything else on this topic?
-<blueness> ulm, no just that i like the idea of a glep here but that's beyond
-           us
-<ulm> otherwise, it's 20:15 UTC                                         [22:16]
-<blueness> call it a meeting and continue next time?
-<ulm> so I suggest that we proceed to open floor here and move the rest of
-      topics to another meeting
-<scarabeus> ok
-<rich0> agree - I have to take off in any case
-<dilfridge> yes, open floor now, next week another meeting              [22:17]
-<ulm> everyone o.k. with next tuesday, same time?
-<WilliamH> fine with me
-<rich0> wfm
-<blueness> works for me
-*** jcallen (~quassel@gentoo/developer/jcallen) has quit: Ping timeout: 264
-    seconds
-<dilfridge> wfm
-* blueness must feed my dog!  brb
-*** jcallen (~quassel@gentoo/developer/jcallen) has joined channel
-    #gentoo-council
-*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
-    "Next meeting: 17 Sep 2013 at 19:00 UTC |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 |
-    http://www.gentoo.org/proj/en/council/"
-<ulm> so, open floor                                                    [22:18]
-* ulm listens
-<ulm> nothing, it seems                                                 [22:19]
-<ulm> so let's close the meeting here                                   [22:20]
-<ulm> thank you everybody
-<scarabeus> thank you for chairing
-<rich0> ulm: thanks :)
-<ulm> ah
-<ulm> everyone o.k. with me chairing in one week?
-<dilfridge> sure
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130917-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20130917-summary.txt
deleted file mode 100644
index 786b65213b..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130917-summary.txt
+++ /dev/null
@@ -1,99 +0,0 @@
-Summary of Gentoo council meeting 17 September 2013
-
-Agenda
-======
-1. Introduction and roll call
-
-2. Minor architectures stabilisation policy [1,2]
-   continued from 2013-09-10 meeting
-
-3. GLEP draft "Prefix with libc" [3,4,5] - heroxbd
-
-4. Drop support for separate /usr partition [6] - williamh
-
-5. Open bugs with council involvement
-
-
-Roll call
-=========
-Present: blueness, dilfridge, rich0, scarabeus, ulm, williamh
-Absent: dberkholz
-
-Minor architectures stabilisation policy
-========================================
-Discussion from last week's meeting was continued. Options considered
-were a) to drop all ebuilds to an unstable keyword and b) the
-following proposal of rich0, hereinafter called "package-by-package":
-
-  "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
-  pending STABLEREQ, for 90 days with archs CCed and otherwise ready
-  to be stabilized, the maintainer can remove older stable versions of
-  the package at their discretion. A package is considered ready to be
-  stabilized if it has been in the tree for 30 days, and has no known
-  major flaws on arches that upstream considers supported."
-
-It was agreed that there should be a separate vote for each
-architecture in question.
-
-* m68k
-  Vote: Drop all ebuilds to unstable keyword.
-  - Accepted unanimously.
-
-* s390
-  Vote: Drop all ebuilds to unstable keyword.
-  - Accepted unanimously.
-
-* sh
-  Vote: Drop all ebuilds to unstable keyword.
-  - Accepted with 5 yes votes and 1 no vote.
-
-* ia64
-  Vote: Action is required for this architecture.
-  - Accepted with 3 yes votes, 2 no votes, and 1 abstention.
-  Vote: Drop to unstable globally, or package-by-package.
-  - Package-by-package proposal accepted unanimously.
-
-* sparc
-  Vote: Action is required for this architecture.
-  - Rejected, tie vote (3 yes votes, 3 no votes).
-
-* alpha
-  Vote: Action is required for this architecture.
-  - Accepted with 4 yes votes, 1 no vote, and 1 abstention.
-  Vote: Drop to unstable globally, or package-by-package.
-  - Package-by-package proposal accepted unanimously.
-
-In summary:
-- m68k, s390, sh: will be dropped to unstable keywords globally.
-- alpha, ia64: Maintainers can remove older stable versions according
-  to the "package-by-package" proposal.
-- sparc: No action.
-
-GLEP draft "Prefix with libc"
-=============================
-* GLEP draft
-  After a short discussion, the following vote was taken:
-  "The council endorses the GLEP draft for RAP and encourages its
-  further refinement (including inside the portage tree if helpful).
-  The council looks forward to the final draft for eventual approval."
-  - Accepted unanimously.
-
-* Reinitiation of a GLEP team and recovery of the GLEP process.
-  - Action: rich0 will put out a call for volunteers.
-
-[At this point, time had passed the one hour that was allocated for
-the meeting, and some council members had to leave. Therefore, agenda
-topics 4 and 5 were skipped and another meeting was scheduled for the
-following week.]
-
-Next meeting date
-=================
-24 September 2013, 19:00 UTC
-
-
-[1] http://article.gmane.org/gmane.linux.gentoo.project/2984
-[2] http://thread.gmane.org/gmane.linux.gentoo.devel/87741
-[3] http://article.gmane.org/gmane.linux.gentoo.project/3022
-[4] http://thread.gmane.org/gmane.linux.gentoo.devel/87466
-[5] http://git.heroxbd.z.tuna.tsinghua.edu.cn/?p=doc.git;a=blob;f=glep-gap.rst;hb=HEAD
-[6] http://thread.gmane.org/gmane.linux.gentoo.project/2946
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130917.txt b/xml/htdocs/proj/en/council/meeting-logs/20130917.txt
deleted file mode 100644
index c5332782fc..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130917.txt
+++ /dev/null
@@ -1,541 +0,0 @@
-<ulm> good afternoon/evening :)
-<ulm> Agenda is here:
-      http://article.gmane.org/gmane.linux.gentoo.devel.announce/1980
-<dilfridge> rich0: but it's stable! :D
-<ulm> roll call
-<rich0> of course
-<rich0> here
-<WilliamH> here
-<dilfridge> here
-<scarabeus> hi							        [21:01]
-<blueness> here
-<ulm> dberkholz?
-<blueness> let's start						        [21:02]
-<ulm> does anyone have his number and can call donnie?
-<blueness> nope							        [21:03]
-<dilfridge> I have it and you should all have it too, but maybe someone not
-	    roaming should try :D
-<ulm> someone in the u.s. preferably				        [21:04]
-<rich0> PM me and I can sms it
-<rich0> err, /msg
-<dilfridge> blueness is doing it already			        [21:05]
-<blueness> no answer
-<ulm> k
-<ulm> let's start then
-<ulm> 2. Minor architectures stabilisation policy		        [21:06]
-<ulm> (episode 2)
-<dilfridge> "The council strikes back"?
-<WilliamH> No one on the arch teams has stepped up, so
-<ulm> some last minute answers on the ml
-<WilliamH> I think we can drop stable keywords on those archs
-<dilfridge> WilliamH: not fully true, comments by jmorgan and matt
-<blueness> how?
-<ulm> ago has posted a bug count for alpha, ia64, sparc
-<WilliamH> ok							        [21:07]
-<scarabeus> ulm: he can't keep up forever honestly
-<rich0> I hear objections on the ml, but no plan to actually address the
-	problems.  I'm in favor of either droping entirely, or the compromise
-	I suggested which would let maintainers drop package-by-package after
-	90 days
-<TomWij> rich0: Yes, I agree regarding your 2c; we can't have users wanting to
-	 use a stabilized minor arch without enough users (incl. Gentoo Devs)
-	 able to keep that particular arch stable tested, after all users can
-	 become arch testers so we're not the ones to blame it. If it can't be
-	 done, it's not our fault that it is being dropped; but rather the
-	 lack of interest and perhaps even the lack of need.
-<TomWij> Step-by-step as well as releasing news could be nice efforts to find
-	 people whom are interested; as perhaps interested users currently
-	 might not notice the lack of interest, and not everyone actively
-	 visits the arch tester staffing needs Wiki page.
-<ulm> http://article.gmane.org/gmane.linux.gentoo.project/3034	        [21:08]
-<rich0> The package-by-package approach has the virtue of putting pressure on
-	the team to take action, but at the same time lowering their burden
-	over time.  They could just bunker down and focus on @system and at
-	least have someplace to move forward from if they get more help
-<ulm> it doesn't look so bad for these three arches
-<WilliamH> rich0: objections without a plan aren't much.
-<rich0> WilliamH: I said as much in my email - the plan is what matters.  I
-	suggest at least implementing the package-by-package approach.
-								        [21:09]
-<WilliamH> rich0: I could go for dropping stable keywords package-by-package.
-<dilfridge> ok now how do we proceed... one thing is clear, decisions now are
-	    per-arch always					        [21:10]
-<rich0> Maybe s390/m68k could be dropped entirely - I'm neutral on that
-<rich0> I think a general policy that allows maintainers to drop packages
-	after 90 days is a good approach.  That could apply across all archs,
-	even the major ones.
-<WilliamH> rich0: I could go for decisions per arch
-<rich0> Again, assuming no legitimate effort to resolve issues/etc.
-<blueness> why can't we just grep the tree, find all packages with stable
-	   keywords for, say m68k, and just drop them all to ~ in one commit
-								        [21:11]
-<blueness> too much work?
-<ulm> let's discuss it arch by arch
-<mgorny> rich0: just to be clear, 90 days after stablereq for the package or
-	 the first dependency that was stablereqed?
-<rich0> blueness: for something like m68k that might be worthwile.  For
-	something like alpha, maybe not quite necessary.
-<blueness> kk
-<ulm> begin with alpha
-*** toralf (~toralf@f054055169.adsl.alicedsl.de) has joined channel
-    #gentoo-council
-<dilfridge> ulm: how about begin with m68k?			        [21:12]
-<WilliamH> mgorny: 90 days after the arch was added to the stablereq.
-<dilfridge> (start with the most problematic case and work our way to the easy
-	    ones)
-<rich0> Honestly, I think the 90-day thing should apply universally.  Even to
-	x86/amd64.
-<ulm> dilfridge: yeah, we can do that
-<ulm> m68k then
-<WilliamH> rich0: I could go for that.				        [21:13]
-* dilfridge proposes dropping to ~m68k
-<WilliamH> rich0: I could go for a smaller window actually -- 60 days maybe?
-<blueness> yes drop everything to ~m68k in one shot
-* WilliamH seconds dilfridge's proposal
-<ulm> can we just vote on m68k then				        [21:14]
-* scarabeus agrees with dilfridge
-<scarabeus> WilliamH: nah that they are small is no excuse for delays, they
-	    can get more people (now amd64 is factically just ago :P)
-<ulm> drop everything to ~m68k? yes/no
-* dilfridge yes
-<WilliamH> yes
-* blueness yes
-* scarabeus yes
-<rich0> yes
-* ulm yes
-<ulm> unanimous
-<ulm> next: s390
-<rich0> drop it to ~s390					        [21:15]
-<blueness> smae
-<blueness> same
-* WilliamH yes
-* blueness yes
-* ulm yes
-* rich0 yes
-* dilfridge yes
-<ulm> blueness: that's a yes?
-<blueness> yes
-<ulm> unanimous
-<ulm> next: sh							        [21:16]
-<blueness> drop to ~sh
-<dilfridge> proposal, wait and folrmulate a proposal that maintinaers can drop
-* WilliamH yes
-* ulm yes
-* blueness yes
-<dilfridge> yes to what?
-<rich0> dilfridge: ++						        [21:17]
-<rich0> Honestly, for all the other archs I'd probably go package-by-package,
-	at least for now.
-<ulm> dilfridge: drop everything to ~sh
-<WilliamH> dilfridge: dropping sh to ~
-<ulm> ok, let's repeat
-<dilfridge> then,
-* dilfridge no
-<ulm> vote for "drop everything to ~sh"
-* blueness yes
-* dilfridge no
-* WilliamH yes							        [21:18]
-* rich0 yes
-<rich0> (lots of bugs, no reply on list)
-* ulm yes							        [21:19]
-<scarabeus> ok drop too
-<scarabeus> checked the queue and state so it took a lag :)
-<ulm> 5 yes votes, 1 no vote
-<ulm> motion passes
-<ulm> next: ia64
-<dilfridge> package-by-package, at least for now
-<ulm> 17 open stable bugs, not so bad				        [21:20]
-<dilfridge> or no action, wait and see
-<ulm> so not sure why we should drop it
-<hwoarang> ulm: because it is onlyu compile tested
-<scarabeus> ulm: only ago doing it, honestly that is not long term and he only
-	    compile-test
-<dilfridge> we can always later talk about a "maintainer drop policy"
-<hwoarang> and because only ago does it so if he goes MIA end of story
-<rich0> I wouldn't drop ia64 yet				        [21:21]
-<blueness> i have mixed feelings about ia64
-*** _AxS_ (~axs@gentoo/developer/axs) has joined channel #gentoo-council
-* WilliamH wants a maintainer drop policy for all archs
-<rich0> I think that there is more hope going package-by-package there.
-<rich0> WilliamH: ++
-<dilfridge> WilliamH: ++
-<hwoarang> i am sorry to repeat myself, but this arch is only compile tested.
-	   does it really qualify as a stable arch?
-<ulm> let's do a two step vote, first vote if any action is required for ia64,
-      and second vote if it'll be global or package by package
-<rich0> hwoarang: I think that is up to the needs of the arch - let them worry
-	about what stable means for them			        [21:22]
-<hwoarang> oook
-<dilfridge> ulm: how would you do "p by p"?
-<dilfridge> or what exactly do you mean by that?
-<ulm> dilfridge: as outlined above				        [21:23]
-<WilliamH> dilfridge: for any package with a stable request that has been
-	   assigned to the arch for 90 days, the maintainer can drop stable
-	   keywords for the package on that arch
-<dilfridge> ok
-<ulm> dilfridge: see rich0's e-mail
-<dilfridge> tbh that should be allowed for any arch...
-<rich0> dilfridge: ++
-<dilfridge> ulm: can we paste that for the log?
-<mgorny> is it the same if stablereq was filed for obligatory dep?
-<WilliamH> dilfridge: the problem is that it isn't currently so we are forced
-	   to keep old versions around
-<ulm> rich0: can you paste you p-to-p proposal?			        [21:24]
-<ulm> *p-by-p
-<dilfridge> mgorny: good point... maybe if the chain is pointed out in the
-	    stable req?
-<ulm> anyway, first vote: is any action required for ia64	        [21:25]
-* ulm no
-* dilfridge no
-* blueness abstains
-<rich0> any action?  yes					        [21:26]
-* WilliamH votes yes
-<WilliamH> The action will be covered if we approve the p-by-p policy for all
-	   archs
-* scarabeus yes
-<ulm> 3 yes votes, 2 no votes, 1 abstention			        [21:27]
-<ulm> passes
-<rich0> My proposal: If a maintainer has an open STABLEREQ, or a KEYWORDREQ
-	blocking a
-<rich0> pending STABLEREQ, for 90 days with archs CCed and otherwise ready to
-<rich0> be stabilized, the maintainer can remove older stable versions of the
-<rich0> package at their discretion.  A package is considered ready to be
-<rich0> stabilized if it has been in the tree for 30 days, and has no known
-<rich0> major flaws on arches that upstream considers supported.
-<scarabeus> basically i still agree with the compile-only-tested we used to
-	    have this page that said that stable is actually stable and you
-	    could trust it, we honestly can't ensure it if it is just some
-	    buildbot runnin'					        [21:28]
-<WilliamH> We don't need a separate vote for package-by-package for ia64 if we
-	   adopt it for all arch's.
-<WilliamH> That would also cover the ia64 "action".
-<scarabeus> rich0: who cleans up the rdeps?
-<dilfridge> rich0: one detail, I would add to the text:
-<ulm> second vote then, drop everything to ~ia64, or package-by-package
-<jmbsvicetto> rich0: you should at least include a note about the package not
-	      having any known issues on the arch
-* ulm package-by-package					        [21:29]
-<rich0> jmbsvicetto: That last bit covers no major flaws that upstream
-	considers supported.
-<dilfridge> rich0: ... and the arch team is not responding or no reason is
-	    given why it cannot be stabilized
-<jmbsvicetto> rich0: in the past some packages had new versions that didn't
-	      work on a specific arch for months
-<dilfridge> exactly
-<ulm> blueness sent me a msg that he abstains on ia64
-<scarabeus> jmbsvicetto: and upstream didn't care at all :-)
-<jmbsvicetto> rich0: except when upstream doesn't care a bit about non
-	      amd64/x86
-<rich0> I think we need to distinguish between doesn't work and is a work in
-	progress, and doesn't work and probably won't ever work.
-<scarabeus> come on maintainers are not assholes		        [21:30]
-<hwoarang> i think you over-engineer this
-<rich0> If upstream doesn't care about non-amd64/x86, then the arch team gets
-	to patch every release in 90 days or lose it.
-<scarabeus> if arch guy says i am working on it they wont drop
-<rich0> It shouldn't be on the maintainer to do that.
-<WilliamH> jmbsvicetto: in that case, shouldn't keywords be "-* amd64 x86"
-<scarabeus> but mostly it is nothing for 6 months until some other distro
-	    (debian) fix it
-<dilfridge> rich0: I'm fine if an arch team responds "sorry we cannot do this
-	    version, we'll try to do a future one where bugs for us are fixed"
-<dilfridge> rich0: I'm not fine with an arch team just not responding at all
-								        [21:31]
-<rich0> My issue is that it isn't enough to say that they're working on it.
-	They really need to make progress in a reasonable period of time.  The
-	maintainer always has discretion to wait longer.
-<ulm> rich0: ++
-<scarabeus> rich0: again up to maintianer discretion
-<blueness> back
-<blueness> (sorry)
-<jmbsvicetto> WilliamH: in some cases it might work - unless upstream
-	      purposely tries to break it on other arches
-<rich0> I see all of this as a balance between maintainers and arch teams.  If
-	they can work out their own compromise more power to them.
-<scarabeus> if you won't get the fix or replies about the progress just kill
-	    it
-* WilliamH agrees with scarabeus 				        [21:32]
-<WilliamH> All we are doing at this level is saying that maintainers have
-	   permission to demote packages to ~ when arch teams do not respond
-	   after 90 days on a stable request.			        [21:33]
-<rich0> It is nice that I want a stable KDE on GNU/hurd, but do maintainers
-	need to keep KDE-0.5 around for me to finish up on that?
-<ulm> rich0: any modifications on your p-by-p proposal, or can we vote on the
-      version posted above?
-<WilliamH> link please? I missed the link to the proposal
-<ulm> WilliamH: it's posted inline
-<scarabeus> WilliamH: he pasted it here; the full text :)
-<dilfridge> backlog
-<jmbsvicetto> rich0: you're ignoring option 4
-<jmbsvicetto> rich0: with option 4, maintainer stop having any responsability
-	      for the old versions				        [21:34]
-<rich0> jmbsvicetto: I thought about that a bit - if an arch team member wants
-	to co-maintain they should of course be willing to do so, and then
-	they're the maintainer
-<WilliamH> Yes, it would just be someone stepping up and taking a
-	   co-maintainer role.
-<ulm> rich0: that case won't happen
-<dilfridge> option 4 is not really sensible, also it messes up our definitions
-	    in metadata.xml
-<rich0> I agree.
-<rich0> I don't think it is very practical.  But, nothing really needs
-	adjustment.  If they actually step up and co-maintain, well, they're
-	the maintainer and can work out a compromise with themselves.
-								        [21:35]
-<jmbsvicetto> rich0: if all you the council wants is to address maintainers
-	      complains that they need to keep old versions around for some
-	      "slow arch", why not tell them that when they're ready to drop
-	      that version, they can just leave the keywords for the "slow
-	      arches" and "pass the baby" to the arch teams?
-<mgorny> rich0: one more question though since nobody seem to have understood
-	 my problem with deps
-<mgorny> rich0: let's assume foo-1 didn't have a dep on bar, foo-2 has on
-	 >=bar-2
-<rich0> A problem is though that metadata.xml doesn't really cover this -
-	they're going to get pestered over bugs			        [21:36]
-<mgorny> rich0: i filed stablereq for bar-2 and had no answer,  so i didn't
-	 even bother filing one of foo-2
-<mgorny> rich0: would that quality for dropping foo-1 from stable (it had no
-	 dep on bar)
-<blueness> i woudl think so mgorny
-<rich0> mgorny: good point - I had a discussion with pacho2 about that
-<dilfridge> I would think so yes, but it definitely would help to post in the
-	    stablerequ "this is urgently needed for ..."	        [21:37]
-<WilliamH> mgorny: are you the maintainer of both foo and bar?
-<mgorny> no, and it's just theoretical
-<ulm> mgorny: I'd say that you should file a stablereq for bar, just to make
-      things clear
-<TomWij> mgorny: Doesn't that depend on whether there is a reason to be
-	 dropping keywords on foo-1? eg. Security, ...
-<mgorny> supposedly foo-2 may happen even long after bar
-<mgorny> it is somehow related to python-exec which is a dep of all python
-	 packages
-<mgorny> if nobody bothered stabilizing it, every new python package in the
-	 tree can't go stable					        [21:38]
-<ulm> *sigh* can we proceed please?
-<mgorny> (it's not a case anymore)
-<ulm> still ia64
-<blueness> are we ready for the vote?
-* scarabeus is
-<dilfridge> how about voting aout the general rich0 proposal?	        [21:39]
-<dilfridge> arch independent?
-<rich0> dilfridge: ++
-<ulm> dilfridge: no
-<scarabeus> lets keep it arch by arch and then conver it
-<scarabeus> *convert it
-<blueness> um, not for amd64 and the other major arches, we were not mandated
-	   to do that
-<scarabeus> if desired
-<ulm> we started arch by arch, and we don't change procedure in the middle
-<dilfridge> ok
-<rich0> blueness: honestly, I'd just make the policy generic and apply it to
-	everybody
-<blueness> rich0, maybe but we didn't announce that
-<rich0> Then we don't have to argue about who are and aren't keeping up/etc.
-<rich0> blueness: fair enough					        [21:40]
-<ulm> vote for ia64: drop to ~ia64 globally, or package-by-package proposal of
-      rich0
-* scarabeus p-b-p
-* ulm p-by-p
-* dilfridge p-b-p
-* rich0 p-b-p
-* blueness p-b-p
-* WilliamH p-by-p
-<ulm> unanimously package-by-package
-<ulm> next: sparc						        [21:41]
-<ulm> please vote: action required?
-* ulm no
-* scarabeus aye
-* dilfridge no
-* blueness no
-* rich0 yes
-* scarabeus hopes he won't say yes :P				        [21:42]
-<scarabeus> tie sucks
-<ulm> WilliamH?
-* WilliamH votes yes
-<ulm> 3 yes votes, 3 no votes
-<ulm> tie, so motion doesn't pass
-<ulm> finally, alpha						        [21:43]
-<ulm> please vote: action required?
-* ulm no
-<blueness> yes
-* dilfridge abstains
-* rich0 yes
-* scarabeus yes							        [21:44]
-* WilliamH yes
-<ulm> 4 yes votes, 1 no vote, 1 abstention
-<ulm> passes
-<ulm> vote for alpha: drop to ~alpha globally, or package-by-package?
-* rich0 p-b-p
-* ulm p-by-p							        [21:45]
-* dilfridge p-b-p
-* scarabeus p-b-p
-* WilliamH p-b-p
-* blueness p-b-p
-<ulm> unanimous
-<ulm> so to summarise:
-<ulm> m68k, s390, sh will be dropped to testing globally
-<ulm> alpha and ia64 package-by-package proposal		        [21:46]
-<ulm> no action for sparc
-<scarabeus> ok
-<blueness> nice
-<ulm> are we done with the topic?
-* dilfridge likes
-* dilfridge thinks so						        [21:47]
-<rich0> for now.  :)
-<ulm> next topic
-<ulm> 3. GLEP draft "Prefix with libc"
-<ulm> this has two parts, actually
-<ulm> get the GLEP team working again, and the GLEP draft
-<ulm> let's start with the draft				        [21:48]
-<WilliamH> Wouldn't the glep team handle the glep draft? ;-)
-<ulm> WilliamH: heroxbd didn't get any answer from them for several weeks
-<rich0> I think the issue is that there is no GLEP team.  :)  effectively...
-* dilfridge is wondering where that alias ends up		        [21:49]
-<rich0> I think it needs a little work - in particular the rationale which
-	seems redundant with the motivation and not a defense of the
-	specification which was the intent of the GLEP process
-<creffett> do we need people to step up for the GLEP team?
-<blueness> we should email -dev
-<ulm> creffett: probably					        [21:50]
-<ulm> but we come to this in a minute
-<ulm> let's discuss the draft first
-<dilfridge> in general I like the idea very much
-<ulm> me too, but I'd like to see a comment from the prefix team        [21:51]
-<rich0> Agree with the concept.  Would love to try it out - the docs need a
-	bit of work.  Anybody involved in this besides heroxbd?
-<dilfridge> whatever makes a prefix easier to build and closer to a "vanilla
-	    gentoo" is good
-<blueness> dilfridge, ++					        [21:52]
-<rich0> Yup - ancient glibc is a big problem with prefix - when I tried it out
-	on Solaries it caused tons of issues.
-<dilfridge> well heroxbd is in the prefix team
-<dilfridge> I think
-<ulm> right, he is						        [21:53]
-<rich0> Perhaps we should endorse without necessarily approving to allow it to
-	be further developed.  I see no reason to keep it out of the main tree
-	though.  I think the only question I'd have is if it is final enough
-	to be worth writing in stone yet.
-<ulm> rich0: sounds good					        [21:54]
-<WilliamH> rich0: that sounds reasonable to me
-<ulm> do we need a formal vote on this?
-* scarabeus would leave this to prefix team to play honestly, and lets
-  finalise it when glep team is alive and we have something to write properly
-  that it is working
-<scarabeus> so what rich0 said... :-)
-<rich0> I think a formal endorsement would be good
-<WilliamH> scarabeus: right.
-<WilliamH> We aren't being asked to approve this as final...
-<rich0> This is good work.
-<blueness> yeah let's vote on this
-<ulm> so please vote						        [21:55]
-<rich0> How about:
-<ulm> rich0: go ahead
-<dilfridge> on what?
-<rich0> "The council endorses the GLEP draft for RAP and encourages its
-	further refinement (including inside the portage tree if helpful).
-	The council looks forward to the final draft for eventual approval."
-								        [21:56]
-<blueness> good
-<ulm> k
-* WilliamH yes
-* dilfridge yes
-<ulm> please vote on this ^^
-* blueness yes
-* rich0 yes
-* ulm yes
-* scarabeus yes
-<ulm> unanimous
-<ulm> second request from heroxbd was: "I'd like to ask the council to
-      reinitiate a GLEP team and recover our GLEP process"	        [21:57]
-* dilfridge pulls a glep team out of the magic hat
-<rich0> Suggest putting out a call for volunteers there.
-<ulm> any suggestions what the council can do about this?
-<WilliamH> just put out a call for volunteers...		        [21:58]
-<scarabeus> no idea what we can do
-<WilliamH> That's really the most we can do I think.
-<rich0> I might send him some suggestions if nothing else.
-<scarabeus> ie i can't volunteer, we need somebody to lead it and recruit more
-	    people
-<rich0> Let's see what a call does.  I wouldn't call that "done" but it is a
-	first step.
-<dilfridge> right now glep@g.o forwards to dev-zero ...
-<WilliamH> We should find out what his status is...		        [21:59]
-<ulm> dilfridge: antarus is on the glep team, too
-<rich0> The GLEP team makes our job easier, so we should try to make it robust
-	if we can.
-<dilfridge> that may be the case but he doesn't get the mail
-<blueness> is there anyone on the glep team now?
-<blueness> gleps seem to be fading
-<ulm> blueness: antarus and dev-zero
-<rich0> nobody really bothers with GLEPs - they just do stuff.  :)      [22:00]
-<blueness> dev-zero is usually too busy
-*** mrueg (~mrueg@gentoo/developer/mrueg) has joined channel #gentoo-council
-<scarabeus> technical savy guys should go there; mgorny, ssuominen, somebody
-	    like that if they have time...
-<rich0> Or just make specific proposals in non-GLEP format.  PMS has
-	superseded it to a degree.
-<ulm> so, I note as action that we put out a call for volunteers?
-<dilfridge> yes
-<ulm> who will take care of it?
-<blueness> rich0, well i'm thinking of writing a glep for the vdb stuff
-<WilliamH> We need to see if the people on the team still want to be there
-	   too.							        [22:01]
-<WilliamH> That would be antarus and dev-zero
-<WilliamH> from the project page
-<rich0> ulm: fyi - we're at 1hr and unfortunately I need to leave fairly soon.
-	This might be a record-setting meeting  :)		        [22:02]
-<blueness> me too
-<ulm> well, we still need soneone to take care of the call for volunteers
-<rich0> ulm: I'll volunteer to seek volunteers  :		        [22:03]
-<ulm> rich0: k
-<ulm> so, should we stop here again?
-<dilfridge> I hope you're not proposing to continue next week? :D       [22:04]
-<ulm> WilliamH's topic would suffer from it
-<blueness> ulm, yes please
-<scarabeus> WilliamH: sorry for making your life hell
-<WilliamH> heh
-<blueness> WilliamH, sorry but i really have to go in about 5 mins
-<WilliamH> I think my topic will be pretty quick...
-<rich0>  same bat-time, same bat-channel?
-<rich0> WilliamH: likely anything but.  :)			        [22:05]
-<WilliamH> next week is fine for me.
-<blueness> WilliamH, this will not be quick
-<ulm> so next week?
-* blueness yes
-* rich0 yes
-* dilfridge yes, pending Alitalia behaviour
-<rich0> WilliamH: suggest you feel free to put out feelers via email or list
-	if you want to prepare the ground
-*** Hello71 (Hello71@wikipedia/Hello71) has joined channel #gentoo-council
-								        [22:06]
-<scarabeus> ok
-*** redlizard (~redlizard@168-9-ftth.onsnetstudenten.nl) has joined channel
-    #gentoo-council
-<ulm> next meeting: 2013-09-24 19:00 UTC
-<blueness> i'm out of here guys, sorry to run
-<rich0> we're earning our pay this month.
-*** dilfridge (~quassel@gentoo/developer/dilfridge) has set the topic for
-    #gentoo-council: "Next weekly meeting: 24 Sep 2013 at 19:00 UTC |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | Agenda:
-    http://article.gmane.org/gmane.linux.gentoo.devel.announce/1980 |
-    http://www.gentoo.org/proj/en/council/"
-<rich0> can we vote on a 20% raise?				        [22:07]
-<WilliamH> rich0: heh
-<ulm> someone thinks that he'll be quicker with chairing then me? ;)
-<dilfridge> won't help you much, 20% of zero is still zero :D
-<scarabeus> i demand fosdem beer!
-<scarabeus> :D
-<dilfridge> ulm: I can do it
-<rich0> seriously though - this is all good stuff and we're making progress
-<ulm> dilfridge: pending alitalia?
-<rich0> not much fluff on the agenda
-<dilfridge> flying from italy to muc next tuesday		        [22:08]
-<dilfridge> if all goes well I should arrive in time
-<ulm> dilfridge: ok, you take the chair then
-<dilfridge> will do
-<ulm> with me as a backup
-<ulm> dilfridge: who sends the agenda?
-<dilfridge> will do						        [22:09]
-<ulm> thanks
-<ulm> meeting is closed then
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130924-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20130924-summary.txt
deleted file mode 100644
index b8f4d65b1a..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130924-summary.txt
+++ /dev/null
@@ -1,79 +0,0 @@
-Summary of Gentoo council meeting 24 September 2013
-
-Agenda
-======
-1. Introduction and roll call
-2. Drop support for separate /usr partition [1] - williamh
-3. Open bugs with council involvement
-
-
-Roll call
-=========
-Present:
-   blueness
-   dberkholz
-   creffett (proxy for dilfridge)
-   rich0
-   scarabeus
-   ulm
-   williamh
-
-Drop support for separate /usr partition
-========================================
-Following the decision in the 20130813 meeting, williamh asked the
-council to agree that the preparations for early boot mechanisms are
-complete and that the necessary documentation is in place. In the
-following discussion it was noted that documentation for NFS mounted
-/usr was still missing (bug 481660). According to williamh, this
-should just work, without any need for separate documentation. Some
-council members expressed their concern that separate /usr support
-shouldn't be removed proactively. The overall opinion on this was that
-the base-system team should be trusted to do the right thing. It was
-agreed that a news item should be sent, followed by a reasonable
-transition time for users.
-
-Vote:
-- "The Council agrees that all preparations for dropping support for
-  separate /usr without an initramfs or similar boot mechanism are
-  complete. A news item will be prepared, and users will be given one
-  month to switch after the news item has been sent."
-  Accepted with 5 yes votes, 1 no vote, 1 abstention.
-
-Action:
-- Prepare the news item (williamh).
-
-Open bugs with council involvement
-==================================
-- Bug 481202 "Tracker - Documentation or implementation issues for
-  dropping of separate /usr support" [2]
-  No action, but leave the bug open as a tracker.
-
-- Bug 477030 "Missing summary for 20130611 council meeting" [3]
-  No progress since last meeting.
-
-- Bug 457000 "Missing log and summary for previous council
-  meetings" [4]
-  Action: Add log and summary for the 20080515 meeting (ulm).
-
-- Bug 480408 "Add /releases/${arch}/verified tree for tested
-  autobuilds" [5]
-  Already discussed in August meeting, council can be removed from CC.
-
-- Bug 485448 "Migrate council project page to the wiki" [6]
-  Migration to the wiki was welcomed by council members. It was noted
-  by dberkholz that the wiki in general could profit from a better
-  skin. Also the list of meeting logs should be folded by default, or
-  moved to a subpage.
-  Action: Complete the migration, redirect old project pages (ulm).
-
-Next meeting date
-=================
-8 October 2013, 19:00 UTC
-
-
-[1] http://thread.gmane.org/gmane.linux.gentoo.project/2946
-[2] https://bugs.gentoo.org/show_bug.cgi?id=481202
-[3] https://bugs.gentoo.org/show_bug.cgi?id=477030
-[4] https://bugs.gentoo.org/show_bug.cgi?id=457000
-[5] https://bugs.gentoo.org/show_bug.cgi?id=480408
-[6] https://bugs.gentoo.org/show_bug.cgi?id=485448
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20130924.txt b/xml/htdocs/proj/en/council/meeting-logs/20130924.txt
deleted file mode 100644
index f26b930d84..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20130924.txt
+++ /dev/null
@@ -1,412 +0,0 @@
-<ulm> let's start                                                       [21:00]
-<ulm> roll call
-* scarabeus here
-* rich0 here
-<creffett> here, proxying for dilfridge
-<scarabeus> creffett: but you are uglier than him! you can't! ;-)       [21:01]
-* WilliamH here                                                         [21:02]
-<ulm> blueness: dberkholz:
-<dberkholz> hi
-* blueness here
-<ulm> k
-<ulm> first topic: separate /usr                                        [21:03]
-<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/2946
-<ulm> WilliamH: can you summarise?
-<dberkholz> btw seems that i'm the only person using the google calendar for
-            meetings.                                                   [21:04]
-<WilliamH> ulm: is that the same link as
-           http://comments.gmane.org/gmane.linux.gentoo.project/2946
-<WilliamH> s/link/thread/
-<ulm> dberkholz: hm, should we add such extra meetings?
-<ulm> dberkholz: just remind the chairman then                          [21:05]
-<dberkholz> ulm: i have a ridiculous schedule so i'd actually forgotten this
-            was scheduled for today till i got pinged
-<ulm> WilliamH: yeah, same posting
-<blueness> WilliamH, there is still no documentation for separate NFS mounted
-           /usr
-<WilliamH> The thread I just linked is the original thread where I brought
-           this back up.. Basically we were looking for issues that would
-           block us from going forward and saying that
-<WilliamH> we are ready to drop support for separate /usr without an
-           initramfs.
-<ulm> blueness: that's bug 481660?                                      [21:06]
-<willikins> ulm: https://bugs.gentoo.org/481660 "Documentation for an early
-            boot mechamism with a separate NFS mounted /usr is lacking";
-            Gentoo Linux, Unspecified; CONF; blueness:base-system
-<blueness> yep
-<WilliamH> blueness: the position seemed to be that there is no need for
-           separate documentation.
-<WilliamH> blueness: for nfs.
-<blueness> why?
-<blueness> does it just work?
-<WilliamH> blueness: I don't use nfs, but that was my understanding, it should
-           just work (tm)                                               [21:07]
-<WilliamH> blueness: it depends of course on what is in the initramfs, but
-           iirc genkernel supports it.                                  [21:08]
-<ulm> WilliamH: from some of your previous posts I had the impression that you
-      intend to remove separate /usr support proactively
-<rich0> That seemed to be the consensus - I didn't get a chance to test it
-        personally, but that wouldn't take long to confirm one way or another.
-<ulm> WilliamH: like removing gen_usr_ldscript from ebuilds
-<ulm> WilliamH: and I'm a bit worried about it
-<blueness> me too                                                       [21:09]
-<ulm> WilliamH: so is this going to happen if we vote yes today?
-<WilliamH> ulm: that is really a separate topic... mainly it should probably
-           be discussed among base-system and toolchain...              [21:10]
-<WilliamH> ulm: that is where most of the gen_usr_ldscript stuff is being
-           done.
-<blueness> WilliamH, it is not a separate topic, c'mon!                 [21:11]
-<ulm> well, if we vote in favour of dropping support, we'll give base-system a
-      carte blanche
-<_AxS_> blueness: for genkernel initramfs, yes it just works.           [21:12]
-<WilliamH> We have already stated our intent to drop support eventually.
-<blueness> _AxS_, thanks
-<scarabeus> i am in favor letting them doing what they feel fit, if most stuff
-            work, there always be something cornery
-<ulm> WilliamH: right, but from discussion in the august meeting my impression
-      was that maintainers shouldn't remove existing support without a good
-      reason                                                            [21:13]
-<rich0> There will never be a "good time" for this.  My personal sense is that
-        if we feel there are other things that need to be done to be ready we
-        should identify them.  If it is just a matter of waiting to give
-        people some time to setup initramfs/etc I could understand that, but I
-        do want to avoid delay simply to avoid the unpleasant.
-<WilliamH> ulm: the thing is, all it takes is one maintainer having a "good
-           reason" to remove support.                                   [21:14]
-<blueness> scarabeus, ulm yeah but i'm worried about more mariginal systems
-           like the uclibc systems i work on, i need to know what removing
-           gen_usr_ldscript would do there
-* WilliamH agrees with rich0
-<rich0> I'm also speaking generally, and not about things like
-        gen_usr_ldscript in particular which need to be looked at beyond their
-        impact to needing an initramfs and so on.
-<WilliamH> If there are specific reasons we aren't ready we should fix them.
-<rich0> However, I think the base-system team could be trusted to do that, as
-        with any other detailed change.                                 [21:15]
-<ulm> WilliamH: please remind me, did we push a news item for this already?
-<WilliamH> ulm: No, but we can't without a yes vote that says we are ready to
-           do so.
-<rich0> I don't think we had a news item, and it probably wouldn't hurt to
-        have one.  A news item and a delay for implementation would make more
-        sense than just waiting.
-<creffett> I have one other concern from dilfridge
-<creffett>
-           http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=4
-           <-needs to be clear that you will need an initramfs/early boot
-           mechanism
-<WilliamH> We have to vote that the documentation is ready.             [21:16]
-<creffett> not a blocker, but would be nice to have
-<creffett> also might want to not suggest separate /usr in the example there
-<rich0> creffett: would you mind logging a bug for that, and adding it to the
-        tracker?
-<creffett> rich0: sure, mind linking the tracker?
-<WilliamH> creffett:  http://bugs.gentoo.org/show_bug.cgi?id=481202     [21:17]
-<rich0> bug 481202
-<willikins> https://bugs.gentoo.org/481202 "Tracker - Documentation or
-            Implementation Issues for Dropping of Separate /usr Support";
-            Gentoo Linux, Unspecified; CONF; rich0:rich0
-<creffett> thank you, filing
-<ulm> hm, that bug still has another open blocker
-<rich0> Beyond a news item, any other items that need attention?  I'm more
-        concerned with a roadmap that gets us somewhere.
-<rich0> That was the NFS one - probably can be closed out.              [21:18]
-<blueness> yeah close that one
-<WilliamH> rich0: Once the news item is done, and we give a little time for
-           people to switch,
-<WilliamH> rich0: whatever maintainers do should be transparent after the
-           switch.
-<ulm> WilliamH: how much time? three months?
-<blueness> WilliamH, is there an easy way for me to test what will happen if
-           we drop gen_usr_ldscript on the systems i work on?
-<blueness> et for zlib
-<blueness> can i just comment it out of the ebuild and see what happens?
-                                                                        [21:19]
-<WilliamH> ulm: That seems a little long...  the switch isn't a process that
-           takes a long time or a whole lot of work?
-<_AxS_> IMO bug 481660 can be closed.  Documentation may be needed for dracut
-        and definitely would be needed for a roll-your-own, but overall a
-        genkernel initramfs suffices and iirc tha main
-        'get-an-initramfs-for-separate-/usr' documentation should be fine for
-        that
-<willikins> _AxS_: https://bugs.gentoo.org/481660 "Documentation for an early
-            boot mechamism with a separate NFS mounted /usr is lacking";
-            Gentoo Linux, Unspecified; CONF; blueness:base-system
-<ulm> WilliamH: the relevant time is that some users don't update so often
-<ulm> so certianly one week would be too short                          [21:20]
-<WilliamH> ulm: agreed, a week is too short.
-<ulm> and one year is probably too long
-<WilliamH> ulm: yes, a year is definitely too long.
-<rich0> This is a really big change.  I think three months is probably a good
-        amount of time.  In the meantime I wouldn't expect maintainers to put
-        a huge amount of effort into fixing bugs with not having
-        initramfs/etc.                                                  [21:21]
-<WilliamH> ulm: that's why I said 3 months seems a little long...
-<dberkholz> are we actually breaking backwards compat in that it's impossible
-            to upgrade? that's not my understanding.
-<blueness> dberkholz, i think so
-<WilliamH> dberkholz: not that I know of...
-<rich0> Nope - only real impact here is that your system might not boot, in
-        which case you boot from an install CD, chroot, configure an
-        initramfs, and reboot.
-<WilliamH> dberkholz: no it isn't going to be impossible to upgrade.
-<dberkholz> i think 30 days is probably fine, given that there's a clear,
-            specified upgrade path                                      [21:22]
-<rich0> It is still painful if you didn't prepare.
-<dberkholz> it's not like systems break the second they sync
-<_AxS_> (..which can be a much bigger issue on a headless remote box..)
-<WilliamH> dberkholz:  what would happen if you have separate /usr is
-<dberkholz> you sync, you upgrade, you ignore the docs, you reboot, it fails
-<scarabeus> _AxS_: we can show news item, like we do with other items, like we
-            didn't break boot with udev a lot :P
-<WilliamH> dberkholz: once a maintainer makes the changes, if you don't have
-           an initramfs, you could end up in a situation where you would be
-           unbootable.                                                  [21:23]
-<_AxS_> scarabeus: *nod*
-<dberkholz> this doesn't seem much different from any of dozens of other
-            updates requiring manual effort
-<WilliamH> dberkholz: that is after you upgrade the affected package
-<WilliamH> dberkholz: but it would be fixed as soon as you
-<WilliamH> dberkholz: put an initramfs in place
-<WilliamH> I'm not for a multi-month delay on this.                     [21:24]
-<dberkholz> it would be worthwhile to make some effort to detect whether we're
-            on a system that will break and explicitly notify there
-                                                                        [21:25]
-<creffett> WilliamH: it's waited this long, I don't think a few months will
-           make a difference in the long run
-<dberkholz> in any ebuild with breaking changes
-<ulm> how about this:
-<ulm> "The Council agrees that all preparations for dropping support for
-      separate /usr without an initramfs or similar boot mechanism are
-      complete. A news item will be prepared, and users will be given two
-      months to switch after the news item has been sent."
-<blueness> ulm, sounds good actually                                    [21:26]
-<scarabeus> wfm
-<WilliamH> ulm: why not s/two months/one month/
-<dberkholz> i'd prefer 30 but 60 is not terrible.
-<scarabeus> two months are like package drop so our default timeout :)
-<WilliamH> scarabeus: ?
-<creffett> WilliamH: again, it's waited this long, I don't think it will be a
-           huge problem to wait another month
-<scarabeus> WilliamH: 60 days are package mas for removal :)
-<scarabeus> *mask
-<WilliamH> scarabeus: no, it is 30?
-<ulm> ok, everyone state a time period please, and we'll take the median
-                                                                        [21:27]
-<_AxS_> scarabeus: 30, according to treecleaners
-* ulm 90 days
-<dberkholz> 30 days are like stabilization so our default timeout =)
-* WilliamH says 30 days
-<rich0> I'm fine with anything in the 30-90 day range.
-<blueness> me too                                                       [21:28]
-<blueness> if we wait too long we might want to send a second news item
-           reminder, else people would forget
-<ulm> creffett: scarabeus: ?
-<rich0> We could always vote on your proposal with 30 days, then if it fails
-        try again at 60, and so on.
-<rich0> using ulm's text                                                [21:29]
-<WilliamH> I agree with blueness, that's why I say 30 days, keep it short and
-           sweet.
-<creffett> ulm: 30-90 acceptable to me too
-* scarabeus agree with 30-90
-<dberkholz> 30-90 is acceptable to everyone. the question is which of those
-            numbers to pick.
-<_AxS_> averaging out responses = 45 days
-<dberkholz> 30,60,90
-<WilliamH> It seems that the majority who care say 30
-<ulm> ok, let's vote
-<creffett> I can live with 30, but again, I don't see the harm in 60/90
-                                                                        [21:30]
-<_AxS_> wait -- might it be better for this if it's an actual set deadline
-        instead of a duration?
-<ulm> "The Council agrees that all preparations for dropping support for
-      separate /usr without an initramfs or similar boot mechanism are
-      complete. A news item will be prepared, and users will be given one
-      month to switch after the news item has been sent."
-<ulm> one month variant
-* WilliamH votes yes
-* ulm votes no
-* rich0 yes
-* scarabeus yes
-<dberkholz> yes
-* blueness yes
-* creffett abstains
-<ulm> 5 yes, 1 no, 1 abstention
-<ulm> accepted
-<ulm> anything else for this topic?                                     [21:31]
-<ulm> seems not
-<ulm> next, open bugs with council involvement
-<ulm> let's start with bug 481202 with is related to the previous topic
-                                                                        [21:32]
-<willikins> ulm: https://bugs.gentoo.org/481202 "Tracker - Documentation or
-            Implementation Issues for Dropping of Separate /usr Support";
-            Gentoo Linux, Unspecified; CONF; rich0:rich0
-* WilliamH volunteers to work on the news item text
-<rich0> I don't really see any action required there by us.
-<creffett> just added my bug as a blocker
-<ulm> WilliamH: ok, I'll note this as action
-<blueness> yeah close that one
-<rich0> Beyond all previously discussed.
-<rich0> Oh, leave the tracker for now, but I think nothing there is a real
-        blocker to moving forward.
-<ulm> k
-<ulm> no action for this bug, but leave it open for the time being      [21:33]
-<ulm> bug 477030
-<willikins> https://bugs.gentoo.org/477030 "Missing summary for 20130611
-            council meeting"; Doc Other, Project-specific documentation; CONF;
-            ulm:council
-<_AxS_> someone should probably add a comment on the bug about the decision
-        and maybe a link to the minutes/summary
-<ulm> any progress there?
-<ulm> _AxS_: yeah, we can do that                                       [21:34]
-<ulm> seems no progress for the missing log
-<ulm> bug 457000 is related                                             [21:35]
-<willikins> https://bugs.gentoo.org/457000 "Missing log and summary for
-            previous council meetings"; Doc Other, Project-specific
-            documentation; CONF; ulm:council
-<ulm> if there are no objections, I'll add the log and summary for the
-      20080515 meeting
-<ulm> as outlined in comment #8
-<blueness> okay                                                         [21:36]
-<ulm> anyone against it?
-<scarabeus> nope
-<ulm> seems not
-<creffett> nope                                                         [21:37]
-<_AxS_> for the others; does this still fall in jmbsvicetto's domain?  or can
-        others do the work (assuming they have access to the logs)?
-<ulm> _AxS_: the others are done
-<_AxS_> Oh ok nvm
-<ulm> bug 480408 is next
-<willikins> ulm: https://bugs.gentoo.org/480408 "Add
-            /releases/${arch}/verified tree for tested autobuilds"; Gentoo
-            Linux, Unspecified; CONF; mattst88:release
-<blueness> ulm, i'm not sure what we need to vote on there, it seems
-           jmbsvicetto has a plan                                       [21:38]
-<blueness> are we voting on jmbsvicetto comment 4?                      [21:39]
-<_AxS_> ...maybe vote to leave it to releng and un-CC council?
-<ulm> oops, I just see that we had discussed this one in august already
-<ulm> "No action to be taken by the council. This should be sorted out within
-      the releng team."
-<ulm> says the summary of the 20130813 meeting
-<ulm> so action is to remove council from CC, I guess                   [21:40]
-<rich0> ++
-<ulm> I see no objections                                               [21:41]
-<scarabeus> not really :)
-<ulm> finally, bug 485448
-<willikins> https://bugs.gentoo.org/485448 "Migrate council project page to
-            the wiki"; Doc Other, Project-specific documentation; CONF;
-            ulm:council
-<ulm> has anyone looked at the wiki page?
-<ulm> http://wiki.gentoo.org/wiki/Project:Council
-* scarabeus liked                                                       [21:42]
-<dberkholz> It looks wiki-ish
-<blueness> i like it
-<ulm> dberkholz: sure ;)
-<rich0> wfm
-<blueness> dberkholz, is that bad?
-<ulm> dberkholz: not gorg-ish any more
-<dberkholz> yeah, actually. but that's not really a conversation for here. we
-            need a better skin.
-<creffett> well, everything looks wiki-ish...we're using a wiki for everything
-           :P                                                           [21:43]
-<dberkholz> is there some way to fold that really long list of council logs by
-            default?
-<ulm> dberkholz: yeah, I've thought about this, too
-<dberkholz> nobody will scroll past that to see anything at the end
-<dberkholz> either that or put it on its own page and link to it
-<ulm> we could split the table by council terms
-<ulm> or by years
-<dberkholz> i would just throw it on a subpage.                         [21:44]
-<ulm> dberkholz: or that
-<dberkholz> seriously, how many people ever read that, compared to the other
-            stuff
-<creffett> subpage++
-<_AxS_> meeting chairs/logs could go at the end, they don't really need to be
-        right up there with meetings...
-<ulm> dberkholz: or we could fold it by default
-<ulm> that's maybe easiest
-<blueness> yeah subpages sounds best                                    [21:45]
-<ulm> apart from that detail, any objections against completing the migration?
-                                                                        [21:46]
-<ulm> i.e. the old project page would redirect to the wiki
-<ulm> again, I see no objections                                        [21:47]
-<dberkholz> yeah that sounds great.
-<dberkholz> can't wait to get maximal content moved to the wiki
-<ulm> and I'll ask infra to redirect http://council.gentoo.org/ to the wiki
-      page                                                              [21:48]
-<dberkholz> then we can focus more on making the website effective without
-            ridiculous legacy costs for any changes
-<a3li> ulm: read the bug and don't bother us!
-<ulm> a3li: why should we have a double redirect?                       [21:49]
-<ulm> a3li: or is it difficult to update it?
-<a3li> to not have to update it for every project, yes
-<ulm> well, council isn't a project exactly                             [21:50]
-<ulm> any other opionions on this?
-<ulm> *opinions                                                         [21:51]
-<ulm> looks like we're done then                                        [21:52]
-<ulm> no open floor today
-<WilliamH> I would like to have the council proof my newsitem text... is now a
-           good time?
-<rich0> I don't see why that can't go through the normal bikeshedding, but I
-        don't object.                                                   [21:53]
-<ulm> WilliamH: I'd suggest that you send it to council@g.o
-<ulm> but of course, we can also do it now
-<WilliamH> ulm: Ok, I'll just add council@g.o to the newsitem email along with
-           pr@gentoo.org when I send it to -dev.                        [21:54]
-<ulm> WilliamH: sounds good
-<WilliamH> ulm: hang on
-<WilliamH> http://bpaste.net/show/135076
-<WilliamH> The date will be replaced with the date the news item is committed.
-<WilliamH> and the rest of the headers will be filled out of course.    [21:55]
-<ulm> WilliamH: make it a round date, like 1-Nov-2013                   [21:56]
-<ulm> assuming that this will be posted in september still              [21:57]
-<_AxS_> .. a week of bikeshedding would put its post date at just before
-        Oct.1st ..
-<WilliamH> Ok 1-nov-2013 is fair enough. :-)                            [21:58]
-<rich0> I'd change it to talk about other alternatives beyond initramfs - it
-        is a news item after all.  However, that probably is best bikeshedded
-        offline.
-* WilliamH corrects the text
-<ulm> WilliamH: maybe s/you will find/you may find/                     [21:59]
-<_AxS_> rich0: ..  isn't initramfs the only officially supported solution for
-        sep-/usr now tho?
-<rich0> ulm: ++ I thought that as well
-<rich0> It is by far the best documented one, but there are other options.
-<rich0> Not sure I'd go into details, but we could mention that they exist.
-                                                                        [22:00]
-<rich0> The only thing that matters is that you have /usr mounted when you get
-        into the meat of rc.
-<_AxS_> rich0: there are options for making it work, but iirc based on this
-        and prior votes, the only officially supported solution is either
-        initramfs+sep-/usr or /usr-on-/
-<rich0> Well, we don't have to mention it then.                         [22:01]
-<ulm> I suggest that we continue bikesheeding of the news item in the -dev ML
-<rich0> Agree
-<rich0> Others might have more valuable input as well.
-*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
-    "Next meeting: 8 Oct 2013 at 19:00 UTC |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 |
-    http://www.gentoo.org/proj/en/council/"
-<ulm> finally, we're done for this month then
-<ulm> next meeting 8 Oct                                                [22:02]
-<ulm> dilfridge will be chairing
-<scarabeus> so one week without meeting? :P
-<rich0> Just in time for a call for agenda items :)
-<ulm> dilfridge: call for agenda items should be sent today ;)
-<ulm> rich0: right
-<WilliamH> heh
-<ulm> so thanks everyone                                                [22:03]
-<WilliamH> We have had several extra meetings, but we are getting things done.
-           :-)
-<ulm> and I close this meeting
-<WilliamH> So I don't mind the extra meetings.
-<blueness> until next time!                                             [22:04]
-<creffett> hey, better to have people percieve the council as getting stuff
-           done                                                         [22:05]
-<rich0> thanks ulm...  we got our money's worth out of you this time.
-<creffett> instead of pushing everything back
-<rich0> creffett: ++ - yes, I feel like we're really moving along.
-* WilliamH agrees with creffett  
-<rich0> Now we just get to see how that news item goes over.  :)        [22:06]
-<WilliamH> rich0: heh, get your fire-proof suit on
-<rich0> I signed on for it.  :)
-* creffett opens the bar
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20131008-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20131008-summary.txt
deleted file mode 100644
index 3796292df7..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20131008-summary.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-Summary of the Gentoo Council meeting 08 October 2013
-
-
-Agenda
-======
-
-1. Introduction and roll call
-2. Resume discussion on the new Code of Conduct [1-4]
-3. Open bugs with council involvement
-   Bug 477030: Missing summary for 20130611 council meeting [5]
-   Bug 481202: Tracker - Documentation or Implementation Issues for 
-               Dropping of Separate /usr Support [6]
-4. Open floor
-
-[1] http://article.gmane.org/gmane.linux.gentoo.project/3061
-[2] http://thread.gmane.org/gmane.linux.gentoo.project/2470
-[3] http://dev.gentooexperimental.org/~scarabeus/gentoo-coc.txt
-[4] http://www.gentoo.org/proj/en/council/meeting-logs/20130611.txt
-[5] https://bugs.gentoo.org/show_bug.cgi?id=477030
-[6] https://bugs.gentoo.org/show_bug.cgi?id=481202
-
-
-Roll call
-=========
-Present:
-   blueness, dberkholz, dilfridge, rich0, scarabeus, ulm, williamh
-
-
-Code of Conduct discussion
-==========================
-
-Vote: 
-- Should the current code of conduct undergo "minor" or "major" 
-  revision, with minor revision being just updating the wording in 
-  the old text to current organizational structures?
-4 votes for minor, 3 for major revision
-
-In the subsequent discussion it was suggested to incorporate changes 
-from Scarabeus' text proposal [3] into the existing Code of Conduct. 
-To ease discussion on this during next month's meeting, a comparison 
-of the files should be circulated among the council members during 
-the upcoming weeks.
-
-Dilfridge volunteers to go through the old Code of Conduct text and 
-fix the worst outdated passages.
-
-
-Open bugs with council involvement
-==================================
-
-- Bug 477030 "Missing summary for 20130611 council meeting" [5]
-  No progress since last meeting.
-
-- Bug 481202: Tracker - Documentation or Implementation Issues for 
-  Dropping of Separate /usr Support [6]
-  Consensus is that all is done here and that both the last bug 
-  blocking [6] and the tracker [6] itself can be resolved.
-
-
-Open floor
-==========
-
-WilliamH brings up the issue of using INSTALL_MASK for avoiding 
-installation of small utility files. His question is how we could 
-avoid requiring a re-build of the entire installed package set when 
-the value of INSTALL_MASK is changed. As a possible solution, a 
-feature for the package manager is proposed: it could record whether 
-a package is affected by INSTALL_MASK during installation, and offer 
-a switch to only rebuild all these packages. Implementation should 
-not have high priority though.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20131008.txt b/xml/htdocs/proj/en/council/meeting-logs/20131008.txt
deleted file mode 100644
index 7f91c1a25e..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20131008.txt
+++ /dev/null
@@ -1,202 +0,0 @@
-[21:10:12] <dilfridge> 1) Roll call
-[21:10:12] -*- WilliamH is here, late, sorry about that
-[21:10:23] -*- blueness here
-[21:10:27] -*- dilfridge here
-[21:10:27] -*- rich0 here
-[21:10:27] -*- scarabeus here
-[21:10:31] <dberkholz> cool, that's everyone
-[21:10:34] -*- ulm here
-[21:10:43] <dilfridge> good
-[21:10:54] <dilfridge> then we immediately go to point 2)
-[21:11:08] <dilfridge> 2) Resume discussion on the new Code of Conduct [2-5]
-[21:11:25] <dilfridge> this is worded a bit vague
-[21:11:37] <dilfridge> maybe one first question would be
-[21:11:49] <dilfridge> (since this came up in the mailing list discussion)
-[21:12:01] <dilfridge> do we want to modify the existing CoC at all?
-[21:12:49] <scarabeus> i do, and seems markos as the tl of the project wants...
-[21:12:58] <dberkholz> i think the new one is useful. it has a more positive tone and provides some more explanation of the basic ideas.
-[21:13:03] <rich0> I already posted on the list, but I think the principles of the CoC don't really need changing.  I'm all ears if somebody has something specific they want to take issue with, but I don't see the point a full rewrite.
-[21:13:14] <ulm> it should be slightly updated to account for changes that happened in the meantime
-[21:13:22] <ulm> but not rewritten from scratch
-[21:13:25] <dberkholz> the basic ideas are the same, but it drops some of the technical stuff that's not really pertinent.
-[21:13:36] <dilfridge> I am personally doubtful whether for example specifying in detail what is offensive is a good idea
-[21:13:40] <blueness> i like the new one
-[21:13:41] <ulm> all the important things are there in the old text
-[21:14:02] <dberkholz> dilfridge: i agree that being complete is impossible and a bad idea, but examples are useful
-[21:14:10] <rich0> I just think the new version is pretty verbose.
-[21:14:14] <rich0> (and that's coming from me)
-[21:14:18] <blueness> i agree with ulm, it basically says the same as the old, but its got a positive spin
-[21:14:42] <dberkholz> with the wiki we could fold in the text for each of the points on the new version easily enough
-[21:14:59] <dilfridge> ok
-[21:15:07] <dilfridge> so in general we have three options
-[21:15:38] <dilfridge> 1) leave as is, no changes at all- makes no sense since the technical details are outdated
-[21:15:59] <dilfridge> 2) minor revisions, basically updating the old text to new organizational structures
-[21:16:19] <dilfridge> 3) major revisions, e.g. according to scarabeus proposal
-[21:16:36] <blueness> dilfridge, are we voting?
-[21:16:40] <dilfridge> not yet
-[21:16:44] <blueness> k
-[21:16:55] <blueness> discussion .. i like scarabeus's proposal
-[21:17:45] <WilliamH> Can someone link his proposal here again real quick?
-[21:17:51] <dberkholz> http://dev.gentooexperimental.org/~scarabeus/gentoo-coc.txt
-[21:17:51] <blueness> http://dev.gentooexperimental.org/~scarabeus/gentoo-coc.txt
-[21:18:26] <dilfridge> is anyone here in favour of option 1)? if no, we dont even have to put it for a vote
-[21:18:55] <rich0> Personally I favor 2.  I'm not opposed to 3, but I think it is a distraction to the issue that people really care about, which is execution.
-[21:19:08] <blueness> i'm not in favor of 1
-[21:19:24] <dilfridge> ok
-[21:20:01] <ulm> I also favour 2, the old CoC would just work if properly enforced
-[21:20:03] <rich0> FYI - #3 also needs the #2 treatment as well.
-[21:20:20] <dilfridge> I propose to put to a vote:
-[21:20:52] <dilfridge> "minor or major revision", minor revision being just updating the wording in the old text to current organizational structures
-[21:21:08] -*- dilfridge minor revision
-[21:21:13] -*- ulm minor
-[21:21:32] -*- scarabeus likes mine obviously
-[21:21:46] -*- WilliamH minor revision; the only difference between old and new really is verbosity and examples...
-[21:21:53] -*- rich0 minor
-[21:21:58] -*- blueness likes scarabeus 
-[21:22:12] <dberkholz> i like scarabeus. and his CoC.
-[21:22:15] <WilliamH> Maybe we could encorporate some of the new points as part of the minor revision...
-[21:22:38] <dilfridge> that's four minor, three major
-[21:22:44] <hwoarang> having examples and verbosity is good in a multicultural and multilingual environment
-[21:22:47] <dberkholz> if we do some of scarabeus' changes in the form of a diff to the existing one, perhaps that would seem more minor.
-[21:22:47] -*- hwoarang shuts up
-[21:22:55] <WilliamH> I'm not opposed to using some of scarabeus' changes
-[21:23:21] <ulm> sure, some of the new wording could be incorporated
-[21:23:26] <rich0> agree
-[21:23:28] -*- WilliamH agrees with dberkholz 
-[21:23:34] <dilfridge> fine
-[21:23:40] <rich0> I just want to focus more on what is broken, and starting with the current state makes that more clear.
-[21:23:42] <WilliamH> we should encorporate parts of scarabeus  changes...
-[21:23:51] <dilfridge> but I suppose we'd have to properly prepare this for the next time
-[21:24:40] <dilfridge> my suggestion:
-[21:24:43] <WilliamH> sounds good to me. I don't want to shut out what scarabeus  has written, I'm just not sure we need a complete rewrite.
-[21:24:54] <dilfridge> a) let's update the old text now as agreed, 
-[21:25:16] <dilfridge> b) let's prepare an extended version incorporating part of scarabeus' stuff until next time
-[21:25:26] <dilfridge> c) let's then vote on the result
-[21:25:53] <WilliamH> Sounds good to me.
-[21:26:07] <ulm> fine with me
-[21:26:17] <blueness> okay
-[21:26:40] <dilfridge> any other opinions?
-[21:26:48] <dberkholz> but rewrites fix everything, right? http://www.jwz.org/doc/cadt.html
-[21:27:44] <blueness> let's see what the new document looks like and go from there
-[21:27:55] <dilfridge> ^^
-[21:28:23] <dilfridge> dberkholz: the whole point was not to rewrite but to extend
-[21:28:38] <dilfridge> because that was what some people here were saying
-[21:29:18] <dilfridge> ok
-[21:29:35] <dilfridge> seems like we have said everything we can say today
-[21:29:59] <dilfridge> who is doing the work?
-[21:32:07] <dberkholz> scarabeus: can you turn your work into a diff against the existing copy?
-[21:32:17] <dberkholz> scarabeus: maintaining the general format and the main points of the original?
-[21:32:24] <scarabeus> well most probably yep, if next meeting is in omth
-[21:32:29] <scarabeus> *month
-[21:33:12] <scarabeus> but would be lovely if someone wants to coop as i am not greedy to keep all the work for myself :)
-[21:34:39] <dilfridge> ok
-[21:34:51] <dilfridge> seems like we dont get any further here.
-[21:34:53] <blueness> scarabeus, write something and then email use to review
-[21:35:05] <dilfridge> I volunteer to go through the old text and fix the worst outdatedness.
-[21:35:42] <dilfridge> yeah scarabeus I guess noone objects if you just send it to the alias somehow
-[21:35:45] <dilfridge> ok
-[21:35:52] <dilfridge> let's conclude this for now
-[21:36:00] <scarabeus> yea use our alias so we all can bikeshed in advance
-[21:36:06] <blueness> right!
-[21:36:17] <dilfridge> 3. Open bugs with council involvement
-[21:36:27] <dilfridge> Bug 477030: Missing summary for 20130611 council meeting [6]
-[21:36:29] <willikins> dilfridge: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council
-[21:36:37] <dilfridge> any news?
-[21:36:42] <scarabeus> nope
-[21:37:03] <dilfridge> ok same resolution as always, let's annoy petteri
-[21:37:10] <dilfridge> Bug 481202: Tracker - Documentation or Implementation Issues for Dropping
-[21:37:10] <dilfridge>                of Separate /usr Support [7]
-[21:37:11] <willikins> dilfridge: https://bugs.gentoo.org/481202 "Tracker - Documentation or Implementation Issues for Dropping of Separate /usr Support"; Gentoo Linux, Unspecified; CONF; rich0:rich0
-[21:37:39] <dilfridge> anything we need to talk about here?
-[21:37:51] -*- WilliamH isn't sure of anything either
-[21:38:19] <WilliamH> rich0: What is left on that bug?
-[21:38:19] <blueness> i thought we agreed that the NFS mounted /usr was not in need of more documentation and that it "just works"
-[21:38:28] <dilfridge> actually
-[21:38:38] <WilliamH> blueness: yes, we did.
-[21:38:40] <dilfridge> since we already decided that the support is there
-[21:38:47] <dilfridge> we can probably drop the council from the tracker
-[21:38:54] <blueness> i agree
-[21:39:17] <dilfridge> ok
-[21:39:28] <dilfridge> I'm closing both bugs then now, unless there is protest
-[21:39:52] <dilfridge> this concludes point 3
-[21:40:01] <dilfridge> 4. Open floor
-[21:40:04] <ulm> dilfridge: both bugs?
-[21:40:16] <dilfridge> ulm: the tracker and the nfs usr bug
-[21:40:25] <ulm> ah
-[21:40:37] <ulm> I thought the missing summary one
-[21:40:40] <dilfridge> nah
-[21:40:44] <dilfridge> that is not fixed :)
-[21:41:24] <dilfridge> Open Floor anyone?
-[21:41:37] <WilliamH> I have something I've been thinking about... an old policy that maybe we should look at again, but this is just a question not a proposal to change anything...
-[21:41:42] <dilfridge> k
-[21:41:53] <dilfridge> go ahead
-[21:42:32] <WilliamH> I've been thinking about our policy to tell people to use INSTALL_MASK to for example block installation of systemd units, logrotate files, etc, and,
-[21:42:49] <blueness> right
-[21:43:02] <WilliamH> the conn of that arrangement is that,
-[21:43:03] <dilfridge> oh dear
-[21:43:15] <WilliamH> if you change your mind, you have to,
-[21:43:24] <WilliamH> adjust INSTALL_MASK then
-[21:43:30] <WilliamH> emerge -e @world
-[21:43:44] <blueness> so?
-[21:43:50] <WilliamH> I'm wondering if we put that policy in place before
-[21:44:12] <WilliamH> we had --newuse and --changed-use (I don'tknow the exact option for the second one right now), and
-[21:44:25] <WilliamH> since we have that it should be re-examined?
-[21:44:40] <WilliamH> because now you can
-[21:44:48] <ulm> anything that would save significant amounts of space should have a USE flag
-[21:44:51] <WilliamH> adjust use flags and only rebuild the affected packages?
-[21:44:58] <rich0> The former has been around for a LONG time.  I don't really see the need.  Nobody should bother with INSTALL_MASK unless they have a good reason for it, and if they do, well, they can re-install stuff.
-[21:45:06] <dilfridge> well, you'd still rebuild the package then... imagine libreoffice had a systemd unit file 
-[21:45:21] <WilliamH> dilfridge: yes, but you wouldn't rebuild the world
-[21:45:27] <blueness> rich0, i agree, it works for me because i build embedded systems where every file counts
-[21:45:35] <dberkholz> our policy has been to minimize additional use flags when they don't make any meaningful difference in installed size
-[21:45:38] <ulm> there's no good reason to use INSTALL_MASK for things like systemd unit files
-[21:45:39] <blueness> on my desktop where i use openrc i don't care about systemd unit files
-[21:45:42] <ulm> or bash completion
-[21:45:43] <dberkholz> the only people doing that stuff should be building embedded systems
-[21:45:46] <blueness> so INSTALL_MASK is good enough for me
-[21:45:55] <rich0> You wouldn't have to rebuild the world if you didn't mask it in the first place...  makes sense on embedded, but are you just going to switch init systems on an embedded system on a whim?
-[21:46:53] <rich0> I don't see INSTALL_MASK as being broken.  It caters to some unusual cases, and for thsoe who want to use it, they can.  It has downsides, like all the alternatives.
-[21:46:59] <dilfridge> WilliamH: the question is more, what is the reason for putting something into INSTALL_MASK in the first place? on a desktop system, pure hate for bash completion files for example?
-[21:47:17] <dilfridge> I see the point for an embedded system
-[21:47:33] <blueness> that's why i brought it up on the list
-[21:47:50] <blueness> i already go in and clean stuff out manually, but INSTALL_MASK helps
-[21:48:30] <blueness> it might be possible to write a portage helper script which looks for all pachages providing files in INSTALL_HELP
-[21:48:36] <blueness> err ... INSTALL_MASK
-[21:48:45] <blueness> and then just re-emerges them
-[21:48:58] <blueness> i can see how that could be written (using equery as an example)
-[21:49:04] <dilfridge> not really, since the files are not recorded then
-[21:49:05] <blueness> but i'm not sure how important that is
-[21:49:11] <blueness> dilfridge, no?
-[21:49:15] <dilfridge> I dont think so
-[21:49:21] <WilliamH> blueness: I think that's the thing though, if you mask things out, I don't think they appear in contents at all.
-[21:49:30] <blueness> ah
-[21:49:45] <dilfridge> but, we could ask zac for that feature (store a list of blocked files in the vdb)
-[21:49:52] <blueness> open a bug against portage and give zemdico more work!
-[21:50:01] <blueness> :)
-[21:50:16] <dilfridge> then such a utility would be easy and you would not have to rebuild world, only the relevant packages
-[21:50:31] <dberkholz> in terms of return on effort, i'm just not seeing the value
-[21:50:31] <dilfridge> WilliamH: what do you think?
-[21:50:45] <blueness> i would just put some marker in vdb's CONTENTS
-[21:50:59] <dilfridge> blueness: also possible ("something was blocked")
-[21:51:27] <WilliamH> dilfridge: I'm not a portage dev, so I can't really comment on how feasable that is...
-[21:51:52] <rich0> dberkholz: ++  Sure, it sounds like a nice feature, but I'd rather zmedico spent the time mowing my lawn as long as we're handing out orders.  :)
-[21:52:06] <blueness> WilliamH, grep the portage tree for INSTALL_MASK and go from there, i'm not a portage dev either but that doesn't stop me ;)
-[21:52:19] <WilliamH> I wouldn't make it a high priority; I don't use install_mask myself.
-[21:52:26] <dilfridge> zac is missing in action a bit, we could always ask Arfrever :)
-[21:52:26] <WilliamH> I was just brainstorming really.
-[21:52:42] <rich0> is Arfrever good at lawns?
-[21:52:44] <WilliamH> dilfridge: heh
-[21:53:04] -*- blueness is git pulling portage as we speak
-[21:53:25] <blueness> its in here -> bin/misc-functions.sh
-[21:53:41] <dilfridge> WilliamH: to be honest, I dont think it's a complex feature to just store a marker "something was blocked by INSTALL_MASK" in the vdb for each package
-[21:53:52] <jmbsvicetto> dilfridge: I would prefer you get Zac back
-[21:54:22] <jmbsvicetto> dilfridge: There's already enough I'd like him to fix before we break more things
-[21:54:31] <dilfridge> no objection
-[21:54:48] <blueness> hmm ... it just remove stuff from the image dir before qmerge i think
-[21:55:13] <dilfridge> ok but this is technical stuff
-[21:55:16] <blueness> actually from ${ED}
-[21:55:20] <dilfridge> anything else for the open floor?
-[21:56:04] <blueness> done?
-[21:56:06] <dilfridge> seems not
-[21:56:09] <dilfridge> done
-[21:56:12] <dilfridge> meething closed
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20131112-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20131112-summary.txt
deleted file mode 100644
index 2fbe8f4ad2..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20131112-summary.txt
+++ /dev/null
@@ -1,86 +0,0 @@
-Summary of the Gentoo Council meeting 12 November 2013
-
-
-
-Agenda
-======
-
-1. Introduction and roll call
-
-2. Status of the QA team
-   * Proposal to disband the QA team and call for new team members [1]
-   * Proposal to add Patrick Lauer to the QA team [2]
-
-3. Request for a minimal policy for pgp keys and key handling (for 
-   commit signing) [3]
-
-4. Removing last keyworded package version for a minor arch [4]
-
-5. Metastructure: Dead projects [5]
-
-6. Metastructure: Reorganization of the project tree [6]
-
-7. Modernization/adaption of the Code of Conduct, the return [7]
-
-8. Revival of archives.gentoo.org
-
-9. Open bugs with council involvement
-   * Bug 477030 - Missing summary for 20130611 council meeting [8]
-
-10. Open floor
-
-
-[1] http://thread.gmane.org/gmane.linux.gentoo.project/3116/focus=3129
-[2] <20131029165206.1430a2be@shanghai.paradoxon.rec>
-    http://dev.gentoo.org/~dilfridge/mail-3.txt
-[3] <527053EF.9080200@gentoo.org>
-    http://dev.gentoo.org/~dilfridge/mail-4.txt
-[4] http://article.gmane.org/gmane.linux.gentoo.project/3110
-[5] <201310292251.02052.dilfridge@gentoo.org>
-    http://dev.gentoo.org/~dilfridge/mail-6.txt
-[6] <201310292255.04913.dilfridge@gentoo.org>
-[7] http://www.gentoo.org/proj/en/council/meeting-logs/20131008.txt
-[8] https://bugs.gentoo.org/show_bug.cgi?id=477030
-
-
-
-Roll call
-=========
-
-Present:
-   blueness, dberkholz, dilfridge, rich0, scarabeus, ulm, williamh
-
-
-
-Status of the QA team
-=====================
-
-After a lengthy discussion, the following proposal was put up for
-vote:
-
-"The current QA team is dissolved (but not its subprojects). The 
-Council announces on the gentoo-dev-announce mailing list that 
-interested developers should send council@gentoo.org a mail in the 
-next two weeks if they want to join the QA team. The Council takes on 
-the role of the QA team lead for six weeks, with elections in the 
-team afterwards. The Council accepts interested developers into the 
-team with secret majority vote of the council members."
-
-This motion was passed with 4 yes and 3 abstentions.
-
-This makes the proposal to add Patrick Lauer to the QA team obsolete 
-since he can now follow the process outlined above.
-
-In addition, it was discussed whether GLEP48 should be amended 
-such that the QA team elect its team lead, but the Council has to 
-confirm that election. A decision on this was postponed to the next 
-regular Council meeting; a draft of the GLEP48 change should be
-prepared and sent to the gentoo-project mailing list for discussion.
-
-
-
-===
-
-Afterwards the meeting was adjourned; the Council will reconvene in a 
-week as per a separate announcement. 
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20131112.txt b/xml/htdocs/proj/en/council/meeting-logs/20131112.txt
deleted file mode 100644
index bb3ed5ec45..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20131112.txt
+++ /dev/null
@@ -1,327 +0,0 @@
-[20:03:33] <dilfridge> ok
-[20:03:39] <dilfridge> time it is
-[20:03:51] <dilfridge> who's chairing? ah right, me
-[20:04:21] * dilfridge has changed topic for #gentoo-council to: "Next meeting: 12 Nov 2013 at 19:00 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | http://wiki.gentoo.org/wiki/Project:Council | Agenda: http://article.gmane.org/gmane.linux.gentoo.project/3149"
-[20:04:27] --> TomJBE (~tb@gentoo/developer/tomjbe) hat #gentoo-council betreten
-[20:05:00] <dilfridge> blueness: dilfridge: rich0: scarabeus: ulm: WilliamH: Council meeting!
-[20:05:08] <dilfridge> dberkholz: 
-[20:05:16] -*- rich0 is here
-[20:05:23] <dilfridge> 1 Roll Call
-[20:05:38] <dberkholz> morning
-[20:05:39] -*- WilliamH here
-[20:05:44] <dilfridge> morning!
-[20:06:11] -*- rich0 here
-[20:06:25] <scarabeus> here here here
-[20:06:28] <scarabeus> :)
-[20:07:00] <dilfridge> blueness, ulm?
-[20:08:02] <ulm> here
-[20:08:12] <dilfridge> phew
-[20:08:21] -*- dilfridge was just searching for the phone number
-[20:08:33] <dberkholz> i don't suppose anyone's put together a version of the agenda that embeds the emails that aren't in online archives?
-[20:08:48] <dilfridge> anyone in the us wants to message blueness?
-[20:09:02] <dberkholz> referring to things that are not trivial to access is less than friendly for people reading it
-[20:09:27] <dilfridge> dberkholz: not yet but I should have most of them here, so if you all are willing to wait a moment
-[20:09:58] --> pacho2 (~pacho@gentoo/developer/pacho) hat #gentoo-council betreten
-[20:10:56] <rich0> I'm finding it difficult to find those emails as well - does gmail support searching for msgids?
-[20:11:04] <rich0> I do vaugely remember reading the originals...
-[20:11:48] --> Zero_Chaos (user18791@gentoo/developer/pentoo/zerochaos) hat #gentoo-council betreten
-[20:11:58] <rich0> Could have been auto-deleted - I don't normally save list mail, figuring that it is supposed to be archived... :)
-[20:13:02] <dilfridge> ok I copied [3,4,6], I doubt we get further
-[20:13:21] <dilfridge> http://dev.gentoo.org/~dilfridge/mail-3.txt
-[20:13:24] <dilfridge> http://dev.gentoo.org/~dilfridge/mail-4.txt
-[20:13:27] <dilfridge> http://dev.gentoo.org/~dilfridge/mail-6.txt
-[20:13:52] <dilfridge> I'll put something nicer together later
-[20:14:01] <dilfridge> anyone got blueness phone number?
-[20:15:32] <ulm> dilfridge: should I text him?
-[20:15:35] <dilfridge> Ok I sent him a text
-[20:15:45] <ulm> k
-[20:15:46] <dilfridge> let's start now anyway, we're already late
-[20:16:06] <dilfridge> Agenda topic 2: Status of the QA team
-[20:16:07] <blueness> damnit!
-[20:16:12] <blueness> i'm here the time change!
-[20:16:31] <dilfridge> :)
-[20:16:35] <blueness> i forgot about the time change to daylight savings so we start at 3 not 4
-[20:16:37] <dberkholz> start using the google calendar =)
-[20:16:43] <blueness> yeah i know
-[20:16:44] <WilliamH> heh
-[20:17:15] <rich0> I've already voiced them, but I have concerns with our general approach to staffing QA (which is not meant to reflect on any team members, or actual team performance).
-[20:17:27] <dilfridge> so basically we have two proposals related to QA... one by Polynomial-C, requesting to add Patrick; one by kensington, requesting dissolving and re-forming QA
-[20:17:48] <rich0> It basically lacks oversight, is a thankless job, and seems to have considerable authority.
-[20:18:02] <dilfridge> it would make sense to talk about kensington proposal first, since that one would make the other obsolete imho
-[20:18:12] <blueness> okay
-[20:18:13] <ulm> k
-[20:18:16] <scarabeus> k
-[20:18:20] -*- WilliamH agrees
-[20:18:55] <seemant> .
-[20:19:01] <dilfridge> ulm: did you hear anything still? you're the qa guy here...
-[20:19:13] <blueness> dissolving is pretty serious, we'd face the dicision of who do we staff QA with initially
-[20:19:25] <ulm> dilfridge: diego has sent an answer to me privately
-[20:19:30] <blueness> also, i'm not sure what diego's position is
-[20:19:36] <WilliamH> blueness: it is, but the current staff is basically non-responsive.
-[20:19:47] <blueness> ulm, can you share?
-[20:20:06] <rich0> Certainly interested in knowing how the current QA staff feels.
-[20:20:16] <ulm> blueness: unfortunately, the answer is of a nature that I'd rather not share it here
-[20:20:34] <blueness> ulm, okay i can guess what he said
-[20:20:49] <dilfridge> blueness: diego was asked a couple of times to get things going again... hwoarang was pretty active there
-[20:21:09] <dilfridge> so
-[20:21:19] <blueness> we need two things for QA, a team and someone willing to run the tinderbox stuff
-[20:21:19] <ulm> also no replies to my call for devs interested to join qa: http://thread.gmane.org/gmane.linux.gentoo.project/3116/focus=3129
-[20:21:21] <dberkholz> if this is a route people want to go, how can we avoid repeating the same mistakes again with a new team?
-[20:21:27] <rich0> I want to be sensitive to feelings, but if the current team can't even talk publicly about the problems faced by the current team, I think we need to rethink things.
-[20:21:34] <scarabeus> i have somebody at the door, gimme sec to run over and see what is going on :)
-[20:21:39] <blueness> rich0, ++
-[20:21:51] <seemant> what does QA actually mean for Gentoo? outside of things like repoman, etc?
-[20:22:02] <rich0> seemant: defining that would be a good first step.  :)
-[20:22:04] <dilfridge> there's a whole glep about it
-[20:22:12] <Zero_Chaos> ulm: I don't see a call for interested devs. I'm interested, have been for years.
-[20:22:18] <WilliamH> glep 48 defines qa
-[20:22:22] <dilfridge> http://www.gentoo.org/proj/en/glep/glep-0048.html
-[20:22:33] <rich0> The GLEP as written isn't bad.
-[20:22:34] <ulm> Zero_Chaos: see the link I've posted above
-[20:22:44] <ulm> "Could everyone who is interested in joining the QA team repeat their application here, so we can get a complete list?"
-[20:23:03] <rich0> The only thing I'd change as I've stated before is that the QA lead should be confirmed by council - by all means let the team nominate somebody.
-[20:23:14] <dilfridge> ulm: I'm not so worried about that, to be honest. It's easier to join a new team than to jump on a boat that's already rotting.
-[20:23:17] <ulm> Zero_Chaos: maybe not everyone reads -project
-[20:23:28] <Zero_Chaos> ulm: I missed it in the thread, happy to take full blame but I might not be the only one that missed it. (I'm on -project)
-[20:23:29] <rich0> I think if we re-constituted the team from scratch we'd probably get more takers.
-[20:23:41] <dilfridge> rich0: exactly
-[20:23:46] <scarabeus> back
-[20:24:03] <blueness> is patrick interested?
-[20:24:06] <seemant> I'm sorry, but the glep is unclear
-[20:24:11] <rich0> I don't want being on the QA team to be a thankless job.
-[20:24:14] <seemant> what is a "good state" for the portage tree?
-[20:24:32] <dilfridge> blueness: I asked and he says he's basically neutreal to what we decide here, that's all I got
-[20:24:35] <WilliamH> seemant: following http://devmanual.gentoo.org is a good start
-[20:24:42] <dilfridge> anyway
-[20:24:52] <rich0> I'm fine with QA setting and enforcing standards, but they should be written down.
-[20:24:54] <dilfridge> I think we can all agree that the current state is not OK.
-[20:24:58] <rich0> Sometimes they are.
-[20:25:27] <WilliamH> dilfridge: Agreed.
-[20:25:33] <rich0> dilfridge: ++
-[20:25:44] <blueness> well if the state of the current QA team is that bad, how about considering both recommendations
-[20:25:45] <hwoarang> ulm: nobody wants to join QA as it is right now. that's why (i think) nobody replied
-[20:25:57] <blueness> disolve it and put patrick in charge of reconstituting it
-[20:25:57] <dberkholz> if the QA team has been dysfunctional/nonfunctional for this long, is it even something we need?
-[20:26:04] <blueness> dberkholz, yes
-[20:26:10] <blueness> we do
-[20:26:13] <dilfridge> So, step 2A would be to vote on Kensington's proposal to dissolve QA and call for new team members. (we can talk later about the detailed proceedings for that.)
-[20:26:21] <rich0> I'd like to first get the design of the team/purpose/etc worked out before we permanently staff it.
-[20:26:22] <dilfridge> dberkholz: yes we do.
-[20:26:28] <Zero_Chaos> hwoarang: no one can join QA right now. multiple people (including me) claim to have tried and been ignored...as the bugs are ignored
-[20:26:29] <hwoarang> looking at the bugs (and private threads) where qa@ is CC'd yes we need it
-[20:26:32] <dberkholz> blueness: what problems are we currently having as a result of this?
-[20:26:38] <blueness> the tinderbox runs are very useful even if they must be taken with a grain of salt
-[20:26:51] <rich0> If patrick wants to help with that I'd be glad to have him on-board, but I think the council should approve the final result and confirm the new team.
-[20:27:03] <dilfridge> dberkholz: comrel gets dragged into technical issues 
-[20:27:08] <rich0> So, you don't need a QA team to have a tinderbox.
-[20:27:09] <blueness> dberkholz, its not a question of which problems, its a question of consistency between systems
-[20:27:10] <dberkholz> i guess i'm asking whether it's rare enough that the council should directly resolve disputes
-[20:27:13] <blueness> eg --as-needed
-[20:27:18] <blueness> as an ldflag
-[20:27:29] <rich0> Anybody can test anything and log bugs if they're helpful.
-[20:27:42] <blueness> rich0, true
-[20:27:49] <blueness> but i would like QA to also run the tinderbox
-[20:27:51] <rich0> If Gentoo infra were being used I could see having a role to decide what it gets applied to/etc, but right now it is all private anyway.
-[20:28:01] <blueness> or at least work closely
-[20:28:11] <ulm> rich0: but not everyone has the authority to force changes
-[20:28:13] <rich0> blueness: I'd love to have QA run the tinderbox, but Gentoo doesn't actually own a tinderbox.
-[20:28:15] <blueness> rich0, we could make the tinderbox part of infra
-[20:28:26] <rich0> blueness: of course
-[20:28:32] <blueness> can't hurt to ask
-[20:28:39] <dilfridge> Right now ComRel gets dragged into technical issues, which is not Comrel job. That is what the QA team is for, deciding what is appropriate for the tree.
-[20:29:04] <rich0> I see QA as an executive team, and council as an oversight team.
-[20:29:05] <dilfridge> ComRel can't slap anyone for committing garbage.
-[20:29:08] <-> johu_ heißt jetzt johu
-[20:29:15] <ulm> dilfridge: the problem is that there aren't enough active members
-[20:29:20] <rich0> We can set major policies, but that doesn't mean that we have to second-guess every little QA decision/policy/etc.
-[20:29:33] <dilfridge> ulm: right now there are NO effective members. well, maybe luca.
-[20:29:38] <rich0> I'd like to have the council confirm the QA team so that they have real backing and authority.
-[20:29:55] <dilfridge> rich0: the current one? no way.
-[20:30:00] <rich0> People would know that if QA speaks the council is likely to back them up.  They could still appeal.
-[20:30:19] <rich0> dilfridge: that's why I want to fix it first.  I don't want to just rubber-stamp the status quo.
-[20:30:24] <ulm> dilfridge: there are more active members
-[20:30:34] <ulm> in subprojects mainly
-[20:30:37] <blueness> i'd like to see the QA team be highly skilled programmers to watch for and even pre-empt issue and provide consistency across our packages wrt how they are compiled/built
-[20:31:01] <dilfridge> ulm: we're not talking about subprojects, and kensington is also not talking about subprojects.
-[20:31:06] <blueness> in my mind QA = police, council = judiciary
-[20:31:18] <scarabeus> well we can do whatever we want but in result the current qa was quite demotivated by the results of most the appeals
-[20:31:19] <rich0> I think we need to distinguish between the advisory side of QA (tinderbox, testing, etc), and the executive side of QA (power to force changes, ban, etc).
-[20:31:48] <blueness> rich0, yes i agree with that, but I'd still like the two tied
-[20:31:48] <rich0> scarabeus: that's why I'd like to make sure QA and Council are on the same page.  That avoids all the second-guessing.
-[20:32:15] <rich0> Sure, they are related, but ANYBODY can run a tinderbox and log bugs/etc.  Nobody is going to object to that.
-[20:32:17] <dberkholz> rich0: yeah, i think it's reasonable to give council additional oversight on QA and comrel vs other teams, given the authority they have over people outside their projects
-[20:32:33] <rich0> What gets people fired up about QA is when somebody tells them they have to change something over their dead cvs access, or whatever.
-[20:32:41] <blueness> rich0, someone needs to decide if a tinderbox result is something that is advisory or compulsory
-[20:32:41] <dilfridge> yep
-[20:32:56] <dberkholz> rich0: particularly to avoid them turning into insular "old boy" groups
-[20:33:10] <rich0> Well, the results are advisory just due to their nature.  It is the policy that they're running against that is compulsory.
-[20:33:20] <ulm> rich0: +!
-[20:33:22] <ulm> +1
-[20:33:27] <dilfridge> well, not replying at all to applications for new members is the best way to become an "old boys group"
-[20:33:30] <dilfridge> +1
-[20:33:42] <rich0> Package ignores CFLAGS - that's information.  Package isn't allowed to ignore CFLAGS - that's policy.
-[20:33:42] <dilfridge> OK
-[20:33:51] <dilfridge> NOW
-[20:34:10] <dilfridge> shall we vote?
-[20:34:21] <blueness> dilfridge, pose the question
-[20:35:04] <dilfridge> 2A Kensington's proposal to dissolve QA and put out a call for new team members. (detailed proceedings for that to be decided afterwards.)
-[20:35:32] <ulm> we should decide what to do
-[20:35:39] <blueness> dilfridge, there are two questions there
-[20:35:44] <ulm> not dissolve qa and then come up with a plan
-[20:35:50] <dilfridge> ok 
-[20:35:59] <dilfridge> then let's discuss the proceedings first
-[20:36:18] <dilfridge> here's a more detailed proposal (will take a moment to type)
-[20:36:31] <rich0> I don't care whether we dissolve QA right now.  What I'd like is to have a team start designing a "new QA."  That doesn't need to be super-complicated.  The goal would be to replace QA with the results of that, including initial staffing.
-[20:36:58] <ulm> we could dissolve qa and have the council take the role of the qa lead temporarily, for accepting new members into the team
-[20:37:17] <ulm> afterwards, qa would elect a new lead
-[20:37:23] <ulm> (or even the old lead again)
-[20:37:37] --> graaff (~graaff@gentoo/developer/graaff) hat #gentoo-council betreten
-[20:37:43] <rich0> ulm: honestly, I'd like to really get to a system where QA doesn't just run itself completely independently.
-[20:37:56] <dilfridge> 2B. Dissolve QA (sans subprojects). Send an e-mail that interested devs should send Council a mail that they want to join QA. Council takes the role of the QA lead for two months, with elections in the team afterwards. Council accepts interested devs into the team with single secret majority vote.
-[20:38:14] <ulm> rich0: then we need to change glep 48
-[20:38:19] <dilfridge> s/single//
-[20:38:32] <rich0> ulm: Seems to be the season for changing GLEPs.  :)
-[20:38:46] <blueness> dilfridge, i don't know if i want this to be a completely democratic process though, i think the council should look for people with high technical skills
-[20:38:53] <rich0> I'd suggest creating a next-gen QA team with the goal of designing a new GLEP 48.
-[20:38:53] <hwoarang> i believe given the inactivity of the glep team, this will cause ever more delays...
-[20:39:04] <ulm> dilfridge: sounds good
-[20:39:13] <dilfridge> blueness: well it's up to us to decide.
-[20:39:23] <blueness> okay
-[20:39:34] <ulm> blueness: we're free to reject applicants
-[20:39:45] <dilfridge> ok let me clarify the text once more, just a second
-[20:39:48] <ulm> guess that's the reason for the secret vote
-[20:40:08] <blueness> ulm, i'm just worried about who the lead will be, if QA has a good lead, then the rest will fall into place
-[20:40:19] <dilfridge> 2C. Dissolve QA (sans subprojects). Send an e-mail that interested devs should send Council a mail that they want to join QA. Council takes the role of the QA lead for two months, with elections in the team afterwards. Council accepts interested devs into the team with secret majority vote of the council members.
-[20:40:50] <WilliamH> What do you mean "sans subprojects"?
-[20:40:54] <ulm> dilfridge: e-mail to whom? -dev-announce?
-[20:41:06] <dilfridge> I mean that we're not dissolving e.g. treecleaners.
-[20:41:17] <dilfridge> e-mail to council.
-[20:41:26] <scarabeus> sounds good
-[20:41:41] <ulm> dilfridge: no, I meant where we would send the e-mail ;)
-[20:41:57] <WilliamH> ulm: council@g.o
-[20:42:09] <dilfridge> we send our mail to gentoo-dev-announce to get maximum coverage. after all that's where all devs must be subscribed. 
-[20:42:11] <blueness> 2C sounds good
-[20:42:18] <ulm> k
-[20:42:21] <dilfridge> we accept applications at council@gentoo.org
-[20:42:44] <Arfrever> Do applications have to be secret?
-[20:43:08] <dilfridge> I dont think so, you can always copy the mail to somewhere else
-[20:43:14] <dilfridge> (if you want)
-[20:43:24] <WilliamH> Arfrever: well, we wouldn't stop people from saying that they have applied if they wanted to; that's up to them.
-[20:43:39] <rich0> I'd really like the proposed lead to be aligned with the council.  I'm still not sure that it is a good idea to just pick somebody and have them take over with the current structure.
-[20:43:40] <dilfridge> what I want to avoid is,
-[20:43:55] <rich0> If the current QA team feels like the council undercuts them, what will stop the new team from feeling this way?
-[20:43:59] <dilfridge> that someone is turned down and this becomes some sort of public shaming
-[20:44:10] <blueness> rich0, the current QA team can speak for themselves
-[20:44:27] <blueness> dilfridge, correct, the point of secrecy is to avoid hurt feelings
-[20:44:57] <dilfridge> anyway, the new QA lead in two months will be able to accept members too
-[20:45:00] <ulm> dilfridge: two months seems a bit too long
-[20:45:01] <rich0> blueness: I just don't think that the self-governing but powerful team with no formal oversight other than appeal system is really a good design.  We run all our big teams this way, and I think it can make them insular.
-[20:45:10] <dberkholz> i would like to see it move toward a model where the QA team votes for a lead but it requires council approval to put them in place.
-[20:45:15] <rich0> I think nominations should only be open for a week or two.
-[20:45:29] <rich0> Then I think we really should try to interview or otherwise interact with the candidates.
-[20:45:36] <rich0> dberkholz: ++
-[20:45:49] <dilfridge> dberkholz: good plan, how do we implemenet it?
-[20:45:54] <blueness> dberkholz, yes eventually
-[20:46:05] <rich0> Well, we can always just make it a policy.
-[20:46:13] <rich0> Or amend the current GLEP to say that.
-[20:46:30] <rich0> Just change the second bullet and leave the rest alone to start.
-[20:46:31] <ulm> dberkholz: that's against the systematics in all other projects
-[20:46:37] <dilfridge> shall we make "amedning the glep to say that" an additional vote?
-[20:46:55] <rich0> ulm: I think QA and comrel are not ordinary projects.
-[20:47:00] <dilfridge> ulm: yeah but qa is a special project (as is comrel)
-[20:47:07] <dberkholz> ulm: QA and comrel are exceptional projects because they have power over developers not part of their project
-[20:47:08] <ulm> and I wouldn't want to be a member of a project with a lead not appointed by the project members themselves
-[20:47:15] <rich0> If QA were like all other projects, then I could start my own QA project today and be the lead of that project.
-[20:47:39] <rich0> Other projects don't have distro-wide authority.
-[20:47:42] <dilfridge> ulm: elected by the members, confirmed by the council?
-[20:48:02] <dilfridge> (not, chosen by the council but council can reject)
-[20:48:08] <dilfridge> s/,//
-[20:48:13] <ulm> if we don't trust the new qa to be able to elect a reasonable person as team lead, then we should just give up
-[20:48:15] <rich0> If the council doesn't confirm, they can pick a new lead.  If things aren't worked out in some period of time council appoints a lead.
-[20:48:31] <rich0> ulm: giving up on the current system is EXACTLY what I'm proposing.
-[20:48:32] <dilfridge> anyway this all is a separate discussion
-[20:48:45] <rich0> Why not just have each council appoint the new council.  Can't we be trusted to do a good job with that?
-[20:48:53] <dberkholz> ulm: isn't that what we've already done just by having this item on the agenda?
-[20:48:53] <dilfridge> let me re-formulate the proposal one last time...
-[20:48:56] <blueness> rich0, heh
-[20:49:01] <dberkholz> ulm: it seems like you're arguing that the current situation could never happen again
-[20:49:27] <ulm> we have it on the agenda because sort of a deadlock sitation arose
-[20:49:34] <ulm> *situation
-[20:49:39] <blueness> the argument might go like this: the council is elected by all devs, so we are being trusted with judiciary powers.  QA is not elected by all devs and yet has power over all devs.  so it needs extra oversight
-[20:49:48] <ulm> that doesn't mean that it will happen again
-[20:50:03] <blueness> that extra oversight is the council approves the lead, to make sure the QA team doesn't go crayz
-[20:50:21] <rich0> blueness: that, and the QA team has some kind of mandate
-[20:50:30] <ulm> blueness: as I said, glep 48 needs to be changed then
-[20:50:40] <blueness> ulm, i agree i think it does
-[20:50:43] <rich0> Well, changing GLEP 48 just to codify that is simple.
-[20:50:48] <dilfridge> 2D. Dissolve QA (sans subprojects). Send an e-mail to gentoo-dev-announce that interested developers should send council@gentoo.org a mail in the next two weeks that they want to join QA. Council takes the role of the QA lead for six weeks, with elections in the team afterwards. Council accepts interested devs into the team with secret majority vote of the council members.
-[20:50:53] <rich0> Let the team work out the details.
-[20:51:00] <WilliamH> The other side of extra oversite is that there is no point to appealing to the council if  qa does something you don't agree with?
-[20:51:00] <dilfridge> Let us vote on 2D now and discuss the GLEP afterwards.
-[20:51:18] <dberkholz> yes, glep 48 needs about 5 words added to the 2nd bullet "and confirmed by the council"
-[20:51:30] <rich0> I'm fine with voting on that, as long as the council is under no obligation to appoint anybody in six weeks.
-[20:51:34] <blueness> i'm ready to vote
-[20:51:49] -*- dilfridge yes on 2D
-[20:51:55] -*- rich0 yes on 2d
-[20:51:56] -*- blueness yes on 2D
-[20:52:10] <scarabeus> yup
-[20:52:16] <WilliamH> please restate 2d again? It has scrolled off?
-[20:52:24] <dilfridge> 2D. Dissolve QA (sans subprojects). Send an e-mail to gentoo-dev-announce that interested developers should send council@gentoo.org a mail in the next two weeks that they want to join QA. Council takes the role of the QA lead for six weeks, with elections in the team afterwards. Council accepts interested devs into the team with secret majority vote of the council members.
-[20:52:53] <ulm> I abstain
-[20:52:55] <ulm> as I am a member of the current QA team
-[20:53:49] <dilfridge> dberkholz: WilliamH?
-[20:54:21] <blueness> did we loose them?
-[20:54:39] -*- WilliamH is still here thinking...
-[20:54:42] <dberkholz> abstain, it already passed and i'm not confident enough that it's the right answer
-[20:55:10] <WilliamH> abstain also; I'm not confident.
-[20:55:15] <rich0> dberkholz: I plan to offer some proposals on a revised GLEP 48 - there is no reason that we can't pass that before we appoint a new QA lead.
-[20:55:27] <dilfridge> ok that's 4 yes and 3 abstain, motion passed.
-[20:55:29] <rich0> No reason we can't get the ball rolling though.
-[20:55:40] <dilfridge> Now about GLEP48
-[20:55:58] <ulm> rich0: I think the new qa team should at least be heard on their opinion on a new glep 48
-[20:56:11] -*- WilliamH tends to agree
-[20:56:12] <rich0> Sure, but I'll hear that before I vote to put anybody on a new QA team.
-[20:56:19] <ulm> even if it's up to the council to approve it
-[20:56:24] <dberkholz> yeah we'll need to send the mods around for discussion
-[20:56:24] <rich0> There won't be a new QA team as far as I'm concerned until those issues are sorted out.
-[20:56:50] <rich0> However, no need to bikeshed it right now.
-[20:56:55] <dilfridge> ulm: we can change the rules later again, but for now we need some set of rules to play by
-[20:56:59] <Zero_Chaos> rich0: I think it is fair to ask the "new QA team" to fix the glep as their first official act.
-[20:57:10] <WilliamH> rich0: My concern about making the lead chosen by the council is that can get into a situation where
-[20:57:11] <dilfridge> OK let's vote on
-[20:57:18] <rich0> I'm also fine with interim appointments - such as giving them a six month term to fix things/etc.
-[20:57:19] <dberkholz> i think we should add "and confirmed by the council" to the 2nd bullet point, 1st sentence, as a draft for discussion
-[20:57:21] <dilfridge> 2E should we change GLEP48 now?
-[20:57:26] <dberkholz> and send it around to -dev then vote
-[20:57:55] <rich0> dberkholz: agree.  I can send a draft out to the list, and we can vote next meeting?
-[20:58:00] <blueness> dilfridge, 2E is too open, sould we say what we're changing?
-[20:58:04] <dberkholz> or -project, wherever seems appropriate
-[20:58:13] <dilfridge> OK
-[20:58:20] <scarabeus> the voting next time sounds feasible, and we should sent this to project :)
-[20:58:26] <WilliamH> probably -project
-[20:58:34] <dberkholz> certainly a unilateral vote on a glep change by council without any opportunity for community discussion seems wrong
-[20:58:43] -*- WilliamH agrees with dberkholz 
-[20:58:56] <dilfridge> dberkholz: scarabeus: next meeting sounds good, since that is also still before the qa team election
-[20:59:00] <rich0> Well, not bad - we got through half of one agenda item in an hour.  :)
-[20:59:09] <rich0> That was a big one though.
-[20:59:10] <WilliamH> How long are we taking applications for members?
-[20:59:16] <dilfridge> two weeks
-[20:59:18] <rich0> Per the proposal - two weeks.
-[20:59:28] <WilliamH> ok
-[20:59:32] <blueness> okay with me
-[20:59:48] <dilfridge> I think Polynomial-C's proposal is now off the table, does anyone disagree with that?
-[20:59:58] <Polynomial-C> :)
-[20:59:58] <dilfridge> (adding Patrick to the QA team)
-[21:00:16] <WilliamH> If he wants to be added he can feel free to apply. :-)
-[21:00:18] <dilfridge> good
-[21:00:45] <dilfridge> now since we've reached the magical limit of 60min, let's stop here and reconvene in a week...
-[21:00:59] <WilliamH> heh ok.
-[21:01:00] <dilfridge> and I'll summarize the result
-[21:01:04] <blueness> okay
-[21:01:05] <scarabeus> hehe oky
-[21:01:12] <blueness> that was a thorny issue though
-[21:01:30] <dilfridge> well yes, we definitely decided something.
-[21:01:38] -*- dilfridge bangs on the table.
-[21:01:40] <WilliamH> It needed to be addressed; the qa situation wasn't good.
-[21:01:42] <dilfridge> meeting closed.
-[21:02:12] <scarabeus> :)
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20131119-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20131119-summary.txt
deleted file mode 100644
index aa216c3bf5..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20131119-summary.txt
+++ /dev/null
@@ -1,132 +0,0 @@
-Summary of the Gentoo Council meeting 19 November 2013
-
-
-
-Agenda
-======
-
-1. Roll call
-
-2. Request for a minimal policy for pgp keys and key handling (for commit 
-   signing) [2,3,4]
-
-3. Removing last keyworded package version for a minor arch [5]
-
-4. Metastructure: Dead projects [6,7]
-
-5. Metastructure: Reorganization of the project tree [8,9]
-
-6. Modernization/adaption of the Code of Conduct, the return [10]
-
-7. Revival of archives.gentoo.org [11]
-
-8. Open bugs with council involvement
-   * Bug 477030 - Missing summary for 20130611 council meeting [12]
-
-9. Open floor
-
-[ 1] http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00
-[ 2] <527053EF.9080200 <at> gentoo.org>
-[ 3] http://dev.gentoo.org/~dilfridge/mail-4.txt
-[ 4] http://thread.gmane.org/gmane.linux.gentoo.project/3155
-[ 5] http://article.gmane.org/gmane.linux.gentoo.project/3110
-[ 6] <201310292251.02052.dilfridge <at> gentoo.org>
-[ 7] http://dev.gentoo.org/~dilfridge/mail-6.txt
-[ 8] <201310292255.04913.dilfridge <at> gentoo.org>
-[ 9] http://dev.gentoo.org/~dilfridge/mail-7.txt
-[10] http://www.gentoo.org/proj/en/council/meeting-logs/20131008.txt
-[11] http://article.gmane.org/gmane.linux.gentoo.devel.announce/2025
-[12] https://bugs.gentoo.org/show_bug.cgi?id=477030
-
-
-
-Roll call
-=========
-
-Present:
-   blueness, dberkholz, dilfridge, rich0, scarabeus, ulm, williamh
-
-
-
-Request for a minimal policy for pgp keys and key handling (for commit 
-   signing) [2,3,4]
-======================================================================
-
-After some discussion about details (e.g. the merits of a key expiration date
-and the functionality of key revocation certificates) the following resulution
-was accepted unanimously:
-
-"We appreciate the GLEP draft submitted by robbat2 in above mailing list post 
-[4], and look forward to approving a final version with additional minor changes 
-merged in."
-
-
-
-Removing last keyworded package version for a minor arch [5]
-============================================================
-
-The proposal by rich0 in [5] was accepted unanimously. The modified rule now 
-reads:
-
-"If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a
-pending STABLEREQ, for 90 days with archs CCed and otherwise ready
-to be stabilized, the maintainer can remove older versions of
-the package at their discretion. A package is considered ready to be
-stabilized if it has been in the tree for 30 days, and has no known
-major flaws on arches that upstream considers supported."
-
-
-
-Metastructure: Dead projects [6,7]
-==================================
-
-For all three projects listed in the e-mail (Kolab, GSE, Gentoo/Alt AT) the 
-following resolution was passed with 6 yes votes:
-
-"Remove the project web page, and if noone cares, all is done."
-
-
-
-Metastructure: Reorganization of the project tree [8,9]
-=======================================================
-
-Consensus was that such and similar changes should rather be made in small steps
-and make more sense once the migration of the project pages to the wiki is 
-complete. No action was taken.
-
-
-
-Modernization/adaption of the Code of Conduct, the return [10]
-==============================================================
-
-A minimally modernized version of the CoC page "Consequences" section was 
-presented by dilfridge. Consensus was that - since this is a sensitive area -
-the text will be sent to the project mailing list for discussion and decided
-in the next council meeting. 
-
-
-
-Revival of archives.gentoo.org [11]
-===================================
-
-The current technical problems with archives.gentoo.org were discussed, and the 
-council was CCed to bug 424647. No further action was taken.
-
-
-
-Open bugs with council involvement
-==================================
-
-* Bug 477030 - Missing summary for 20130611 council meeting [12]
-  Consensus is to continue annoying betelgeuse for that.
-
-
-
-Open floor
-==========
-
-TomWij remarks that some documentation changes or clarifications are pending and 
-will be brought up in a future meeting, regarding:
-* new project to be filed on wiki, authors not marked as retired, ...
-* KEYWORD="" and/or package.mask
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20131119.txt b/xml/htdocs/proj/en/council/meeting-logs/20131119.txt
deleted file mode 100644
index 48f014b867..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20131119.txt
+++ /dev/null
@@ -1,382 +0,0 @@
-[20:02:51] * dilfridge has changed topic for #gentoo-council to: "Next meeting: 19 Nov 2013 at 19:00 UTC, i.e. NOW | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | http://wiki.gentoo.org/wiki/Project:Council | Agenda: http://article.gmane.org/gmane.linux.gentoo.devel.announce/2029"
-[20:03:12] <dilfridge> ok lets get this meeting started!
-[20:03:18] <blueness> roll call!
-[20:03:33] <dilfridge> blueness: dilfridge: rich0: scarabeus: ulm: WilliamH: dberkholz - roll call!
-[20:03:38] -*- rich0 here
-[20:03:45] --> dberkholz|web (0cb05905@gentoo/developer/dberkholz) hat #gentoo-council betreten
-[20:03:46] -*- blueness here
-[20:03:49] <dberkholz|web> hi
-[20:03:55] -*- ulm here
-[20:04:05] <dberkholz|web> can't ssh to woodpecker for some reason so enjoying freenode's web interface
-[20:05:18] -*- dilfridge is picking out WilliamH and scarabeus mobile numbers
-[20:05:33] <dberkholz> ah, there we go.
-[20:05:36] <dberkholz> yay for hotel internet
-[20:07:20] <dilfridge> ok I messaged WilliamH, 
-[20:07:32] <dilfridge> will do scarabeus and then we start
-[20:08:11] <blueness> k
-[20:08:41] -*- WilliamH is here
-[20:08:49] --> graaff (~graaff@gentoo/developer/graaff) hat #gentoo-council betreten
-[20:09:05] <dilfridge> done
-[20:09:14] <dilfridge> if he doesnt turn up now there's no help :)
-[20:09:20] <dilfridge> ook
-[20:09:22] <scarabeus> ah thanks for the ping
-[20:09:25] -*- scarabeus here
-[20:09:28] <dilfridge> :)
-[20:09:40] <dilfridge> Now, let's REALLY start.
-[20:10:05] <dilfridge> Agenda topic 2: Request for a minimal policy for pgp keys and key handling (for commit 
-[20:10:05] <dilfridge>    signing)
-[20:10:21] <dilfridge> did robbat2 send out another e-mail today?
-[20:10:26] <dilfridge> I thought he wanted to
-[20:10:55] <dilfridge> but I didnt get any
-[20:11:09] <ulm> I'd much prefer if this was a regular glep
-[20:11:18] <blueness> i didn't get any, but i did see the two extra links he had
-[20:11:21] <ulm> not some unnumbered draft
-[20:11:31] -*- WilliamH agrees with ulm
-[20:11:37] <dilfridge> ulm: yes I see your point, but do we have a glep team?
-[20:11:44] <blueness> ulm, i agree, we can pass with with the condition that it be glep-ed
-[20:12:20] <WilliamH> Are we grandfathering in old keys that do not meet the criteria?
-[20:12:22] <ulm> blueness: sounds good
-[20:12:33] <dilfridge> could we say, we recommend this be fully formalized and look forward to confirming it?
-[20:12:47] <Zero_Chaos> WilliamH: please no
-[20:12:53] <WilliamH> dilfridge: sounds good to me.
-[20:12:55] <dilfridge> WilliamH: better not
-[20:12:58] <ulm> WilliamH: maybe with some longish transition period?
-[20:13:11] <dilfridge> long-ish means what? 1 year?
-[20:13:23] <ulm> something like that
-[20:13:24] <blueness> something like that
-[20:13:27] <ulm> :)
-[20:13:31] <blueness> heh
-[20:13:50] <dilfridge> I'd honestly prefer if the transition period were over the moment we really start the git transition
-[20:13:53] <dberkholz> way too long
-[20:14:06] <dberkholz> 3 months should be more than enough time for people to read a doc and follow the instructions
-[20:14:11] <dilfridge> because then the keys may really be used
-[20:14:25] <WilliamH> dberkholz: seems reasonable
-[20:14:35] <dilfridge> but I have no idea on the timescale there
-[20:14:45] <dilfridge> no objections against 3 months from me
-[20:14:48] <Hello71> [21:28:24] <creffett> robbat2: *GLEP hat on* when are you planning to submit the proposal for formal GLEPification?
-[20:14:53] <blueness> who's going to enforce it, i bet there will be lots of devs who will be sloppy about it
-[20:14:53] <Hello71> [21:28:46] <robbat2> how about in 30 mins when I finish the edits?
-[20:14:57] -*- WilliamH grumbles about the git migration taking way too long
-[20:15:04] <-- ssuominen (~ssuominen@gentoo/developer/ssuominen) hat das Netzwerk verlassen (Ping timeout: 272 seconds)
-[20:15:24] <dberkholz> easy to grumble, harder to do the work =)
-[20:15:30] --> ssuominen (~ssuominen@gentoo/developer/ssuominen) hat #gentoo-council betreten
-[20:15:31] <dilfridge> Hello71: what's your timezone? i.e. how long ago was that? :)
-[20:15:44] <ulm> and what would we do if a dev doesn't update his key in time?
-[20:15:46] <Zero_Chaos> dilfridge: last night
-[20:15:53] <ulm> revoke commit access?
-[20:16:13] <scarabeus> nah just suspend it until he comply
-[20:16:26] <dilfridge> ulm: well, in an ideal world commit just wouldnt work because only properly signed commits go in
-[20:16:28] <scarabeus> and he gets lost access if he is not active, so that is covered
-[20:16:47] <ulm> well, how about enforcing signed commits, in the first place? ;)
-[20:17:01] <dilfridge> chicken, egg, chicken, egg, ...
-[20:17:09] <blueness> repoman could check the key size
-[20:17:31] <blueness> i'm not worried about imposing all the criteria (eg expires in 3 years) but the keysize is important
-[20:17:34] <dilfridge> that's actually something the qa team could do too
-[20:17:37] -*- dilfridge ducks
-[20:17:52] <blueness> dilfridge, i was thinking that but didn't dare say!
-[20:18:03] -*- WilliamH isn't really worried about expiration either.
-[20:18:03] <dilfridge> anyway
-[20:18:13] <dberkholz|web> maybe the "QA lead" should take responsibility =P
-[20:18:21] <dilfridge> there are best practices and it's best to follow all of them, 
-[20:18:49] <dilfridge> and since we are talking about minimum and recommended policies here we should not weaken them unnecessarily
-[20:19:05] <dilfridge> i.e. robbat2 knows his stuff
-[20:19:26] <blueness> security vs convenience
-[20:19:49] <dilfridge> yeah but we're talking not only about our own personal security here
-[20:20:05] <ulm> IMHO, getting rid of < 2048 bit RSA is the most important point
-[20:20:07] <dilfridge> and to be honest using cvs is the bigger inconvenience :)
-[20:20:15] <ulm> I don't care much about the rest
-[20:20:31] <ulm> well, maybe except for SHA1
-[20:20:52] <blueness> we should have a deprecation plan, ie tell devs to sign their old 1024 keys with their >=2048RSA/DSA keys
-[20:21:29] <dilfridge> not sure if that is needed, since nothing uses the keys so far
-[20:21:49] <dilfridge> however, once we start using them, they should adhere to the guidelines
-[20:21:56] <blueness> dilfridge, there are devs signing their manifests with keys now
-[20:22:08] <dilfridge> blueness: yes but does anything check these sigs? 
-[20:22:19] <blueness> true
-[20:22:23] <ulm> dilfridge: they will be used if robbat2's tree signing gleps are implemented
-[20:22:25] <blueness> humans can
-[20:22:30] <dilfridge> (I'm doing that too, but it's an exercise in pointlessness)
-[20:22:36] <ulm> which I guess will be shortly after git migration
-[20:22:58] <dilfridge> ulm: exactly, and that's imho the time when all the keys shoudl follow our new standard
-[20:23:16] <ulm> so transition time can be looong :p
-[20:23:17] <blueness> dilfridge, yeah sounds reasonabl
-[20:24:12] <dilfridge> ok I pinged robbat on infra channel
-[20:24:34] <dilfridge> so
-[20:24:50] <dilfridge> we don't have a "latest document version" unfortunately
-[20:25:03] --> robbat2 (~robbat2@gentoo/developer/robbat2) hat #gentoo-council betreten
-[20:25:15] <dilfridge> what shall we do, postpone for next week?
-[20:25:15] <blueness> hi robbat2
-[20:25:17] <robbat2> hi, sorry about not updating the GLEP, work stuff
-[20:25:24] <dilfridge> hi!
-[20:25:36] <blueness> robbat2, we're thinking we should see a final glep before voting
-[20:25:53] <robbat2> does this council still do vote-by-email like prior councils?
-[20:26:02] <dilfridge> if necessary yes
-[20:26:12] <robbat2> and/or do you have any concerns you'd like me to answer now?
-[20:26:18] -*- dilfridge no
-[20:26:28] -*- WilliamH doesn't think so
-[20:26:46] <robbat2> ok, just a merged final version for your seal of approval
-[20:27:09] <dilfridge> how does it get a glep number? /me has no idea
-[20:27:32] <dberkholz|web> the glep editor assigns one
-[20:27:34] <robbat2> i'll have it in a day or two I hope, i just want to review the ENISA paper that dilfridge linked in another channel
-[20:27:48] <dberkholz|web> it's in glep 1: http://www.gentoo.org/proj/en/glep/glep-0001.html
-[20:28:00] <dilfridge> who's the glep editor?
-[20:28:52] <ulm> dilfridge: the project page says antarus, but I don't know if he still has the job
-[20:29:16] <robbat2> i'll find somebody to do it
-[20:29:22] <dilfridge> ok there's one serious question (robbat2 maybe you can comment), when shall it come into effect, i.e. how long is transition period
-[20:29:22] <blueness> robbat2, the only concern i had about the min requirements was the expiration date of 3 years rather than never, i'm afraid people might forget.  i know its a good idea, but how bad would it be if people didn't do that?
-[20:29:35] <ulm> robbat2: well, just take the next free number ;)
-[20:30:18] <robbat2> blueness, the required expiry is there so if they lose their key and didn't make a revocation cert, the key does go away
-[20:30:21] <robbat2> in time
-[20:30:27] <robbat2> *lose their private key
-[20:30:57] <blueness> robbat2, i figured that, but can't the revocation keys be made public? or no?
-[20:31:06] <robbat2> no, they can't
-[20:31:09] <dilfridge> no
-[20:31:14] <Zero_Chaos> robbat2: shouldn't revocation certs be held by a central authority? I mean, what happens when a dev quits and doesn't revoke his own key?
-[20:31:22] <blueness> they need a passphrase and the private key to unlock, no?
-[20:31:40] <ulm> could we require that devs have either a revocation cert or expiry time?
-[20:31:48] <robbat2> no, revocation certs do NOT need any additional auth to use
-[20:31:48] <dilfridge> blueness: no, a revoke sig is just a signature, anyone can add it to a key if he has it
-[20:32:06] <dberkholz> ulm: that defeats the point of what robbat2 just said
-[20:32:11] <robbat2> Zero_Chaos, why would I have to revoke my key if I quit?
-[20:32:11] <dberkholz> 19:30 <   robbat2 > blueness, the required expiry is there so if they lose their key and didn't make a revocation cert, the key does go away
-[20:32:15] <blueness> dilfridge, k i've used one but never looked at it carefully
-[20:32:34] <dberkholz> ulm: and frankly it's a lot more likely that someone loses the key *and* the revocation cert
-[20:32:40] <robbat2> I want to clarify something here:
-[20:32:43] <dilfridge> basically if I had your revocation cert, I could add it to your public key and update your key on the keyserver
-[20:32:45] -*- blueness thinks i need to write a nagging script for the community to remind them their key is ab out to expire!
-[20:32:46] -*- WilliamH agrees with robbat2 about revoking a key
-[20:32:47] <Zero_Chaos> robbat2: so you can't sign things and have them be from a valid gentoo dev?
-[20:32:56] <robbat2> this GLEP ONLY covers what GPG keys a dev must have
-[20:33:07] <ulm> dberkholz: this can only happen if he's extremely badly organised
-[20:33:08] <robbat2> it does NOT cover the trustweb from gentoo(infra) to devs
-[20:33:12] <dilfridge> right
-[20:33:17] <dilfridge> OK 
-[20:33:18] <blueness> i gathered that
-[20:33:18] <Zero_Chaos> okay, retracted
-[20:33:24] <dberkholz> ulm: i would never assume that every dev is well organized
-[20:33:27] <chithead> if you want you can set key expiry at 1d and use a new key every day
-[20:33:32] <ulm> heh
-[20:33:34] <dilfridge> can we agree that having an expiry time is a good thing?
-[20:33:37] <robbat2> Zero_Chaos, i can answer your question later in another channel
-[20:33:44] <blueness> dilfridge, yes
-[20:33:45] <robbat2> but trust me, it's not a problem
-[20:34:02] <blueness> i'm convince the goods of the expiration date outweigh the evils
-[20:34:03] <dilfridge> ok
-[20:34:06] <Hello71> popular CAs limit SSL certificate duration to 5 years atm, no?
-[20:34:11] <robbat2> or less
-[20:34:26] <dilfridge> so, to finish this I would suggest
-[20:34:39] <dilfridge> let's put to a vote
-[20:35:11] <robbat2> preliminary approval of the GLEP, pending merging the final edits for later approval
-[20:35:19] <dberkholz> sure
-[20:35:41] <blueness> works for me
-[20:35:43] <dilfridge> 2: we appreciate and approve robbat2's efforts as shown on the mailing list and look forward to signing off the final version of his glep on gpg key policies
-[20:36:07] <dilfridge> ^ everyone?
-[20:36:10] <rich0> agree - I think the direction is good - just need to nail down just what we approve
-[20:36:22] -*- WilliamH yes
-[20:36:25] <ulm> could you please post the link to the draft that we preliminary approve?
-[20:36:59] <dilfridge> http://thread.gmane.org/gmane.linux.gentoo.project/3155
-[20:37:05] <dilfridge> ok let me reformulate
-[20:38:40] <dilfridge> 2A: We appreciate the GLEP draft submitted by robbat2 in above mailing list post, and look forward to approving a final version with additional minor changes merged in.
-[20:39:00] <dilfridge> better?
-[20:39:12] <robbat2> (weight=0) aye
-[20:39:24] <rich0> sure
-[20:39:29] <ulm> yep
-[20:39:30] -*- dilfridge yes
-[20:39:34] <dberkholz> k
-[20:39:35] -*- WilliamH yes
-[20:39:49] -*- blueness yes
-[20:39:51] <ulm> though I still think that 4096 bits are overkill, unless we require everybody to have well-paid armed guards protecting his keys ;)
-[20:39:53] <scarabeus> k
-[20:40:01] <dilfridge> ok that's 7 yes, unanimous :)
-[20:40:28] <dilfridge> next topic
-[20:40:37] <dilfridge> (wow, we get to do more than one topic today!)
-[20:40:44] <dilfridge> 3. Removing last keyworded package version for a minor arch [5]
-[20:40:55] <dilfridge> http://article.gmane.org/gmane.linux.gentoo.project/3110
-[20:41:16] <dberkholz> i'm ready to just vote on that
-[20:41:41] <blueness> ditto
-[20:41:42] -*- dilfridge reading
-[20:41:54] -*- WilliamH reading
-[20:42:02] <blueness> key point -> Surely if a stable version can be removed, an unstable one could be...
-[20:42:34] <dilfridge> ok as for me we can vote too
-[20:42:48] <rich0> hold on - I have serious concerns with that proposal.  :)
-[20:42:52] -*- rich0 ducks
-[20:43:04] -*- WilliamH agrees, if a stable version can be removed, so can an unstable one.
-[20:43:22] <dilfridge> do we need to write this out? I suggest voting on the e-mail, I'll paste it into the log later.
-[20:43:33] <dilfridge> 3: http://article.gmane.org/gmane.linux.gentoo.project/3110
-[20:43:39] <dilfridge> ^ everyone?
-[20:43:46] -*- rich0 yes
-[20:43:52] <dberkholz> yes
-[20:43:54] -*- dilfridge yes
-[20:43:58] -*- WilliamH votes yes
-[20:44:01] -*- blueness yes
-[20:44:16] -*- ulm yes
-[20:44:48] <dilfridge> 6 yes, 1 MIA, motion passed
-[20:45:08] <dilfridge> next topic!!!
-[20:45:25] <dilfridge> 4. Metastructure: Dead projects [6,7]
-[20:45:31] <scarabeus> hum i thought i said yes previously :P
-[20:45:37] <scarabeus> so just count that in :)
-[20:45:37] <dilfridge> http://dev.gentoo.org/~dilfridge/mail-6.txt
-[20:46:00] <dilfridge> none of these three projects evoked any response
-[20:46:18] -*- ulm looking at our metastrcture
-[20:46:19] <blueness> i'm not sure what to do with them though, do we remove the project pages?
-[20:46:43] <dilfridge> "remove" is relative in cvs
-[20:47:05] <dilfridge> but yes, I'd suggest so, since they are way outdated
-[20:47:40] <rich0> makes sense
-[20:47:53] <dilfridge> unless someone suddenly jumps in and says "nononono, it's still alive and (occasionally) kicking"
-[20:47:58] <ulm> http://www.gentoo.org/proj/en/gentoo-alt/at/index.xml
-[20:48:00] <ulm> http://www.gentoo.org/proj/en/gse/index.xml
-[20:48:21] <ulm> http://www.gentoo.org/proj/en/kolab/index.xml
-[20:48:42] -*- ulm never even heard of these projects
-[20:48:48] <blueness> did neddyseagoon responde for Gentoo Support Everywhere ?
-[20:49:07] <dilfridge> nobody responded for any of this
-[20:49:16] <dilfridge> but maybe he's not on -project
-[20:49:20] <dilfridge> we could ask him
-[20:49:28] <scarabeus> i would jus tkill them :) and let them start anew in wiki if they want?
-[20:49:31] <blueness> he's the only dev i recognize
-[20:49:32] <dberkholz> the alt arch-testers is a subproject, i don't see why that's something the council should care about
-[20:49:47] <dilfridge> shrug, ok
-[20:50:11] <dberkholz> just ask the alt team to trash it
-[20:50:17] <dilfridge> yep
-[20:50:43] <dilfridge> general question, is this even something we should bother about?
-[20:51:00] -*- dilfridge is a bit "meh"
-[20:51:19] <dilfridge> the kolab project looks most certainly dead
-[20:51:25] <dilfridge> http://overlays.gentoo.org/proj/kolab/browser/overlay
-[20:51:40] <Hello71> take a vote on it ;)
-[20:51:52] <blueness> actually scarabeus' idea is not bad
-[20:51:55] <dberkholz> dilfridge: yeah, we should care because it's just confusing to people when we document things that don't exist
-[20:52:09] <dilfridge> ok
-[20:52:15] <blueness> just remove the pages and if no one cares its done, otherwise start over on the wiki
-[20:52:26] <dilfridge> let's decide this stuff by voting
-[20:52:45] <dilfridge> 4: for all three projects, remove project page and if noone cares it's done
-[20:52:52] <dilfridge> everyone? ^
-[20:53:19] -*- blueness yes
-[20:53:22] <rich0> Sure - and if anybody ever wants to resurrect them, no objections from us
-[20:53:23] -*- rich0 yes
-[20:53:27] <scarabeus> yes
-[20:53:28] -*- dilfridge yes
-[20:54:04] -*- ulm yes
-[20:54:13] -*- WilliamH yes
-[20:54:22] <dilfridge> that's 5 yes, motion passed
-[20:54:31] <dilfridge> 6 yes
-[20:54:55] <dilfridge> next topic
-[20:55:09] <dilfridge> 5. Metastructure: Reorganization of the project tree [8,9]
-[20:55:18] <dilfridge> http://dev.gentoo.org/~dilfridge/mail-7.txt
-[20:55:30] <ulm> I'd rather not waste time for reorganising the project tree in proj/en
-[20:55:33] <dilfridge> I brought this up, but now I'm not so convinced anymore that it's a good idea
-[20:55:49] <ulm> let's wait until we have more complete coverage in the wiki and then do it there
-[20:55:55] <dilfridge> yeah
-[20:56:07] -*- scarabeus agress
-[20:56:10] <scarabeus> ees
-[20:56:14] <scarabeus> just convert to wiki and then do it there
-[20:56:19] <rich0> Make sense.  We can always do alignments little-by-little where it makes sense.
-[20:56:19] -*- WilliamH agrees
-[20:56:23] <dilfridge> what we could do is ask george if there is still any point in his umbrella project
-[20:56:28] <dberkholz> yeah, i think we'll reorganize the website content significantly once we've got stuff in the wiki
-[20:56:30] <rich0> If anybody can start a project we'll always have loose nodes.
-[20:56:36] <dilfridge> if not we just forget about that during the wiki conversion
-[20:57:17] <dilfridge> does anyone want to decide, vote, discuss something still here?
-[20:57:32] -*- WilliamH has nothing  for this
-[20:57:33] <ulm> rich0: yeah, but in the wiki it's easy to adjust things later on
-[20:57:53] <ulm> it's flat namespace, with links between projects
-[20:58:13] <dilfridge> seems no... with the wiki conversion the namespace becomes flat anyway.
-[20:58:14] <ulm> trivial to convert a tlp to a subproject
-[20:58:26] <dilfridge> ok
-[20:58:36] <dilfridge> then let's conclude this as well.
-[20:58:44] <dilfridge> next topic!
-[20:58:55] <dilfridge> 6. Modernization/adaption of the Code of Conduct, the return [10]
-[20:59:07] <ulm> "the return"?
-[20:59:25] <dilfridge> well, yes :)
-[20:59:39] <dilfridge> (as in "of the Jedi")
-[21:00:01] -*- dilfridge admonishes dilfridge to be more professional during council session
-[21:00:04] -*- scarabeus didn't have time to look on it due to opensuse release that hapened today :P
-[21:00:19] <scarabeus> so i know dilfridge did some updates there so it is more of his topic now
-[21:00:28] <dilfridge> ok let me post the links, just a moment
-[21:01:29] <dilfridge> http://dev.gentoo.org/~dilfridge/coc-minimal-new.txt
-[21:01:34] <dilfridge> http://dev.gentoo.org/~dilfridge/coc-old.txt
-[21:02:20] <dilfridge> the "minimal-new" version is the best I could come up with so far, it's mainly new terms (e.g. ComRel) but also some adaption to realities
-[21:02:34] <-- dberkholz|web (0cb05905@gentoo/developer/dberkholz) hat das Netzwerk verlassen (Ping timeout: 250 seconds)
-[21:02:36] <dilfridge> maybe we shouldn't decide on this now, but read it and take it home
-[21:02:57] -*- WilliamH reads
-[21:03:04] <rich0> I don't really care for the last sentence - being invovled isn't a conflict of interest - having a stake in the outcome is a conflict of interest.
-[21:03:30] <rich0> But that seems to be a Gentoo thing - no other org that I'm aware of uses the Gentoo definition of conflict of interest.  :)
-[21:03:31] <dilfridge> the last sentence is actually a weakened version of an old one
-[21:03:48] <dilfridge> "To prevent conflicts of interest, Council members may not perform the duties of a proctor."
-[21:04:56] <rich0> I'd really prefer that it said something like "Council members and Community Relations members are expected to not participate in cases in which they have a conflict of interest." or something like that.
-[21:05:03] <dilfridge> why not
-[21:05:27] <rich0> Or better still "Council members and Community Relations members are expected to declare and not participate in cases in which they have a conflict of interest."
-[21:06:04] <rich0> However, I won't vote against the improved CoC as it currently stands.
-[21:06:26] <rich0> I realize that this is a sensitive area for whatever reason.  Not the hill I need to die on...
-[21:06:38] <dilfridge> my suggestion: we think about this and vote in the next regular session, and I can also send it to the ml for comments.
-[21:06:55] -*- WilliamH agrees with dilfridge 
-[21:07:05] <dilfridge> then we could actually finish our agenda today!
-[21:07:10] <blueness> okay
-[21:07:36] <rich0> Sure - we can turn that into its own little thread and then incorporate whatever we settle on.
-[21:07:56] <dilfridge> any additional comments?
-[21:08:25] <dilfridge> seems not
-[21:08:27] <blueness> nope
-[21:08:31] <dilfridge> good
-[21:08:44] <dilfridge> 7. Revival of archives.gentoo.org [11]
-[21:08:51] <scarabeus> what we can do there?
-[21:09:00] <scarabeus> it is mostly up to infra
-[21:09:01] <dilfridge> I don't want to push or order anyone around here
-[21:09:19] <dilfridge> my point was just to suggest that we say
-[21:09:21] <blueness> dilfridge, just ask infra what's up with the archive and what their ideas are
-[21:09:46] <dilfridge> "It was a good idea and it would be great to have it back at some point in the future."
-[21:09:48] <rich0> Agree - unless we're going to beg the Trustees to let us hire somebody to do it or something, all we can say is "yeah, sounds like a good idea...duh..."  :)
-[21:09:49] <robbat2> that was asked in  our channel already, i thought by one of you
-[21:10:03] <robbat2> the problem is just the web frontend being really broken
-[21:10:04] <ulm> dilfridge: maybe cc council to the relevant bug?
-[21:10:15] <robbat2> some of the mhonarc customizations got lost in the sands of time
-[21:10:20] <dilfridge> ulm: can do
-[21:10:31] <ulm> bug 424647
-[21:10:33] <willikins> ulm: https://bugs.gentoo.org/424647 "archives.gentoo.org: Broken URLs for e.g. gentoo-dev-announce and others"; Gentoo Infrastructure, Other; CONF; darkside:infra-bugs
-[21:10:35] <robbat2> and we'd love somebody to come forward with another solution, because mhonarc was reaching scalability limits anyway
-[21:11:05] --> dberkholz|mob (~dberkholz@gentoo/developer/dberkholz) hat #gentoo-council betreten
-[21:11:16] <ulm> robbat2: scalability because of increased traffic?
-[21:11:20] <ulm> or archive size?
-[21:11:22] <dilfridge> I remember that someone was already interested to look at it but I dont remember who it was
-[21:11:32] <robbat2> archive size, increased list traffic
-[21:12:08] <rich0> Isn't there an out-of-the-box solution for email archiving?  There has to be...
-[21:12:11] <robbat2> at least one part of mhonarc was O(n) where n is the number of messages to the list so far; so growing worse at each pass
-[21:12:19] <dilfridge> :(
-[21:12:26] <robbat2> rich0, mhonarc is one of those solutions
-[21:12:40] <blueness> can't we "outsource" this ie just use gmane
-[21:12:57] <rich0> Why is gmane missing emails anyway?
-[21:12:57] <ulm> blueness: gmane loses some messages
-[21:13:01] <robbat2> so one proposal was gmane, another was run the gmane code ourselves
-[21:13:04] <blueness> have links up to the relavent gmane lists
-[21:13:05] <dilfridge> well for some weird reason gmane lost most
-[21:13:12] <dilfridge> of the proposals for last session
-[21:13:16] <blueness> wierd
-[21:13:45] <robbat2> it's probably a 60-80-hour project for whomever wants to take it on
-[21:13:57] <ulm> also importing an existing archive into gmane is a PITA
-[21:14:36] <ulm> last time I asked for it, they screwed up message order, and then refused to fix it
-[21:14:57] <dilfridge> does anyone see a need for a vote of  whatever kind here? I don't really, I think the difficulty is clear
-[21:16:07] -*- WilliamH doesn't see the need for a vote either
-[21:16:45] <blueness> nah no need to vote here
-[21:16:55] <dilfridge> ok
-[21:17:02] <ulm> don't know what we would vote on
-[21:17:15] <dilfridge> then, lets continue
-[21:17:26] <dilfridge> 8. Open bugs with council involvement
-[21:17:26] <dilfridge>    * Bug 477030 - Missing summary for 20130611 council meeting [12]
-[21:17:27] <willikins> dilfridge: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council
-[21:17:40] <dilfridge> any news here? :)
-[21:18:02] <ulm> scarabeus: you wanted to ping betelgeuse?
-[21:18:05] <dilfridge> btw there is another summary missing, my fault, it's done and will be commited once I get around to it
-[21:19:08] <dilfridge> ook no news here. wash, rinse, repeat, next meeting.
-[21:19:14] <blueness> lol yeah
-[21:19:17] <ulm> *sigh*
-[21:19:26] <dilfridge> which brings us to
-[21:19:33] <dilfridge> 9. Open floor
-[21:20:22] <dilfridge> anyone?
-[21:20:22] <blueness> every, i need to leave, but it looks like we're done anyhow
-[21:20:28] <blueness> good meeting!
-[21:21:22] <dilfridge> seems like there are no voices on the open floor
-[21:21:29] <-- graaff (~graaff@gentoo/developer/graaff) hat das Netzwerk verlassen (Quit: Leaving)
-[21:21:31] <dilfridge> with that
-[21:21:34] <dilfridge> I'd say
-[21:21:39] <TomWij> There's some minor stuff that got outdated (new project to be filed on wiki, authors not marked as retired, ...) or isn't clearly documented (KEYWORD="" and/or package.mask), but I haven't came around to writing patches yet; so it's gonna be for another meeting.
-[21:21:49] <dilfridge> ok
-[21:22:16] <dilfridge> sounds good
-[21:22:26] <dilfridge> anyone else?
-[21:22:55] <dilfridge> nope
-[21:23:27] <dilfridge> meeting closed; next one is 10 December
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20131210-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20131210-summary.txt
deleted file mode 100644
index 828f112908..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20131210-summary.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Modernization/adaption of the Code of Conduct
-=============================================
-
-Goal: Vote on whether to slightly modify the CoC with the below changes
-Time: 5 minutes
-
-Last meeting, a minimally modernized version of the CoC page 
-"Consequences" section was presented by dilfridge. Consensus was that - 
-since this is a sensitive area - the text would be sent to the project 
-mailing list for discussion and decided in the next council meeting.
-
-The proposed text is in reference 2.
-
-References:
-1. http://www.gentoo.org/proj/en/council/meeting-logs/20131119-summary.txt
-2. http://article.gmane.org/gmane.linux.gentoo.project/3190
-
-
-GLEP 48: QA Team's Role and Purpose
-===================================
-
-Goal: Vote to approve 1 of 3 proposals for modifying the QA team GLEP
-Time: 30 minutes
-
-The proposals are documented in reference 1.
-
-References:
-1. http://thread.gmane.org/gmane.linux.gentoo.project/3162
-2. http://article.gmane.org/gmane.linux.gentoo.project/3191
-
-
-Open bugs/issues with council involvement
-=========================================
-
-Time: 20 minutes
-
-Status of PGP key GLEP
-- Not specifically requested for vote but topic of last meeting
-- http://comments.gmane.org/gmane.linux.gentoo.project/3155
-- Any updates? Any actions we can take?
-
-Bug 424647: archives.g.o
-- Any updates? Any actions we can take?
-
-Bug 477030: Old council meeting summary
-- Any updates? Any actions we can take?
-
-
-Open floor
-==========
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20131210.txt b/xml/htdocs/proj/en/council/meeting-logs/20131210.txt
deleted file mode 100644
index fe0e8037da..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20131210.txt
+++ /dev/null
@@ -1,307 +0,0 @@
-[20:00:42] <dberkholz> ok it's 1900, let's get started. who's here?
-[20:00:50] -*- dilfridge here
-[20:01:14] <dberkholz> blueness scarabeus ulm WilliamH phajdan-jr (for rich0): speak up
-[20:01:19] -*- WilliamH here
-[20:01:21] -*- blueness  here
-[20:01:39] <dilfridge> blueness: not to my knowledge, I did not see anything new on the glep either
-[20:02:46] <WilliamH> I didn't see anything either.
-[20:03:11] <dberkholz> scarabeus ulm phajdan-jr: ping
-[20:03:22] <blueness> ulm said he'd be a bit late
-[20:03:51] <phajdan-jr> here
-[20:04:23] <blueness> where's our opensuse liason?
-[20:04:38] <dberkholz> alright, we've got 5 folks so let's get started with the 1st item and we can wait if we can't make it past a vote
-[20:04:48] <dberkholz> Modernization/adaption of the Code of Conduct
-[20:05:20] <dberkholz> i propose that we vote on ulm's version of the changes: http://article.gmane.org/gmane.linux.gentoo.project/3205 — any objections?
-[20:05:21] <ulm> here
-[20:05:23] <dilfridge> for what it's worth, I'm fine with ulm's comment about the "future" sentence 
-[20:05:34] <dilfridge> we can leave that out for now
-[20:05:41] <dilfridge> the background of the sentence is, 
-[20:06:11] <dilfridge> in comrel we discussed a lot about the restructuring, and having a separate subproject for CoC enforcement was the original plan
-[20:06:27] <dilfridge> but it was deferred to later, because 
-[20:06:36] <dilfridge> of basically not having enough people at hand
-[20:06:40] <dberkholz> sure.
-[20:06:46] <blueness> okay
-[20:06:46] <dilfridge> I'm not sure how current the plan still is though.
-[20:06:48] <dberkholz> no point in talking about hypotheticals in the CoC
-[20:06:53] <dilfridge> indeed.
-[20:06:55] <blueness> agreed
-[20:07:05] <dberkholz> so let's vote on ulm's version of the CoC changes
-[20:07:07] <WilliamH> agreed
-[20:07:13] <dberkholz> +1 from me
-[20:07:14] -*- dilfridge yes ulm's version
-[20:07:19] <phajdan-jr> +1
-[20:07:22] -*- WilliamH yes ulm's version
-[20:07:26] <ulm> +1
-[20:07:47] -*- blueness yes
-[20:07:55] <dberkholz> great, it's approved
-[20:08:00] <dberkholz> now for the fun stuff!
-[20:08:07] <dberkholz> next item: GLEP 48: QA Team's Role and Purpose
-[20:08:10] <dilfridge> hehe
-[20:08:32] <dberkholz> we have 3 proposals to revise the glep, described here: http://thread.gmane.org/gmane.linux.gentoo.project/3162
-[20:09:04] <dberkholz> do people feel comfortable voting on one of them, or is there something we're missing?
-[20:09:16] <dilfridge> I like it, in particular 3
-[20:09:25] <phajdan-jr> same here
-[20:09:42] <phajdan-jr> I think not that much discussion happend on the MLs, so it's not really controversial
-[20:09:47] <ulm> I dislike approving the qa lead
-[20:10:04] <ulm> as it potentially will result in stalemates
-[20:10:12] <dilfridge> hmm
-[20:10:22] <phajdan-jr> I think I pointed that out
-[20:10:22] <blueness> dilfridge, what is it about 3 that you like, they are all pretty close
-[20:10:23] <dilfridge> and how is that worse than current?
-[20:10:27] <ulm> what are we going to do if the qa team and the council disagree
-[20:10:33] <ulm> ?
-[20:10:33] <phajdan-jr> and rich0 replied that in a stalemate council can appoint a lead
-[20:10:47] <blueness> ulm, the qa team has to try again
-[20:10:51] <phajdan-jr> I'm fine with amending the text to be more explicit about that
-[20:11:09] <blueness> or better yet appoint a lead
-[20:11:16] <dilfridge> 1 is the basics... 2 makes clear what happens if things go wrong, 3 is correcting some typos
-[20:11:31] <blueness> because QA has disciplinary powers, that power must be legitimized by a voted body, aka the council
-[20:11:36] <blueness> QA is not any ordinary team
-[20:11:42] <ulm> it is against the principles that projects organise themselves
-[20:11:47] <dilfridge> 1 alone can lead to a mess, since there is no definition what happens if the lead is not confirmed
-[20:11:48] <dberkholz> phajdan-jr: options 2-3 already mention the council appointing an interim lead.
-[20:12:17] <blueness> ah okay, i like 3 then
-[20:12:35] <dilfridge> ulm: yes, but that rule makes sense for non-exclusive projects... now if qa were purely advisory, that would be fine
-[20:12:35] <phajdan-jr> correct - just in case it's not clear, we could even more clearly say (if people want that) that this means in case of stalemate/disagreement, council appoints a lead resolving the stalemate
-[20:12:44] <blueness> ulm, "it is against the principles that projects organise themselves" -> but QA is not any old project, its special
-[20:13:01] --> mrueg_ (~mrueg@gentoo/developer/mrueg) hat #gentoo-council betreten
-[20:13:02] <phajdan-jr> qa is special, similar to e.g. devrel, recuiters, council
-[20:13:12] <dilfridge> same as, I can't just go and found comrel2
-[20:13:21] <blueness> right
-[20:13:24] <WilliamH> blueness: I understand what ulm is saying. All projects are accountable to the council.
-[20:13:31] <dilfridge> (or infra2, that's already taken by patrick)
-[20:13:32] <blueness> haha! i don't like QA so i'll form QA2
-[20:14:11] <WilliamH> blueness: The way I seeit the council can block qa2.
-[20:14:36] <blueness> dilfridge, how shall we proceed with a 3 way vote?
-[20:14:57] <dilfridge> tbh, it makes no sense to split between 2 and 3
-[20:15:05] <blueness> agreed
-[20:15:06] <dilfridge> let me make a diff, just a moment
-[20:16:08] <dilfridge> arrgh
-[20:16:09] <Zero_Chaos> WilliamH: the council has no ability to block creation of a new project. They could refuse that project any power of course.
-[20:16:50] <dilfridge> dosnt work that quickly
-[20:17:03] <WilliamH> Zero_Chaos: I guess that's what I mean. if someone wanted to make qa2, qa2 wouldn't have any tree-wide "power" without the council giving them that.
-[20:17:22] <dilfridge> but as foar as I can see, 
-[20:17:27] <dilfridge> 3 adds
-[20:17:37] <dilfridge> * sentence about revision
-[20:17:53] <dilfridge> * typo fix percieved
-[20:18:17] <Zero_Chaos> WilliamH: well they would have the power they assign themselves until the council removes it :-)
-[20:18:17] <dilfridge> * devrel -> comrel
-[20:18:32] <dilfridge> and no other changes that I can see now
-[20:18:48] <dilfridge> so the question is more 1+typo fixes, or 3
-[20:19:00] <dberkholz> Zero_Chaos: insofar as that power is basically identical to that of any individual developer, sure
-[20:19:24] <blueness> dilfridge, okay
-[20:19:25] <phajdan-jr> Zero_Chaos: I don't think that's true; it'd be hard to claim powers of e.g. managing the infrastructure, recruiting/retiring developers and so on; in the tree there are also pretty clear rules for developers that are also quite flexible
-[20:19:35] <Zero_Chaos> dberkholz: happy to discuss later, I don't want to derail the meeting with OT banter.
-[20:19:56] <Zero_Chaos> phajdan-jr: see above :-)
-[20:20:18] <phajdan-jr> right, dberkholz's answer is even shorter and I fully agree
-[20:21:42] <blueness> dilfridge, can you formulate what we are/will be voting on then
-[20:21:47] <blueness> language wise
-[20:22:33] <dberkholz> we also need an option of "minor typographical changes only"
-[20:23:11] <dberkholz> so really the choices are 1) typo fixes, 2) lead confirmation, 3) filling in the holes in (2) to avoid stalemates etc
-[20:23:24] <ulm> we really don't have to vote about spelling fixes
-[20:23:28] <dilfridge> what we can do is vote yes no on each of those
-[20:23:28] <ulm> just do it
-[20:23:41] <dilfridge> http://bpaste.net/show/157371/
-[20:23:56] <dilfridge> here's the difference between 2 and 3 (the "typo fixes")
-[20:24:32] <ulm> lines 7 to 9 don't make sense in this context
-[20:24:43] <dberkholz> the 1st point belongs in a version that has substantive changes
-[20:24:47] <dilfridge> yes
-[20:25:12] <dberkholz> i agree with ulm, the rest should just happen without any vote required
-[20:25:35] <ulm> e after i except after c ;)
-[20:26:11] <dberkholz> but my initial point was really that we need an option for "keep it the same as it was"
-[20:26:21] <dilfridge> how about we vote on lead confirmation, i.e. 1, first (yes/no), then we vote on the difference 1-2 (yes/no)?
-[20:26:24] <dberkholz> including any minor updates
-[20:26:30] <dilfridge> if the first goes no, well it's over
-[20:27:14] <dberkholz> seems reasonable, although i really hope we don't end up stuck in the middle
-[20:27:22] <blueness> dilfridge, i'm okay with your voting scheme
-[20:27:37] <dberkholz> so let's vote on lead confirmation
-[20:27:41] <dberkholz> +1 from me
-[20:27:44] -*- blueness yes
-[20:27:48] -*- dilfridge yes
-[20:27:52] -*- ulm no
-[20:27:55] <phajdan-jr> yes for lead confirmation
-[20:27:57] -*- WilliamH no
-[20:28:26] <dberkholz> ok, that one's approved.
-[20:28:49] <dberkholz> given that we will confirm leads, do you want to have the version that fixes some of the issues there to enable council to deal with any stalemates?
-[20:29:10] <blueness> let's vote!
-[20:29:22] -*- dilfridge yes for 2 (and 3)
-[20:29:34] -*- ulm no
-[20:29:37] -*- blueness yes
-[20:29:40] <phajdan-jr> yes for resolving stalemates (council appointing lead)
-[20:29:59] <dberkholz> +1 again
-[20:30:09] -*- WilliamH no
-[20:30:23] <dberkholz> same again, approved by a 4–2 vote.
-[20:30:57] <dberkholz> good, we've got that dealt with
-[20:31:18] <dberkholz> next topic
-[20:31:19] <dberkholz> Open bugs/issues with council involvement
-[20:31:40] <dberkholz> i put a bunch of time for this mainly because of the key glep
-[20:32:21] <dberkholz> robbat2: i noticed you didn't request a vote for this meeting, and i didn't get a response from my irc ping the other day
-[20:32:38] <dberkholz> robbat2: any chance you're around to provide a quick update? is this ready to vote on?
-[20:33:28] <dberkholz> the other issue i wanted to suggest, which i put in the agenda, is whether this should be an actual glep at all
-[20:33:33] <dberkholz> vs a policy owned by QA
-[20:33:44] <blueness> dberkholz, glep is fine
-[20:33:55] <blueness> its both QA and infra really
-[20:34:03] <phajdan-jr> note that for a GLEP vote, it'd be good to have a unified final version of the GLEP
-[20:34:20] <phajdan-jr> I think it makes sense as a GLEP btw
-[20:34:33] <dilfridge> glep is good, more official
-[20:34:51] <blueness> should we table this issue seeing as robbat2 is not here and none of us saw a final glep
-[20:34:53] <dberkholz> phajdan-jr: what do you think is missing from http://permalink.gmane.org/gmane.linux.gentoo.project/3155
-[20:35:28] -*- WilliamH agrees with blueness for now
-[20:35:36] <phajdan-jr> dberkholz: there is some discussion after initial e-mail
-[20:35:47] <ulm> we agreed last month that it should be a GLEP
-[20:35:52] <ulm> with a number
-[20:36:17] <ulm> so that any updates can be tracked
-[20:36:24] <blueness> uep
-[20:36:25] <blueness> yep
-[20:36:42] <dilfridge> yeah
-[20:37:04] <ulm> apart from that, the text seems to be fine mostly
-[20:37:15] <phajdan-jr> +1
-[20:37:15] <ulm> but again, we said that last month already
-[20:37:19] <dberkholz> phajdan-jr: there were dol-sen's follow-ups, in which he basically said (1) ignore the first point, i was wrong and (2) +1
-[20:37:32] <blueness> ulm, i thought the ideas were all fine, but that it would be a glep, so i'd like to see that language
-[20:37:38] <dberkholz> phajdan-jr: did i miss something?
-[20:38:07] <dberkholz> anyone want to take responsibility for making sure this thing gets a number?
-[20:38:09] -*- phajdan-jr checks quickly
-[20:38:32] <dberkholz> we need someone to find and chase the glep editor
-[20:38:46] <dilfridge> actually
-[20:38:55] <dilfridge> we had an agenda topic some months ago
-[20:39:01] <dilfridge> about re-forming the glep team
-[20:39:11] <dilfridge> does anyone know what became of that?
-[20:39:12] <jmbsvicetto> iirc, the glep will get a number when the glep editor is fine with it and thinks it's ready to be submitted to council for a vote
-[20:39:37] <WilliamH> jmbsvicetto: who is the glep editor?
-[20:39:43] <jmbsvicetto> antarus
-[20:39:44] <phajdan-jr> dberkholz: I see dol-sen's "Sounds good to me" to "This should probably make it into the glep."
-[20:40:05] <phajdan-jr> which refers to keyrings = line in metadata/layout.conf
-[20:40:12] <dilfridge> robbat2 wanted to check at least one more reference document, so maybe he still has changes to integrate
-[20:40:41] <phajdan-jr> and the issue of key distribution doesn't seem to be fully resolved to me
-[20:40:53] <phajdan-jr> I'd be fine with making that a part of seperate GLEP if people would find it useful
-[20:41:04] <phajdan-jr> and accepting the developer key guidelines first
-[20:41:05] <dilfridge> better separate
-[20:41:22] <blueness> let's vote to table then
-[20:41:35] <dilfridge> table means defer to next meeting?
-[20:41:37] <dberkholz> yeah i just went and checked history for gleps (http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/glep/) and it's mostly antarus as editor recently.
-[20:41:47] <blueness> yes defer the vote because its not ready
-[20:41:56] <phajdan-jr> if we defer let's specify what action is required
-[20:42:23] <phajdan-jr> my suggestions: split per-developer key/gpg guidelines from key distribution mechanism/policy;
-[20:42:32] <blueness> phajdan-jr, we could say by next meeting but it really depends on robbat2
-[20:42:42] <blueness> we already approved the principle
-[20:42:46] <phajdan-jr> and having a text on MLs not raising significant questions/objections
-[20:42:53] <blueness> we just need to approve the final language
-[20:42:59] <dilfridge> indeed
-[20:43:09] <dilfridge> so final language is what we need
-[20:43:14] <phajdan-jr> +1
-[20:43:16] <blueness> yeah
-[20:43:20] <ulm> +1
-[20:43:39] <blueness> (it'd be wierd to approve again in principle)
-[20:44:02] <ulm> "We appreciate the GLEP draft submitted by robbat2 in above mailing list post, and look forward to approving a final version with additional minor changes merged in." <-- this we had last month
-[20:44:21] <dberkholz> i just pinged antarus about getting it a glep #
-[20:44:37] <blueness> yep
-[20:44:45] <dberkholz> so we can get stop worrying about the "paperwork" side of things
-[20:45:00] <phajdan-jr> sounds good
-[20:45:10] <blueness> btw, nothing is stopping the new QA team from beginning to implement the gpg guidelines
-[20:45:26] -*- dilfridge hears a "hint hint" there :D
-[20:45:35] <blueness> there's probably a lot of work to look at all the dev's gpg keys to make sure they fit
-[20:45:41] <blueness> yeah hint hint!
-[20:45:43] <phajdan-jr> please correct me if I miss something, but I think the key distribution part of the GLEP is not fully resolved; that'
-[20:45:49] <phajdan-jr> s the only issue I see
-[20:46:00] <Zero_Chaos> blueness: that's mostly been done already
-[20:46:00] <ulm> blueness: last time I looked at them it was a total mess
-[20:46:00] <dberkholz> yeah, this is purely key policies, not verification
-[20:46:01] <dilfridge> phajdan-jr: talk to dol-sen about that, he's working on it
-[20:46:03] <phajdan-jr> and, yeah, +1 to QA doing things
-[20:46:13] <Zero_Chaos> blueness: details from dol-sen
-[20:46:20] -*- phajdan-jr sends a reply on gentoo-dev about that
-[20:46:22] <ulm> blueness: keys in ldap being different from what was used for signing etc
-[20:46:27] <phajdan-jr> oh, gentoo-project actually
-[20:46:36] <dberkholz> alright, can we move on to the next issue?
-[20:46:41] <blueness> ulm, you'll need some automation there, i'm sure, and produce a checklist in a chart with green arrows and red x's
-[20:46:50] <dberkholz> just a couple more things then open floor for whatever else
-[20:46:58] <dilfridge> ook
-[20:47:03] <dilfridge> betelgeuse
-[20:47:04] <blueness> Zero_Chaos, that's right, i remember dol-sen doing some of that work
-[20:47:22] <blueness> he pinged me about my gpg key for some reason, so he was looking at them
-[20:47:22] --> TomJBE (~tb@gentoo/developer/tomjbe) hat #gentoo-council betreten
-[20:47:42] <dberkholz> let's keep going, and slide this discussion over to #-dev if you want to continue it
-[20:47:57] <dberkholz> since we're not going to get anywhere on it today
-[20:48:06] <dberkholz> anything happen on archives.g.o in the past couple weeks (bug #424647)? doubt it but we should keep thinking about it
-[20:48:08] <willikins> dberkholz: https://bugs.gentoo.org/424647 "archives.gentoo.org: Broken URLs for e.g. gentoo-dev-announce and others"; Gentoo Infrastructure, Other; CONF; darkside:infra-bugs
-[20:48:48] <dilfridge> not that I know
-[20:49:55] <dberkholz> boo
-[20:50:08] <dberkholz> maybe we can get a gsoc student to do something with it, if it's still busted then.
-[20:50:31] <dberkholz> last open issue is bug #477030
-[20:50:33] <willikins> dberkholz: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council
-[20:50:41] <jmbsvicetto> dberkholz: robbat2 explained again the issue with archives
-[20:51:09] <jmbsvicetto> dberkholz: anyone wanting to fix archives needs to read robbat2's email and address the issues he raised
-[20:51:57] <dberkholz> jmbsvicetto: could you add a pointer to the email in that bug?
-[20:52:06] <phajdan-jr> yeah, looks more like infra issue thatn council
-[20:52:11] <phajdan-jr> +1 to e-mail reference
-[20:52:44] <dberkholz> i just pinged betelgeuse re that summary
-[20:52:49] <dberkholz> for the last open bug
-[20:53:11] <dberkholz> any volunteers who were here last year if he doesn't?
-[20:53:44] <ulm> dberkholz: I can take a look at it
-[20:54:07] <ulm> although I would dislike Petteri getting away like that ;)
-[20:54:26] <phajdan-jr> isn';t the link http://thread.gmane.org/gmane.linux.gentoo.project/3149/focus=3153 ? :)
-[20:54:30] <phajdan-jr> maybe we could add it now
-[20:55:03] <dberkholz> looks good enough
-[20:55:15] -*- dilfridge would even be happy with a mailman-like archive
-[20:55:26] <dberkholz> jmbsvicetto: could you stick that in the bug? http://article.gmane.org/gmane.linux.gentoo.project/3153
-[20:55:31] <dberkholz> don't need 5 people to post dupes of it...
-[20:55:35] <ulm> dilfridge: any archive is better than no archive ;)
-[20:56:40] <dberkholz> alright
-[20:56:44] <dberkholz> that's it for open issues
-[20:56:48] <dberkholz> now for the open floor
-[20:56:56] <dberkholz> anyone, council or otherwise, have something to say?
-[20:57:59] <blueness> nothing from me
-[20:58:05] <WilliamH> here's my thing about us confirming the qa lead.
-[20:58:30] <WilliamH> Why do we need to confirm the lead since we can step in and remove a lead of any project at any time?
-[20:59:08] <phajdan-jr> good question
-[20:59:21] <ulm> WilliamH: I'm all with you there
-[20:59:28] <phajdan-jr> I think historically council didn't step in that much in pretty obvious (arguably) QA "crisises"
-[20:59:40] <ulm> I'd have been happier with the council approving qa members instead of the lead
-[20:59:43] <jmbsvicetto> back, I had to relocate
-[20:59:47] <phajdan-jr> and I think an explicit confirmation would address that by _requiring_ council action
-[21:00:03] <dberkholz> the problem is that people have a really hard time taking any sort of negative action
-[21:00:04] <dilfridge> phajdan-jr+
-[21:00:10] <blueness> a pro-active confirmation is also a vote of confidence which is important message to the community
-[21:00:11] <phajdan-jr> I'd prefer the QA lead to have enough autonomy to approve team members
-[21:00:12] <dberkholz> a removal is seen as far more severe than a confirmation
-[21:00:17] <phajdan-jr> +1
-[21:00:20] <dilfridge> +1
-[21:00:22] <dberkholz> so we wait way too long to do anything
-[21:00:24] <phajdan-jr> to both blueness and dberkholz
-[21:00:35] <blueness> dberkholz, +1
-[21:00:54] <blueness> look at how messy it was to "remove" the previous QA situation
-[21:00:59] <blueness> hurt feelings etc
-[21:01:09] <floppym> It's like Google+ in here with all these +1's :P
-[21:01:15] <WilliamH> blueness: it really wasn't, we just stepped in and did it.
-[21:01:18] <Zero_Chaos> the council absolutely should not have authority to dictate individual team members for a team.
-[21:01:22] <blueness> floppym++
-[21:01:22] <Zero_Chaos> that's nonsense
-[21:01:33] <blueness> Zero_Chaos, then QA is not a team
-[21:02:05] <Zero_Chaos> blueness: team/project/herd/orgy I don't care what it's called. Council shouldn't have the authority to dictate team members, that's not their job.
-[21:02:08] <blueness> it is something more akin to the council with over-arching powers
-[21:02:26] <Zero_Chaos> blueness: totalitarian is the word you are looking for.
-[21:02:29] <blueness> there is a distinction: a team eg hardened does not have overarching powers
-[21:02:42] <dberkholz> Zero_Chaos: enabling formation of a cliquey in-group with too much authority and no external oversight is an entirely different problem
-[21:02:56] <blueness> Zero_Chaos, that's a straw man argument, the point is that over-arching powers need legitimation by vote
-[21:03:07] <blueness> people vote for the council which has overarching powers
-[21:03:11] <blueness> this makes it legitimate
-[21:03:20] <blueness> people do not vote for QA, and yet it has overarchin powers
-[21:03:28] <Zero_Chaos> blueness: the lead already has to be approved. just like in government. did you elect the desk clerk at the dmv?
-[21:03:28] <jmbsvicetto> dberkholz: I've added the project ml thread link to the bug
-[21:03:29] <blueness> so how is its legitimacy entrenched
-[21:03:31] <blueness> ?
-[21:03:40] <dberkholz> thx jmbsvicetto
-[21:03:42] <WilliamH> blueness: qa is accountable to the council though just like any of us are.
-[21:03:50] <ulm> blueness: abuse of power was not a problem at all with qa
-[21:03:58] <ulm> but rather inactivity
-[21:04:12] <phajdan-jr> I remember some concerns about qa's actions from the past though
-[21:04:17] <phajdan-jr> there were some conflicts
-[21:04:17] <blueness> ulm, but legitimacy is because people will say, who is QA to make these decisions on my package
-[21:04:26] <blueness> rich0, had a nice write-up on it
-[21:04:48] <dberkholz> alright, we're not bringing up any new issues here but rehashing old discussions
-[21:04:54] <blueness> eg if the council were not elected, people would say, who are we to make such over-arching decisions
-[21:04:58] <dberkholz> i'm going to close the formal meeting but feel free to keep talking about this
-[21:05:00] <blueness> dberkholz, indeed
-[21:05:02] <WilliamH> blueness: that's what an appeal to the council takes care of.
-[21:05:16] <blueness> okay guys nice meeting until next time!
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140114-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20140114-summary.txt
deleted file mode 100644
index 781433094e..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140114-summary.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-Roll call
-=========
-
-blueness (35 min late)
-dberkholz
-dilfridge
-rich0
-scarabeus
-ulm 
-williamh
-
-
-
-Formalizing top-level profiles at EAPI=5
-========================================
-
-dilfridge:
-"Making the whole profile tree EAPI=5
-
-(This involves setting EAPI=5 in the main profiles directory, then 
-moving the eapi-5-files files to a suitable place (base?) and removing 
-the eapi-5-files directory.)
-
-The 10.0 profiles were deprecated on 2 Feb 2013 and removed from 
-profiles.desc on 9 Feb 2013, i.e. since then everyone should have 
-switched to a 13.0 profile using EAPI=5 anyway.
-
-The plan was to wait one year from that moment on."
-
-(The previous vote was 2 for ≥1yr, 2 for ≤1yr, 2 for exactly 1 yr [one 
-of which noted our standard 1-year support])
-
-We already voted on the timing, so we just need to vote on the 
-implementation now that we're at the cutoff.
-
-My suggestion for the vote:
-I propose we send out a final 30-day notice to give people a last 
-chance, then point at some of the writeups on migration paths for old 
-systems using snapshots.
-
-
-Vote: we will send 30-day notice and then switch all profile directories 
-to EAPI 5.
-
-Approved unanimously.
-
-
-
-References:
-- http://www.gentoo.org/proj/en/council/meeting-logs/20130108-summary.txt
-- http://thread.gmane.org/gmane.linux.gentoo.devel/89405
-
-
-GLEP 1/2: GLEP workflow updates and shift to wiki
-=================================================
-
-Vote on updates to GLEP 1 as provided in references.
-
-GLEP 2 comes along for the ride, as it's an example.
-
-Voted unanimously to approve with the updates mentioned in 
-<http://article.gmane.org/gmane.linux.gentoo.project/3241>.
-
-References:
-- http://article.gmane.org/gmane.linux.gentoo.project/3234
-- http://article.gmane.org/gmane.linux.gentoo.project/3211
-- http://thread.gmane.org/gmane.linux.gentoo.project/3213
-- https://wiki.gentoo.org/wiki/User:Creffett/GLEP2
-
-
-Open bugs/issues
-================
-
-Status of GPG key GLEP
-- http://comments.gmane.org/gmane.linux.gentoo.project/3155
-- Not specifically requested for vote but topic of last meeting
-- Do we have a GLEP # yet? dberkholz pinged creffett on 20140110
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140114.txt b/xml/htdocs/proj/en/council/meeting-logs/20140114.txt
deleted file mode 100644
index 0195fc22e4..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140114.txt
+++ /dev/null
@@ -1,341 +0,0 @@
-[20:00:39] <scarabeus> ahoj
-[20:00:41] <scarabeus> :)
-[20:00:45] <dberkholz> hi all
-[20:00:46] <dberkholz> roll call
-[20:00:48] <scarabeus> that is czech hi :)
-[20:01:03] <dilfridge> ho ho ho
-[20:01:06] -*- dilfridge here
-[20:01:21] -*- rich0 here
-[20:01:26] -*- ulm here
-[20:02:17] <dberkholz> just pinged blueness on #-dev
-[20:02:33] --> _AxS_ (~axs@gentoo/developer/axs) hat #gentoo-council betreten
-[20:02:54] <dberkholz> let's give him till 1905, then we'll move on
-[20:03:13] --> few_ (~few_@88.150.18.76) hat #gentoo-council betreten
-[20:03:54] --> grknight (~Thunderbi@50.120.197.130) hat #gentoo-council betreten
-[20:04:17] -*- WilliamH here
-[20:05:58] <dberkholz> alright, let's get into the agenda
-[20:06:16] <dberkholz> first topic is notifications for the EAPI=5 profile flip
-[20:07:21] <dilfridge> one remark
-[20:07:45] <dilfridge> as ciaran states, there's not really an EAPI for the whole profile tree, just for single directories
-[20:07:57] <dilfridge> so, to clarify this, I'd suggest
-[20:08:21] * dberkholz has changed topic for #gentoo-council to: " Next meeting: 14 Jan 2014 at 1900 UTC | http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 | http://wiki.gentoo.org/wiki/Project:Council | Agenda: http://thread.gmane.org/gmane.linux.gentoo.project/3247"
-[20:08:41] <dilfridge> "Making the whole profile tree EAPI=5" means, "anyone can increase the eapi in any profile directory to 5 if the features are needed"
-[20:08:50] <dberkholz> that's kind of the opposite
-[20:08:56] <dberkholz> the decision was default to 5
-[20:09:00] <dilfridge> ok
-[20:09:09] <dilfridge> then we have to place an eapi 5 file in every dir
-[20:09:11] <dberkholz> so what i think we should do is provide 30-day notice for people to drop in an older eapi file, then put 5 into anything that's left empty
-[20:09:22] <dilfridge> fine with me too
-[20:09:28] <rich0> dberkholz: ++
-[20:09:36] <ulm> why would we place an eapi file in dirs where the features are not needed?
-[20:10:03] <_AxS_> what will this do to those running say, pkgcore, that doesn't support EAPI5 yet; this would effectively make any profile incompatible with it, no?
-[20:10:16] <dberkholz> the vote on that topic was a year ago ulm
-[20:10:37] <dilfridge> _AxS_: yes. however, all non-deprecated profiles are already incompatible for a year.
-[20:11:11] <_AxS_> dilfridge: true, but one could at least make their own profile that inherits from base, if base isn't EAPI5
-[20:11:32] <rich0> Do we REALLY want to support non-EAPI5 indefinitely?
-[20:11:38] <dilfridge> the whole point of the exercise was to make base eapi=5 capable
-[20:11:46] <dilfridge> (and all the other places)
-[20:11:50] <rich0> There was a year's notice, and we're giving another month's notice...
-[20:12:09] <rich0> You can always make an overlay that is EAPI4 for whatever subset of the tree still works on EAPI4--
-[20:12:24] <dilfridge> which is probably not much
-[20:12:39] <dberkholz> if we keep rehashing and pushing off previous council decisions whenever we actually have to take action on them, we're not going to get anywhere
-[20:12:47] <rich0> It just doesn't seem all that feasible to avoid EAPI5 as a user, and it just doesn't seem like there is any real reason to support it.
-[20:13:01] <ulm> dberkholz: can you point me to the place where we have decided that we would put an eapi 5 file in every profile directory?
-[20:13:08] -*- WilliamH agrees with dberkholz 
-[20:13:12] <rich0> If I thought the previous decision didn't make sense I'd be all for questioning it, but I think they made the right call...
-[20:13:12] <ulm> I cannot find it in the 20130109 log
-[20:13:20] <ulm> *0108
-[20:13:28] <rich0> Deadlines should mean something, unless it is suicidal to hold to them.
-[20:13:34] -*- WilliamH agrees with rich0 
-[20:14:01] <dilfridge> Vote on proposal "Stable USE masks in the main portage tree" by
-[20:14:01] <dilfridge> Michał Górny [1].  There are three suggested approaches:
-[20:14:01] <dilfridge> 1) by adding new profiles requiring EAPI=5, requiring all users to
-[20:14:01] <dilfridge>    change, and then deprecating the older profile trees [if chosen; a
-[20:14:01] <dilfridge>    subsequent vote on the timeframes involved will follow]
-[20:14:01] <dilfridge> [...]
-[20:14:11] <dilfridge> The council agreed unanimously to vote between the three proposed solutions. 
-[20:14:11] <dilfridge> Solution #1 won with 7 votes.
-[20:14:17] <WilliamH> deadlines are deadlines; if they haven't been able to fix it in time it is on them we don't have to hold back and wait for them
-[20:14:42] <scarabeus> i agree with ya guys, deadlines are deadlines as WilliamH says :)
-[20:14:48] <dberkholz> ulm: that's an implementation detail. the vote was "a 1 year deprecation period for current EAPI<5 profile trees"
-[20:15:02] <dberkholz> as per http://www.gentoo.org/proj/en/council/meeting-logs/20130108.txt
-[20:15:33] <dberkholz> and further clarification of "Removal of the old EAPI<5 profile trees."
-[20:15:46] <ulm> dberkholz: still doesn't imply that every little dir needs the file
-[20:15:50] <dilfridge> I would interpret this as "it's allowed to use eapi 5 everywhere", not "everything has to be eapi 5"... 
-[20:15:57] <ulm> dilfridge: right
-[20:16:29] <dberkholz> anything else makes things more confusing for developers at little tangible benefit
-[20:16:29] <dilfridge> the net effect on users is the same since for sure we'll do it in base, and the arch teams are also interested for their directories
-[20:17:02] -*- WilliamH agrees with dberkholz  there has been anple time; let's make everything eapi 5
-[20:17:25] <dilfridge> meh I dont care between the two options, that difference is not related in any way to the deprecation timeframe
-[20:17:28] <ulm> yeah, just put the file where it's needed
-[20:17:40] <ulm> no need to spam the tree with 600 files
-[20:17:53] <rich0> WE're talking about the profile, not all packages.
-[20:18:10] <dberkholz> i didn't realize we had 600 profiles but thanks for the hyperbole.
-[20:18:18] <ulm> $ find /usr/portage/profiles/ -type d | wc -l
-[20:18:20] <ulm> 609
-[20:18:20] <rich0> Individual ebuilds can be non-EAPI5.  They just will not work on a non-EAPI5 PM due to the profile unless the user uses an overlay/etc.
-[20:18:24] <dilfridge> it's 609 directories
-[20:18:39] <rich0> The number doesn't really concern me.
-[20:18:45] <ulm> well, some are to be removed, tbh
-[20:18:49] <rich0> Just ignore the commit messages for a day, etc.  :)
-[20:18:55] <ulm> but it's some 400 still
-[20:19:00] <WilliamH> question...
-[20:19:17] <WilliamH> If we make base eapi 5, doesn't that mean that everything that inherits from it is eapi 5?
-[20:19:25] <rich0> Set it once in base, or 609 times, the technical impact seems to be the same to me.
-[20:19:27] <ulm> unfortunately not
-[20:19:32] <ulm> ^^ WilliamH
-[20:19:39] <dberkholz> no, pms says otherwise
-[20:19:43] <dilfridge> no, because the eapi is not inherited from parents
-[20:19:45] <dilfridge> however
-[20:19:49] <rich0> So, just conform to PMS and do it 609 times.
-[20:20:05] <dilfridge> this has no meaning w/r to deprecation, since the package manager will have to support eapi 5 anyway
-[20:20:15] <ulm> that's 2.5 MB of disk space on ext4
-[20:20:24] <dberkholz> so?
-[20:20:40] -*- ulm just noting
-[20:20:49] <WilliamH> ulm: maybe it should be fixed in pms?
-[20:20:58] <dberkholz> i don't think we're getting anywhere with this endless argument so why don't we vote on it, again
-[20:21:32] <dberkholz> vote: 30-day notice for people to add an eapi file to profiles, then we're dropping eapi 5 into any empty ones
-[20:21:42] <ulm> WilliamH: not sure if it can be fixed easily
-[20:21:52] <ulm> not immediately, at least
-[20:22:15] <ulm> dberkholz: eh, that makes no sense at all
-[20:22:27] <ulm> why would we want eapi < 5 files anywhere?
-[20:23:01] <ulm> if we put a file, it should be newest eapi
-[20:23:26] <dilfridge> how about two separate votes, as follows:
-[20:23:29] <dberkholz> newest would be the default, this provides an opt-out for anyone with a significant reason otherwise
-[20:23:30] -*- ulm is just concerned about it being several 100 files
-[20:23:39] <dberkholz> who in the world cares about several hundred files
-[20:23:46] <dberkholz> we have tens of thousands in the tree, it's a couple of MB of space
-[20:23:56] <dilfridge> a) 30-days notice, then everything in profiles may require eapi 5
-[20:24:06] <dilfridge> b) drop eapi 5 files everywhere?
-[20:24:16] <ulm> dberkholz: we would have one million if we were always as careless :p
-[20:24:44] --> rafaelmartins (~rafael@gentoo/developer/rafaelmartins) hat #gentoo-council betreten
-[20:25:00] <WilliamH> Why two votes? why not just a vote that in 30 days we will drop eapi 5 files everywhere?
-[20:25:06] <ulm> dilfridge: sounds good
-[20:25:36] <rich0> I don't care how we vote.  However, if we vote yes and then no I think we create a potential PMS mess.
-[20:25:48] <rich0> does anybody really think we should do a but not b?
-[20:25:59] <ulm> rich0: yes ;)
-[20:26:18] <dilfridge> let's think, what is the difference on the profile level exactly?
-[20:26:21] <rich0> I mean, sure, I wish PMS were otherwise, but do we want to try to change it before we implement this?
-[20:26:23] <_AxS_> ulm: fwiw, currently there are 265'ish 'eapi' files in profiles/ , so there would only actually be about 357 new additions..
-[20:27:15] -*- WilliamH thinks we should just give 30 days then do b
-[20:27:21] <ulm> dilfridge: it specifies how the contents of the particular dir is read
-[20:27:29] <_AxS_> ulm: plus, technically we can remove a bunch of files after everything's eapi5 right? since anything related to legacy (non-eapi5) profiles no longer has a point being in profiles/
-[20:27:35] <ulm> no influence on parents or children
-[20:28:26] <ulm> _AxS_: right
-[20:28:44] <rich0> _AxS_: good point, plus for every one of those items there is the directory tree, parent records, and other files in the tree.  So, this is adding 350 files to a collection of thousands
-[20:28:59] <dilfridge> rrriight... slowly I'm getting convinced that placing eapi 5 everywhere is the better solution.
-[20:29:31] <rich0> I'm all for finding a better way to handle profiles long-term, but that seems like a different issue
-[20:29:43] <dilfridge> dberkholz: how about "30-day notice, then we're dropping eapi 5 into any profile dir"?
-[20:29:56] <ulm> rich0: maybe the real issue is us having too many profiles
-[20:30:14] <WilliamH> ulm: that's a separate issue...
-[20:30:19] <dilfridge> actually that is another point, which we sshould immediately address after this one :]
-[20:30:35] <dilfridge> because the 10.0 profiles have no reason to exist then anymore
-[20:30:41] <dberkholz> i have an idea! let's fix every problem with gentoo before we end this council meeting!
-[20:30:46] <dilfridge> :P
-[20:31:00] <dilfridge> your turn mr chair
-[20:31:08] <dberkholz> if we just keep it open and let people go in and out for the next year, i bet we could do it.
-[20:31:47] <dberkholz> ok, can i just get a quick sense of who's opposed in theory to dropping eapi 5 files into every profile in 30 days?
-[20:31:52] <WilliamH> dberkholz: so is dilfridge's statement abov what you were proposing we vote on?
-[20:32:05] <dberkholz> not a formal vote, since it's not carefully phrased
-[20:32:35] -*- dilfridge is happy with both versions, but slowly thinking that making every dir eapi5 is the cleaner solution
-[20:32:37] <ulm> dberkholz: and update existing eapi files to 5, too?
-[20:32:49] <dberkholz> ulm: probably a good idea
-[20:33:02] <dberkholz> everything eapi5, minimize complexity
-[20:33:46] <dilfridge> "big untested change" though
-[20:34:13] <rich0> I'm in favor of dumping eapi5 in every dir in 30 days
-[20:34:29] <rich0> It isn't any uglier than find /usr/portage/profiles
-[20:34:30] -*- WilliamH is in favor
-[20:34:31] <ulm> yeah, let's do it then
-[20:34:33] <ulm> it would save devs from looking up the eapi for every dir
-[20:34:44] <dilfridge> good point
-[20:34:55] <dberkholz> alright, here's our vote: we will send 30-day notice and then switch all profiles to eapi 5
-[20:35:04] -*- WilliamH yes
-[20:35:08] <dilfridge> s/profiles/profile directories/
-[20:35:13] -*- dilfridge yes
-[20:35:20] <ulm> *sigh*
-[20:35:22] -*- ulm yes
-[20:35:27] <dberkholz> yes from me
-[20:35:42] <dberkholz> ulm: ha, i'll buy you a beer or other beverage at fosdem
-[20:35:56] --> blueness (~blueness@gentoo/developer/blueness) hat #gentoo-council betreten
-[20:36:03] <blueness> damn! off by 1 hour
-[20:36:18] <ulm> hi blueness :)
-[20:36:19] <scarabeus> yes
-[20:36:27] <rich0> blueness: no problem - you can tackle fixing all the profiles after we leave as pennance.
-[20:36:33] <dilfridge> I volunteer do the stuff
-[20:36:36] <blueness> i'm so sorry guys, i miscalculated UTC
-[20:36:47] <dilfridge> (did the last changes too, so...)
-[20:36:54] <dberkholz> blueness: just in time to get your voice heard on the vote: we will send 30-day notice and then switch all profiles to eapi 5
-[20:37:04] <blueness> dberkholz, definite yes on that
-[20:37:15] -*- rich0 yes
-[20:37:43] <dberkholz> dilfridge: i might have to duel you for those rights, i need to do some committing or i'll get rusty =)
-[20:37:49] <dilfridge> hehe
-[20:38:09] <dilfridge> do we need to vote on the following cleanup? (2 parts, 
-[20:38:24] <dilfridge> a) move eapi-5-files/* to a better place
-[20:38:29] <dilfridge> b) remove 10.0 profiles
-[20:38:31] <dilfridge> )?
-[20:38:47] <ulm> dilfridge: just do it
-[20:38:50] <dilfridge> ok
-[20:38:52] <dilfridge> no problem
-[20:39:06] <dberkholz> that's just implementation details, don't think we should care
-[20:39:40] <dilfridge> yay, someone owes me beer at fosdem or similar :)
-[20:39:52] <dberkholz> i've got ya.
-[20:39:55] <blueness> :)
-[20:40:03] <dberkholz> cool, next topic
-[20:40:08] <dilfridge> none of you both, someone else... :)
-[20:40:22] <dberkholz> glep 1/2 updates: changes to the workflow and move to the wiki
-[20:40:35] <ulm> in case anyone has missed it, creffett has posted an updated patch for GLEP 1: http://article.gmane.org/gmane.linux.gentoo.project/3241
-[20:40:47] -*- creffett here if there are any questions
-[20:41:13] <blueness> i liked the template, saw no problems with it
-[20:41:28] <dberkholz> key changes are (1) submit gleps and modifications via bugzilla and (2) gleps will be stored on the wiki and formatted appropriately. some other minor ones
-[20:42:12] <dberkholz> anyone have a problem with the proposal?
-[20:42:30] <blueness> i'm good with it
-[20:42:31] -*- dilfridge likes it
-[20:42:40] <ulm> my only comment is that I'd have left public-domain GLEPs alone and not change them to CC-BY-SA
-[20:42:40] -*- WilliamH is fine with it
-[20:42:44] <ulm> but that's a detail
-[20:42:53] -*- scarabeus read it bit back and it looked quite fine
-[20:42:56] <blueness> ulm, why?  what's the concern?
-[20:43:02] <scarabeus> ulm: does the lrelicense pose concern?
-[20:43:07] <WilliamH> ulm: We could ask the authors if they are willing to change them if they are still around
-[20:43:15] <ulm> no real concern
-[20:43:36] <ulm> but also no reason to go from PD to more restrictive
-[20:43:54] <ulm> but I won't oppose it
-[20:44:17] <blueness> can't someone with pd remove the author?
-[20:44:24] <dberkholz> there are some legal questions about whether it's even possible to put something into the public domain
-[20:44:28] <blueness> that's the only difference i think there is between cc and pd
-[20:44:54] <dberkholz> and it would be of value to unify all our content under a single license to make sure sharing stays easy
-[20:45:18] <dberkholz> for example if someone pulls other wiki content into a public domain thing, suddenly they have to realize the license changes
-[20:46:17] <dberkholz> the closest thing to public domain is probably CC0 but i don't think we specified that anywhere.
-[20:46:30] <ulm> in principle you'd have to check in what legislation the author is located
-[20:46:32] <ulm> but the intent should be clear if he has marked his stuff as PD
-[20:47:34] <WilliamH> dberkholz: Do we need a formal vote on the proposed glep changes?
-[20:47:38] <blueness> ulm, what i like about CC-BY-SA is that no one can legally "steal" your kudos
-[20:47:49] <ulm> anyway, I'm still fine with the proposal as it is
-[20:47:53] <blueness> 5 second read -> http://creativecommons.org/licenses/by-sa/3.0/
-[20:47:57] <dberkholz> so ulm is fine with the thing as is, nobody else has objected, let's vote
-[20:48:07] -*- blueness yes
-[20:48:10] -*- WilliamH yes
-[20:48:11] -*- ulm yes
-[20:48:13] -*- dilfridge yes
-[20:48:18] <dberkholz> yes
-[20:48:25] <scarabeus> yep
-[20:48:39] -*- rich0 yes
-[20:49:02] <dberkholz> how about that, we're only 3 minutes behind schedule
-[20:49:08] <dberkholz> on to the open bugs/issues
-[20:49:15] <ulm> dberkholz: was this vote about GLEP 1, or 1&2?
-[20:49:33] <dberkholz> 1 & 2 since 2 is just an templated example of following 1
-[20:49:38] <ulm> k
-[20:49:59] <dberkholz> if anyone has an objected, speak now or forever hold your peace
-[20:50:03] <dberkholz> objection*
-[20:50:36] <dberkholz> re the open issues, i caught up with robbat2 about the gpg signing and he said he hasn't had time to submit it yet as a glep. creffett|irssi also noted that he wanted to run through the new process we just approved with it
-[20:50:54] <dberkholz> so we're still waiting on external efforts for progress on that
-[20:51:35] <blueness> one question i had which i never got answers was how gpg signign was going to be enforce
-[20:51:50] <blueness> scripted or human (aka QA)???
-[20:51:53] <dilfridge> different problem
-[20:51:56] <blueness> true
-[20:51:57] <dberkholz> there's https://wiki.gentoo.org/wiki/Project:Gentoo-keys
-[20:52:40] <blueness> dberkholz, thanks i didn't see that
-[20:52:55] <dberkholz> it's in the references section of robbat2's draft glep =)
-[20:53:42] <dberkholz> anyway, those folks are sorting out that side of things
-[20:54:30] <rich0> I'm fine with the gist of what was propsoed for GPG.  It just sounds like there are details to be worked out - it needs finalization before we can really give it a yes/no.  I don't see anything objectionalbe so far.
-[20:54:40] <blueness> ditto
-[20:55:06] <dberkholz> i just made new keys last week as per the glep
-[20:55:42] <dberkholz> alright, let's move on to the open floor
-[20:55:48] <dberkholz> council members or others, any issues to raise?
-[20:56:09] <WilliamH> I think I'm going to ask us to revisit our stabilization policy again.
-[20:56:26] <WilliamH> bug 487332 is still open withno movement from arch teams
-[20:56:28] <willikins> WilliamH: https://bugs.gentoo.org/487332 "sys-apps/openrc-0.12.4 and net-misc/netifrc-0.1 stable request"; Gentoo Linux, Keywording and Stabilization; CONF; williamh:openrc
-[20:57:05] <WilliamH> imo there isn't a reason for arch teams to take so long on this stuff. :(
-[20:57:14] <dberkholz> WilliamH: do you have something more concrete in terms of solutions?
-[20:57:24] <_AxS_> WilliamH: a lot of arch teams are short staffed, after ago left to pursue security only...
-[20:57:35] <WilliamH> dberkholz: apply the package-by-package policy to all arch's
-[20:57:48] <creffett> ago's doing security only now?
-[20:58:07] <blueness> uh oh
-[20:58:18] <blueness> he burned out
-[20:58:29] <blueness> (i'm guessing)
-[20:58:57] <ulm> the bug was filed only three months ago, and maybe one should be extra conservative with removing important packages like openrc
-[20:59:09] <WilliamH> _AxS_: I understand that the arch teams are short staffed, but  there has to be a better solution than maintainers being forced to keep old versions of packages around because of that.
-[20:59:12] <ulm> because in this case it would hurt our users
-[20:59:22] <_AxS_> re ago; the move was more political, iirc..  some sort of conflicts with other devs..
-[21:00:15] <WilliamH> ulm: The package-by-package policy gives us permission to remove them from some arches after 90 days if there is no response, but it doesn't cover all arch's.
-[21:01:05] <WilliamH> ulm: the arch teams do not necessarily prioritize important packages when they stabilize.
-[21:01:45] <WilliamH> ulm: I pinged one of the arch teams on that bug on irc weeks ago and was just told that it takes time.
-[21:02:27] <WilliamH> I guess my over all question is, if arch teams can't keep up, how relevant is their stable tree anyway?
-[21:02:31] <blueness> WilliamH, okay how do you want to proceed?
-[21:02:36] <ulm> WilliamH: this concerns ia64 only?
-[21:03:16] <WilliamH> blueness: I"m not bringing anything here for a vote right now, just wanting to know what the rest of the council thinks...
-[21:03:42] <WilliamH> ulm: let me pull up the bug again...
-[21:03:46] <dberkholz> WilliamH: are you looking for something more along the lines of force-stabilizing newer versions or dropping stable?
-[21:04:39] <rich0> We solved this in theory for a few specific archs, but we didn't make it a general policy, notably for x86/amd64.
-[21:05:36] <WilliamH> ia64 is the one arch on that bug we solved it for.
-[21:05:57] <WilliamH> We allow removal of stable versions on that arch.
-[21:06:42] <WilliamH> It is the other arch's that haven't responded that we didn't do anything for, see the decision I pointed to in the bug.
-[21:07:47] <blueness> what about a policy allowing devs to stabilize their own packages after a timeout?  provided they ahve access to the arch
-[21:08:01] <dilfridge> I understand that it's frustrating if the stablereq bug is just silent for ages
-[21:08:02] <blueness> that sounds a bit dangerous
-[21:08:04] <rich0> Would that help here?
-[21:08:15] <dberkholz> blueness: it sounds like the way we did things before starting arch teams
-[21:08:24] <blueness> dberkholz, and how did that go?
-[21:08:25] <ulm> maybe we could go for something along the lines of "after x days, responsibility for the old stable ebuild will move from the pacakge maintainer to arch teams still relying on it"
-[21:08:30] <rich0> Ultimately our choices are to help push along stable, or drop it.
-[21:08:36] <rich0> Or keep the old package around.
-[21:08:47] <ulm> although I'm not sure if that wouldn't lead to a total mess
-[21:08:49] <dberkholz> blueness: reasonably well, it was largely a time sink for people who wanted to work on other things
-[21:08:55] <WilliamH> Before we had arch teams we stabilized our own stuff after 30 days
-[21:08:56] <rich0> Pushing potentially affects quality, dropping potentially destroys stable, keeping frustrates maintainers.
-[21:09:05] <dberkholz> blueness: small quality hit but less than you might think
-[21:09:14] <blueness> dberkholz, i self stabilize only hardened specific packages, hardened-sources and gradm
-[21:09:29] <blueness> dberkholz, we could have a hybrid
-[21:09:43] <rich0> If you drop stable entirely then basically all users end up moving to ~arch anyway, so is pushing harder on stable really an issue, such as by letting maintainer stabilize.
-[21:09:44] <blueness> the self-stabilize after a timeout
-[21:09:44] <WilliamH> ulm: No, keeping the old package still causes issues.
-[21:10:00] <rich0> I thik letting the maintainer stabilize makes more sense than dropping stable entirely, especially for something like openrc.
-[21:10:09] <blueness> rich0, i agree
-[21:10:17] <rich0> No stable openrc basically means no stable at all.
-[21:10:57] <WilliamH> I could go with a policy that allows maintainers to auto stabilize after a timeout.
-[21:11:01] <_AxS_> rich0: in the case of openrc (at least this time) it's not just openrc iirc -- kmod is also interrelated here.  at any rate, often multiple packages need to go stable together.
-[21:11:07] <dberkholz> the argument is always what stable means
-[21:11:18] <dilfridge> there is no easy solution
-[21:11:24] <dberkholz> does it mean actually tested by an arch user, or does it mean we try to provide you with something that we hope works
-[21:11:38] <ulm> dberkholz: the former
-[21:11:44] <dberkholz> with the aim of not breaking your upgrades vs not breaking your running system
-[21:12:00] <ulm> ~arch is the latter
-[21:12:15] <ulm> and no keywords or masked means we don't know if it works
-[21:12:20] <dberkholz> i would prefer to drop stable vs force-stable untested software, then people have to explicitly ~arch it
-[21:12:29] <dilfridge> +1
-[21:12:57] <rich0> dberkholz: good point
-[21:13:05] <rich0> at least they know what they're getting
-[21:13:21] <rich0> though that raises the question of whether stable packages can depend on unstable
-[21:13:29] <dberkholz> alright WilliamH, do you want to kick off a discussion on -dev about a broader stabilization timeout for more arches and possible options
-[21:13:36] <rich0> If not you end up cascade-destablilizing half the tree for a critical dep
-[21:13:40] <dberkholz> we could discuss this for a long time here and not make much more progress i think
-[21:13:59] <ulm> rich0: that question is sort of moot if you don't have stable openrc
-[21:14:02] <rich0> ++ - I like the discussion so far, but this isn't going to get resolved in this meeting
-[21:14:24] <WilliamH> dberkholz: I can do that, but it is basically two options. 1) allow maintainers to stabilize after 90 days, or 2) removing stable packages.
-[21:14:38] <rich0> ulm: my thought is that there is a difference between package.keyword for just openrc vs having to accept ~arch for the entire tree
-[21:14:45] <dberkholz> or 3), make maintainers leave old ebuilds around
-[21:14:52] <blueness> rich0, should we bring this up on #gentoo-dev ... the fact that we don't ahve the manpower for stabilizatoin we used to
-[21:14:56] <blueness> and see what the community wants
-[21:14:57] <rich0> WilliamH: sure, but there could be nuances and we can at least hash it out.
-[21:15:07] <rich0> ++
-[21:15:24] <rich0> we aren't going to make the problem go away with any decision - I think this needs some open discussion/debate
-[21:15:36] <ulm> rich0: my point was that we don't need to care about tree consistency if important packages are missing from stable
-[21:16:04] <ulm> for the affected archs, that is
-[21:16:20] <WilliamH> ulm: the issue seems to be that arch teams don't see system packages as more  important than others...
-[21:16:29] <rich0> sure - I just wanted to toss it out there - it is a change in the letter of policy
-[21:16:42] <WilliamH> ulm: I just remembered another part of the irc conversation I had.
-[21:16:45] <rich0> letter of policy suggests that if you de-stabilize glibc you de-stablize 80% of the tree
-[21:16:49] <dilfridge> that (@system) is actually a good point
-[21:16:52] <ulm> WilliamH: was this ever different?
-[21:17:22] <ulm> I still remember waiting for stabilisation for about one year in 2007 or 2008
-[21:17:30] <ulm> on minor arches
-[21:17:47] <blueness> that's why i'm glad mips is ~arch!
-[21:17:53] <blueness> it makes my life so much easeri
-[21:18:00] <dberkholz> alright, let's wrap this meeting up
-[21:18:19] <ulm> blueness: I think it even was on arm then ;)
-[21:18:22] <dberkholz> thanks all for helping make progress on a couple of tricky and useful issues
-[21:18:46] <dberkholz> till next time! i'm chair next time and then handing off to blueness for march
-[21:18:51] <ulm> dberkholz: thank you for chairing
-[21:19:03] <dilfridge> thanks everyone!
-[21:19:09] <blueness> ta ta
-[21:19:13] <dberkholz> thanks ulm for prodding on notifications =)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140225.txt b/xml/htdocs/proj/en/council/meeting-logs/20140225.txt
deleted file mode 100644
index 644613a0c0..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140225.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-[19:59:47] <dilfridge> have we started already?
-[19:59:52] -*- dilfridge here
-[19:59:56] -*- WilliamH is here
-[19:59:58] <ulm> dilfridge: not really ;)
-[20:00:00] -*- blueness here
-[20:00:00] <dberkholz> nope
-[20:00:01] <WilliamH> no we haven't started.
-[20:00:09] <rich0> I'm sure we're all listening in though :)
-[20:00:12] <dberkholz> now it's 1900
-[20:00:12] <mgorny> false start :D
-[20:00:14] <blueness> we are
-[20:00:18] -*- dilfridge reads backlog
-[20:00:34] <dberkholz> so speak up, councilors
-[20:00:37] <blueness> dilfridge, don't read the backlog, it iwll damage your brain forever!
-[20:00:41] -*- ulm here
-[20:00:45] <scarabeus> nah it is just fun to read and be quiet :)
-[20:00:47] -*- scarabeus here
-[20:00:56] -*- blueness here again
-[20:01:05] -*- rich0 still here
-[20:01:17] <dberkholz> ok that's everybody
-[20:01:38] <dberkholz> i attempted to order the topics so that the more controversial stuff was at the end, so we don't end up debating that for the whole meeting
-[20:01:56] -*- WilliamH is here
-[20:02:36] <dberkholz> first off, i just wanted to note that the gpg signing glep is now an actual glep, although robin hasn't requested a vote yet
-[20:03:11] <dilfridge> dberkholz: yeah, I made that stuff, but I want to read the eu crypto regulations and discuss them with robin first
-[20:03:40] <WilliamH> dberkholz: can you please link the agenda real quick?
-[20:03:47] <dilfridge> next time we should be able to finish it, there just wasnt enough time for the 90 pages
-[20:03:56] <dberkholz> yeah it's here: http://dev.gentoo.org/~dberkholz/council_agenda_20140225.txt
-[20:04:06] <blueness> do we need a final vote on the gpg glep?
-[20:04:24] <dilfridge> there are minor changes between robbat2's mail and the wiki version but nothing serious
-[20:04:34] <dberkholz> so hopefully next meeting we can vote on that
-[20:04:40] <blueness> k
-[20:04:43] <dilfridge> I recommend we wait until next meeting with the formal vote, or do it in between via bug
-[20:04:49] <rich0> I think it needs a bit of documentation cleanup, but the policy side looks fine to me
-[20:04:53] -*- blueness is collecting agenda items already ;)
-[20:05:05] <ulm> dilfridge: can you explain point 8. of the Recommendations section in a nutshell?
-[20:05:16] <dilfridge> wait 
-[20:05:21] -*- dilfridge fires up browser
-[20:05:32] <ulm> that fifthhorseman thingy
-[20:06:10] <rich0> yeah, that had me scratching my head
-[20:06:13] <rich0> Didn't dig up the docs.
-[20:06:21] <dilfridge> for the details you have to ask robbat2, but as far as I can remember it's a workaround for a protocol weakness (which will be hardcoded in some future standard)
-[20:06:31] --> dwfreed (~dwfreed@encoded/developer/dwfreed) hat #gentoo-council betreten
-[20:06:34] <dilfridge> it was discussed on the ml long time ago
-[20:06:42] <ulm> k
-[20:06:50] <ulm> I'll try to dig it up then
-[20:06:56] <rich0> Is that a literal, or is that a <stick your email here>?
-[20:07:09] <dilfridge> the fifthhorseman bla is just some arbitrary identifier, which was once chosen on the gnupg mailing list
-[20:07:41] <rich0> That wasn't obvious to me.
-[20:07:42] <dilfridge> my internet is slow, can anyone give me a direct link to the wiki page?
-[20:07:49] <rich0> https://wiki.gentoo.org/wiki/GLEP:63
-[20:07:57] -*- dilfridge is on gsm / gprs
-[20:08:29] <dilfridge> 10s quassel lag
-[20:09:06] <dilfridge> afaik gnupg inserts some variable there a la printf
-[20:09:11] <dilfridge> page still loading
-[20:09:25] --> grknight (~Thunderbi@50.120.197.130) hat #gentoo-council betreten
-[20:09:32] <rich0> In any case, that was the sort of thing I meant by doc issues-  it is a bit hazy on how to follow the guide.  The policies themselves seem fine.
-[20:09:53] <blueness> rich0, ditto regarding setting an expiration date
-[20:09:58] <rich0> It references some general howtos, but simply following those doesn't ensure compliance
-[20:10:02] <dilfridge> sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g
-[20:10:43] <dilfridge> the %g is replaced by gnupg. the  issuer-fpr@notations.openpgp.fifthhorseman.net= is an identifier that was once (arbitrarily) chosen and stays the same now.
-[20:10:56] <ulm> k
-[20:11:03] <dberkholz> alright
-[20:11:04] <ulm> not very obvious, though
-[20:11:13] <dilfridge> that's all I can say right now
-[20:11:24] <dberkholz> yeah it would be great if few people who are not gnupg experts could try running through it and see how it goes for them
-[20:11:27] <dberkholz> such as all of you
-[20:11:44] <dberkholz> and then report back on your experiences and any issues that crop up
-[20:12:21] <dberkholz> on that note, i don't think we're going to make any more progress today on the glep so let's move on, shall we?
-[20:12:25] <ulm> so we postpone voting till next month?
-[20:12:32] <dilfridge> yes please
-[20:12:32] <blueness> ulm, yes
-[20:12:41] <ulm> sounds good
-[20:12:43] <blueness> item #1 next month
-[20:12:46] <dberkholz> the first new topic is EAPI deprecation
-[20:13:16] <dberkholz> anyone have any concerns to raise before we vote?
-[20:13:41] <ulm> everyone seen these graphs? http://www.akhuettel.de/~huettel/plots/eapi.php
-[20:14:44] <rich0> Yup - the QA meeting log was also helpful
-[20:15:02] <blueness> dberkholz, do we vote on each eapi?
-[20:15:06] <rich0> Honestly, they already covered most of the key observations
-[20:15:15] <blueness> ie 4 votes/
-[20:15:23] <dberkholz> i'd like to try a group vote to just approve everything at once, unless someone has a specific concern
-[20:15:39] <blueness> dberkholz, just one concern
-[20:15:44] <blueness> eapi=0 and toolchain
-[20:16:03] <WilliamH> blueness: the vote is to complain about eapi0 not ban it.
-[20:16:03] <blueness> its only a warning, but much of the toolchain stuff is still eapi=0
-[20:16:12] <dilfridge> deprecation in general is no problem, with banning it's not 100% clear what it means
-[20:16:18] <blueness> WilliamH, understood
-[20:16:35] <blueness> so we should at least mention this in the minutes as a concern for eapi=0
-[20:16:41] <WilliamH> dilfridge: banning means no new ebuilds of that eapi are allowed
-[20:16:53] <blueness> deprecation as a step to banning
-[20:17:01] <ulm> WilliamH: right, adding a new ebuild file won't be allowed
-[20:17:04] <rich0> Yeah, I have no issues with deprecating.  Honestly, I wouldn't necessarily even mind a ban with a toolchain exception or whatever (they can just ignore repoman).
-[20:17:11] <ulm> changing an existing one is still fine
-[20:17:12] <scarabeus> how did that attempt to new eapi toolchain went actually?
-[20:17:34] <blueness> scarabeus, i don't know, i never heard back from dirtyepic
-[20:17:49] <WilliamH> I think it is being worked.
-[20:17:49] <blueness> he said mgorny had done some work here, but i'm not sure its ready
-[20:18:20] <TomWij> ( In the QA meeting it came up that one needs to be clear whether you ban 1) in-place edits, 2) revision bumps and/or 3) new versions; in this case, "new ebuilds" would be interpreted as (2) and (3). )
-[20:18:20] <scarabeus> okey
-[20:18:32] <scarabeus> new files simply is the best
-[20:18:35] <mgorny> blueness: on toolchain? not that i know of :)
-[20:18:37] <scarabeus> ban anything that is new file
-[20:18:39] <blueness> okay so the concern is noted for the minutes ... to keep in mind that we can't go the next step and ban eapi=0 without ack from toolchain when this comes up in the future
-[20:18:54] <scarabeus> if you inline edit you are fine
-[20:18:54] <scarabeus> you should actually not inline change eapi ever
-[20:18:56] <scarabeus> ;)
-[20:19:09] <dberkholz> alright.
-[20:19:10] <scarabeus> by inline i mean in one file
-[20:19:21] <mgorny> how about security revbumps?
-[20:19:41] <WilliamH> mgorny: same deal, new file = update the eapi
-[20:19:45] <dberkholz> i don't think we should make special cases
-[20:19:58] <dilfridge> 0 can stay 0
-[20:20:05] <dilfridge> 1 is practically irrelevant
-[20:20:12] <dilfridge> 2 can be changed to 3 easily
-[20:20:36] <blueness> k
-[20:20:55] <blueness> i'm ready to vote on mass
-[20:20:57] <blueness> en masse
-[20:21:09] <scarabeus> yeah lets try first en masse :)
-[20:21:35] <dberkholz> so i think the vote can be, deprecate EAPIs 0 and 3, and ban EAPIs 1 and 2. repoman should warn about new deprecated ebuilds and block new banned ebuilds.
-[20:21:37] <rich0> How about we do a bunch of them at once instead?
-[20:21:57] <ulm> dberkholz: one vote only?
-[20:22:03] <rich0> WFM
-[20:22:09] <ulm> I'm against banning eapi 2
-[20:22:12] <WilliamH> rich0: that's what we are doing ;-)
-[20:22:12] <rich0> If it fails we can tweak it until it passes
-[20:22:12] <dberkholz> if we can't manage to pass it in one vote, we can break it down
-[20:22:31] --> jdhore2 (~jdhore@gentoo/developer/jdhore) hat #gentoo-council betreten
-[20:22:54] <ulm> can't we have the votes indicated in the agenda?
-[20:23:15] <dberkholz> fine, i don't care.
-[20:23:28] <dberkholz> vote to deprecate EAPI 3
-[20:23:34] <scarabeus> yap
-[20:23:35] -*- rich0 yes
-[20:23:36] -*- ulm yes
-[20:23:38] <dberkholz> yes
-[20:23:39] -*- WilliamH yes
-[20:23:40] -*- blueness yes
-[20:23:43] -*- dilfridge yes
-[20:23:48] <dberkholz> vote to deprecate EAPI 0
-[20:23:51] -*- rich0 yes
-[20:23:52] -*- scarabeus yes
-[20:23:53] -*- ulm yes
-[20:23:55] <dberkholz> yes
-[20:23:57] -*- dilfridge yes
-[20:23:57] -*- WilliamH yes
-[20:24:00] -*- blueness yes
-[20:24:09] <dilfridge> a bit slower please :|
-[20:24:20] <dberkholz> vote to ban new EAPI 1 ebuilds
-[20:24:24] -*- ulm yes
-[20:24:25] -*- rich0 yes
-[20:24:27] -*- dilfridge yes to ban EAPI 1
-[20:24:29] -*- blueness yes
-[20:24:30] <dberkholz> yes
-[20:24:31] -*- scarabeus yes
-[20:24:35] -*- WilliamH yes
-[20:24:43] <dberkholz> vote to ban new EAPI 2 ebuilds
-[20:24:46] -*- ulm no
-[20:24:50] <dberkholz> yes
-[20:24:50] -*- rich0 yes
-[20:24:51] -*- blueness yes
-[20:24:56] -*- scarabeus yes
-[20:24:57] -*- dilfridge abstain
-[20:25:04] -*- WilliamH yes
-[20:25:18] <dberkholz> nice work, team. 4 votes in 2 minutes.
-[20:25:28] --> seemant (seemant@unaffiliated/seemant) hat #gentoo-council betreten
-[20:25:34] <rich0> If only we could be paid by the vote...
-[20:25:41] <scarabeus> do we get effectivity achievement?
-[20:25:46] <scarabeus> rich0: wait you are getting paid? :D
-[20:25:52] <dberkholz> next topic is "Stable keywords on testing architectures
-[20:25:57] <rich0> scarabeus: what, you're not embezzling?
-[20:26:09] -*- WilliamH wants part of that paycheck ;-)
-[20:26:38] <ulm> can someone clarify what archs we are talking about?
-[20:27:03] <dilfridge> sh s390 m68k
-[20:27:06] <blueness> ulm,  the ones we dropped to ~arch
-[20:27:13] <blueness> as dilfridge
-[20:27:33] <blueness> what happened was vapier continued to mark m68k stable after the last concil vote to drop them to ~arch
-[20:27:56] <WilliamH> blueness: not just m68k, all of them I think.
-[20:27:57] <blueness> his point was that its not a problem because if we mark those arches exp in profiles.desc then repoman won't complain
-[20:27:59] <dilfridge> not just m68k, all of them
-[20:28:13] <blueness> dilfridge, WilliamH oh okay, i only say the mass m68k stuff
-[20:28:30] <ulm> I've seen some for s390 too
-[20:28:46] <rich0> I don't have a problem with arch teams redefining "stable" for their arch, as long as it is clear that maintainers can ignore the flag and treat it like ~arch otherwise
-[20:28:56] <ulm> leaving dependencies in inconsistent state, so repoman -d would barf
-[20:29:24] <dilfridge> if it's "exp" repoman won't barf
-[20:29:27] <WilliamH> ulm: that's why we would mark the profiles exp in profiles.desc
-[20:29:54] <ulm> that's repoman -e then?
-[20:30:02] -*- ulm never used that one
-[20:30:05] <blueness> ulm, i think so yes
-[20:30:17] <blueness>        --experimental-inherit=<y|n>
-[20:30:17] <blueness>               Enable experimental inherit.missing checks which  may  misbehave
-[20:30:17] <blueness>               when the internal eclass database becomes outdated.
-[20:30:33] <blueness> sorry
-[20:30:37] <ulm>  -e <y|n>, --include-exp-profiles <y|n>
-[20:30:38] <blueness>        -e <y|n>, --include-exp-profiles=<y|n>
-[20:30:38] <blueness>               Include exp profiles in dependency checks.
-[20:30:39] <ulm> include exp profiles in dependency checks
-[20:30:40] <dilfridge>       -e <y|n>, --include-exp-profiles=<y|n>
-[20:30:40] <dilfridge>               Include exp profiles in dependency checks.
-[20:30:42] <ulm> yeah
-[20:30:49] <ulm> :)
-[20:31:00] <blueness> so we can have it both ways
-[20:31:25] -*- WilliamH doesn't have a problem with marking the profiles exp and being done with it ;-)
-[20:31:33] <blueness> developers can ingore stable/unstable for sh/s390/m68k (and not do repoman -e)
-[20:31:39] <dberkholz> i'm pretty happy with the 'exp' solution
-[20:31:49] --> Chainsaw (~chainsaw@gentoo/developer/chainsaw) hat #gentoo-council betreten
-[20:31:50] <blueness> while those arch teams that want to mark stable and keep consistent stable can use repoman -e
-[20:31:53] <dberkholz> anyone got an issue to raise with it, or should we vote?
-[20:31:59] <blueness> i'm ready to vote
-[20:32:00] <dilfridge> me too... one suggestion, 
-[20:32:17] <dilfridge> maybe eshowkwd could group exp-only arches out somehow
-[20:32:27] <dilfridge> but that's a technical detail.
-[20:32:44] -*- WilliamH agrees
-[20:32:55] <WilliamH> it shouldn't stop this vote
-[20:33:06] <dberkholz> sounds great, look forward to that commit
-[20:33:33] <rich0> Never realized eshowkwd even existed prior to that thread.  I still have grep KEY * on the brain.
-[20:33:34] <ulm> dilfridge: the problem is that "stable arch" and "arch having stable keywords" are not the same thing
-[20:33:50] <blueness> eshowkw
-[20:33:51] <dilfridge> yes
-[20:33:53] <blueness> no d at the end
-[20:33:56] <dilfridge> that is something for the future
-[20:34:27] <dilfridge> I want to bring that up, because i agree with kensington that profiles.desc is not really the right place to define which arch is stable
-[20:34:27] <scarabeus> blueness: it is quite straight forward to reorder/whitespace/etc there
-[20:34:31] <blueness> ulm, i like that distinction -> "stable arch" vs  "arch having stable keywords"
-[20:34:42] <dberkholz> does this working make sense? minor archs with inconsistent keywording should be marked 'exp'
-[20:34:45] <dberkholz> wording*
-[20:34:52] <dilfridge> yep
-[20:35:11] <dilfridge> but the profiles.desc semantics is something for a future meeting.
-[20:35:25] <ulm> yes
-[20:35:35] <ulm> and we should have more types there
-[20:35:40] <dilfridge> (meaning of "stable" profiles vs. arch having stable keywords)
-[20:36:01] -*- WilliamH doesn't get the distinction.
-[20:36:20] <ulm> dilfridge: I encounter the same problems in app-emacs/ebuild-mode
-[20:36:31] <ulm> which also has some keywords logic
-[20:36:56] <blueness> WilliamH, package maintainers don't have to worry about stable keywors on "minor arches that have stable keywords but are not stable arches"
-[20:37:27] <dilfridge> WilliamH: too complicated to describe now on the fly... mailing list first
-[20:37:38] <blueness> exp = minor arches that may or may not have stable keywords
-[20:37:58] <WilliamH> dilfridge: ok
-[20:38:16] <dberkholz> alright, let's try a vote: minor archs with inconsistent stable keywording should be marked 'exp'
-[20:38:53] -*- WilliamH yes
-[20:38:58] <dberkholz> yes
-[20:39:02] -*- blueness yes
-[20:39:04] -*- rich0 yes
-[20:39:08] -*- ulm yes
-[20:39:26] <scarabeus> -me yes
-[20:39:31] -*- dilfridge yes
-[20:39:36] <dberkholz> cool.
-[20:39:53] <dberkholz> the 2nd half of this issue seemed more complex and i don't know if we can resolve it today
-[20:40:12] <rich0> The non-responsive arch concern?
-[20:40:17] <dberkholz> what should be done about keywords on 'exp' archs when cleaning old ebuilds
-[20:40:39] <rich0> I suspect the concerns went beyone the 3 exp ones.
-[20:40:40] <blueness> dberkholz, don't worry about them ;)
-[20:40:55] <scarabeus> don't give square <censored> about them i agree
-[20:41:02] <rich0> But next meeting is in two weeks.  I can try putting some proposals out on the list to try to summarize the options.
-[20:41:06] -*- WilliamH agrees
-[20:41:32] <WilliamH> If an arch is set to exp don't worry about the keywords
-[20:41:32] <blueness> dberkholz, scarabeus this is like mips, i just add/remove ~arch keywords to packages and no one knows the difference
-[20:41:47] <blueness> because mips falls under the radar of repoman
-[20:42:19] <ulm> but mips is "dev"?
-[20:42:19] <rich0> I think the exp ones are easy - prune at will.  The non-exp ones are more of an issue.  Once upon a time they had time to stabilize something, now they don't.
-[20:42:24] <blueness> no maintainer gets annoyed that they have to stabilize dependecny
-[20:42:30] <blueness> ulm, it shouldn't be in my opinion
-[20:42:35] <blueness> its dev but with ~arch only
-[20:42:37] <WilliamH> ulm: no, it is exp?
-[20:42:48] <blueness> it should be exp with both stable and unstable
-[20:42:51] <blueness> WilliamH, its both
-[20:42:52] <WilliamH> It should be exp probably if it isn't.
-[20:42:55] <ulm> WilliamH: some of its profiles are dev
-[20:43:17] <blueness> WilliamH, ulm its *effectively* exp because everything is ~arch
-[20:43:20] <dilfridge> mips doesnt have "inconsistent stable keywording"
-[20:43:35] <blueness> dilfridge, precisely
-[20:43:35] <dilfridge> it has no stable keywording, meaning it can well be dev
-[20:44:06] <blueness> dilfridge, it might be meaningful to reduce it all to exp and start adding stable keywords as vapier does for sh/s390/m68k
-[20:44:07] <dberkholz> there's nothing wrong with an arch being in 'dev' if it's all ~arch keyworded. it would probably have to get moved to 'exp' if someone wanted to start a stable version of it, during the keywording process
-[20:44:13] <WilliamH> dilfridge: that's a simantics issue, but it probably should be exp.
-[20:44:15] <blueness> we've been talking about it in the mips team
-[20:44:36] <blueness> dberkholz, exactly -> there's nothing wrong with an arch being in 'dev' if it's all ~arch keyworded. it would probably have to get moved to 'exp' if someone wanted to start a stable version of it, during the keywording process
-[20:44:37] <dilfridge> but that is again going painfully in the direction of profiles.desc semantics
-[20:45:29] <blueness> dberkholz, so what's the second half of the vote?
-[20:46:16] <WilliamH> according to the agenda there  isn't one?
-[20:46:34] <dberkholz> yeah, i wasn't really sure whether we even needed to make a decision.
-[20:47:01] <dberkholz> do we need to say it's ok to drop the last stable version for an 'exp' arch?
-[20:47:13] <WilliamH> No, that's understood.
-[20:47:37] <blueness> dberkholz, there is no expected consistency
-[20:47:44] <WilliamH> because you don't care about keywords for an exp arch.
-[20:48:26] <dberkholz> fair enough
-[20:48:44] <dberkholz> i don't think there's anything else we need to decide on this topic, then
-[20:49:26] <dberkholz> let's move on to the whole gtk/QA kerfluffle
-[20:49:37] <dilfridge> yay
-[20:49:37] <creffett|irssi> permission to address the council about this?
-[20:49:58] <dberkholz> my expectation today is that we will be able to vote on the first part of this but probably not the second
-[20:50:09] <dilfridge> creffett|irssi: sure, no problem, go ahead
-[20:50:14] <creffett|irssi> dilfridge: thank you
-[20:50:27] <creffett|irssi> just wanted to say a couple things about this from my perspective as QA lead
-[20:51:04] <creffett|irssi> first, there was basically no outcome of the GTK situation that would please everyone. Either we vote as we did and tick off GNOME, vote to keep the GNOME solution and tick off a different set, or do nothing and tick off a third set of people
-[20:51:47] <creffett|irssi> I know we don't know all the intricacies of the GTK situation perfectly, but the thing is, we (or at least I) voted this way because I feel that the GNOME team solution does not really make sense.
-[20:52:02] <creffett|irssi> and I got the impression from the ML discussion that several non-GNOME devs feel that way
-[20:52:33] <creffett|irssi> now, I know there were concerns that we did not give enough time for debate, but this is a topic that has been argued for a long, long time, and I felt that further discussion would not bring up anything new
-[20:52:55] <creffett|irssi> so we voted, we decided as we did, and now we get to deal with the results
-[20:53:12] <creffett|irssi> nothing further from me
-[20:53:37] <rich0> creffett|irssi: curious as to whether you still feel discussion would profit more in light of today's thread?  That is, anything new/concerning here from your perspective?
-[20:53:48] <creffett|irssi> rich0: which part of the thread?
-[20:53:56] <rich0> Everything sent today on -dev.
-[20:54:10] <rich0> Just whether any of that hasn't already been considered by QA.
-[20:54:44] <rich0> You could be forgiven for not keeping up for the last few hours.  :)
-[20:54:44] <creffett|irssi> I'm sorry, but I don't have the ML in front of me right now
-[20:54:49] <rich0> np, thanks
-[20:55:12] -*- creffett|irssi has to run now, very sorry about that, will try to get back on in a few if possible
-[20:55:46] <dberkholz> let's start with the whole QA tree policy thing
-[20:55:58] <rich0> So, I already said this on the list, but I think that in general it might not hurt to propose policies but give a little time for comment before they're effective, when not urgent.
-[20:56:28] <dberkholz> is the right vote/wording whether QA owns tree policy?
-[20:56:29] <WilliamH> rich0: there is nothing currently stopping qa from doing that.
-[20:56:33] <rich0> I have no issues with QA being able to set policy like this.  Maybe there are lessons to be learned about how to go about it.
-[20:56:44] <rich0> WilliamH: agree completely.
-[20:56:50] <chithead> may I address the council about this?
-[20:56:56] <dilfridge> well, this was discussed in two monthly qa meetings
-[20:57:02] <ulm> dberkholz: "has authority over tree policy" (as in the agenda) sounds better
-[20:57:08] <WilliamH> rich0: The question was whether qa has the authority to set tree policy.
-[20:57:11] <dberkholz> k
-[20:57:14] <dberkholz> chithead: yeah go ahead
-[20:58:46] <TomWij> WilliamH: However, it could become a requirement that QA need to have non-crucial policy changes survive two meetings; in the first meeting, we vote on it being a proposal and if it survives that as well as further thoughts the following meeting will make the proposal policy. (Although, I think it is kind of what a council decision overriding QA does; a different party looking into it, fair approach)
-[20:59:29] <rich0> chithead: ?
-[20:59:30] <chithead> thank you. basically, leio summed up the reasons why I think that QA should not have tree policy authority in his most recent email (19:49 utc) to gentoo-project. there is no proper process in place, and maintainers feel that their concerns have not been taken into consideration enough
-[21:00:34] <dberkholz> that doesn't seem to be a problem with QA owning policy
-[21:00:34] <blueness> chithead, can you repeate leio's point here in brief
-[21:00:46] <dberkholz> so much as it is a problem with how they're going about implementing changes in it
-[21:01:28] <dilfridge> chithead: do you mean this mail? http://article.gmane.org/gmane.linux.gentoo.project/3339
-[21:01:32] <ulm> AFAIR, leio was even present at the last QA meeting
-[21:01:51] <rich0> Understand leio's concerns.  QA really is new to all of this, and I think we should give them the opportunity to correct/etc.  I defintely support them putting things out for comment.  That said, when issues arise people have to be prompt about dealing with them.
-[21:02:00] -*- WilliamH needs to go now
-[21:02:21] <chithead> I quote him: "I applaud such initiatives of consistency, however I severely question the process in which this has been undertaken. [...] We are suggesting to be part of a due process to come up with a properly discussed, agreed and with all use cases thought about and considered properly."
-[21:02:29] <rich0> I get a bit concerned that sometimes when policies are being created everybody is quiet, and then after they're proposed suddenly there is a mess.
-[21:02:29] <dberkholz> ulm: leio's point was that he was present but not prepared, as he just happened to be around at the time
-[21:02:38] <WilliamH> I want to add a quick comment.
-[21:02:44] <blueness> chithead, thank i got the point
-[21:03:17] <rich0> I felt that way a bit with the -project thread.  I think decent points were raised, it was just a bit frustrating that they get raised two hours before the meeting.
-[21:03:31] <blueness> rich0, ++
-[21:04:08] <dilfridge> To be honest, I'm a bit astonished why the qa vote so much surprised everyone. The discussion was ongoing for a while, and it was perfectly clear they were going to vote, long before the meeting.
-[21:04:14] <rich0> Devs aren't required to read -dev, but that doesn't really mean that you get to pick apart everything after the fact...
-[21:04:31] <dberkholz> i need to go in the next 10 minutes or so too, fyi
-[21:04:41] <dberkholz> i'd like to get through at least the first vote
-[21:05:16] <blueness> dberkholz, regarding the question whether "QA owns tree policy"  i would have difficulties voting either way because its sounds too open ended
-[21:05:22] <blueness> first what do you mean own?
-[21:05:30] <rich0> I don't think the role of QA needs any change.  Certainly we need to find better ways of working together, but I wouldn't put all of that on QA.  I don't think a policy change RE GLEP48 and such is warranted.
-[21:05:31] <blueness> enforce policy set by council?
-[21:05:39] <blueness> or set their own policy and enforce it?
-[21:05:55] <dberkholz> i mean creates policy as glep 48 states about qa standards
-[21:06:12] <rich0> I have no issues with them setting policy, and it is already subject to council override if necessary.  If that becomes a regular occurence we can always revisit.
-[21:06:16] <blueness> dberkholz, in that case, why a new vote?
-[21:06:18] <blueness> its already there
-[21:06:32] <TomWij> rich0: (Responding to "QA really is new") Imo the QA team needs to apply more knowledge codification and be more public with things; I think it is fundamentally wrong that https://bugs.gentoo.org/buglist.cgi?quicksearch=ALL%20blocked%3A420493 (which came up in private to the QA team the first week of January) didn't come up in public, etc...; I think we should also contact or even invite affected
-[21:06:34] <TomWij> parties to the agenda, meetings, ...; as well as write down cases and their associated information on the wiki, etc... It takes a bit of getting used to before we get to good practices (kind of like the QA team applying QA on themselves).
-[21:06:38] <creffett|irssi> sort of back, nothing to say about what has been said so far
-[21:06:41] <rich0> I think that the gtk flag was fair game for them.  It affected more than just gnome, and there were inconsistencies in the tree.
-[21:06:55] <chithead> it would be the interpretation whether QA can have "QA standards" means that they can introduce new tree policy
-[21:06:56] <dberkholz> blueness: because we're the council and it's our job to address issues that gentoo devs ask us to deal with
-[21:07:36] <blueness> dberkholz, true but i wanted clarification on what we were voting on
-[21:07:46] <dberkholz> it wouldn't be fair of me to just leave it off the agenda because i personally disagree. if someone thinks it's unclear, then it may be worth clarifying
-[21:08:01] <blueness> dberkholz, of course
-[21:08:09] <rich0> dberkholz: ++  yup, we can vote even if it is just to say that no further action needed, or whatever
-[21:08:32] <rich0> then everybody gets to beat us up - that's why we're paid so much
-[21:08:40] <dilfridge> lol
-[21:08:48] <dberkholz> yeah, i am going to need a beer after this meeting is over.
-[21:09:25] <blueness> dberkholz, we can just reaffirm then that qa has the right under glep 48 to address the question of the gtk* flag names
-[21:09:45] <-- graaff (~graaff@gentoo/developer/graaff) hat das Netzwerk verlassen (Quit: Leaving)
-[21:09:54] <rich0> blueness: ++
-[21:10:18] <dilfridge> flag names and functionalities
-[21:10:52] <rich0> I certainly encourage them to consider the latest feedback/etc, and discuss.  They can try to be more proactive about putting proposals on -dev or whatever.
-[21:11:10] <dberkholz> ok
-[21:11:40] <rich0> They should also reply on -dev about expectations around when their policy goes into effect, that is if they want to tweak it, or if they still want it to be the "final answer"
-[21:11:48] <blueness> well that's my second point, i think qa and gnome should keep talking, i couldn't keep up with the nuances of the gtk+{,2,3} meanings
-[21:12:22] <rich0> blueness: ++ - yup, my intent earlier was to probe, not to gloss over.  I think there are some legitimate questions that are bigger even than gtk.
-[21:12:36] <rich0> Libs vs consumers of libs, and so on.
-[21:12:37] <dberkholz> so should we vote to clarify that QA's right to create standards in glep 48 includes flag names/functions
-[21:12:51] <rich0> dberkholz: ++
-[21:12:54] <blueness> dberkholz, yep
-[21:13:04] <dilfridge> yeah let's vote
-[21:13:07] <dberkholz> alright, let's do it. consider that the vote.
-[21:13:09] <blueness> we are acting as judges interpreting the law
-[21:13:28] -*- rich0 yes
-[21:13:30] <dberkholz> yes from me
-[21:13:32] -*- blueness yes
-[21:13:49] -*- dilfridge yes
-[21:13:58] <ulm> I abstain, because I'm QA member myself
-[21:14:08] <ulm> (and it already has a majority)
-[21:14:11] <blueness> yeah conflict of interest
-[21:14:22] <dberkholz> alright that's 4 in favor, 2 abstaining (including williamh who's gone)
-[21:14:33] <dberkholz> scarabeus?
-[21:14:57] <dberkholz> doesn't really matter i guess but you can get your voice heard =)
-[21:14:59] <scarabeus> sorry disconnected 2 mins ago
-[21:15:03] <scarabeus> gimme time to read
-[21:15:08] <scarabeus> yep
-[21:16:14] -*- scarabeus votes yes
-[21:16:18] <dberkholz> k cool
-[21:16:57] <blueness> open floor?
-[21:17:04] <dberkholz> i think that negates the next point about gtk flag names, yeah.
-[21:17:34] <creffett|irssi> so to be clear, yoj are affirming QA's decision?
-[21:17:51] <creffett|irssi> *you
-[21:18:40] <scarabeus> we are affirming qa possibility to make the decision
-[21:18:52] <creffett|irssi> okay
-[21:19:01] <blueness> creffett|irssi, my reading is that you do have the right to set flag name/function policy, but i personally would urge you to work with gnome on this
-[21:19:27] <TomWij> creffett|irssi: Given I assume that you missed out on leio's mail; he has asked the council to not address it this time, as to have the GNOME team and QA team discuss this further outside of this context. From what I recall in #gentoo-desktop, Eva was writing up something based on the blocker bug; so, I suspect they will bring reasoning forward soon, feel free to ask leio for confirmation about this
-[21:19:29] <TomWij> and what GNOME team's plan about this is.
-[21:19:31] <scarabeus> you can do what the heck you want there, but if people come screaming to us you didn't talk you should be backed up by hard evidence
-[21:19:38] <rich0> Yes, we didn't explicity uphold or denonuce the decision
-[21:19:57] <dberkholz> i think we should wrap for today
-[21:20:11] <TomWij> Open floor?
-[21:20:12] <blueness> dberkholz, when do we have the next meeting?
-[21:20:12] <dberkholz> let that discussion with QA and gnome continue, since it's obviously still ongoing
-[21:20:15] <dilfridge> basically, we're saying this is within your rights to do.
-[21:20:23] <blueness> because we were off schedule?  should i try to get us back on?
-[21:20:37] <rich0> blueness: suggest we get back on the original schedule - two weeks
-[21:20:43] <blueness> rich0, will do
-[21:20:48] <blueness> i'll send out the call for items tomorrow
-[21:20:55] <dberkholz> i would do that, yeah. next one on march 11
-[21:20:59] <blueness> k
-[21:21:08] <dberkholz> let's have open floor for a couple of minutes and then close
-[21:21:25] <dberkholz> anyone, council or not, got new issues to raise?
-[21:21:38] <chithead> I think council was asked to explicitly affirm the gtk flag policy?
-[21:21:38] <blueness> (my dogs says, let's go for a walk NOW!)
-[21:21:52] <ulm> we have a problem with banning EAPIs 1 and 2
-[21:21:54] <TomWij> Okay, in the context of the MATE discussion; I would like to ask the council whether one should prefer "consistent category naming" or whether one should prefer "bigger categories over smaller categories"?
-[21:21:58] <ulm> with "eapis-banned = 1 2" in layout.conf repoman will complain about any ebuild with these EAPIs being present
-[21:22:08] <ulm> so repoman needs to be patched
-[21:22:32] <ulm> I've deprecated 0 and 3 in layout.conf, for the time being
-[21:22:43] <blueness> ulm, that doesn't seem a big deal, is it?
-[21:22:55] <dilfridge> ulm: didnt expect otherwise... let's talk to the portage guys
-[21:23:01] <rich0> ulm: no issues with delaying implementation of the policy until things are fixed/etc.
-[21:23:10] <dilfridge> exactly
-[21:23:18] <dberkholz> chithead: what i said there was 20:20 < dberkholz@> let that discussion with QA and gnome continue, since it's obviously still ongoing
-[21:23:22] <TomWij> ulm: Not that I speak for creffett, but creffett|irssi and I (or anyone interested) could patch repoman to do as such. Otherwise this becomes a PMS issue; which, I think we're not going to have addressed any time soon.
-[21:23:52] <rich0> Well, we can consider it banned even if repoman isn't patched.
-[21:23:55] <blueness> who is taking care of portage these days? is it dol-sen?
-[21:23:56] --> billie_ (~billie@gentoo/developer/billie) hat #gentoo-council betreten
-[21:24:04] <rich0> Just nobody will be yelling at you for it just yet.
-[21:24:08] <ulm> TomWij: layout.conf is not in PMS
-[21:24:14] <TomWij> blueness: A whole team, dol-sen is the leader.
-[21:24:22] <blueness> open a bug
-[21:24:23] <TomWij> ulm: Sorry, excuse me; I'm reading between the lines.
-[21:24:51] <TomWij> (New leader in ~3 weeks IIRC)
-[21:24:52] <ulm> TomWij: probably a new variable would be best
-[21:25:08] <ulm> and keep the meaning of present eapis-banned
-[21:25:26] <TomWij> ulm: In that case; then yes, that would work.
-[21:25:28] <dberkholz> TomWij: i tend to prefer bigger categories personally.
-[21:25:50] <dberkholz> TomWij: i have a script around that makes recommendations on category size. probably d.g.o/~me/scripts/
-[21:25:58] <TomWij> (And we name the other one in a way that it indicates "no new ebuilds" or so.)
-[21:26:24] <ulm> TomWij: let's bikeshed this in #-portage ;)
-[21:26:29] <TomWij> dberkholz: Yes, someone brought up to me in #gentoo-desktop that past discussion(s) on the ML (eg. the new games category) reveals that larger categories are preferred.
-[21:26:36] <dberkholz> TomWij: if you need anything more formal, next meeting is coming up in just a couple of weeks
-[21:26:56] <dberkholz> TomWij: it's mainly pragmatic having to do with most new categories involving package moves for negligible benefit
-[21:26:59] <rich0> Call for agenda will probably go out in the next day or two :)
-[21:27:12] <dberkholz> alright, we're gonna close the meeting, but feel free to keep discussing here
-[21:27:15] <dberkholz> thanks all
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140311-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20140311-summary.txt
deleted file mode 100644
index d1fad18cef..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140311-summary.txt
+++ /dev/null
@@ -1,120 +0,0 @@
-Summary of Gentoo council meeting 11 March 2014
-
-
-Agenda
-======
-1. Roll call
-2. Open issues - vote on GLEP 63
-3. Ban on EAPI 1 and 2 should extend to updating EAPI in existing ebuilds
-4. Make all cosmetic repoman warnings fatal
-5. Adherence to FHS standards in Gentoo: putting config files int /etc
-6. Bugs assigned to Council
-7. Open floor
-
-
-1. Roll call
-============
-
-Present: blueness dberkholz dilfridge rich0 ulm williamh
-Absent: scarabeus
-
-
-2. Open issues - vote on GLEP 63
-================================
-
-Previous council action approved in principle the policies outlined in
-"GLEP 63: Gentoo GPG key policies" [1], but delayed the vote for approval
-until the final language was put in place.  dilfridge presented a shorter
-version of the GLEP which removed the "howto" language and reduced it to
-just policy [2].  Discussion progressed to a consensus that we should have
-only policy in the GLEP and a practical guide should be a separate document
-which can be changed without council vote.
-
-We tabled the vote until either an email vote (initiated by dilfridge) or
-the next meeting.
-
-Ref:
-[1] https://wiki.gentoo.org/wiki/GLEP:63
-[2] https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1001a
-
-
-3. Ban on EAPI 1 and 2 should extend to updating EAPI in existing ebuilds
-=========================================================================
-
-The council considered the question of whether the ban on EAPIs 1 and 2 should
-extended to updating EAPIs in *existing* ebuilds, and not just new ebuilds added
-to the tree [3]. mgorny noted that we need bumps from EAPI 0 to 1 because we need
-an easy way to introduce slotting without the major rewriting of ebuild phases
-than an EAPI 0 to 3 bump would require.  After discussion, the council voted on
-the following motion:
-
-"EAPI 1 and 2 are now banned.  This ban should not only be limited to new ebuilds,
-but should be extended to include updating EAPIs in *existing* ebuilds.  In case
-of non-maintainer commits to fix dependencies, EAPI=0 ebuilds may be updated to
-EAPI=1 to keep the changes at a non-intrusive level, as a temporary workaround."
-
-The motion carried with 4 yes, 1 no and 1 abstention.
-
-Ref:
-[3] http://permalink.gmane.org/gmane.linux.gentoo.project/3382
-
-
-4. Make all cosmetic repoman warnings fatal
-===========================================
-
-The council considered the question of whether all repoman warnings should be
-made fatal [4].  Consensus was reached that this would lead to too many false
-positives.
-
-The motion failed with 4 no and 1 abstention.
-
-Ref:
-[4] http://permalink.gmane.org/gmane.linux.gentoo.project/3358
-
-
-5. Adherence to FHS standards in Gentoo: putting config files int /etc
-======================================================================
-
-The question of where config files should go was raised by patrick [5,6,7].  The
-council discussed whether it should be policy to put all config files in /etc.
-However, what defines a config file is unclear because some packages, like udev or
-eudev, put their *default* config files in /lib/udev/rules.d which are overridden
-by the files in /etc/udev/rules.d.  The former are not meant to be user-edited while
-the later are.  The council is okay with static config files living outside of /etc
-while user-editable config files should be in /etc.
-
-rich0 introduced the following motion:
-
-"Council does not feel additional policy required regarding config files in /etc.
-In particular packages that place config templates in /usr or /lib* and allow overriding
-in /etc are fine. Specific issues not already discussed can be raised in future meetings."
-
-The motion passed with 4 yes and 1 abstention.
-
-Ref:
-[5] http://permalink.gmane.org/gmane.linux.gentoo.project/3357
-[6] http://permalink.gmane.org/gmane.linux.gentoo.project/3367
-[7] http://devmanual.gentoo.org/general-concepts/filesystem/index.html
-
-
-6. Bugs assigned to Council
-===========================
-
-The council looked at two open bugs:
-
-a) Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council meetings
-
-dberkholz said he would upload those summaries soon.
-
-b) Bug #477030 - Missing summary for 20130611 council meeting
-
-There has been no progress.  scarabeus was to nudge betelgeuse for that summary.
-
-
-7. Open floor
-=============
-
-No issues were brought forward.
-
-
-Summary submitted by Anthony G. Basile <blueness@gentoo.org>
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140311.txt b/xml/htdocs/proj/en/council/meeting-logs/20140311.txt
deleted file mode 100644
index fdea0fc49b..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140311.txt
+++ /dev/null
@@ -1,496 +0,0 @@
-Mar 11 14:59:01 <blueness>	ping dberkholz dilfridge rich0 scarabeus ulm  williamh
-Mar 11 14:59:06 dberkholz dberkholz|mob dilfridge dilfridge|mobile dleverton_ DrEeevil 
-Mar 11 14:59:13 <blueness>	dberkholz|mob, mob?
-Mar 11 14:59:28 *	ulm here
-Mar 11 14:59:30 <dberkholz|mob>	mobile
-Mar 11 14:59:38 <blueness>	ah
-Mar 11 14:59:44 *	rich0 here
-Mar 11 14:59:47 *	dilfridge here
-Mar 11 14:59:58 <rich0>	he's ganging up on us
-Mar 11 15:00:13 <blueness>	ping scarabeus ulm  williamh
-Mar 11 15:00:50 *	ulm still here ;)
-Mar 11 15:01:07 <blueness>	scarabeus, WilliamH are missing
-Mar 11 15:01:47 <blueness>	let's wait a few minutes (the time it takes me to run downstairs and get tea)
-Mar 11 15:02:25 <dberkholz|mob>	Sounds good
-Mar 11 15:02:29 *	WilliamH is here
-Mar 11 15:03:30 <blueness>	scarabeus, ping last time
-Mar 11 15:03:45 <blueness>	let's start
-Mar 11 15:03:55 <rich0>	I think we might actually make it through the agenda this time!
-Mar 11 15:03:56 <blueness>	agenda: http://dev.gentoo.org/~blueness/council/council_agenda_20140311.txt
-Mar 11 15:04:17 <blueness>	If there are no objections we'll proceed to item 1
-Mar 11 15:04:29 <blueness>	Vote: GPG signing GLEP 63
-Mar 11 15:04:36 <blueness>	https://wiki.gentoo.org/wiki/GLEP:63
-Mar 11 15:05:03 <dilfridge>	there was discussion whether we should place in the GLEP only the bare specs or also the howto parts
-Mar 11 15:05:04 <blueness>	So we're voting to accept GLEP 63 which should be ready
-Mar 11 15:05:22 <dilfridge>	https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1001a
-Mar 11 15:05:32 <dilfridge>	^ this is a re-arranged "barebones" version.
-Mar 11 15:05:48 <rich0>	I'm fine with accepting it as-is as long as it is understood that it isn't effective/implemented until communications/docs/etc are in place.  Works fine as a reference for design/etc of all that.
-Mar 11 15:06:05 <dilfridge>	I prefer the longer version.
-Mar 11 15:06:09 <rich0>	Of course, if they do clean up the docs, presumably the docs section of the GLEP should be updated.
-Mar 11 15:06:18 <dilfridge>	Just wanted to have something to show up.
-Mar 11 15:06:37 <rich0>	But it isn't absolutely required if the intent is to just show the state at the time of review.
-Mar 11 15:07:03 <ulm>	I think the documentation should better go to a less rigid part of the wiki
-Mar 11 15:07:16 <blueness>	dilfridge, by the longer version you mean the one at https://wiki.gentoo.org/wiki/GLEP:63
-Mar 11 15:07:21 <ulm>	so it can be updated more easily, without us voting on it every time
-Mar 11 15:07:24 <dilfridge>	blueness: yes.
-Mar 11 15:07:28 <rich0>	The biggest issue with docs in a GLEP is that they tend to get crufty.
-Mar 11 15:07:33 <dberkholz|mob>	Prefer longer with examples, not necessarily as canonical doc
-Mar 11 15:08:18 <rich0>	I'm fine either way - I could see the argument for either approach.
-Mar 11 15:08:29 <dilfridge>	_robbat2|irssi: a penny for your thoughts?
-Mar 11 15:08:29 <blueness>	Well what came forward last time was to vote on the longer version, so i'm not sure what to do with the shorter one now
-Mar 11 15:09:16 <WilliamH>	blueness: the vote is on the longer version...
-Mar 11 15:09:32 <ulm>	the shorter version is not so much shorter, btw
-Mar 11 15:10:03 <blueness>	Should be proceed with the vote then?
-Mar 11 15:10:08 *	dilfridge is fine with voting on the long version.
-Mar 11 15:10:08 <blueness>	on the longer version?
-Mar 11 15:10:18 <rich0>	wfm
-Mar 11 15:10:22 <ulm>	wfm too
-Mar 11 15:10:23 <blueness>	waiting
-Mar 11 15:11:00 <WilliamH>	I'm also not sure that the official howto for this should be part of the glep...
-Mar 11 15:11:05 <ulm>	I'd like to hear robbat2's opinion
-Mar 11 15:11:37 <dberkholz|mob>	I'm for longer as I said. Should be clear it's example how to do it now
-Mar 11 15:12:00 <dberkholz|mob>	Not docs council must always approve updates of
-Mar 11 15:12:03 <blueness>	its unlikely things will change
-Mar 11 15:12:05 <rich0>	I view the docs in the GLEP a bit like a "reference implementation" - it doesn't mean it is the version you run.
-Mar 11 15:12:17 <rich0>	Granted, they fall considerably short of a reference implementation.
-Mar 11 15:12:30 <_robbat2|irssi>	sorry, was in this talk
-Mar 11 15:12:39 *	kallamej has quit (Ping timeout: 264 seconds)
-Mar 11 15:12:53 <_robbat2|irssi>	and this conference wifi is bad
-Mar 11 15:13:16 <blueness>	_robbat2|irssi, did you get the backlog?
-Mar 11 15:13:21 <_robbat2|irssi>	i do like the 1001a part
-Mar 11 15:13:30 <_robbat2|irssi>	but i think I need to reformat the recommendation chunk
-Mar 11 15:13:34 <_robbat2|irssi>	to explain what it's doing
-Mar 11 15:13:38 <_robbat2|irssi>	or rather specify
-Mar 11 15:13:42 <_robbat2|irssi>	not in a gnupg config file format
-Mar 11 15:14:20 <_robbat2|irssi>	then after that, explain why
-Mar 11 15:14:25 <_robbat2|irssi>	lastly, in a NEW document
-Mar 11 15:14:28 <_robbat2|irssi>	have the gpg config file
-Mar 11 15:14:32 <_robbat2|irssi>	along with instructions
-Mar 11 15:14:53 <_robbat2|irssi>	is the council in favour of the actual spec contents?
-Mar 11 15:14:58 <_robbat2|irssi>	(aside from the format)
-Mar 11 15:15:02 <rich0>	In effect, the "bare minimum requirements" are the real policy.  The rest is just howtos, commentary on best practices, etc.
-Mar 11 15:15:14 <rich0>	Only the minimum requirements really have any kind of force.
-Mar 11 15:15:37 <dilfridge>	suggestion: we vote now that the minimum requirements remain unchanged
-Mar 11 15:16:00 <_robbat2|irssi>	i'm wondering if some of the parts in recommendations might be moved to the min requirements
-Mar 11 15:16:06 <dilfridge>	ok
-Mar 11 15:16:18 <blueness>	its sounds like you two want to work on this more
-Mar 11 15:16:23 <blueness>	we can table the vote
-Mar 11 15:16:44 *	WilliamH agrees with blueness
-Mar 11 15:16:56 <dilfridge>	works for me too, shall we target the next meeting then?
-Mar 11 15:17:12 <ulm>	we could have a vote per e-mail if we don't want to delay it by another month
-Mar 11 15:17:13 <blueness>	dilfridge, yes, we need to vote to table it though (following roberts rules)
-Mar 11 15:17:39 <blueness>	ulm, i'm not sure there's an urgency, but i'm not against an email vote
-Mar 11 15:18:10 <rich0>	Those working on implementation shouldn't hold up or anything.  Nobody objects to the policy itself.  This is really about the docs/etc.
-Mar 11 15:18:11 <dilfridge>	_robbat2|irssi: your call (I think in general there is agreement with the specs, but we can't formally vote on something unfinished :)
-Mar 11 15:18:30 <rich0>	We've been fine on the specs for two months now.
-Mar 11 15:18:55 <blueness>	rich0, we wanted to see final language, which is why this keeps getting tabled
-Mar 11 15:19:29 <rich0>	blueness: sure - wasn't a complaint.  Just supporting the comment that getting this GLEP approved shouldn't stop anybody from writing infra code, docs, etc.
-Mar 11 15:19:38 <dilfridge>	I dont see much disagreement with the specs here...
-Mar 11 15:20:54 <blueness>	dilfridge, is the short document sufficient for a vote now, given that we agree with the specs? ie are all the spec in there?
-Mar 11 15:21:41 <dilfridge>	in my opinion yes, but robbat2 is the real author.
-Mar 11 15:22:00 <blueness>	_robbat2|irssi, ^^^ any opinion on my question
-Mar 11 15:22:19 <dilfridge>	my intention was to have the long and short version "identical in specifications, differing in explanation/docs"
-Mar 11 15:22:51 <blueness>	i think robbat2 is having net issues
-Mar 11 15:23:34 <blueness>	i suggest tabling this with a email vote, initiated by dilfridge when he and robbat2 have sorted it out
-Mar 11 15:23:47 <WilliamH>	That's fine with me.
-Mar 11 15:24:11 <dilfridge>	ok
-Mar 11 15:24:29 <blueness>	table it? dberkholz rich0 ulm 
-Mar 11 15:24:38 <ulm>	+1
-Mar 11 15:24:40 <rich0>	++
-Mar 11 15:24:43 <dilfridge>	+1
-Mar 11 15:24:44 <WilliamH>	table it
-Mar 11 15:25:08 <blueness>	okay, dilfridge when you're ready, email the group and we'll vote.  otherwise its on the next agenda
-Mar 11 15:25:14 <dilfridge>	will do
-Mar 11 15:25:24 <blueness>	okay next item: Ban on EAPI 1 and 2 should extend to updating EAPI in existing ebuilds
-Mar 11 15:25:43 <blueness>	ulm, you brought this up, do you want to speak to it?
-Mar 11 15:26:15 <ulm>	IMHO a "ban" means that once the count of e.g. EAPI 1 ebuilds is down to zero, it should stay there
-Mar 11 15:26:37 <ulm>	which isn't the case if changing ebuilds to EAPI 1 and 2 is still allowed
-Mar 11 15:27:03 <ulm>	in other words, these EAPIs are on their way out of the tree
-Mar 11 15:27:26 <blueness>	ulm, to be honest, i thought that was implicit in what we voted on last time, but i can see how that confusion might arrise because we did say the bans was on "new" ebuilds
-Mar 11 15:27:29 <ulm>	so there should be no excuse for adding such ebuilds, or changing others to these EAPIs
-Mar 11 15:28:04 <ulm>	blueness: devs are more creative in interpreting the rules than we had imagined ;)
-Mar 11 15:28:17 <blueness>	ulm, okay
-Mar 11 15:28:23 <mgorny>	ulm: how are we supposed to add slot deps to EAPI=0 ebuilds then?
-Mar 11 15:28:29 <WilliamH>	Why would you change an ebuild *to* one of these eapis?
-Mar 11 15:28:37 <ulm>	mgorny: update to EAPI 3 or later
-Mar 11 15:28:59 <mgorny>	this goes outside of 'acceptable' for touching sb's package
-Mar 11 15:29:14 <mgorny>	and this is a lot of unnecessary work for old ebuilds
-Mar 11 15:29:18 <ulm>	but you have to change the EAPI anyway, so why not to a supported one?
-Mar 11 15:29:37 <mgorny>	because changing 0 -> 1 doesn't require many changes, while 0 -> 3 does
-Mar 11 15:29:41 <rich0>	EAPI 0->1 is less work than 0->5 - less phase rewriting/etc.
-Mar 11 15:29:48 <blueness>	i see
-Mar 11 15:29:55 <blueness>	mgorny, just do it one step at a time
-Mar 11 15:29:55 <rich0>	I can see why people would rather do it.
-Mar 11 15:29:57 <dilfridge>	file a bug to maintainer (get ignored)
-Mar 11 15:30:11 *	kallamej (~kallamej@gentoo/developer/kallamej) has joined #gentoo-council
-Mar 11 15:30:42 <blueness>	does anyone have a count of how many ebuilds we're talking here?
-Mar 11 15:30:53 <ulm>	less than 300
-Mar 11 15:30:57 <ulm>	for eapi 1
-Mar 11 15:31:20 <rich0>	If we just made the policy no moving from a non-banned EAPI to a banned one that covers the obvious loophole.
-Mar 11 15:31:21 <dilfridge>	EAPI=0 is somewhere around 6000
-Mar 11 15:31:45 <ulm>	dilfridge: yeah, but not all of them to be converted to 1
-Mar 11 15:31:47 <rich0>	EAPI0 might get an exception.
-Mar 11 15:31:59 <rich0>	EAPI0 is almost banned, but we have some details to work out first.
-Mar 11 15:32:06 <dberkholz>	so the argument here is that any forward ports to 0 must move forward to at least 3
-Mar 11 15:32:11 <dberkholz>	errr. *from 0
-Mar 11 15:32:19 <rich0>	I don't see EAPI0->1 as really anything but an improvement.
-Mar 11 15:32:46 <dilfridge>	we want to remove EAPI=1 usage, if we allow upgrade 0->1 that will never happen
-Mar 11 15:32:58 <ulm>	we could add an exception for updating from 0 to 1 in case of slot dependenies
-Mar 11 15:33:15 <rich0>	dilfridge: at the moment EAPI1 doesn't cost us anything, and EAPI0 will not be around forever.
-Mar 11 15:33:18 <blueness>	ugh no, that's messy
-Mar 11 15:33:27 <ulm>	blueness: it is ;)
-Mar 11 15:33:37 *	ulm prefers clear rules
-Mar 11 15:34:05 <rich0>	The thing is, we have to bite the EAPI3 bullet sooner or later.
-Mar 11 15:34:36 <ulm>	basically, all the ebuilds that are moved from 0 to 1 now have to be touched a second time lateron
-Mar 11 15:34:42 <WilliamH>	To me banned is banned. no emore ebuilds should be committed to the tree with a banned eapi.
-Mar 11 15:34:52 <mgorny>	ulm: they will be mostly removed later on
-Mar 11 15:35:00 <blueness>	rich0, that's why i'm saying we can move at a comfortable pace here
-Mar 11 15:35:08 <ulm>	mgorny: honestly, I doubt this
-Mar 11 15:35:09 <mgorny>	we need to fix deps in old versions, they don't take more maint than that
-Mar 11 15:35:33 <mgorny>	at least the ebuilds i was touching had newer versions with newer EAPI
-Mar 11 15:35:43 <rich0>	If the package manager teams were screaming for EAPI relief I could see pushing harder.  Right now they're content.
-Mar 11 15:35:53 <ulm>	mgorny: if there's a newer ebuild around for the same pkg, you can take that one as example
-Mar 11 15:36:11 <dberkholz>	is it really that much work to bring them forward to 3?
-Mar 11 15:36:25 <dberkholz>	most of the stuff you can skip, a tiny bit of function refactoring for 2, eh
-Mar 11 15:36:53 <blueness>	dberkholz, i wouldn't have thought it was that much work, but i guess i can see some thorny situations
-Mar 11 15:37:12 <blueness>	eapi0 made for some very strange phase coding
-Mar 11 15:37:17 <rich0>	dberkholz: certainly more opportunity for trouble with the refactoring.  Not that big a deal, but if I had to edit 50 ebuilds I'd be reluctant to deal with it...
-Mar 11 15:37:25 <blueness>	like configuring during compile etc
-Mar 11 15:37:27 <mgorny>	when i have like 50 packages to update, i don't want to waste time converting old ebuilds nobody will use...
-Mar 11 15:37:48 <blueness>	mgorny, can you give us a deprecation pathway then
-Mar 11 15:37:58 *	alexxy has quit (Ping timeout: 240 seconds)
-Mar 11 15:37:58 <mgorny>	if you tell me it's fine to leave broken deps in old ebuilds, i'm fine with that
-Mar 11 15:38:10 <blueness>	like if we make an exception for a few older ebuild versions until phased out?
-Mar 11 15:38:15 <rich0>	Maybe look at it another way - which is worse, treecleaning or having more EAPI1 ebuilds?  I think in practice users would object more to the treecleaning.
-Mar 11 15:38:41 <dberkholz>	mgorny: if nobody's gonna use them, why not remove them
-Mar 11 15:39:06 <rich0>	dberkholz: That's the whole ain't-broke-don't-fix thing.
-Mar 11 15:39:07 *	WilliamH agrees with dberkholz  here. if no one is using the old stuff, remove it.
-Mar 11 15:39:24 <rich0>	I'm sure most of it will get treecleaned, but there is some value in delaying that as much as possible.
-Mar 11 15:39:25 <mgorny>	because the maintainer believes in keeping old versions and i'm really tired of fighting all the personal preference issues in gentoo?
-Mar 11 15:39:40 <dilfridge>	file a bug for the maintainer?
-Mar 11 15:39:48 <rich0>	If it IS maintained then LART the maintainer.
-Mar 11 15:39:49 *	alexxy (~alexxy@gentoo/developer/alexxy) has joined #gentoo-council
-Mar 11 15:40:04 <blueness>	LART?
-Mar 11 15:40:11 <dberkholz>	is that like LARP
-Mar 11 15:40:18 <rich0>	I think the bigger issue is stuff that isn't maintained, in which case the preferences that matter are those of the folks who actually want to do something about it.
-Mar 11 15:40:34 *	Arfrever has quit (Read error: Operation timed out)
-Mar 11 15:40:45 <dilfridge>	"Luser Attitude Readjustment Tool"
-Mar 11 15:40:49 <blueness>	ahah!
-Mar 11 15:40:54 <blueness>	i like that
-Mar 11 15:41:11 <ulm>	if the opinion is that it causes to many inconveniences to devs, then our decision on banning EAPIs 1 and 2 was premature and we should revert it
-Mar 11 15:41:32 <ulm>	which I'd really dislike though
-Mar 11 15:41:38 <blueness>	sound logic
-Mar 11 15:42:13 *	WilliamH agrees with what was said above.
-Mar 11 15:42:25 <WilliamH>	At some point we are going to have to convert all of this stuff to at least eapi 3.
-Mar 11 15:42:36 <dberkholz>	inconvenience to devs isn't just a short term thing
-Mar 11 15:42:43 <dberkholz>	it's also about long term maintenance inconvenience
-Mar 11 15:42:57 <rich0>	I don't think we need absolutes.
-Mar 11 15:43:03 <blueness>	dberkholz, what do you mean?
-Mar 11 15:43:07 <rich0>	We don't want people writing new stuff in EAPI1/2
-Mar 11 15:43:12 <dberkholz>	having a big stack of EAPIs sitting around is confusing
-Mar 11 15:43:28 <dberkholz>	pretty much nobody even remembers what's in what anymore, unless they were around for generation 0
-Mar 11 15:43:28 <rich0>	That doesn't mean that using it as a stepping-stone for existing EAPI0 stuff is bad.
-Mar 11 15:43:49 <mgorny>	well, in my opinion there's no real issue here
-Mar 11 15:44:09 <mgorny>	if people are intentionally doing step-0-to-1 to use banned EAPI, there will be action required
-Mar 11 15:44:14 *	WilliamH still thinks that if an eapi is banned it is banned
-Mar 11 15:44:21 <rich0>	I'm all for banning EAPI0 as well, just with an exception for the toolchain.
-Mar 11 15:44:39 <rich0>	mgorny: ++
-Mar 11 15:44:40 <blueness>	rich0, one at a time!
-Mar 11 15:45:06 <blueness>	okay has everyone had enough discussion?
-Mar 11 15:45:11 <rich0>	We're not robots.  We don't need rules that a robot can follow, or a lawyer for that matter.
-Mar 11 15:45:13 <mgorny>	but if there's a bug that needs being fixed quickly and with little effort, i don't see doing temporarily EAPI change a problem
-Mar 11 15:45:42 <ulm>	mgorny: it's also about EAPI support in eclasses
-Mar 11 15:45:44 <blueness>	mgorny, how would you phrase that as a clean exception to the eapi1/2 ban
-Mar 11 15:46:07 <blueness>	so we clearly exclude undesireable 0->1 bumps
-Mar 11 15:46:28 <rich0>	Why not this, EAPI1/2 may not be used for ebuilds that are not already in the tree as of this date.
-Mar 11 15:46:51 <ulm>	rich0: this would allow 5->1
-Mar 11 15:47:03 <blueness>	heh
-Mar 11 15:47:29 <dberkholz>	i think rich0 was right about this point, we shouldn't need to explicitly preclude every absurd behavior
-Mar 11 15:47:30 <rich0>	EAPI1/2 may not be used for ebuilds unless they are already in the tree using EAPI0 as of this date.
-Mar 11 15:47:43 <mgorny>	blueness: if you really feel we need this, how about saying something about timeframe for keeping ebuilds?
-Mar 11 15:47:59 <mgorny>	as in, allowing bump from 0 to 1 when ebuild is not intended to be kept more than 30/60 days or so
-Mar 11 15:47:59 <ulm>	the thing is, either we trust devs to DTRT, then we don't need a ban
-Mar 11 15:48:04 <blueness>	mgorny, i like rich0's wording
-Mar 11 15:48:11 <ulm>	or we don't, then we should enforce it in some way
-Mar 11 15:48:40 <rich0>	Or more refined, EAPI1/2 may not be used for ebuilds unless they are already in the tree using EAPI0/1/2 as of this date.
-Mar 11 15:49:05 <blueness>	how do people feel about rich0's extention to the ban on 1/2 ?
-Mar 11 15:49:05 <dilfridge>	is there a good reason for using EAPI=2?
-Mar 11 15:49:05 <ulm>	rich0: better ;)
-Mar 11 15:49:17 <TomWij>	mgorny: If stabilization of EAPI 1 ebuild takes place it can keep it around for longer; to be more clear, the second stabilization of a non-EAPI 1 ebuild after that can block the EAPI 1 ebuild and keep it in position.
-Mar 11 15:49:27 <dilfridge>	I mean, the step from 2 to 3 is minima.
-Mar 11 15:49:43 <blueness>	good point
-Mar 11 15:49:53 <ulm>	dilfridge: /EAPI/s/2/3/ ?
-Mar 11 15:50:00 <rich0>	That is really just the minimum policy.  Devs should move to EAPI5 whenever practical.
-Mar 11 15:50:05 <TomWij>	(Just hoping the actual cleaning effort and the effect of stabilization is taken into consideration if you really want to see this go towards 0.)
-Mar 11 15:50:05 <rich0>	And implement slot op deps as well.
-Mar 11 15:50:44 <mgorny>	and use :<current-slot> whenever no other slot is applicable but this is yet another topic
-Mar 11 15:51:21 <dilfridge>	"In case of non-maintainer commits to fix dependencies, EAPI=0 ebuilds may be updated to EAPI=1 to keep the changes at a non-intrusive level, as a temporary workaround."
-Mar 11 15:52:15 <blueness>	sounds good to me, is the committee comfortable with discuss/voting on dilfridge's formulation of the exception?
-Mar 11 15:52:22 <ulm>	dilfridge: plus the wording from the agenda?
-Mar 11 15:52:35 <dilfridge>	why not
-Mar 11 15:52:36 <dilfridge>	yes
-Mar 11 15:52:38 <rich0>	wfm - that's the tightest possible exception - there is a risk that other exceptions will come up.
-Mar 11 15:52:40 <dberkholz>	i don't think we need to add specific policy to say something is allowed that our current vote already says is allowed
-Mar 11 15:52:53 <ulm>	"EAPI 1 and 2 are now banned.  This ban should not only be limited to new ebuilds, but should be extended to include updating EAPIs in *existing* ebuilds."
-Mar 11 15:53:13 <ulm>	plus dilfridge's suggestion above
-Mar 11 15:53:19 <rich0>	ulm: ++ for now
-Mar 11 15:53:27 <rich0>	We can revisit if something comes up.
-Mar 11 15:53:36 <dberkholz>	this feels like we're getting too specific
-Mar 11 15:53:40 <rich0>	Seriously, we need to get to the whitespace ban before we run out of time!  :)
-Mar 11 15:53:44 <dilfridge>	lol
-Mar 11 15:53:52 <blueness>	okay the motion is: "EAPI 1 and 2 are now banned.  This ban should not only be limited to new ebuilds, but should be extended to include updating EAPIs in *existing* ebuilds.  In case of non-maintainer commits to fix dependencies, EAPI=0 ebuilds may be updated to EAPI=1 to keep the changes at a non-intrusive level, as a temporary workaround."
-Mar 11 15:54:17 *	ulm yes
-Mar 11 15:54:20 *	rich0 yes
-Mar 11 15:54:25 *	dilfridge yes
-Mar 11 15:54:26 *	blueness yes
-Mar 11 15:54:28 <dberkholz>	no, way too specific
-Mar 11 15:54:41 <blueness>	WilliamH, ???
-Mar 11 15:54:56 <dberkholz>	what does temporary even mean, does that guarantee someone's going to come back and fix it
-Mar 11 15:54:59 *	WilliamH is reading
-Mar 11 15:55:22 <rich0>	temporary = not eternal
-Mar 11 15:55:24 <dilfridge>	dberkholz: in this context it's more or less a declaration of intent...
-Mar 11 15:55:47 <dilfridge>	this is about the most restricted exception that I could come up with
-Mar 11 15:55:52 <rich0>	I don't have a problem with the specificity - this isn't the last meeting of the council ever and we can deal with issues that arise
-Mar 11 15:55:55 <ulm>	dberkholz: if there are no EAPI 0 ebuilds left, the workaround will end
-Mar 11 15:56:04 <blueness>	even without WilliamH vote, it passes
-Mar 11 15:56:19 <ulm>	or if the sun expands to a red giant, if that will happen earlier ;)
-Mar 11 15:56:31 <dilfridge>	Dalek invasion.
-Mar 11 15:56:47 <blueness>	we need to move on to the other issues
-Mar 11 15:56:51 <dberkholz>	i'd just define that a banned EAPI means that no new ebuilds or backports are allowed, and in-place edits are discouraged
-Mar 11 15:56:58 <dberkholz>	but then again i'm not the chair =)
-Mar 11 15:57:15 <blueness>	dberkholz, chairs don't drive discussions ;)
-Mar 11 15:57:50 <rich0>	driving discussions isn't always a bad thing...  :)
-Mar 11 15:58:01 <ulm>	blueness: by robert's rule, you have to admit us to the floor ;)
-Mar 11 15:58:08 <blueness>	yes
-Mar 11 15:58:22 <blueness>	its just hard in irc because of timing
-Mar 11 15:58:30 *	dilfridge never got to know that robert
-Mar 11 15:58:38 <WilliamH>	lol
-Mar 11 15:58:48 <blueness>	are we done with this issue?
-Mar 11 15:59:02 *	rich0 is remined of attack plan R, R as in Robert...
-Mar 11 15:59:08 <blueness>	next: Make all cosmetic repoman warnings fatal
-Mar 11 15:59:21 *	WilliamH abstains
-Mar 11 15:59:23 <WilliamH>	for the record
-Mar 11 15:59:31 <blueness>	WilliamH, okay noted WilliamH 
-Mar 11 15:59:35 <WilliamH>	that was for previous issue
-Mar 11 15:59:49 <blueness>	WilliamH, understood
-Mar 11 16:00:10 <blueness>	okay so this comes from patrick, and he wants all repoman cosmetic warnings to be fatal
-Mar 11 16:00:26 <blueness>	discussion?
-Mar 11 16:00:44 <ulm>	I've seen way too many false positives for both whitespace and quoting issues, to make these warnings fatal
-Mar 11 16:00:53 <rich0>	The only specific suggestion I'd entertain was unused local useflag descriptions in metadata.xml, but I'm not sure if that has any risk of false positives.
-Mar 11 16:01:01 <ulm>	fatal for use flag descriptions is fine
-Mar 11 16:01:28 <blueness>	i agree with ulm, too many false positives but use flags is fine
-Mar 11 16:01:31 <rich0>	I'm also fine with devs forcing that situation anyway if the removal is only temporary.
-Mar 11 16:02:02 <ulm>	e.g. patches or config files inlined in here-documents are bound to produce false whitespace warnings
-Mar 11 16:02:14 <blueness>	ulm, good point
-Mar 11 16:02:19 <dilfridge>	how about this:
-Mar 11 16:02:45 <dilfridge>	"make all repoman warnings where with current portage tree no false positives are known fatal"
-Mar 11 16:02:59 <blueness>	not sure about that
-Mar 11 16:03:04 <rich0>	I think that is pretty broad.
-Mar 11 16:03:08 <blueness>	"no false positives" might be vague
-Mar 11 16:03:22 <ulm>	dilfridge: that would include -j1
-Mar 11 16:03:23 <rich0>	That includes deprecated eclasses, etc.
-Mar 11 16:03:41 <rich0>	Warnings are warnings for a reason.
-Mar 11 16:03:42 <dilfridge>	true, makes no sense.
-Mar 11 16:03:55 <rich0>	Devs need to use their brains.
-Mar 11 16:04:18 <ulm>	must we vote about this at all?
-Mar 11 16:04:28 <blueness>	if they didn't then we'd just write an ebuild writing utility
-Mar 11 16:05:00 <blueness>	ready for the vote?
-Mar 11 16:05:02 <ulm>	who in his right mind would see a use flag description warning and not fix it?
-Mar 11 16:05:10 <dilfridge>	we could just make an informal request to the portage team to turn the screw in future releases
-Mar 11 16:05:22 <blueness>	ulm, i don't always on my overlay when i copy a package form the tree
-Mar 11 16:05:43 <ulm>	blueness: yeah, in that situation it makes some sense
-Mar 11 16:06:04 <rich0>	Council to repoman: we're tired of being the only ones made to dance...
-Mar 11 16:06:04 <blueness>	i only want to change one ebuild, and keep everything else the same, you get the idea
-Mar 11 16:06:45 <blueness>	i'm getting the sense the council isn't for this ... no voices in favor
-Mar 11 16:06:55 <rich0>	blueness: good point - as an arch tester you get repoman warnings all the time
-Mar 11 16:07:03 <blueness>	yep
-Mar 11 16:07:11 <blueness>	i did my share of that
-Mar 11 16:07:58 <blueness>	okay lets vote: vote yes if you are in favor of "Making all cosmetic repoman warnings fatal" 
-Mar 11 16:08:15 *	rich0 no
-Mar 11 16:08:17 *	blueness no
-Mar 11 16:08:20 *	WilliamH no
-Mar 11 16:08:21 *	dilfridge abstains
-Mar 11 16:08:40 <blueness>	ulm, dberkholz ???
-Mar 11 16:09:18 <blueness>	dberkholz|mob, ulm ???
-Mar 11 16:09:30 *	ulm no
-Mar 11 16:09:51 dberkholz dberkholz|mob dilfridge dilfridge|mobile dleverton_ DrEeevil 
-Mar 11 16:09:59 <blueness>	even without dberkholz the motion fails
-Mar 11 16:10:10 <blueness>	okay next item ...
-Mar 11 16:10:13 <blueness>	drum roll
-Mar 11 16:10:19 <blueness>	Adherence to FHS standards in Gentoo: putting config files int /etc
-Mar 11 16:10:49 <blueness>	this also comes from patrick, who wants us to adhere to at least part of FHS standards
-Mar 11 16:10:49 <rich0>	I think config files intended to be user-editable should go in /etc.
-Mar 11 16:10:55 <blueness>	namely config files in /etc
-Mar 11 16:10:57 <blueness>	only
-Mar 11 16:11:09 <rich0>	The stuff that was under debate is really just config defaults, intended to be overridden in /etc.
-Mar 11 16:11:09 <WilliamH>	Here's the thing.
-Mar 11 16:11:23 <WilliamH>	rich0: has it correct.
-Mar 11 16:11:42 <rich0>	Every binary has config defaults stored in /usr - you just normally have to edit the C source to change them.
-Mar 11 16:11:43 <WilliamH>	These files that are not going in /etc are
-Mar 11 16:11:45 <dilfridge>	This kinda conflicts with our policy to stick with upstream. (As much as it pains me.)
-Mar 11 16:11:48 <blueness>	(guys, excuse me for a few mins while i run to the washroom)
-Mar 11 16:11:59 <WilliamH>	supplied by the packages and are not to be edited by the user.
-Mar 11 16:12:01 <rich0>	The newer trend is to move all the constants into a rule file in /usr, and allow overrides in /etc.
-Mar 11 16:12:30 <ulm>	config files go to CONFIG_PROTECTed locations like /etc
-Mar 11 16:12:36 <ulm>	whereas config defaults are static files and don't need config-protection
-Mar 11 16:12:52 <ulm>	so they can go to /usr/share or /lib
-Mar 11 16:13:09 <rich0>	Certainly room for user education here, however, as I can see why there is confusion.  IF somebody does edit something in /usr it could get clobbered in an update.
-Mar 11 16:13:24 <mgorny>	udev rules are as much config files as .desktop files in /usr/share/applications
-Mar 11 16:13:43 <rich0>	If there is stuff config-protected in /usr that might suggest an area for improvement.
-Mar 11 16:13:45 <blueness>	back
-Mar 11 16:14:06 <rich0>	mgorny: udev rules can be overriden in /etc.  I'm not sure if that is true of .desktop files.
-Mar 11 16:14:21 <WilliamH>	mgorny: what the ones are in /lib/udev or /usr/lib/udev are defaults.
-Mar 11 16:14:23 <rich0>	I don't really think of desktop files as "configuration" though.
-Mar 11 16:14:48 <rich0>	By that logic maybe I want to tweak one of my fonts.  :)
-Mar 11 16:14:54 <ulm>	rich0: there are things like /usr/share/gnupg/ and /usr/share/config/, in fact :(
-Mar 11 16:15:40 *	Arfrever (~Arfrever@apache/committer/Arfrever) has joined #gentoo-council
-Mar 11 16:15:48 <WilliamH>	Patric's goal with this was to force us to move /lib/udev/rules/d/* to /etc/udev/rules.d
-Mar 11 16:16:01 <rich0>	I'm flat against doing that with udev rules.
-Mar 11 16:16:12 <WilliamH>	s#rules/d#rules.d#
-Mar 11 16:16:14 <blueness>	i have to agree
-Mar 11 16:16:17 <rich0>	I might feel differently if udev didn't already have an /etc-based solution
-Mar 11 16:16:22 <dilfridge>	While a clear separation would be nice, I fear it will force us into an unmaintainable mess of patching.
-Mar 11 16:16:23 <ulm>	as long as these files are static they're fine in /lib
-Mar 11 16:16:30 <rich0>	we used to do it that way with udev rules
-Mar 11 16:16:41 <rich0>	I finally cleaned out the last cruft from that some time ago
-Mar 11 16:17:03 <WilliamH>	Also if we did this /usr/lib/systemd/system/* would have to go to /etc/systemd/system/*
-Mar 11 16:17:09 *	ulm hopes that nobody will suggest creating /share
-Mar 11 16:17:45 *	rich0 ducks
-Mar 11 16:18:11 *	WilliamH as against this because it will force a patching nightmare
-Mar 11 16:18:51 <blueness>	WilliamH, in eudev i could easily change it from //lib/udev/rules.d to /etc/udev/rules.d but this defeats the stacking structure of config files
-Mar 11 16:19:10 <blueness>	we want the default rules to not be touched
-Mar 11 16:19:15 <blueness>	these are in /lib/udev
-Mar 11 16:19:19 <WilliamH>	blueness: that is what patrick is suggesting. he doesn't like the stacking structure.
-Mar 11 16:19:36 <WilliamH>	That's why I'm against this.
-Mar 11 16:19:49 <blueness>	WilliamH, the ambiguity hinges on "what is a config file"
-Mar 11 16:19:55 <dilfridge>	even KDE has such a stacking structure
-Mar 11 16:20:02 <blueness>	are the "default" rules config files
-Mar 11 16:20:05 <blueness>	i say no
-Mar 11 16:20:08 <ulm>	blueness: no
-Mar 11 16:20:10 <rich0>	Honestly, probably best to take FHS issues one-at-a-time
-Mar 11 16:20:12 <dilfridge>	(you can define overrides for user config files in /usr)
-Mar 11 16:20:16 <ulm>	they are static
-Mar 11 16:20:22 <rich0>	I'm sure there are some in the tree, but I'm hard-pressed to think of any big ones.
-Mar 11 16:20:45 <rich0>	I don't consider udev/systemd violations of FHS insofar as how they handle config files.
-Mar 11 16:21:16 <blueness>	amazingly enough that is one thing systemd does not violate ...
-Mar 11 16:21:16 <WilliamH>	rich0: that's why this issue is before us though; Patrick does.
-Mar 11 16:21:19 *	blueness ducks
-Mar 11 16:21:26 <dberkholz>	i'm not interested in anything we can't get upstream as a build option
-Mar 11 16:21:35 <rich0>	WilliamH: well, he's welcome to his opinion  :)
-Mar 11 16:21:46 <rich0>	we're not going to ban the practice though
-Mar 11 16:22:03 *	WilliamH agrees
-Mar 11 16:22:24 <blueness>	okay it sounds to me like the council is against this motion
-Mar 11 16:22:35 <rich0>	Hey, if somebody has another example that is causing real problems they can feel free to bring it up, upstream or not.  I just don't see any examples yet.
-Mar 11 16:22:40 <blueness>	ready to vote or more discussion?
-Mar 11 16:22:51 <rich0>	blueness: stick a fork in it
-Mar 11 16:22:54 *	WilliamH ready to vote
-Mar 11 16:23:20 <blueness>	okay ... vote for "Adherence to FHS standards in Gentoo: putting config files int /etc".  Vote yes if you want to see all config files in /etc.
-Mar 11 16:23:34 *	ulm yes
-Mar 11 16:23:41 <WilliamH>	wait
-Mar 11 16:23:45 <dilfridge>	hehe
-Mar 11 16:23:47 <blueness>	wait
-Mar 11 16:24:01 <blueness>	waiting, did i say something ambiguous?
-Mar 11 16:24:01 <dberkholz>	i don't think that has enough nuance to it so i'm going to vote no
-Mar 11 16:24:02 <ulm>	given that a "config file" is a file intended to be modified by the user
-Mar 11 16:24:08 <dilfridge>	one does not simply walk into mordor.
-Mar 11 16:24:12 <ulm>	^^ my vote above
-Mar 11 16:24:13 <rich0>	Don't like the wording of that.  Ambiguous
-Mar 11 16:24:29 <blueness>	sorry guys, my bad, let me reword that given the discussion
-Mar 11 16:24:50 <rich0>	How about "Council does not feel additional policy required regarding config files in /etc.  Specific issues not already discussed can be raised in future meetings."
-Mar 11 16:25:11 <dberkholz>	i support putting everything in /etc that upstream provides a way, or will accept a way, to put in /etc.
-Mar 11 16:25:17 *	WilliamH likes rich0's wording
-Mar 11 16:25:32 <blueness>	rich0, i think we need to have something in ther clarifying human editable config files versus default config files
-Mar 11 16:25:50 <blueness>	that was the error in my first wording
-Mar 11 16:26:15 <rich0>	Council does not feel additional policy required regarding config files in /etc.  In particular packages that place config templates in /usr and allow overriding in /etc are fine. Specific issues not already discussed can be raised in future meetings.
-Mar 11 16:26:37 <blueness>	yeah
-Mar 11 16:26:41 <WilliamH>	rich0:  s#/usr#/ or /usr#
-Mar 11 16:27:03 <blueness>	i was leaning towards patrick's idea until that distinction came to light
-Mar 11 16:27:19 <blueness>	okay revote: "Council does not feel additional policy required regarding config files in /etc.  In particular packages that place config templates in /usr and allow overriding in /etc are fine. Specific issues not already discussed can be raised in future meetings."
-Mar 11 16:27:30 *	rich0 yes
-Mar 11 16:27:31 *	blueness yes
-Mar 11 16:27:35 *	dilfridge yes
-Mar 11 16:27:41 <ulm>	what about /lib?
-Mar 11 16:27:58 <rich0>	Again, if somebody finds some other case they are concerned with they can raise it - upstream-supported or not.  Let's fix actual issues though and not debate theology.
-Mar 11 16:27:59 <blueness>	ulm, i think its implicit in there
-Mar 11 16:28:02 <ulm>	wasn't it started by files in /lib?
-Mar 11 16:28:13 <rich0>	udev rules are in /usr
-Mar 11 16:28:23 <blueness>	rich0, no in /lib/udev
-Mar 11 16:28:23 <WilliamH>	rich0: no they aren't
-Mar 11 16:28:28 <rich0>	ah
-Mar 11 16:28:54 <ulm>	so: s#/usr#/lib or /usr/share#
-Mar 11 16:29:00 <blueness>	okay waiting for a vote form ulm and dberkholz 
-Mar 11 16:29:07 <blueness>	and WilliamH 
-Mar 11 16:29:11 <rich0>	"Council does not feel additional policy required regarding config files in /etc.  In particular packages that place config templates in /usr or /lib* and allow overriding in /etc are fine. Specific issues not already discussed can be raised in future meetings."
-Mar 11 16:29:25 <blueness>	okay, better
-Mar 11 16:29:37 *	ulm yes on rich0's wording
-Mar 11 16:29:45 *	WilliamH votes yes on rich0's last wording
-Mar 11 16:29:45 *	rich0 yes
-Mar 11 16:29:45 *	blueness yes
-Mar 11 16:30:07 *	dilfridge yes on rich0's wording
-Mar 11 16:30:14 <blueness>	dberkholz, ?
-Mar 11 16:30:33 <blueness>	okay rich0 motion carries
-Mar 11 16:30:44 <dberkholz>	meh
-Mar 11 16:30:52 <blueness>	meh? 
-Mar 11 16:30:56 <blueness>	= abstain?
-Mar 11 16:31:04 <dberkholz>	i don't care, sure abstain i guess
-Mar 11 16:31:08 <blueness>	lol
-Mar 11 16:31:14 <dberkholz>	for the record, i don't know if y'all have seen it but here's the fhs 3.0 beta: http://www.linuxbase.org/betaspecs/fhs/fhs/index.html and the announcement: http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs-30-draft-1
-Mar 11 16:31:35 <blueness>	dberkholz, interesting, ididn't know that
-Mar 11 16:31:38 <blueness>	i'll be sure to look
-Mar 11 16:31:51 <blueness>	okay next item
-Mar 11 16:31:52 <dberkholz>	it's surprisingly hard to chase down
-Mar 11 16:31:57 <blueness>	Bugs assigned to Council
-Mar 11 16:32:08 <blueness>	Bug #503382 -  Missing summaries for 20131210, 20140114, and 20140225 council meetings
-Mar 11 16:32:10 <willikins>	blueness: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
-Mar 11 16:32:11 <dberkholz>	summaries are in progress from my meetings
-Mar 11 16:32:15 <blueness>	Bug #477030 - Missing summary for 20130611 council meeting
-Mar 11 16:32:17 <willikins>	blueness: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council
-Mar 11 16:32:31 <blueness>	so we have some missing summaries
-Mar 11 16:32:45 <dberkholz>	i mostly finished them but haven't yet gotten them finalized and committed
-Mar 11 16:32:51 <dilfridge>	!note betelgeuse bug 477030
-Mar 11 16:32:51 <willikins>	fine, dilfridge
-Mar 11 16:32:52 <dberkholz>	we need a secretary again
-Mar 11 16:33:20 <ulm>	hadn't someone volunteered for the 20130611 summary?
-Mar 11 16:33:39 <blueness>	ulm, i thought it was under control, but i don't know what's going on there
-Mar 11 16:34:16 <blueness>	wasn't someone going to chase down betelgeuse?
-Mar 11 16:34:36 <ulm>	scarabeus wanted to do this
-Mar 11 16:34:39 <blueness>	k
-Mar 11 16:35:08 <blueness>	yeah i remember now, but he's awal
-Mar 11 16:35:10 <blueness>	awol
-Mar 11 16:35:31 <ulm>	so looks there's no progress on the 2013 one, and donnie's summaries are on their way
-Mar 11 16:35:37 <blueness>	yep
-Mar 11 16:35:46 <blueness>	i'll do mine right after the emeting
-Mar 11 16:36:01 <blueness>	okay let's move on to the last item: open floor
-Mar 11 16:36:05 <blueness>	any new business?
-Mar 11 16:36:54 <blueness>	anything?
-Mar 11 16:37:31 <blueness>	if there's nothing else then meeting ajourned
-Mar 11 16:37:50 <blueness>	thanks everyone: dberkholz
-Mar 11 16:37:50 <blueness>	dilfridge
-Mar 11 16:37:50 <blueness>	rich0
-Mar 11 16:37:50 <blueness>	scarabeus
-Mar 11 16:37:50 <blueness>	ulm 
-Mar 11 16:37:50 <blueness>	williamh!
-Mar 11 16:37:57 <dilfridge>	hm?
-Mar 11 16:38:00 <rich0>	thank you!
-Mar 11 16:38:06 <dilfridge>	thank you all too :)
-Mar 11 16:38:08 <blueness>	next meeting April 8th i believe
-Mar 11 16:38:12 <rich0>	blueness
-Mar 11 16:38:13 <rich0>	blueness
-Mar 11 16:38:13 <ulm>	blueness: thanks for chairing
-Mar 11 16:38:13 <rich0>	blueness
-Mar 11 16:38:14 <rich0>	blueness
-Mar 11 16:38:14 <rich0>	blueness
-Mar 11 16:38:15 <rich0>	blueness
-Mar 11 16:38:17 <rich0>	blueness
-Mar 11 16:38:27 <blueness>	who chairs?
-Mar 11 16:38:29 <blueness>	me again?
-Mar 11 16:38:47 <ulm>	no objections ;)
-Mar 11 16:38:50 <blueness>	heh
-Mar 11 16:38:55 <WilliamH>	heh
-Mar 11 16:38:59 <rich0>	blueness: you have May
-Mar 11 16:39:03 <rich0>	err april
-Mar 11 16:39:13 <rich0>	I can take May/June
-Mar 11 16:39:16 <blueness>	k
-Mar 11 16:39:18 <rich0>	If nobody else objects
-Mar 11 16:39:21 <blueness>	works for me
-Mar 11 16:39:35 <blueness>	(and now i must feed my dog who is bouncing off the walls!)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140408-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20140408-summary.txt
deleted file mode 100644
index 4fb459ac4a..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140408-summary.txt
+++ /dev/null
@@ -1,133 +0,0 @@
-Summary of Gentoo council meeting 8 April 2014
-
-
-Agenda
-======
-1. Roll call
-2. Open issues - vote on GLEP 63
-3. Use of ISO/IEC prefixes vs base-10
-4. Discussion of the recent controversy regarding new libudev and libgudev
-   virtuals, their masking by QA member and subsequent unauthorized unmasking
-   by their maintainer.  
-5. Bugs assigned to Council
-6. Open floor
-
-1. Roll call
-============
-
-Present: blueness dberkholz dilfridge rich0 ulm williamh scarabeus
-
-
-2. Open issues - vote on GLEP 63
-================================
-
-Council action last meeting tabled the vote on "GLEP 63: Gentoo GPG key
-policies" [1] because dilfridge, one of the authors, presented a shorter version
-which removed the "howto" language and reduced it to just policy [2].  The
-council has now had time to consider this version and the general feeling was
-that the GLEP should concentrate only on policy and move any questions of
-implementation to another document.
-
-The council unanimously approved the shorter version. [2]
-
-Ref:
-[1] https://wiki.gentoo.org/wiki/GLEP:63
-[2] https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1001a
-
-
-3. Use of ISO/IEC prefixes vs base-10
-=========================================================================
-
-The council considered whether a) ISO/IEC prefixes, Ki=2^10, etc., should be
-preferred over ISO base-10 prefixes, k=10^3, etc., or b) we should just require
-unambiguous units in check-reqs.eclass, where KiB etc are base-2  and k etc are
-base-10 [1].  Two proposal were brought forward by rich0 [2].  Proposal 2 was
-adopted:
-
-"Whenever practical developers are required to use unit prefixes defined in
-IEC 80000-13 (kB, KiB, etc) so that output is unambiguous.  This does not
-require maintainers to patch upstream code to change its behavior, but they
-should be applied with code that originates in Gentoo."
-
-Ref:
-[1] http://article.gmane.org/gmane.linux.gentoo.project/3428
-[2] http://article.gmane.org/gmane.linux.gentoo.project/3438
-
-
-4. Recent events regarding new virtuals, masking by QA and then unmasking
-=========================================================================
-
-The council consider what action to take with regards to the controversy around
-the recent introduction of virtual/libudev and virtual/libgudev.  Roughly the
-time sequence of events was as follows:
-
-	1) the eudev team was excluded from discussions about the virtuals
-	2) the virtuals were committed, leading to breakage for eudev
-	3) the virtuals were masked by a member of the QA team
-	4) the vertuals were unmasked by their maintainer without authorization
-	   from QA.
-
-This led to two long discussion threads on gentoo-project@g.o [1] and
-gentoo-dev@g.o [2].  dilfridge suggested the council take a position on five
-points which address the systematic problems in the Gentoo community that led to
-the above events [3].  The council approved sending an email to the community
-based on the following 4 of the 5 points:
-
-* The council encourages teams maintaining central parts of Gentoo to accept 
-new developers as team members and teach them the required knowledge and 
-intricacies.  We consider this important to ensure long-term continuity and 
-increase the bus factor in critical areas.
-
-* While it is any developer's choice not to participate on the gentoo-dev and 
-gentoo-project mailing lists, they nevertheless serve as main communication 
-channels. If something has been discussed there, and then action has been taken,
-the council regards ignorance of the discussion not as a good  foundation for
-protests against the actions.
-
-*  The council believes that a wide announcement and if needed discussion of
-changes to central parts of Gentoo (as, e.g., system packages, profiles) should
-be preferred. In particular, only informing "relevant people" makes no sense if
-others will also be affected.
-
-* The council strongly disapproves of any developers unilaterally reverting QA
-team actions.  While any future case decisions lie with QA and ComRel teams, the
-council welcomes the idea of immediate sanctions in such a case. An individual
-developer who disagrees with an action made in the name of QA, whether the
-action is proper or not, MUST follow the escalation procedures set forth in GLEP
-48, and is encouraged to work with QA, or eventually ComRel or the council to
-settle any concerns. The council will follow up on any accusations of QA abuse
-the same way as on any commit that is in conflict with a QA action.
-
-One point urging QA to adopt policies regarding internal disagreements was
-dropped since QA is in fact looking into the matter now [4].
-
-
-Ref.
-[1] http://article.gmane.org/gmane.linux.gentoo.project/3417
-[2] http://article.gmane.org/gmane.linux.gentoo.devel/90800
-[3] http://article.gmane.org/gmane.linux.gentoo.project/3474
-[4] http://article.gmane.org/gmane.linux.gentoo.project/3522
-
-
-5. Bugs assigned to Council
-===========================
-
-The council looked at two open bugs:
-
-a) Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council
-   meetings
-
-dberkholz said he would upload those summaries soon.
-
-b) Bug #477030 - Missing summary for 20130611 council meeting
-
-Still no progress here.  scarabeus said he would try to bug Betelgeuse again.
-
-
-6. Open floor
-=============
-
-No issues were brought forward.
-
-
-Summary submitted by Anthony G. Basile <blueness@gentoo.org>
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140408.txt b/xml/htdocs/proj/en/council/meeting-logs/20140408.txt
deleted file mode 100644
index 47f80785a4..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140408.txt
+++ /dev/null
@@ -1,653 +0,0 @@
-Apr 08 15:03:36 <blueness>	let's start: blueness dberkholz dilfridge rich0 scarabeus ulm  williamh
-Apr 08 15:03:39 <blueness>	ping ^^^
-Apr 08 15:03:44 *	WilliamH here
-Apr 08 15:03:48 *	rich0 is here
-Apr 08 15:03:59 *	ulm here
-Apr 08 15:04:03 *	dilfridge here
-Apr 08 15:04:17 <dberkholz>	hi
-Apr 08 15:04:27 <blueness>	scarabeus, ping?
-Apr 08 15:04:42 <blueness>	the minutes are at http://dev.gentoo.org/~blueness/council/council_agenda_20140408.txt
-Apr 08 15:04:57 <blueness>	take a minute to look them over and see if they are okay, if i missed something
-Apr 08 15:05:47 <dilfridge>	I'll pop up the resolution suggestions in the right places...
-Apr 08 15:05:59 <blueness>	dilfridge, yes that would be best
-Apr 08 15:06:10 <blueness>	for the agenda i tried to be minimalist
-Apr 08 15:06:27 <blueness>	okay first item then is GLEP 63 
-Apr 08 15:06:33 <blueness>	if you recall we tabled that from last time
-Apr 08 15:06:41 <blueness>	pending some language changes from dilfridge 
-Apr 08 15:06:54 <ulm>	blueness: should I text scarabeus?
-Apr 08 15:06:55 <blueness>	we had an issue regarding how much policy vs implementation should be in the GLEP
-Apr 08 15:07:02 <blueness>	ulm, yes!
-Apr 08 15:07:04 <blueness>	please do
-Apr 08 15:07:07 <blueness>	we had an issue regarding how much policy vs implementation should be in the GLEP
-Apr 08 15:07:07 <ulm>	he's in danger of a slacker mark
-Apr 08 15:07:19 <blueness>	the feeling was we should move implementation out
-Apr 08 15:07:21 <ulm>	sent
-Apr 08 15:07:26 <scarabeus>	[pmg
-Apr 08 15:07:27 <scarabeus>	pong
-Apr 08 15:07:29 <scarabeus>	:)
-Apr 08 15:07:32 <scarabeus>	thanks for the ping :)
-Apr 08 15:07:34 <blueness>	scarabeus, okay!  saved by the bell
-Apr 08 15:07:35 <ulm>	hi :)
-Apr 08 15:07:42 <scarabeus>	i was here but meanwhile i got distracted again :)
-Apr 08 15:08:06 <blueness>	dilfridge, do you want to say anything about the final language for GLEP 63?
-Apr 08 15:08:36 <dilfridge>	nothing changed... I pinged robbat2 but did not get any result.
-Apr 08 15:08:41 <dilfridge>	I suggest the following:
-Apr 08 15:09:06 <dilfridge>	1) we vote whether we prefer the long or the short version (with or without docs/explanations)
-Apr 08 15:09:19 <dilfridge>	2) we vote to confirm the version
-Apr 08 15:09:25 <dilfridge>	the versions are here:
-Apr 08 15:09:40 <dilfridge>	https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1001 long version
-Apr 08 15:09:49 <dilfridge>	https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1001a short version
-Apr 08 15:10:02 <dilfridge>	the actual specs should be identical
-Apr 08 15:11:07 <rich0>	I do prefer the short version - the docs are spotty, but the spec is fine.
-Apr 08 15:11:10 <blueness>	dilfridge, the shorter version just seems to have the full ~/.gnupg/gpg.conf at the end
-Apr 08 15:11:26 <dilfridge>	it's not the full file
-Apr 08 15:11:27 <blueness>	rich0, i concur, the shorter is better
-Apr 08 15:11:38 <scarabeus>	i like the shorter too
-Apr 08 15:11:51 <rich0>	Oh, the spec isn't quite the same, good catch blueness
-Apr 08 15:11:54 <blueness>	dilfridge, okay if you make avaialble the extra FAQ in a seperate wiki, then yeah
-Apr 08 15:12:09 <blueness>	separate wiki page
-Apr 08 15:12:09 <ulm>	I'd prefer the shorter version too
-Apr 08 15:12:23 <blueness>	okay are we ready to vote for GLEP 63 - shorter version - to be adopted?
-Apr 08 15:12:58 <blueness>	let me call the question ... all those in favor of GLEP 63 - short version - say "yes"
-Apr 08 15:13:01 <rich0>	Sure - this is a standards glep, so it is accepted until a reference std is in place
-Apr 08 15:13:08 <rich0>	Then it is final.
-Apr 08 15:13:13 <dilfridge>	I seem to be the only one to prefer the long version, but I also vote yes for the short one
-Apr 08 15:13:15 *	dilfridge yes
-Apr 08 15:13:18 *	blueness yes
-Apr 08 15:13:21 *	ulm yes
-Apr 08 15:13:22 *	rich0 yes
-Apr 08 15:13:24 *	scarabeus yes
-Apr 08 15:13:30 *	WilliamH  yes
-Apr 08 15:13:34 <blueness>	unanimous
-Apr 08 15:13:42 <creffett|irssi>	ping the bug with a reminder of your decision, please
-Apr 08 15:13:54 <dberkholz>	yes
-Apr 08 15:13:56 <blueness>	creffett|irssi, okay
-Apr 08 15:14:03 <blueness>	creffett|irssi, do you have the bug number handy for the log?
-Apr 08 15:14:16 <creffett|irssi>	blueness: unfortunately I do not
-Apr 08 15:14:28 *	twitch153 (~twitch153@gentoo/developer/twitch153) has joined #gentoo-council
-Apr 08 15:14:31 <blueness>	creffett|irssi, okay no problem i'll look it up later
-Apr 08 15:14:46 <ulm>	bug 501726?
-Apr 08 15:14:47 <willikins>	ulm: https://bugs.gentoo.org/501726 "new GLEP: Gentoo GPG key policies"; Doc Other, New GLEP submissions; IN_P; dilfridge:glep
-Apr 08 15:14:56 <dilfridge>	indeed
-Apr 08 15:15:05 <blueness>	that's it
-Apr 08 15:15:08 <blueness>	thanks
-Apr 08 15:15:11 <rich0>	Might not hurt to CC council on bugs like this when it is waiting for us.
-Apr 08 15:15:17 <blueness>	rich0, ++
-Apr 08 15:15:43 <blueness>	okay if there is no more discussion on this, item 2 - Use of ISO/IEC prefixes vs base-10
-Apr 08 15:16:14 <rich0>	I see there as two parts to this one - whether we advocate base 2 vs 10, and whether we require unambiguous units.
-Apr 08 15:16:18 <dilfridge>	isnt ISO = base10?
-Apr 08 15:16:22 <rich0>	No
-Apr 08 15:16:25 <WilliamH>	dilfridge: no
-Apr 08 15:16:36 <blueness>	the question here is whether or not we should prefer ISO/IEC prefixes over base 10 especially in check-reqs.eclass
-Apr 08 15:16:42 <rich0>	IEC/ISO just says to use GiB for base 2, and GB for base 10.
-Apr 08 15:16:43 *	dilfridge confused, but it's not so important
-Apr 08 15:16:45 <ulm>	rich0: IIRC, you posted two versions of a possible motion
-Apr 08 15:16:54 <ulm>	do you have a pointer to it?
-Apr 08 15:16:59 <rich0>	sure
-Apr 08 15:17:03 <blueness>	http://article.gmane.org/gmane.linux.gentoo.project/3428
-Apr 08 15:17:08 <rich0>	http://article.gmane.org/gmane.linux.gentoo.project/3438
-Apr 08 15:17:28 <rich0>	(blueness is to thread, my link is to my proposals)
-Apr 08 15:17:38 <blueness>	rich0, true
-Apr 08 15:17:52 <rich0>	Both of my proposals require the ISO/IEC units for non-ambiguity.  The first suggests base 10 when there isn't a reason to do otherwise.
-Apr 08 15:18:02 <blueness>	rich0, do you want to lead this discussion then?
-Apr 08 15:18:03 *	NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-Apr 08 15:18:29 <WilliamH>	What are upstreams doing on this these days?
-Apr 08 15:18:41 <rich0>	Sure.  Honestly, I think non-ambiguous units are the most important thing here - GB if base 10, GiB if base 2.  I think we should prefer 10, but that gets into religion, and it should always be maintainer-discretion.
-Apr 08 15:19:14 <rich0>	I think upstreams vary - it is a religous debate.  But, the GB vs GiB thing is becoming much more common.  I think people recognize the value of clarity.
-Apr 08 15:19:23 <blueness>	WilliamH, there is no consistency that i can see
-Apr 08 15:19:34 <ulm>	IMHO the rationale for switching to IEC prefixes in Linux summarises it well:
-Apr 08 15:19:36 <ulm>	"Best practice in editing a technical or standards document is to (a) avoid ambiguous usages, seek clarity and precision; and (b) to use, follow and reference international standards."
-Apr 08 15:19:50 <dilfridge>	I dont particularly like the "i" stuff, but it's good for being precise.
-Apr 08 15:19:54 <dilfridge>	so yes.
-Apr 08 15:20:01 <WilliamH>	ulm: makes sense to me.
-Apr 08 15:20:31 <dilfridge>	(given that in Germany people are filing lawsuits since monitor diagonals are specified in the non-si unit inch)
-Apr 08 15:20:53 <blueness>	would it be fair to say that the council doesn't care about SI vs ISO/IEC provided we don't have ambiguity
-Apr 08 15:21:04 <blueness>	so KB means 1000 B and KiB means 1024
-Apr 08 15:21:29 <dilfridge>	I'm all for proposal 1
-Apr 08 15:21:29 <rich0>	Well, I feel strongest that we should use the "ibi" units when referring to base 2.  I don't feel strongly about base 2 vs 10.  Use your favorite units, but be clear.  Maintainers have the best insight into what makes the most sense.
-Apr 08 15:21:35 <ulm>	blueness: that's rich0's proposal 2
-Apr 08 15:21:48 <blueness>	ulm, correct, but i'm asking if everyone feels the same
-Apr 08 15:22:11 <dilfridge>	but indeed, most important is that it's unambiguos. by a mile.
-Apr 08 15:22:11 <rich0>	blueness: just to clarify - ISO/IEC specifies both.  It isn't about base 2 vs 10.  It is about using the right abbreviation for each.
-Apr 08 15:22:21 <ulm>	I'm happy with both, slight preference for 2
-Apr 08 15:22:21 <blueness>	rich0, oh okay
-Apr 08 15:22:32 <rich0>	Sounds like we have consensus for 2.  Do we want to vote on 1 first and see how it goes?
-Apr 08 15:22:49 <ulm>	can do
-Apr 08 15:22:50 <blueness>	we can do that ...
-Apr 08 15:23:01 <rich0>	Proposal 1
-Apr 08 15:23:01 <rich0>	"Whenever practical Developers are encouraged to use SI units and base
-Apr 08 15:23:01 <rich0>	10 values (ie 1KB = 1000 bytes).  They may use base 2 values when this
-Apr 08 15:23:01 <rich0>	output is more likely to be useful to users (eg in memory hexdumps,
-Apr 08 15:23:01 <rich0>	etc).  Either way, unit prefixes defined in IEC 80000-13 (KB, KiB,
-Apr 08 15:23:02 <rich0>	etc) must be used so that output is unambiguous.  This does not
-Apr 08 15:23:04 <rich0>	require maintainers to patch upstream code to change its behavior, but
-Apr 08 15:23:06 <rich0>	they should be applied with code that originates in Gentoo."
-Apr 08 15:23:20 <blueness>	who is in favor of this formulation of the motion ^^^
-Apr 08 15:23:40 *	blueness no
-Apr 08 15:23:40 *	dilfridge yes
-Apr 08 15:23:42 *	rich0 yes
-Apr 08 15:23:57 *	WilliamH yes -- let's not force maintainers to patch
-Apr 08 15:24:26 <blueness>	dberkholz, scarabeus ping
-Apr 08 15:24:30 *	ulm abstain
-Apr 08 15:24:33 <ulm>	I prefer 2
-Apr 08 15:24:35 <rich0>	(emphasis on "encouraged")
-Apr 08 15:24:40 <WilliamH>	hang on
-Apr 08 15:24:46 *	WilliamH wants to see 2
-Apr 08 15:24:51 <scarabeus>	i preffer 2
-Apr 08 15:25:01 *	WilliamH retracts vote without seeing 2
-Apr 08 15:25:08 <dberkholz>	i find the ibi units confusing for many people regardless so i'm going to abstain
-Apr 08 15:25:20 <rich0>	Ok, let me post 2 just so that it is here...
-Apr 08 15:25:27 <rich0>	Proposal 2
-Apr 08 15:25:27 <rich0>	"Whenever practical developers are required to use unit prefixes
-Apr 08 15:25:27 <rich0>	defined in IEC 80000-13 (KB, KiB, etc) so that output is unambiguous.
-Apr 08 15:25:27 <rich0>	This does not require maintainers to patch upstream code to change its
-Apr 08 15:25:27 <rich0>	behavior, but they should be applied with code that originates in
-Apr 08 15:25:29 <rich0>	Gentoo."
-Apr 08 15:25:54 <blueness>	it looks to me like proposal 1 failed ... only dilfridge and rich0 said yes
-Apr 08 15:26:00 <blueness>	WilliamH, changed his minde
-Apr 08 15:26:10 <blueness>	so let's vote for proposal 2
-Apr 08 15:26:15 *	blueness yes
-Apr 08 15:26:16 *	rich0 yes to 2
-Apr 08 15:26:21 *	ulm yes
-Apr 08 15:26:26 *	dilfridge yes to 2
-Apr 08 15:26:29 *	scarabeus yes
-Apr 08 15:26:35 *	WilliamH yes
-Apr 08 15:26:50 <ulm>	argh
-Apr 08 15:26:58 <ulm>	rich0: s/KB/kB/
-Apr 08 15:27:09 <dilfridge>	hehe
-Apr 08 15:27:15 <rich0>	Yes, thanks
-Apr 08 15:27:23 <dilfridge>	KB and mB
-Apr 08 15:27:31 <blueness>	okay proposal 2 passes
-Apr 08 15:27:32 <rich0>	It is kB and KiB
-Apr 08 15:27:32 <ulm>	it's kB MB GB vs KiB MiB GiB
-Apr 08 15:27:44 <dilfridge>	not kiB
-Apr 08 15:27:45 <dilfridge>	?
-Apr 08 15:27:49 <blueness>	nope
-Apr 08 15:27:49 <TomWij>	(A comma between "practical" and "developers" might help reading; I've been reading it as "practical developers", had to backtrack from the end of the sentence to see where I've misread)
-Apr 08 15:27:58 <blueness>	dilfridge, it is in fact kB and KiB
-Apr 08 15:28:03 <blueness>	don't ask!
-Apr 08 15:28:06 <dilfridge>	ugh, how ugly
-Apr 08 15:28:06 <blueness>	K is kelvin
-Apr 08 15:28:07 <rich0>	yes, a comma would help.  :)
-Apr 08 15:28:12 <ssuominen>	ulm: not mB?
-Apr 08 15:28:26 <ulm>	ssuominen: that would be millibytes ;)
-Apr 08 15:28:30 <dilfridge>	that would be millibyte... :D
-Apr 08 15:28:30 <rich0>	Let's not mention that in JEDEC it is K for KiB
-Apr 08 15:28:35 <blueness>	eg temperature of the surface of the sun is 2.5 kK
-Apr 08 15:28:47 <rich0>	Err, JEDEC is KB for 1024 bytes.  :)
-Apr 08 15:28:55 <rich0>	enough...
-Apr 08 15:28:56 <WilliamH>	dilfridge: KB = 1000, KiB = 1024
-Apr 08 15:28:57 *	dilfridge notes that the council has 3 physicists
-Apr 08 15:29:02 <ssuominen>	ulm: dilfridge just mentioned it above ^, got confused.
-Apr 08 15:29:12 <rich0>	I'm a chemist, not a physicist
-Apr 08 15:29:21 <dilfridge>	me, ulm, blueness
-Apr 08 15:29:26 <blueness>	and i'm a physicist, not a chemist!
-Apr 08 15:29:34 <rich0>	dberkholz is a biologist or biochemist if I'm not mistaken
-Apr 08 15:29:39 <rich0>	yikes!
-Apr 08 15:29:51 <blueness>	thank god there are no comp sci majors here!
-Apr 08 15:30:03 *	WilliamH is a comp sci major lol
-Apr 08 15:30:13 *	WilliamH was actually, lol.
-Apr 08 15:30:15 <blueness>	WilliamH, we still love you!
-Apr 08 15:30:32 *	WilliamH graduated in 91 so it has been a few years ;-)
-Apr 08 15:30:37 <rich0>	No wonder we're all indoctrinated in SI.
-Apr 08 15:31:02 <rich0>	So, on to the main event?
-Apr 08 15:31:06 <blueness>	okay .... shall we move on to item 3 ... discussion of recent events regarding new virtuals, masking by QA and then unmasking
-Apr 08 15:31:11 <dilfridge>	yippi-yey
-Apr 08 15:31:41 *	rich0 finishes tightening the straps on his helmet
-Apr 08 15:31:51 <blueness>	okay first, let me ask for minimal bikeshedding while the council tries to work thorugh this thorny issue(s)
-Apr 08 15:31:57 *	WilliamH says no for the first point, I don't think this is a policy issue.
-Apr 08 15:32:15 <blueness>	WilliamH, 1 sec ... let me first see if the 3 items are acceptable
-Apr 08 15:32:21 <ulm>	I believe that discussing the concrete case in this council meeting wouldn't be wise
-Apr 08 15:32:22 <ulm>	before comrel and qa have done their part
-Apr 08 15:32:31 <ulm>	discussing general guidelines for the future is o.k. though
-Apr 08 15:32:35 <blueness>	so ... i wasn't even sure how to formulate this, so I came up with 3 issues that came forward
-Apr 08 15:32:37 <dilfridge>	ulm++
-Apr 08 15:33:05 <blueness>	is everyone okay with the 3 issues ... even if you plan to vote no ... 
-Apr 08 15:33:05 <rich0>	I do support ulm that we should focus more on the general / future / policy and less on who did what when last week.
-Apr 08 15:33:09 <blueness>	do you think i missed any issues
-Apr 08 15:33:42 <blueness>	rich0, ulm how then do you want to proceed?
-Apr 08 15:33:46 <rich0>	might I suggest that some of the elements of the proposal seemed non-controversial.  Maybe tackle those first?
-Apr 08 15:34:11 <blueness>	rich0, okay begin by suggesting issue 1
-Apr 08 15:34:53 <rich0>	Ugh - digging through the thread...
-Apr 08 15:35:03 <dilfridge>	http://article.gmane.org/gmane.linux.gentoo.project/3474
-Apr 08 15:35:04 <dilfridge>	this one?
-Apr 08 15:35:18 <rich0>	http://thread.gmane.org/gmane.linux.gentoo.project/3412/focus=3417
-Apr 08 15:35:24 <rich0>	There we go...
-Apr 08 15:35:39 <rich0>	dilfridge: ++
-Apr 08 15:35:43 *	FamousEccles (~roy@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-Apr 08 15:36:00 <rich0>	How about work from the end back.
-Apr 08 15:36:03 <blueness>	okay let's drop my 3 issues and look at dilfridge's stuff
-Apr 08 15:36:13 <rich0>	5) The council encourages teams maintaining central parts of Gentoo to accept
-Apr 08 15:36:13 <rich0>	new developers as team members and teach them the required knowledge and
-Apr 08 15:36:13 <rich0>	intricacies. We consider this important to ensure long-term continuity and
-Apr 08 15:36:14 <rich0>	increase the bus factor in critical areas.
-Apr 08 15:36:34 <blueness>	okay let's begin there ... discussion regarding this?
-Apr 08 15:36:43 <dberkholz>	i don't think that's something we should even need to vote on or write down
-Apr 08 15:37:06 <dberkholz>	we're in danger of over documenting what normal behavior should be
-Apr 08 15:37:07 *	WilliamH agrees with dberkholz 
-Apr 08 15:37:07 <dilfridge>	imho this is fairly non-controversial, a pure recommendation, and something that should be obvious to everyone
-Apr 08 15:37:08 <rich0>	I like it - not everything has to be a rule.
-Apr 08 15:37:25 <WilliamH>	There is nothing for us to do wrt that.
-Apr 08 15:37:37 <dilfridge>	by spelling it out, we might just put some emphasis behind it.
-Apr 08 15:37:38 <rich0>	I think it is a message we can still endorse.
-Apr 08 15:37:49 <rich0>	It doesn't have to be engraved in the code of Gentoo.,
-Apr 08 15:38:07 <blueness>	dberkholz, i read that as a position the council encourages without it being policy or "written down"
-Apr 08 15:38:44 <blueness>	dberkholz, i would say, the council should email gentoo-dev@ and "remind" people of this fact
-Apr 08 15:39:19 <rich0>	I think as leaders it is a message we should try to send.  We can't force people to do it, but that doesn't mean it shouldn't be said.
-Apr 08 15:39:33 <ulm>	can we make an action item of it, i.e. someone (dilfridge?) sends a mail to -dev?
-Apr 08 15:39:36 <blueness>	so how about we vote on it with the understanding that i will email gentoo-dev@ as an "encouragement" to the community.
-Apr 08 15:39:44 <rich0>	blueness: ++
-Apr 08 15:39:51 <dilfridge>	ok
-Apr 08 15:39:58 <blueness>	or dilfridge can speak on behalf of hte committee since he wrote it
-Apr 08 15:39:58 <rich0>	that's as far as it need go
-Apr 08 15:40:11 <dilfridge>	that's all the action it needs from us
-Apr 08 15:40:25 <blueness>	dilfridge, okay as an action item, you will email that to gentoo-dev@ as an encouragement from the council
-Apr 08 15:40:35 <dilfridge>	will do.
-Apr 08 15:40:36 <blueness>	shall we vote on this?
-Apr 08 15:40:38 <rich0>	Unless there is more to discuss, maybe just vote and see where we end up?  The meat is really in the first item or two.
-Apr 08 15:40:38 *	blueness yes
-Apr 08 15:40:42 *	rich0 yes
-Apr 08 15:40:44 *	dilfridge yes
-Apr 08 15:40:45 *	WilliamH yes
-Apr 08 15:40:53 *	ulm yes
-Apr 08 15:41:08 *	scarabeus yes
-Apr 08 15:41:10 <dberkholz>	ok
-Apr 08 15:41:14 <blueness>	okay!
-Apr 08 15:41:24 <blueness>	next would be #4 in our countdown
-Apr 08 15:41:31 <blueness>	4) While it is any developer's choice not to participate on the gentoo-dev and 
-Apr 08 15:41:31 <blueness>	gentoo-project mailing lists, they nevertheless serve as main communication 
-Apr 08 15:41:31 <blueness>	channels. If something has been discussed there, and then action has been 
-Apr 08 15:41:31 <blueness>	taken, the council regards ignorance of the discussion not as a good 
-Apr 08 15:41:31 <blueness>	foundation for protests against the actions.
-Apr 08 15:41:44 <dilfridge>	this is a similar "intent"
-Apr 08 15:41:55 <blueness>	make it part of the other email?
-Apr 08 15:41:57 <rich0>	++ from me - there was a lot of debate about the "optionalness" of the lists -
-Apr 08 15:41:59 <dilfridge>	I'd suggest we do the same as for 5
-Apr 08 15:42:12 <dilfridge>	action = mailing to list
-Apr 08 15:42:15 <ulm>	dilfridge++
-Apr 08 15:42:19 <WilliamH>	++
-Apr 08 15:42:22 <blueness>	dilfridge, yes, make it part of the same email
-Apr 08 15:42:26 <rich0>	sure
-Apr 08 15:42:27 <blueness>	shall we vote then?
-Apr 08 15:42:30 <rich0>	sure
-Apr 08 15:42:32 *	blueness yes
-Apr 08 15:42:32 *	dilfridge yes for 4
-Apr 08 15:42:36 *	rich0 yes for 4
-Apr 08 15:42:36 *	WilliamH yes for 4
-Apr 08 15:42:41 *	ulm yes for 4
-Apr 08 15:42:55 <blueness>	scarabeus, dberkholz 
-Apr 08 15:43:13 <dberkholz>	i guess
-Apr 08 15:43:24 <blueness>	scarabeus, ??
-Apr 08 15:43:41 <dberkholz>	kinda feeling that important discussions should be kicked off with a pointer from -dev-ann
-Apr 08 15:43:59 <scarabeus>	ye
-Apr 08 15:44:00 <scarabeus>	s
-Apr 08 15:44:02 <blueness>	dberkholz, sometimes that makes sense
-Apr 08 15:44:07 <rich0>	dberkholz: ++
-Apr 08 15:44:19 <blueness>	okay next ...
-Apr 08 15:44:20 <blueness>	3) The council believes that a wide announcement and if needed discussion of 
-Apr 08 15:44:20 <blueness>	changes to central parts of Gentoo (as, e.g., system packages, profiles, 
-Apr 08 15:44:20 <blueness>	global use-flags) should be preferred. In particular, only informing "relevant 
-Apr 08 15:44:20 <blueness>	people" makes no sense if others will also be affected.
-Apr 08 15:44:23 <rich0>	Not sure we need to debate the wording, but that can go in the email.
-Apr 08 15:44:26 <dilfridge>	dberkholz: makes sense for really important stuff, but if we do it too often people just get drowned there too.
-Apr 08 15:44:56 <rich0>	I think the wording of #3 could probably be cleaned up a tad, but I agree with the intent.
-Apr 08 15:45:01 <blueness>	this one feels different, it is a response to a "relevant person" argument brought forward during the email exchagnes
-Apr 08 15:45:34 <dilfridge>	it still is only an intent or advice, though.
-Apr 08 15:45:46 <ulm>	the devmanual already says "Before introducing a new global USE flag, it must be discussed on the gentoo-dev mailing list."
-Apr 08 15:46:02 <ulm>	so no need to include use flags again
-Apr 08 15:46:20 <blueness>	i'd like to discourage the provincalism of "relevant people" ... not just to avoid clicks but so that newbies can come to better understand how gentoo's internals evolve
-Apr 08 15:46:22 <rich0>	Doesn't hurt to include use-flags just to have one consolidated policy.
-Apr 08 15:46:54 <blueness>	ulm, let's avoid making htis policy and include this with the previous email ad encouragement
-Apr 08 15:47:01 <ulm>	rich0: if the policy says "must" and we say "should be preferred" we weaken it
-Apr 08 15:47:03 <rich0>	Yup, gentoo-dev isn't high-volume compared to some other project dev lists where all kinds of minutae get discussed
-Apr 08 15:47:15 <rich0>	ulm, fair enough
-Apr 08 15:47:39 *	FamousEccles has quit (Remote host closed the connection)
-Apr 08 15:47:40 <rich0>	Honestly, my whole feeling on this stuff is that we almost shouldn't have to say any of this, but it still bears saying.
-Apr 08 15:47:54 <dilfridge>	ok, take use flags out, same e-mail?
-Apr 08 15:47:57 <rich0>	It amounts to "act like part of a community"
-Apr 08 15:48:05 <dilfridge>	well, as does e.g. 5
-Apr 08 15:48:37 <blueness>	okay so do people want this to be added to the email dilfridge will be sending out?
-Apr 08 15:48:48 <WilliamH>	Fine with me.
-Apr 08 15:48:50 <rich0>	Sure, why not.
-Apr 08 15:49:00 <dberkholz>	works for me
-Apr 08 15:49:03 <ulm>	yes, if global use flags are taken out
-Apr 08 15:49:11 <dilfridge>	yes without use flags
-Apr 08 15:49:23 <blueness>	looks like a vote to me ... os i'll add a yes
-Apr 08 15:49:40 <blueness>	scarabeus, are you in favor?
-Apr 08 15:50:02 <blueness>	*sigh*
-Apr 08 15:50:08 <blueness>	let's move one to item 2
-Apr 08 15:50:09 <rich0>	3a) The council believes that a wide announcement and if needed
-Apr 08 15:50:09 <rich0>	discussion of changes to central parts of Gentoo (as, e.g., system
-Apr 08 15:50:09 <rich0>	packages, profiles) should be preferred. In particular, only informing
-Apr 08 15:50:09 <rich0>	"relevant people" makes no sense if others will also be affected.
-Apr 08 15:50:54 <rich0>	2) The council recognizes that there are some open questions around when
-Apr 08 15:50:55 <rich0>	individuals in QA ought to take action, and how internal disagreements
-Apr 08 15:50:55 <rich0>	get resolved. The council would like to ask QA to design its own
-Apr 08 15:50:55 <rich0>	operating procedures and publish them. There should be a reasonably
-Apr 08 15:50:55 <rich0>	clear process so that QA members can act in the confidence that they are
-Apr 08 15:50:56 <rich0>	doing things properly, and the rest of the community can be assured that
-Apr 08 15:50:58 <rich0>	there is accountability. The council requests an update on the progress
-Apr 08 15:51:00 <rich0>	of establishing procedures prior to its next monthly meeting.
-Apr 08 15:51:11 <blueness>	okay moving on to item 2
-Apr 08 15:51:12 *	FamousEccles (~roy@gentoo/developer/NeddySeagoon) has joined #gentoo-council
-Apr 08 15:51:45 <ulm>	I think creffett has already prepared something for the next qa meeting which is next week
-Apr 08 15:51:47 <TomWij>	(We need to remind ourselves that a primary goal of public awareness is to have more eyes on these important matters; to catch duplication (eg. eclasses), errors (we're human), breakage (something unforeseen). Discussion, bikeshedding and disagreements are side effects; it's kind of like a cost/benefit situation, ...)
-Apr 08 15:51:57 <ulm>	so no need to remind qa
-Apr 08 15:52:00 <rich0>	ulm: agree, creffett did address some of this on -dev
-Apr 08 15:52:26 <blueness>	we can put this on the side and return to it if QA doesn't follow through on what they announced on -dev
-Apr 08 15:52:39 <rich0>	Maybe we should just note in the summary that we take note that QA is looking to document their proceses?
-Apr 08 15:52:48 <blueness>	that's good enough
-Apr 08 15:53:19 <rich0>	blueness: ++
-Apr 08 15:53:21 <blueness>	is everyone okay with that ^^^
-Apr 08 15:53:25 <scarabeus>	yea that is nice
-Apr 08 15:53:29 *	WilliamH yes
-Apr 08 15:53:30 <ulm>	yes, we can always come back if there are still open questions
-Apr 08 15:53:42 <dilfridge>	ok fine with me
-Apr 08 15:53:44 *	WilliamH has to abstain if this is a vote
-Apr 08 15:53:56 <dilfridge>	let's get back to it next month
-Apr 08 15:54:00 <blueness>	dberkholz, any feelings on this?
-Apr 08 15:54:36 <ulm>	WilliamH: you think this is a conflict of interest for qa members?
-Apr 08 15:54:47 <TomWij>	blueness: From QA perspective, we've already have had quite some talk on it in the past, we're already doing things in certain ways, there's the GLEP 48 stating expectations; as I see it we're doing fine, in this case there wasn't a team wide vote based on disagreement because nobody send out a disagreement to the team, but none the less, more discussion will follow (it's on agenda, as well as in our
-Apr 08 15:54:49 <dberkholz>	i agree, it's along the lines of what devrel has
-Apr 08 15:54:50 <TomWij>	minds) so I think will work out.
-Apr 08 15:54:55 <dberkholz>	now comrel
-Apr 08 15:55:03 <WilliamH>	ulm: are we voting?
-Apr 08 15:55:15 <ulm>	WilliamH: not sure ;)
-Apr 08 15:55:21 <blueness>	WilliamH, we weren't really voting, i was just asking for feelings
-Apr 08 15:55:27 <rich0>	For reference on QA - creffett's email: http://article.gmane.org/gmane.linux.gentoo.project/3522
-Apr 08 15:55:30 <dberkholz>	given the impact on other groups, additional transparency into how QA works is of value
-Apr 08 15:55:32 <WilliamH>	blueness: Ok, I'm fine with it then.
-Apr 08 15:56:14 <blueness>	okay unless there are objections and someone wants a vote, i'll just note that the council notes that QA is looking into documenting their process
-Apr 08 15:56:41 <blueness>	okay let's go onto item 1
-Apr 08 15:56:42 <blueness>	1) The council strongly disapproves of any developers unilaterally reverting 
-Apr 08 15:56:42 <blueness>	QA team actions. While the case decision lies with QA and ComRel teams, the 
-Apr 08 15:56:42 <blueness>	council welcomes the idea of immediate sanctions in such a case. An individual 
-Apr 08 15:56:42 <blueness>	developer who disagrees with an action made in the name of QA, whether the 
-Apr 08 15:56:42 <blueness>	action is proper or not, MUST follow the escalation procedures set forth in 
-Apr 08 15:56:42 <blueness>	GLEP 48, and is encouraged to work with QA, ComRel or eventually the council 
-Apr 08 15:56:42 <blueness>	to settle any concerns. The council will follow up on any accusations of QA 
-Apr 08 15:56:42 <blueness>	abuse the same way as on any commit that is in conflict with a QA action.
-Apr 08 15:57:14 <blueness>	the question here is: is comrel looking into this?
-Apr 08 15:57:33 <rich0>	I hear they are, but do not have specific knowledge.
-Apr 08 15:57:50 <WilliamH>	There is a bug
-Apr 08 15:58:00 <blueness>	WilliamH, do you have the bug #
-Apr 08 15:58:10 <dilfridge>	pinged antarus
-Apr 08 15:58:16 <WilliamH>	blueness: I can get it probably, hang on.
-Apr 08 15:58:19 <blueness>	i like the statement but i don't want to step on comrel's toes
-Apr 08 15:58:21 <ulm>	didn't we agree that we were to discuss general guidelines only?
-Apr 08 15:58:33 <ulm>	but not past week's incident
-Apr 08 15:58:35 <dilfridge>	right
-Apr 08 15:58:36 <rich0>	ulm: agree
-Apr 08 15:58:48 <dilfridge>	the bug is ONLY on a specific event.
-Apr 08 15:58:50 <blueness>	ulm, how are these not general guidelines?
-Apr 08 15:58:52 <WilliamH>	bug 506156
-Apr 08 15:58:52 <dilfridge>	which is not our scope.
-Apr 08 15:59:14 <blueness>	what! -> You are not authorized to access bug #506156. 
-Apr 08 15:59:15 <rich0>	I do think we should make it clear that GLEP48 already specifies the proper way to handle disagreements with QA.
-Apr 08 15:59:15 <dilfridge>	so how about we clarify somehow that 1) is meant as future guideline.
-Apr 08 15:59:48 <scarabeus>	blueness: we can't see devrel bugs if nto devrel
-Apr 08 15:59:54 <ulm>	I'd strongly advise that we wait for comrel and qa before taking any action in the concrete case
-Apr 08 15:59:56 <WilliamH>	blueness: comrel bugs are typicaly restricted to the parties involved
-Apr 08 16:00:08 <ssuominen>	what's 506156? i'm not authorized either.
-Apr 08 16:00:10 <ulm>	if it's escalated to us then it's our turn, but not before
-Apr 08 16:00:16 <rich0>	I think the "immediate sanctions" sentence is really the one that needs the most care.
-Apr 08 16:00:17 <blueness>	okay if we can't see that bug, then i don't know if comrel is looking into the matter
-Apr 08 16:00:43 <WilliamH>	blueness: That's typical comrel policy, qa and comrel can see it.
-Apr 08 16:00:44 <rich0>	The rest seems to be general policy.
-Apr 08 16:00:45 <blueness>	so i feel that dilfridge's item 1 should be included in his email stipulating our position
-Apr 08 16:01:25 <blueness>	do we want some version of 1 to be included with the email dilfridge will send out?
-Apr 08 16:01:32 <dilfridge>	how about the following minor change:
-Apr 08 16:01:55 <dilfridge>	"While the case decision lies" -> "While any future case decisions lie"
-Apr 08 16:02:15 <blueness>	sure
-Apr 08 16:02:39 <blueness>	again, this is meant to be an encouragement as to how things should go in the future
-Apr 08 16:02:42 <rich0>	Agree.  We should be clear that we're not calling for any "punishment" for a case we haven't even formally heard the facts on.
-Apr 08 16:03:08 <ulm>	dilfridge "encouraged to work with QA, ComRel or eventually the council" -> "encouraged to work with QA or eventually ComRel or the council"
-Apr 08 16:03:09 <blueness>	i think everyone looking over what happened realizes that things could have gone so much better
-Apr 08 16:03:17 <blueness>	and so let's just steer people that way
-Apr 08 16:03:25 <ulm>	they should start with qa
-Apr 08 16:03:35 <dilfridge>	ulm: fine with me, yes.
-Apr 08 16:03:36 <ulm>	comrel implies that it's a personal matter
-Apr 08 16:03:56 <blueness>	ulm, good point, it might be a purely technical difference
-Apr 08 16:04:35 <rich0>	So, cleaned up we have:
-Apr 08 16:04:36 <rich0>	1) The council strongly disapproves of any developers unilaterally
-Apr 08 16:04:36 <rich0>	reverting QA team actions. While any future case decisions lie with QA
-Apr 08 16:04:36 <rich0>	and ComRel teams, the council welcomes the idea of immediate sanctions
-Apr 08 16:04:36 <rich0>	in such a case. An individual developer who disagrees with an action
-Apr 08 16:04:36 <rich0>	made in the name of QA, whether the action is proper or not, MUST follow
-Apr 08 16:04:38 <rich0>	the escalation procedures set forth in GLEP 48, and is encouraged
-Apr 08 16:04:40 <rich0>	to work with QA, or eventually ComRel or the council to settle any
-Apr 08 16:04:42 <rich0>	concerns. The council will follow up on any accusations of QA abuse the
-Apr 08 16:04:44 <rich0>	same way as on any commit that is in conflict with a QA action.
-Apr 08 16:05:08 <blueness>	looks good to me
-Apr 08 16:05:13 <dilfridge>	ok to me
-Apr 08 16:05:23 <ulm>	LGTM
-Apr 08 16:05:27 <blueness>	LGTM?
-Apr 08 16:05:29 <WilliamH>	lgtm
-Apr 08 16:05:36 <dilfridge>	looks good to me = LGTM
-Apr 08 16:05:38 <blueness>	ah!
-Apr 08 16:05:40 <scarabeus>	fine
-Apr 08 16:05:55 <rich0>	Those ETLAs...
-Apr 08 16:06:07 <blueness>	okay so it looks like dilfridge will be rolling that into the email as well ... no vote unless someone objects
-Apr 08 16:06:26 <rich0>	I think we should probably vote on this one.
-Apr 08 16:06:31 <blueness>	okay
-Apr 08 16:06:51 <blueness>	vote to include this item (as cleaned up by rich0) for incusion in the email to the community by dilfridge 
-Apr 08 16:06:55 *	blueness yes
-Apr 08 16:06:58 *	dilfridge yes
-Apr 08 16:07:03 *	rich0 yes
-Apr 08 16:07:07 *	WilliamH yes
-Apr 08 16:07:42 <blueness>	ulm, dberkholz scarabeus ping
-Apr 08 16:07:42 <dberkholz>	yes
-Apr 08 16:07:45 <scarabeus>	yes
-Apr 08 16:07:47 <ulm>	it's already accepted?
-Apr 08 16:07:51 <dberkholz>	brb
-Apr 08 16:07:59 <ulm>	I abstain, because I'm qa member myself
-Apr 08 16:08:02 <blueness>	okay
-Apr 08 16:08:09 <scarabeus>	i thought we voted above with the fine "P
-Apr 08 16:08:10 *	WilliamH retracts vote for the same reason
-Apr 08 16:08:31 <blueness>	scarabeus, kinda sorta
-Apr 08 16:08:38 <TomWij>	ulm: +1; this event went too fast from a single QA developer to higher instances, it should be more like talking with everyone and elevating when really necessary: 1) qa dev 2) qa@gentoo.org 3) gentoo-dev ML or comrel (depends on matter) 4) council
-Apr 08 16:08:46 <blueness>	okay is there any more discussion regarding this issue?
-Apr 08 16:09:02 <ulm>	TomWij: I fully agree
-Apr 08 16:09:46 <blueness>	ulm, TomWij whether or not that's true, the council has not, in my opinion, acted heavy handedly
-Apr 08 16:10:01 <blueness>	so while it came to our attention early, its not like we acted rashly
-Apr 08 16:10:09 <TomWij>	blueness: Just saying that escalation went too fast, not action.
-Apr 08 16:10:15 <blueness>	and the issue is not over since it is working its way throuh QA and comrel
-Apr 08 16:10:33 <rich0>	I think ignoring the issue would have been a mistake, because it did go public on the lists
-Apr 08 16:10:36 <blueness>	TomWij, i'm not sure there was escalation, we noted the event and took a position
-Apr 08 16:10:43 <rich0>	If it were a private dispute a private resolution would be fine.
-Apr 08 16:10:49 <blueness>	i'm with rich0 
-Apr 08 16:11:02 <blueness>	we're "nipping it in the bud"
-Apr 08 16:11:29 <blueness>	any more discussion
-Apr 08 16:11:40 <blueness>	regarding this issue
-Apr 08 16:11:41 <TomWij>	eg. rich0's mails address QA, which is good as we can always use improvement; but if nobody that was involved sends a mail to the whole team to vote for a disagreement, QA kind of hasn't had the ability to do anything.
-Apr 08 16:12:14 <WilliamH>	TomWij: The council hasn't done anything other than state a position.
-Apr 08 16:12:27 <TomWij>	blueness: There was escalation to ComRel quite early, because things got personal too fast; this happened at night hours in the weekend when QA team was barely around, at the worst possible time...
-Apr 08 16:12:30 <rich0>	TomWij: creffett plans to discuss how to handle QA disagreements in the next meeting, so I'm content to let you guys hash it out for now.
-Apr 08 16:12:42 <creffett|irssi>	yes creffett does.
-Apr 08 16:13:00 <TomWij>	WilliamH: See above message to blueness, I'm not referring to Council in specific.
-Apr 08 16:13:28 <blueness>	TomWij, i don't see any problems escalating something to comrel on day 0
-Apr 08 16:13:33 <blueness>	that's their job
-Apr 08 16:13:42 <blueness>	coming to council should be a last resort
-Apr 08 16:13:57 <TomWij>	blueness: Same goes for ComRel as they've stated multiple times.
-Apr 08 16:13:58 <rich0>	Well, escalating to anybody should only be done when people can't work it out themselves.
-Apr 08 16:14:01 <blueness>	gentlemen, on a personal note, i'm very happy about how this was handled above ^^^
-Apr 08 16:14:23 <rich0>	however, anybody CAN escalate to Comrel on day 0 if they just can't handle it.  Anybody can put something on our agenda as well.
-Apr 08 16:14:29 <rich0>	We're just not the best forum for personal conflict.
-Apr 08 16:14:35 <blueness>	correct
-Apr 08 16:14:40 <dilfridge>	yeah. I'm aware that lots of different things went wrong recently. but that's why this is not on the current issue but more a statement for future issues.
-Apr 08 16:15:39 <TomWij>	rich0: The lead of a project shouldn't be skipped in that day 0 process; but well, I know whom to talk to about this. Thanks.
-Apr 08 16:15:49 <rich0>	Yup, if all the parties can work out an agreeable solution, fine.  The community at large shouldn't get the impression that we just ignore issues.
-Apr 08 16:16:29 <rich0>	TomWij: I'll send you some thoughts on that by email - just friendly advice.  :)
-Apr 08 16:16:48 <scarabeus>	friendly with baseball bat?
-Apr 08 16:16:49 <scarabeus>	:D
-Apr 08 16:16:52 <blueness>	okay everyone, it think we can move this back to the email lists
-Apr 08 16:17:08 <rich0>	I just view this in the sense that as Council we're accountable for fixing things, even if we necessarily aren't the ones to fix them...
-Apr 08 16:17:16 <rich0>	blueness: ++
-Apr 08 16:17:33 <TomWij>	rich0: No need, afaik, this is all "written down".
-Apr 08 16:17:35 <blueness>	TomWij, no one is closing dialog here, so feel free to continue the discussion
-Apr 08 16:17:55 <blueness>	but we must finish off the meeting (since I really have to pee soon too!)
-Apr 08 16:18:01 <blueness>	last issue
-Apr 08 16:18:07 <blueness>	Bugs assigned to Council
-Apr 08 16:18:14 <blueness>	Bug #503382 -  Missing summaries for 20131210, 20140114, and 20140225 council meetings
-Apr 08 16:18:14 <blueness>	Bug #477030 - Missing summary for 20130611 council meeting
-Apr 08 16:18:14 <blueness>	Bug #498332 - Dropping stable keywords on m68k, s390, sh
-Apr 08 16:18:15 <willikins>	blueness: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
-Apr 08 16:18:16 <willikins>	blueness: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council
-Apr 08 16:18:17 <willikins>	blueness: https://bugs.gentoo.org/498332 "Dropping stable keywords on m68k, s390, sh"; Gentoo Linux, Keywording and Stabilization; CONF; dilfridge:council
-Apr 08 16:18:20 <TomWij>	(blueness: I'm not intending to stall, I was merely pointing out fast escalation; feel free to proceed)
-Apr 08 16:18:32 <blueness>	anything to do there?
-Apr 08 16:18:49 <ulm>	sure, write the summaries ;)
-Apr 08 16:19:01 <dberkholz>	i have 2 of those 3 summaries written
-Apr 08 16:19:08 <dberkholz>	i lost the 3rd one so i am rewriting it
-Apr 08 16:19:12 <dilfridge>	yay! dberkholz++
-Apr 08 16:19:17 <blueness>	okay
-Apr 08 16:19:25 <ulm>	progress ;)
-Apr 08 16:19:33 <blueness>	what about the  20130611 council meeting minutes?
-Apr 08 16:19:45 *	antarus (user97381@gentoo/developer/antarus) has joined #gentoo-council
-Apr 08 16:19:50 <antarus>	I hath been summoned
-Apr 08 16:19:55 <antarus>	what can I help you with?
-Apr 08 16:20:00 <ulm>	blueness: scarabeus wanted to ping betelgeuse
-Apr 08 16:20:24 <dilfridge>	antarus: too late :)
-Apr 08 16:20:36 <blueness>	scarabeus, can you report back for next time to see what we want to do with this one, its been plaguing us since the beginning
-Apr 08 16:21:03 <scarabeus>	i pinged, i should be more drastic
-Apr 08 16:21:09 <scarabeus>	maybe some posters campain
-Apr 08 16:21:16 <scarabeus>	then musical marching band...
-Apr 08 16:21:21 <blueness>	scarabeus, try your best and we'll decide next time what to do about it
-Apr 08 16:21:38 <blueness>	shall we move to the open floor?
-Apr 08 16:21:40 <scarabeus>	that might be too rad i guess, anyway i shall sent him mail again :P
-Apr 08 16:22:29 <blueness>	rich0, can you close out the meeting, i really have to go (in a couple of ways) .... sorry guys
-Apr 08 16:22:45 <rich0>	blueness: sure
-Apr 08 16:22:48 <blueness>	rich0, thanks
-Apr 08 16:22:56 <rich0>	open floor then...
-Apr 08 16:23:05 *	creffett|irssi has one
-Apr 08 16:23:18 <rich0>	creffett|irssi: go ahead
-Apr 08 16:23:51 <creffett|irssi>	I would like the council's opinion on whether a developer ignoring existing ebuild policy is a QA issue or a ComRel issue.
-Apr 08 16:24:16 <creffett|irssi>	sorry to spring this one on you, but it's relevant to what I'm going to be doing with QA team, and it just occurred to me about two hours ago.
-Apr 08 16:24:27 <ulm>	the first time, it's a qa issue
-Apr 08 16:24:37 <WilliamH>	Well, the way I"ve always heard it is it is a technical issue, unless
-Apr 08 16:24:37 <rich0>	Good question.  I've seen this debated before.  I've gotten the impression that comrel would prefer QA handle these kinds of issues and that it be an enforcing body as a result.
-Apr 08 16:24:45 <ulm>	but if he continues after being reminded it will become a comrel issue
-Apr 08 16:24:53 <WilliamH>	a dev says "leave my @#$% ebuild alone"
-Apr 08 16:24:56 <creffett|irssi>	rich0: and I, speaking with the lead hat on, would like it to be comrel's problem.
-Apr 08 16:25:06 <creffett|irssi>	since I feel that it's muddying the scope of what QA does
-Apr 08 16:25:07 <antarus>	aren't you lucky that I am here then!
-Apr 08 16:25:09 <antarus>	;p
-Apr 08 16:25:17 <rich0>	I think Comrel may want a determination from QA as to whether policy was broken or not.
-Apr 08 16:25:31 <creffett|irssi>	I intend to crack down on QA people "flashing the badge" without cause
-Apr 08 16:25:32 <rich0>	antarus: ++
-Apr 08 16:25:34 <rich0>	your thoughts?
-Apr 08 16:25:37 <antarus>	I'm happy to enforce existing, clear, documented policy
-Apr 08 16:25:51 <antarus>	(as a comrel issue)
-Apr 08 16:25:53 <antarus>	w/ 20
-Apr 08 16:25:55 <antarus>	bah
-Apr 08 16:26:18 <creffett|irssi>	I like what ulm had to say: we ask them nicely, they ignore us, we pass them to comrel.
-Apr 08 16:26:55 <ssuominen>	WilliamH: a dev says because he believe someone is deliberately sabotaging his work with no technical basis, or policy to back it up and says "don't touch my ebuild ever again." with a minor temper :)
-Apr 08 16:27:41 <antarus>	creffett|irssi: I understand that there may be difficulties in getting new policies adopted
-Apr 08 16:27:45 <rich0>	Well, I imagine before Comrel gets involved they'd want a formal statement by "QA" and not by an individual member of QA.
-Apr 08 16:27:47 <antarus>	creffett|irssi: I'm not sure what to do about that
-Apr 08 16:27:58 <WilliamH>	ssuominen: At that point, it is still personal, because qa can touch  any ebuild in the tree.
-Apr 08 16:28:00 <creffett|irssi>	antarus: I'm not even concerned with adopting new policies at this point
-Apr 08 16:28:04 <antarus>	rich0: I don't mind making rulings
-Apr 08 16:28:08 <creffett|irssi>	right now I'm concerned with existing policy
-Apr 08 16:28:16 <TomWij>	rich0: Wrt that determination, I believe the problem here is that QA is technical whereas ComRel is personal.
-Apr 08 16:28:19 <antarus>	rich0: as long as people aren't actually angry when we rule against them ;p
-Apr 08 16:28:24 <creffett|irssi>	TomWij: precisely.
-Apr 08 16:28:46 <antarus>	the problem as I see it is that qa is happy for comrel to rule, until comrel makes ruling they dislike
-Apr 08 16:28:47 <rich0>	antarus: people get angry around here?  never, as long as you're beating up on somebody else...
-Apr 08 16:28:56 <antarus>	then suddenly it is an issue
-Apr 08 16:28:58 <creffett|irssi>	I feel that some issues with people flashing the QA badge have been people issues, not technical issues, and so we should not have gotten involved to start with
-Apr 08 16:29:29 <creffett|irssi>	antarus: your decision is your decision
-Apr 08 16:29:30 <rich0>	Personally I think it is a grey area, and if the policy is that questionable that is why you can appeal to council...
-Apr 08 16:29:34 <antarus>	I don't care who decides, as long as it is celar, IMHO
-Apr 08 16:29:37 <antarus>	clear*
-Apr 08 16:30:16 <ulm>	isn't there a rule in glep 48 for this?
-Apr 08 16:30:32 <rich0>	Yup
-Apr 08 16:30:34 <ulm>	"If a particular developer persistently causes breakage, the QA team may request that Comrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to Comrel."
-Apr 08 16:30:49 <antarus>	thats sort of a bad rule
-Apr 08 16:30:52 <creffett|irssi>	that's not enough.
-Apr 08 16:30:54 <antarus>	I'm unlikely to actually suspend people
-Apr 08 16:31:11 <ulm>	should be last resort, probably
-Apr 08 16:31:16 <creffett|irssi>	it does not actually make clear the distinction between people issues and technical issues
-Apr 08 16:31:19 <antarus>	in the case of this particular bug
-Apr 08 16:31:24 <antarus>	I mostly just talked to both parties
-Apr 08 16:31:35 <antarus>	and described how I thought they should handle the situation
-Apr 08 16:31:39 <antarus>	no suspensions were involved
-Apr 08 16:31:51 <antarus>	(I don't find suspensions to be very useful)
-Apr 08 16:32:42 <antarus>	creffett|irssi: would you liek to discuss that aspect further then?
-Apr 08 16:32:48 <antarus>	creffett|irssi: what parts do you want to own (if any?)
-Apr 08 16:33:44 <creffett|irssi>	antarus: ...I'm still hashing it out mentally, but roughly speaking, if someone causes actual breakage (dependencies break, ebuilds running rm -rf /, like that), it's in our court
-Apr 08 16:34:02 *	jlec (~jlec@gentoo/developer/jlec) has joined #gentoo-council
-Apr 08 16:34:09 *	jlec (~jlec@gentoo/developer/jlec) has left #gentoo-council
-Apr 08 16:34:30 <creffett|irssi>	if it's just ignoring a policy but not actively breaking stuff (recent udev issue, as far as I could tell, fell into this) it's yours
-Apr 08 16:35:00 <creffett|irssi>	again, still thinking this through, that's why I asked the council what they think
-Apr 08 16:35:04 <antarus>	ok
-Apr 08 16:35:33 <dilfridge>	in the end, it's mostly that qa and comrel come to an agreement among themselves
-Apr 08 16:35:48 <johu>	i have a question too, when QA/ComRel stuff is finished
-Apr 08 16:36:15 <antarus>	dilfridge: I concur, I think creffett|irssi is mostly looking input from others
-Apr 08 16:36:18 <antarus>	(not a ruling, per se)
-Apr 08 16:36:20 <TomWij>	creffett|irssi: I think I see what you're getting at, communicating to the mailing list feels like ComRel terrain (in the positive sense); but I think that the mask is still our terrain, a bit more technical, and I hope to see a mail to qa@gentoo.org next time we've got a similar case going on.
-Apr 08 16:36:45 <creffett|irssi>	unless the council has other opinions on this, I've got nothing further
-Apr 08 16:36:59 *	antarus also has nothing further
-Apr 08 16:38:00 <dilfridge>	rich0? shall we pass to johu's question?
-Apr 08 16:38:01 <rich0>	Anything else?  I'm fine with where you're heading with this - you have to live with it!
-Apr 08 16:38:09 <rich0>	If not, go ahead johu
-Apr 08 16:38:53 <rich0>	johu?
-Apr 08 16:39:32 <johu>	Ok current situation: proj xml is not allowed anymore, few projects migrated, a lot of missing, a3li from wiki team said to me he dont want to enforce ppl to migrate. who is reponsible to get out of this half migrated state?
-Apr 08 16:40:15 <rich0>	I suggest we take it to the lists to see if there is any reason not to push, but at some point we should push.
-Apr 08 16:40:37 <johu>	Swift made a script to have auto-conversion
-Apr 08 16:40:53 <dilfridge>	https://wiki.gentoo.org/wiki/Project:Wiki/Project_Page_Migration_Status
-Apr 08 16:40:59 <dilfridge>	this looks still more red than green
-Apr 08 16:41:17 <ulm>	what's still missing is hosting for text files
-Apr 08 16:41:25 <ulm>	like council logs
-Apr 08 16:41:39 <johu>	create a git repo for logs and done
-Apr 08 16:41:43 <rich0>	Well, we could still move the proj.xml, right?
-Apr 08 16:42:00 <rich0>	Council is done, for example.
-Apr 08 16:42:02 <dilfridge>	the git repo is actually not such a bad idea, it uses existing infrastructure
-Apr 08 16:42:16 <ulm>	johu: still there needs to be some nice way for presenting them
-Apr 08 16:42:20 <dilfridge>	and even cvs history could be converted
-Apr 08 16:42:47 <dilfridge>	ulm: well, right now we just get the bare text display in the browser... same if we link to the raw file in gitweb
-Apr 08 16:42:51 <johu>	is the current log still presented in a nice way? :D
-Apr 08 16:43:26 <dilfridge>	anyway this is getting into details
-Apr 08 16:43:30 <rich0>	yup
-Apr 08 16:43:44 <rich0>	I suggest starting a -project thread about this.  Is there a reason we shouldn't just do a final migration?
-Apr 08 16:43:46 <ulm>	yeah, presumably that's not the main blocker
-Apr 08 16:44:53 <rich0>	Anything further on this/
-Apr 08 16:44:55 <rich0>	?
-Apr 08 16:45:00 <johu>	thanks for your wokr
-Apr 08 16:45:02 <johu>	work
-Apr 08 16:45:16 <rich0>	johu: thanks for brining it up!  :)
-Apr 08 16:45:37 <rich0>	Ok, anything else?
-Apr 08 16:45:57 <dberkholz>	i'd prefer to have 'em on the wiki, actually, so they're searchable
-Apr 08 16:46:05 <rich0>	++
-Apr 08 16:46:12 <dilfridge>	good point.
-Apr 08 16:46:25 <rich0>	Ok, sounds like we're done.  Next meeting is the 13th I believe, and I'm chairing.
-Apr 08 16:46:38 *	rich0 bangs the gavel
-Apr 08 16:46:41 <ulm>	dberkholz: what? council logs?
-Apr 08 16:47:12 <dberkholz>	yep, logs, summaries, other related text files
-Apr 08 16:47:15 <ulm>	they're logs, supposed to be static
-Apr 08 16:47:30 <ulm>	nothing to put into a wiki
-Apr 08 16:47:31 <rich0>	aren't the text files searchable?
-Apr 08 16:47:39 <dberkholz>	i often find myself searching for when something was discussed
-Apr 08 16:47:43 <rich0>	Summaries maybe in wiki?
-Apr 08 16:48:29 <rich0>	The trustees kept a log of motions across meetings.
-Apr 08 16:48:37 <ulm>	yeah, summaries might be there
-Apr 08 16:48:56 <jmbsvicetto>	what's the issue with static files in the wiki?
-Apr 08 16:48:57 <ulm>	but then you'd have to convert the old ones
-Apr 08 16:49:48 <rich0>	Logs are raw.  Seems like work to try to wikify them for what?
-Apr 08 16:49:50 <WilliamH>	jmbsvicetto: they wouldn't be static any more if you put the content in a wiki ;-)
-Apr 08 16:50:21 <jmbsvicetto>	mark the logs as read-only ?
-Apr 08 16:50:44 <WilliamH>	Is that possible?
-Apr 08 16:50:53 <jmbsvicetto>	I'm asking ;)
-Apr 08 16:50:54 <ulm>	jmbsvicetto: another issue is that mediawiki isn't well suited for plain ascii
-Apr 08 16:51:44 <ulm>	you'll need <pre> </pre> blocke everywhere
-Apr 08 16:51:47 <jmbsvicetto>	ulm: hmm, <code>old ascii text</code> ? It shouldn't look any worse than the plain txt files looked in the old project pages, no?
-Apr 08 16:51:48 <ulm>	*blocks
-Apr 08 16:52:08 <jmbsvicetto>	ulm: or <pre> blocks
-Apr 08 16:52:31 <ulm>	also there are more use cases than just logs
-Apr 08 16:52:53 <ulm>	e.g. text files that should be easy to download
-Apr 08 16:53:19 <ulm>	there's some bug open for it, but I fail to find it
-Apr 08 16:54:37 <ulm>	bug 451074
-Apr 08 16:54:38 <willikins>	https://bugs.gentoo.org/451074 "wiki.gentoo.org doesn't allow upload of plain text files"; Website www.gentoo.org, Wiki; CONF; ulm:wiki
-Apr 08 16:55:32 <ulm>	e.g. in tracwiki one would simply attach the meeting logs to the council page
-Apr 08 16:55:42 *	antarus (user97381@gentoo/developer/antarus) has left #gentoo-council
-Apr 08 16:55:55 <ulm>	not possible with mediawiki, you need subpages there, or external hosting
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140513-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20140513-summary.txt
deleted file mode 100644
index 5203b6bb30..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140513-summary.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-Summary of Gentoo council meeting 13 May 2014
-
-
-Agenda
-======
-1. Roll call
-2. Package Default USE Flags / Security
-3. Non-upstream pkg-config
-4. Bugs assigned to Council
-5. Open floor
-
-1. Roll call
-============
-
-Present: blueness, dberkholz, rich0, scarabeus, ulm
-Absent: dilfridge, williamh
-
-
-2. Package Default USE Flags / Security
-=========================================================================
-
-The council discussed default USE flags, in-particular including those
-of openssl and openssh [1 and 2].  The council felt that this should be
-left to the maintainer's discretion.
-
- "Per existing policy, the council leaves the default USE flags to the
- discretion of the maintainer, but encourages following upstream when
- there is no reason to do otherwise."
-
-Aye: dberkholz, rich0, scarabeus, ulm
-Not present for vote: blueness
-
-
-[1] - https://bugs.gentoo.org/show_bug.cgi?id=507130
-[2] - https://bugs.gentoo.org/show_bug.cgi?id=507210
-
-
-3. Non-upstream pkg-config
-=========================================================================
-
-The council felt unanimously that an outright ban on non-upstream
-pkg-config files was inappropriate.  It was felt that any sensible
-policy would leave it to the maintainer's discretion.  The exact wording
-of the recommendations was deferred to the lists/etc.
-
- "The council agrees to revise the devmanual policy regarding pkg-config
- files to set guidelines for non-upstream pkg-config files but to leave
- the inclusion up to the maintainer's discretion.  Wording will be
- worked out following the meeting, and in the meantime the changes
- introduced in bug 445130 will be reverted."
-
-Aye: blueness, dberkholz, rich0, scarabeus, ulm
-
-
-4. Bugs assigned to Council
-===========================
-
-Bugs 503382 and 477030 are for missing summaries - those responsible are
-reminded to write them up.
-
-Bug 498332 was discussed and it was not felt that it was necessary for
-Council to remain CC'ed.  A note to this effect will be posted on the
-bug by rich0.
-
-
-5. Open floor
-=============
-
-No issues were brought forward.
-
-
-Summary submitted by Richard Freeman <rich0@gentoo.org>
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140513.txt b/xml/htdocs/proj/en/council/meeting-logs/20140513.txt
deleted file mode 100644
index c90509750b..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140513.txt
+++ /dev/null
@@ -1,149 +0,0 @@
-[15:01:40] <rich0> Roll call: blueness, dberkholz, dilfridge, scarabeus, ulm, williamh
-[15:01:49] -*- ulm here
-[15:01:56] <dberkholz> hi
-[15:02:01] -*- rich0 notes email from williamh expecting to not be present
-[15:02:39] <rich0> ulm, dilfridge?
-[15:02:47] -*- ulm still here :)
-[15:03:01] <scarabeus> ulm: too tiny to be noticed i guess :P
-[15:03:01] <rich0> err, blueness...
-[15:03:13] <rich0> I knew I was missing two more...
-[15:03:37] <rich0> Ok, blueness, williamh, dilfridge not present.  We can start
-[15:03:54] <rich0> Topic #1: Package Default USE Flags / Security
-[15:04:30] <rich0> tls-heartbeat and hpn were specific examples brought up, but the general question is what should our default USE flags be from a security standpoint.
-[15:04:54] <rich0> Any comments?  I posted mine on the list.
-[15:05:05] <ulm> maintainers should go with the upstream default
-[15:05:23] <ulm> but finally it's the maintainer's choice what flags to enable
-[15:05:24] <rich0> So, that would be tls-heartbeat on, and hpn off.
-[15:05:42] <ulm> yep
-[15:05:57] <rich0> My personal sense is maintainer's discretion, with the principle of following upstream.
-[15:05:57] <scarabeus> up to the dev honestly
-[15:06:15] <rich0> We'll never come up with a blanket policy that makes sense without some discretion.
-[15:07:09] <rich0> Ok, how about "The council leaves default USE flags to the discretion of the maintainer, but encourages following upstream when there is no reason to do otherwise."
-[15:07:45] <ulm> sounds good
-[15:07:54] <rich0> Ok, do we want to vote?
-[15:08:24] <rich0> If so, aye for me.
-[15:08:43] <scarabeus> aye from me
-[15:08:49] <ulm> yes
-[15:08:55] <rich0> dberkholz ?
-[15:09:16] <dberkholz> hmmm
-[15:09:44] <dberkholz> that doesn't even sound like we're saying anything new
-[15:09:52] <dberkholz> i don't know why we would vote on it at all
-[15:10:19] <rich0> I understand - I just see that as our conclusion, so that we can document that we agree to leave things alone.
-[15:10:43] <dberkholz> sure. maybe we can note that we're supporting existing policy with that statement rather than changing
-[15:11:07] <dberkholz> prepend it with "As per existing policy," or something
-[15:11:19] <rich0> Ok, how about, "Per existing policy, the council leaves the default USE flags to the discretion of the maintainer, but encourages following upstream when there is no reason to do otherwise."
-[15:11:46] <dberkholz> good for me.
-[15:11:52] <ulm> +1
-[15:11:59] <rich0> +1 for me as well
-[15:12:05] <rich0> scarabeus?
-[15:12:29] <scarabeus> +1
-[15:12:33] <rich0> Ok, topic #2: Non-upstream pkg-config
-[15:12:54] <rich0> A few more ideas circulated on the lists in addition to the ones in the agenda.
-[15:13:31] <rich0> Options also include controlling the installation of non-upstream pkg-config files via a USE flag, or sticking them in a special path.
-[15:14:35] <rich0> I think the USE flag idea isn't a terrible one, even though in general I'm not a fan of controlling single file installtion via USE flags this seems a bit different and INSTALL_MASK won't work.
-[15:15:03] <dberkholz> funny, i don't like the USE flag idea
-[15:15:09] <scarabeus> that is bad with the use
-[15:15:10] <rich0> Thoughts?  I'm not a big fan of a complete ban.
-[15:15:43] <scarabeus> it should not be banned either, it should be installed if we want it per maitnainer decision, but he needs to talk with other distros and have them do the same darn thing
-[15:15:57] <scarabeus> stupid would be each distro providing own pc
-[15:16:20] <scarabeus> if the pc make life easier why not have it
-[15:16:20] <rich0> I do agree that alignment with other distros should be a consideration.  In practice, only the maintainer could make that call.
-[15:16:40] <ulm> I don't see this as anything were the council should intervene
-[15:16:53] <ulm> leave it to qa on a case by case basis
-[15:16:55] <dberkholz> +1 ulm
-[15:16:56] <rich0> Not sure if we can send upstream a lart-o-gram.
-[15:17:16] <ulm> and general policy is that patches should be sent upstream if possible
-[15:17:30] <rich0> ulm: nothing new there
-[15:17:33] <ulm> I don't see how pkgconfig files are special in this respect
-[15:17:36] <creffett|irssi> (qa hat on) I don't even see why this needs to be a QA problem, I consider this equivalent to, say, patching to fix a build--upstream if you can
-[15:17:39] <creffett|irssi> what ulm said
-[15:18:21] <rich0> I can understand how this calls for more care than just patching a build system, since we're basically defining a distro-specific interface of sorts.
-[15:18:49] <rich0> However, I think that any sensible policy is going to leave this to maintainer's discretion.  We can give guideance, but we can't come up with some kind of blanket rule.
-[15:19:21] <rich0> If we went with this it does mean a change to the devmanual, which apparently outright bans them.
-[15:19:43] <scarabeus> agree it is like any other build patch; only this time it is more required to coordinate with others
-[15:20:39] <rich0> Anybody have the devmanual link?
-[15:20:54] <ulm> the patch is in bug 445130
-[15:20:56] <willikins> ulm: https://bugs.gentoo.org/445130 "document that pkgconfig files should not be modified/added/renamed"; Doc Other, Devmanual; RESO, FIXE; hasufell:devmanual
-[15:21:04] <ulm> introduced quite recently
-[15:21:29] <ulm> and tbh, I don't understand why it was accepted without much discussion
-[15:22:05] <rich0> Ok, do we want to work out exact wording now?
-[15:22:17] <creffett|irssi> ulm: because it was directly committed
-[15:22:20] <rich0> Or just agree on the change with wording to be worked out along these lines?
-[15:22:54] <scarabeus> sweet didn't know this rule
-[15:23:04] <scarabeus> revert and write better wording would be best
-[15:23:34] <rich0> If so, how about, "The council agrees to revise the devmanual policy regarding pkg-config files to set guidelines for non-upstream pkg-config files but to leave the inclusion up to the maintainer's discretion.  Wording will be worked out following the meeting."
-[15:24:03] <rich0> We could revert in the interim, though I don't see any rush.
-[15:24:09] <ssuominen> having pkg-config files should be recommended, it's the only way to solve some of the current build problems that works for every scenario
-[15:24:23] <rich0> I'm not opposed to reverting for now.
-[15:24:49] <ssuominen> if upstream doesn't provide them, we should, just like we patch important bugs even if upstream refuses them
-[15:24:55] <rich0> If we do that, then: "The council agrees to revise the devmanual policy regarding pkg-config files to set guidelines for non-upstream pkg-config files but to leave the inclusion up to the maintainer's discretion.  Wording will be worked out following the meeting, and in the meantime the changes introduced in bug 445130 will be reverted."
-[15:24:56] <willikins> rich0: https://bugs.gentoo.org/445130 "document that pkgconfig files should not be modified/added/renamed"; Doc Other, Devmanual; RESO, FIXE; hasufell:devmanual
-[15:25:42] <rich0> Do we really want to recommend ALWAYS creating a pkg-config file?
-[15:25:43] <ulm> rich0: +1
-[15:26:00] <ulm> (on the wording)
-[15:26:06] <dberkholz> works for me
-[15:26:40] <rich0> scarabeus, you OK with that wording for now?
-[15:26:47] <ssuominen> not always, but when there is need to have list of libraries used for static linking *somewhere* (ie. Libs.private:) over even if package provides foobar-config
-[15:27:04] -*- blueness is here
-[15:27:45] <scarabeus> fine
-[15:27:55] <rich0> blueness: do you want to vote RE pkg-config?
-[15:27:57] <rich0> The proposal is:
-[15:28:05] <rich0> "The council agrees to revise the devmanual policy regarding pkg-config files to set guidelines for non-upstream pkg-config files but to leave the inclusion up to the maintainer's discretion.  Wording will be worked out following the meeting, and in the meantime the changes introduced in bug 445130 will be reverted."
-[15:28:06] <willikins> rich0: https://bugs.gentoo.org/445130 "document that pkgconfig files should not be modified/added/renamed"; Doc Other, Devmanual; RESO, FIXE; hasufell:devmanual
-[15:28:38] <blueness> thanks rich0 let me read that bug
-[15:29:08] <rich0> blueness: go ahead.  https://445130.bugs.gentoo.org/attachment.cgi?id=330930 is basically the gist of it
-[15:30:03] <blueness> rich0, i'm okay with the council's position
-[15:30:09] <blueness> ie that wording
-[15:30:35] <rich0> ok, anything else on that?  Otherwise I think the new guildelines will benefit from general bikeshedding, and we've already outlined where we're going.
-[15:31:21] <rich0> Ok, if nothing else...
-[15:31:22] <blueness> rich0, the only thing i couldn't figure out from the emails is where this became an issue
-[15:31:38] <ulm> rich0: do we vote on this
-[15:31:49] <rich0> Ah, I counted those as votes.
-[15:31:53] <ulm> yes from me, too
-[15:32:00] -*- blueness yes
-[15:32:03] -*- scarabeus yes
-[15:32:12] -*- rich0 yes (for the record)  :)
-[15:32:39] <dberkholz> yes again
-[15:32:53] <ulm> commit reverted: http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=commit;h=41e625daa4be537f934ba50276a97c97b7f3fd85
-[15:32:54] <rich0> blueness: the actual issue is that if somebody uses gentoo they might leverage a pkg-config file in their own software's build system, and then have it break on other distros
-[15:33:34] <rich0> Or maybe upstream finally issues one and something changes, breaking reverse deps.
-[15:34:08] <blueness> rich0, i guess i'm asking if this happened somewhere
-[15:34:14] <rich0> There are pros and cons either way, but I think that they're helpful more often than not.
-[15:34:20] <rich0> I doubt it.
-[15:34:23] <blueness> k
-[15:34:33] <rich0> And if you find out your build system breaks on slackware or something, then you fix it.
-[15:35:03] <rich0> Ok, moving on...
-[15:35:07] <blueness> rich0, the reason i'm asking is because i was about to remove curl-config but didn't -> https://bugs.gentoo.org/show_bug.cgi?id=497956
-[15:35:11] <blueness> *for the records.
-[15:35:18] <blueness> okay sorry let's move on ...
-[15:35:58] <rich0> Ok, open bugs.
-[15:36:11] <rich0> Two are missing summaries - other than another ping, anything to talk about with those?
-[15:36:27] <rich0> For bug 498332, is there any reason we're still CC'ed?
-[15:37:00] <rich0> I think that one is basically resolved as far as we're concerned. Non-stable archs can use stable flags if they want, but maintainers can ignore them.
-[15:37:02] <scarabeus> no idea why we are cced :)
-[15:37:19] <rich0> Ok, I'll leave a note on 498332 and remove us.
-[15:37:30] <ulm> +1
-[15:38:02] <rich0> Ok, I think that wraps up bugs.  AOB?
-[15:38:40] <rich0> If not, moving to open floor.  Anybody have anything to bring up?
-[15:39:44] <ulm> just a heads up, I intend to come up with a feature list for eapi 6 fro the next meeting
-[15:40:09] <rich0> looks like we get to go out with a ban
-[15:40:10] <blueness> ulm, okay
-[15:40:13] <rich0> err, bang
-[15:40:21] <blueness> rich0, fizzle/
-[15:40:27] <blueness> :(
-[15:40:29] <blueness> :)
-[15:40:33] <rich0> if we don't like the feature list, we can always ban you from brining forward mroe
-[15:40:36] <blueness> (i can't type)
-[15:41:05] <rich0> Another question - do we need to do something to plan for elections?
-[15:41:34] <rich0> Can't believe it has been a year...
-[15:42:16] <rich0> Looks like last year's results were never posted.
-[15:42:16] <blueness> is there a committee that takes care of elections?
-[15:42:29] <scarabeus> blueness: election team has to handle it
-[15:42:33] <scarabeus> not our job luckily ;D
-[15:42:37] <blueness> k
-[15:42:45] <blueness> scarabeus, well it can't be
-[15:42:53] <rich0> Ok, I'll ping them and remind them to start planning.  Looks like we still have a month before nominations start.
-[15:43:17] <rich0> And I'll bug them to post their summaries too.
-[15:43:32] <rich0> Ok, if nothing else, then I'm chairing next month, and will post the logs/summary.
-[15:43:45] <dberkholz> thanks rich0!
-[15:43:47] -*- rich0 bangs the gavel
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140610-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20140610-summary.txt
deleted file mode 100644
index 29430391a1..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140610-summary.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-Summary of Gentoo council meeting 10 Jun 2014
-
-
-
-Roll call
-============
-
-Present: blueness, dberkholz, dilfridge, rich0, ulm
-Absent: scarabeus, williamh (slacker)
-
-
-Approve Preliminary EAPI 6 Features
-===================================
-These were discussed/voted in blocks as suggested by ulm in discussion,
-but I'm going to split them up in the summary for clarity.  See the log
-for the details of how things went:
-
-get_libdir()
-bug #463586
-Used in econf, but so far not available as separate PM function
-Aye: blueness, dberkholz, dilfridge, rich0, ulm
-
-einstalldocs()
-bug #459692
-Aye: blueness, dberkholz, dilfridge, rich0, ulm
-
-Query function for IUSE_EFFECTIVE (or IUSE?)
-bug #449862
-Aye: blueness, dberkholz, dilfridge, rich0, ulm
-
-nonfatal die()
-bug #451938
-Aye: blueness, dberkholz, dilfridge, rich0, ulm
-
-Allow empty DOCS variable
-bug #463736
-Aye: blueness, dberkholz, dilfridge, rich0, ulm
-
-Directory support for DOCS
-bug #481980
-Aye: blueness, dberkholz, dilfridge, rich0, ulm
-
-Unpack .txz
-bug #458102
-Aye: blueness, dberkholz, dilfridge, rich0, ulm
-
-Case-fold extensions in unpack
-bug #476730
-Aye: blueness, dberkholz, dilfridge, rich0, ulm
-
-unpack() accept absolute paths
-bug #483244
-Aye: blueness, dberkholz, dilfridge, rich0, ulm
-
-Bash 4.2
-bug #431340
-Aye: blueness, dberkholz, dilfridge, rich0, ulm
-
-failglob in global scope
-bug #463822
-(Council agreed on failglob in global scope only - not local scope.)
-Aye: blueness, dberkholz, dilfridge, rich0, ulm
-
-PATCHES support in default src_prepare
-bug #463692
-Aye: dilfridge, rich0
-Nay: blueness, dberkholz
-Abstain: ulm
-This motion was defeated.
-
-There was extensive discussion on user patches, and we'll continue on
-the list before voting next week.
-
-
-Meeting called and will be continued on 17 Jun 2014 at 19:00 UTC.
-
-Summary submitted by Richard Freeman <rich0@gentoo.org>
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140610.txt b/xml/htdocs/proj/en/council/meeting-logs/20140610.txt
deleted file mode 100644
index 07679ebbc5..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140610.txt
+++ /dev/null
@@ -1,413 +0,0 @@
-[15:02:41] <rich0> roll call: blueness dberkholz dilfridge scarabeus ulm williamh
-[15:02:46] <rich0> (or proxies)
-[15:03:01] -*- dilfridge here
-[15:03:49] -*- ulm here
-[15:03:57] <dberkholz> i am still here
-[15:04:23] <rich0> blueness, scarabeus, williamh?
-[15:05:16] <dilfridge> scarabeus mentioned to me that he couldnt attend and was looking for a proxy
-[15:05:21] <ulm> PMS makes people feel uneasy, it seems :)
-[15:05:31] <creffett|irssi> williamh probably still missing wrt hardware issues?
-[15:05:32] <rich0> creffett|irssi: if you have agreement with scarabeus you can proxy for him.
-[15:05:33] <blueness> here
-[15:05:40] <rich0> Tend to agree re williamh
-[15:05:48] <creffett|irssi> rich0: no agreement, sorry
-[15:06:10] <rich0> Ok, then scarabeus, williamh not here, rest present.  Let the PMS fun begin.
-[15:06:18] <dilfridge> whee
-[15:06:21] <rich0> First topic - items for EAPI6
-[15:06:35] <rich0> Per ulm's suggestion we'll use the pools he recommened which I put in the agenda.
-[15:06:48] <rich0> First: 1a-c
-[15:07:00] <rich0> As found on: https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_6_tentative_features
-[15:07:13] <rich0> Any commentary before we vote?
-[15:07:26] <dilfridge> edocs++, einstalldocs--
-[15:07:47] <blueness> rich0, one sec while i refresh my memory on those
-[15:07:48] <rich0> Ok, let's chat about all, but we'll break up the vote.
-[15:08:22] <rich0> oh, you're just talking about the function name
-[15:08:31] <dilfridge> yep.
-[15:08:34] <rich0> Just about everything on the list had some level of bikeshedding RE function names/etc.
-[15:08:47] <dilfridge> yeah, not important.
-[15:08:48] <blueness> ulm, i didn't fully understand  IUSE_EFFECTIVE
-[15:08:50] <rich0> I suggest we vote with regard to whether the feature is in/out, and not the specific implemetnation details unless critical.
-[15:08:57] <ulm> I don't care about the names
-[15:09:15] <rich0> The final PMS change will have to be voted on by the next council before adopted.
-[15:09:24] <rich0> So they can do the bikeshedding.  :)
-[15:09:30] <ulm> blueness: it's equal to IUSE, plus some flags like "prefix" that are injected from profiles
-[15:09:30] <dilfridge> hehe
-[15:09:40] <dberkholz> i'm good with 1a-c
-[15:09:41] <blueness> ulm, okay
-[15:09:46] <dilfridge> vote?
-[15:09:47] <blueness> i'm good with those then
-[15:09:49] <ulm> blueness: so if you query if a flag can be used, it should be IUSE_EFF
-[15:09:51] <rich0> Ok, let's vote.
-[15:10:06] -*- blueness yes to 1a-c
-[15:10:09] <rich0> The council agrees to include 1a-c in EAPI6
-[15:10:09] -*- ulm yes for 1a-c
-[15:10:12] -*- rich0 yes
-[15:10:14] -*- dilfridge yes for 1a-c
-[15:10:34] <dberkholz> yes
-[15:10:36] <rich0> Ok
-[15:10:39] <rich0> Passed
-[15:10:47] <rich0> Next, 2a-f
-[15:10:49] <rich0> Discussion?
-[15:10:51] <blueness> rich0, wait
-[15:10:55] <rich0> (skipping 1d for now)
-[15:10:56] <blueness> what about 1d?
-[15:10:59] <blueness> oh okay!
-[15:11:10] <rich0> (we're picking the fastest stuff to approve first)
-[15:11:11] -*- blueness shutsup
-[15:11:15] <blueness> yes yes
-[15:11:17] <dberkholz> nothing to say re 2a-f
-[15:11:27] <ulm> AFAICS 2a-f should all be non-controversial
-[15:11:35] <rich0> agree
-[15:11:43] <blueness> 2f might be a problem no?
-[15:12:01] <ulm> I don't see a problem for 2f
-[15:12:04] <blueness> my concern there: will old unpack behavior be changed?
-[15:12:19] <rich0> blueness: See comment 11
-[15:12:31] <blueness> lookin now to refresh mymemory
-[15:12:33] <rich0> That seems like a good compromise
-[15:12:35] <blueness> it doesn't help to do these early
-[15:12:54] <rich0> Yeah, we're earning our pay on this agenda.  :)
-[15:13:16] <blueness> i'm okay with comment 11 three
-[15:13:18] <blueness> there
-[15:13:25] <dilfridge> actually
-[15:13:25] <rich0> Ok, anything else on 2a-f?
-[15:13:27] <blueness> i think that's critical for backwards compat
-[15:13:30] <dilfridge> ulm: there is a small problem
-[15:13:30] -*- blueness done
-[15:13:38] <dilfridge>  unpack ./mame.zip
-[15:13:43] <dilfridge> and similar usage in the tree
-[15:13:53] <dilfridge> what happens there?
-[15:14:08] <blueness> it takes the literal path no?
-[15:14:23] <rich0> What does portage do today?
-[15:14:26] <ulm> dilfridge: path contains a slash, so it's taken as is
-[15:14:30] <ulm> no problem there
-[15:14:56] <dilfridge> ok
-[15:14:57] <rich0> I think we're ok
-[15:14:57] <dilfridge> fine
-[15:15:01] <blueness> ulm, dilfridge i assume unpack foo.zip and unpack ./foo.zip do the saem thine
-[15:15:02] <ulm> so unpack ./mame.zip unpacks in current dir
-[15:15:03] <blueness> thing
-[15:15:14] <ulm> unpack mame.zip unpacks in DISTDIR
-[15:15:18] <rich0> Well, unpack foo.zip would be in DISTDIR
-[15:15:25] <blueness> ah yes
-[15:15:34] <rich0> I'd assume unpack ./foo.zip would be current dir (likely in $S
-[15:15:36] <blueness> so where is the "current dir"
-[15:15:41] <blueness> in $S?
-[15:15:45] <ulm> rich0: exactly
-[15:15:45] <dberkholz> wherever you've switched to
-[15:16:16] <blueness> ulm, we may hit a bug there, i suggest we grep the tree
-[15:16:18] <rich0> ulm: is that current behavior?  If so then no issues at all
-[15:16:18] <dilfridge> anyway we're not changing retroactively
-[15:16:30] <blueness> oh never mind, its not retro
-[15:16:31] <dilfridge> so who cares if weird stuff is done
-[15:16:32] <rich0> That is also true - this is a new EAPI, so fix your builds.
-[15:16:47] <rich0> Just get rid of the ./ if it is meant to be DISTDIR
-[15:16:55] <rich0> Or add it if you want it to be $S
-[15:16:58] <blueness> okay devs will just have to watch it on bumping EAPI's
-[15:17:05] <rich0> Ok, good to vote?
-[15:17:06] <ulm> it's just the current behaviour for foo.zip and ./foo.zip
-[15:17:15] <dilfridge> vote
-[15:17:23] <rich0> vote
-[15:17:27] -*- rich0 yes for 2a-f
-[15:17:31] <ulm> and adds that /some/path/foo.zip is handled too
-[15:17:35] -*- dilfridge yes for 2a-f
-[15:17:37] -*- ulm yes for 2a-f
-[15:17:46] -*- blueness yes
-[15:18:11] <rich0> dberkholz ?
-[15:18:12] <dberkholz> yes
-[15:18:15] <rich0> ok, passed
-[15:18:23] <rich0> Next, 3a-b
-[15:18:32] <dberkholz> yes x100
-[15:18:41] <rich0> Bash stuff.  Discussion?
-[15:18:56] <ulm> bash 4.2 is overdue
-[15:18:56] <dilfridge> separate votes
-[15:19:02] <blueness> i'm very much in favor of 4.2
-[15:19:13] <dilfridge> cause 3b looks complicated :P
-[15:19:19] <rich0> sure, we can vote separate - let's discuss together since related
-[15:19:22] <ulm> and failglob will catch unintentional * in global scope
-[15:19:28] <blueness> i had a protage helper bounced because i wrote it using associated arrays in bash only to find out that we're at bash3
-[15:19:41] <blueness> dilfridge, i'm glad you asked, i don't understand 3b fully
-[15:19:55] <blueness> ulm, can you give us a simple example
-[15:20:22] <ulm> blueness: https://bugs.gentoo.org/show_bug.cgi?id=463822 comment 0
-[15:20:49] <ulm> with failglob that will error out
-[15:21:01] <blueness> so this is the issue -> unless user runs emerge from a directory where the glob matches some actual files and then hell breaks loose
-[15:21:14] <ulm> while currently it may or may not work, depending on files in current dir
-[15:21:22] <rich0> blueness: yup.  Globbing can potentially change the behavior of the ebuild depending on environment.
-[15:21:36] <rich0> with failglob that ebuild will always fail, so issue fixed before commiting.
-[15:21:43] <blueness> so what exaclty is nullglob, what context does it live in, is it a bash thingy
-[15:22:09] <ulm> nullglob will remove the word
-[15:22:23] <ulm> if there are no matches, that is
-[15:22:35] <rich0> That might or might not be caught during development.
-[15:22:43] <blueness> yeah that's what i'm thinking rich
-[15:22:47] <blueness> yeah that's what i'm thinking rich0
-[15:23:02] <rich0> It basically under-specifies a dependency, which causes no issues if you have it installed when testing it.
-[15:23:05] <blueness> what about the other solution ->  disable globbing completely in global scope and re-enable it in phase scope
-[15:23:14] <rich0> blueness: that is the proposal
-[15:23:21] <rich0> failglob in global scope
-[15:23:25] <rich0> not in function scope
-[15:23:43] <dilfridge> yep. I just dont know how much this affects eclasses.
-[15:23:59] <rich0> Do we have eclasses globbing in global scope?
-[15:24:07] <rich0> It is only an issue if they don't quote.
-[15:24:13] <rich0> I'd think the fix is to just add quoting to the eclass.
-[15:24:17] <ulm> dilfridge: there's not much going on in global scope in most eclasses
-[15:24:21] <rich0> Which is better than leaving them as they are now.
-[15:24:43] <ulm> it also won't affect eclasses for existing EAPIs
-[15:24:48] <rich0> Also, this only is for EAPI6, so we'll spot that as ebuilds get ported.
-[15:24:51] <dilfridge> ulm: could an eclass switch on these features "manually" again if needed?
-[15:24:52] <blueness> ulm, there are variables set which could have globs
-[15:25:07] <ulm> dilfridge: in global scope? no
-[15:25:10] <dilfridge> (I mean, for the code within the eclass)
-[15:25:28] <rich0> ulm: agree - how can you glob in global scope - you don't know what $PWD is.
-[15:25:32] <ulm> the proposal is to leave things as is in function scope
-[15:26:06] <dilfridge> ok I'll stop discussing since I'm not really getting much wiser :]
-[15:26:10] <ulm> any unquoted * or [] in global scope qualifies as a bug IMHO
-[15:27:08] <blueness> ulm, then have repoman catch it
-[15:27:39] <rich0> blueness: that is the alternative, but why not just have bash assert it?
-[15:27:52] <rich0> Why try to catch errors if we can prevent them?
-[15:28:33] <dilfridge> ok the failglob just introduces an error exit and does not silently change other behaviour?
-[15:28:38] <rich0> I don't see there being side-effects here, and it is EAPI6-only anyway.
-[15:28:42] <ulm> blueness: I don't see any legitimate use case for globbing in global scope
-[15:28:48] <ulm> dilfridge: yes
-[15:28:54] <rich0> dilfridge: failglob should make the ebuild fail in all circumstances
-[15:29:02] <blueness> ulm, i agree
-[15:29:05] <rich0> whether the glob matches or not
-[15:29:36] <blueness> okay i'm good with this, ulm convinced me.  there is no reason to glob in the global context, so failglob in global
-[15:29:51] <blueness> there *is* a reason to glob in local, so failglob in local functions
-[15:29:52] <rich0> I look at it like an assert
-[15:29:56] <blueness> yeah
-[15:30:04] <blueness> okay i'm good
-[15:30:11] <rich0> Ok, vote?
-[15:30:18] <ulm> yes, please
-[15:30:23] -*- blueness thanks ulm for patiently explaining
-[15:30:42] <rich0> vote: 3a-b (but 3b failglob in global scope only)
-[15:30:50] -*- rich0 yes
-[15:30:55] <dberkholz> still incredibly huge fan of 3a (finally), and 3b is fine too
-[15:31:01] -*- dilfridge yes 3a-b
-[15:31:08] -*- ulm yes for 3a-b
-[15:31:17] -*- blueness yes
-[15:31:21] <rich0> ok, passed :)
-[15:31:31] <rich0> Now we have individuals...
-[15:31:34] <rich0> 1d
-[15:31:48] <rich0> PATCHES support in default src_prepare bug #463692
-[15:31:50] <willikins> rich0: https://bugs.gentoo.org/463692 "[Future EAPI] Provide PATCHES array support in default phase of src_prepare"; Gentoo Hosted Projects, PMS/EAPI; CONF; scarabeus:pms-bugs
-[15:32:18] <rich0> I'm fine with it.  Discussion?
-[15:32:29] <ulm> this depends on 4a
-[15:32:30] <dilfridge> ok let me say that the path-level automagic can lead to annoying bugs
-[15:32:44] <rich0> Do we want to hit 4a first?
-[15:32:48] <dilfridge> yep
-[15:32:53] <ulm> rich0: makes more sense
-[15:32:56] <blueness> rich0, i'm worried about the order that hte patches are done
-[15:33:00] <rich0> ok let's do 4a first. agree
-[15:33:05] <dberkholz> k
-[15:33:12] <ulm> blueness: lexicographic order in C locale
-[15:33:18] <rich0> Patch applying function in package manager bug #463768
-[15:33:20] <willikins> rich0: https://bugs.gentoo.org/463768 "[Future EAPI] Introduce patch applying function"; Gentoo Hosted Projects, PMS/EAPI; CONF; mgorny:pms-bugs
-[15:33:31] <rich0> I put my two cents on the list.
-[15:33:47] <rich0> I suggest defaulting to -p1, but allowing the specification of -p#, but no auto-detection
-[15:33:57] <ulm> rich0: +1
-[15:34:15] <rich0> and directories in lexical order
-[15:34:18] <blueness> yeah auto-detection bit me once
-[15:34:29] <rich0> Basically comment 32
-[15:34:29] <dilfridge> rich0: +1
-[15:34:43] <ulm> rich0: however, if you need anything other than -p1 you'll have to call the function explicitly
-[15:34:57] <blueness> rich0, are you sure aobut the lexi order?  because if it a bash array we can control the oder by the order in which the patches are presetned
-[15:35:00] <ulm> and then you could call epatch instead, as well
-[15:35:16] <dberkholz> i don't particularly like making it more difficult or making more work for devs
-[15:35:24] <dilfridge> blueness: that's just if the array contains a directory name
-[15:35:25] <blueness> it might be annoying to have to rename patches to get the order right
-[15:35:33] <ulm> blueness: lexicographical for patches inside some dir
-[15:35:39] <dberkholz> blueness: lexi order is consistent with epatch bulk patching
-[15:35:49] <rich0> Yeah - just for a directory.
-[15:35:50] <ulm> otherwise, the order they are specified in
-[15:35:57] <blueness> dilfridge, got it
-[15:36:04] <rich0> If epatch took multiple arguments then obviously do them however passed.
-[15:36:09] <rich0> That isn't in the bug though.
-[15:36:25] <rich0> Actually, it says "files" so I guess that means multiple args.
-[15:36:29] <blueness> dilfridge, ulm so a user can force an order by avoiding using a dir
-[15:36:38] <dilfridge> yes, as I see it.
-[15:36:46] <blueness> i can live with that
-[15:36:55] <rich0> blueness: yup, or they could just glob in a dir and manipulate the list before passing or whatever
-[15:37:00] <dilfridge> and all patches in a specified directory need to have the same path depth
-[15:37:07] <rich0> dilfridge: ++
-[15:37:16] <ulm> I would advise against to much bikeshedding at this point
-[15:37:17] <dilfridge> now,
-[15:37:18] <ulm> let's first see how the implemetation goes, and then we can reconsider
-[15:37:21] <rich0> ulm: agree
-[15:37:24] <dilfridge> agreed
-[15:37:36] <rich0> I just want to keep it simple so that this isn't a big production to build
-[15:37:44] <rich0> This isn't the final PMS
-[15:38:01] <rich0> Ok, so then here is my proposal: 
-[15:38:03] <dberkholz> i'm not particularly convinced this should be in pms at all
-[15:38:07] <blueness> (implimentation and design simplicity are inversely proportional)
-[15:38:35] <dberkholz> duplicating something that works pretty well with a less functional version that's harder to change just doesn't seem like a great idea
-[15:38:49] <blueness> its in eutils.eclass no?
-[15:39:05] <ulm> epatch, yes
-[15:39:12] <rich0> To summarise again what has been discussed so far, the patch applying
-[15:39:12] <rich0> function should support the following features:
-[15:39:12] <rich0>   - regular patch files - directories, with patches applied in lexical
-[15:39:12] <rich0>   order of their filenames, only files named *.diff and *.patch - either
-[15:39:12] <rich0>   way a) defaults to -p1 b) allows override to -p#
-[15:39:22] <ulm> but if we want user patches we need it in the package manager
-[15:39:48] <rich0> ugh - ugly
-[15:39:48] <blueness> ulm, we have user patches now via /etc/portage/patches
-[15:40:19] <ulm> blueness: which need eutils to be applied
-[15:41:04] <rich0> I think the goal here is to enable PATCHES support and user-patches.
-[15:41:11] <blueness> ulm, ah ues via user_patch
-[15:41:37] <blueness> hmmm ... so is it good to globally add user_patch??
-[15:41:57] <blueness> s/ues/yes/
-[15:41:58] <rich0> blueness: well, that is also on our agenda.
-[15:42:14] <rich0> If we want to discuss all patch-related items before voting I don't have an issue with it.
-[15:43:19] <rich0> I'm in favor of 4a, 1d, and 4b, so I don't have an issue with 4a.  But, 4a might not make much sense without 1d and 4b.
-[15:43:52] <rich0> And 4b probably involves some bikeshedding.
-[15:43:58] <ulm> rich0: right, so maybe we should vote on 1d and 4b only
-[15:44:12] <ulm> and 4a is implied if one of them is accepted
-[15:44:51] <rich0> Let's move on then.
-[15:44:55] <rich0> 1d
-[15:45:26] <rich0> PATCHES support in default src_prepare
-[15:45:26] <rich0> bug #463692
-[15:45:28] <willikins> rich0: https://bugs.gentoo.org/463692 "[Future EAPI] Provide PATCHES array support in default phase of src_prepare"; Gentoo Hosted Projects, PMS/EAPI; CONF; scarabeus:pms-bugs
-[15:45:36] <dberkholz> i'd prefer to see more things move out into eclasses from the core PM rather than vice versa. so i'm against it.
-[15:45:51] <blueness> i think i'm with dberkholz here
-[15:46:20] <ulm> 1d is in line with the recent trend to specify things via variables
-[15:46:26] <rich0> I actually am looking at it from the standpoint that the more you move into environment the better.
-[15:46:29] <ulm> instead of functional coding
-[15:46:31] <blueness> i like the idea of 4b - user_patches, but not of duplicating eutils.eclass functionality
-[15:46:39] <dilfridge> that doesnt make sense if we want to globally accept user patches
-[15:46:58] <rich0> Look at systemd units vs openrc scripts.
-[15:47:01] -*- rich0 ducks
-[15:47:06] <dberkholz> ulm: yeah, which i also dislike. but PATCHES is so generally accepted that i don't really see it as a change there.
-[15:47:13] <rich0> Tell the PM what to do, not how to do it.
-[15:48:23] <ulm> I've nothing more to say about 1d
-[15:48:43] <rich0> Ok, do we want to discuss further?
-[15:49:00] <rich0> I'm all for "less side-effects" so I'm generally in favor of 1d.
-[15:50:32] <rich0> Ok, I'm not hearing more discussion
-[15:50:35] <rich0> Do we just vote?
-[15:50:40] <dberkholz> sure
-[15:50:49] <rich0> Ok, let's vote for 1d alone
-[15:50:51] -*- rich0 yes
-[15:50:55] -*- ulm 1d abstain
-[15:50:58] <dberkholz> no
-[15:51:02] -*- dilfridge yes
-[15:51:11] -*- blueness no
-[15:51:22] <rich0> Ok, that leaves us 2-2 with one abstain
-[15:51:32] <rich0> ulm, care to tiebreak, or else it is defeated.
-[15:51:51] <ulm> rich0: let it be defeated then
-[15:51:56] <rich0> ok, 1d is out.
-[15:52:08] <rich0> 4b - user patches
-[15:52:22] <rich0> This one might get some bikeshedding
-[15:52:29] <rich0> I'm in favor of it, though there are a few ways it could go
-[15:52:33] <dberkholz> fwiw i've gotta run in 10 minutes, but i'll leave my votes behind.
-[15:52:49] <rich0> Ok, before we discuss
-[15:53:01] <rich0> Do we want to plan on same bat time, same bat channel next week?
-[15:53:19] <ulm> rich0: fine with me
-[15:53:23] <dilfridge> yeah
-[15:53:28] <dberkholz> wfm
-[15:53:42] <rich0> Ok, then let's discuss until 4, and then we can avoid further votes and let this die out after 4b
-[15:53:52] <blueness> i'm okay with jun 17 @ this time
-[15:54:25] <rich0> So, I'm fine with either having ebuilds call euserpatch or whatever in src_prepare(), or adding a new phase function to apply user patches.
-[15:54:51] <rich0> But if we do the latter we need a prepare, userpatch, configure step
-[15:54:54] <dilfridge> in principle I like the concept, but getting it "right" is not easy
-[15:55:12] <rich0> I think that calling euserpatch is the lesser evil, despite what I said earlier about what vs how.
-[15:55:45] <rich0> Or apply_user_patches or whatever
-[15:55:58] <ulm> I'd be opposed against any additional phase functions
-[15:56:10] <ulm> the feature isn't important enough for that
-[15:56:19] <rich0> ulm: I don't like the additional functions either - not my first preference.
-[15:56:29] <rich0> I think this feature actually is important.  It is VERY useful.
-[15:56:30] <dberkholz> i just added an entry to the google calendar
-[15:56:40] <rich0> However, I'm not sure adding multiple phases just to implement it is necessary.
-[15:56:57] <ulm> _if_ we accept it, just add it to default_src_prepare, and have ebuilds/eclasses call it from src_prepare
-[15:57:05] <rich0> ulm: ++
-[15:57:19] <rich0> I think that is the simplest solution, as much as some might complain about the need to call it
-[15:57:43] <ulm> rich0: more will complain about automatic calling that can't be disabled
-[15:58:00] <dberkholz> this still means we're adding a weird custom patch function to the PM, which i dislike.
-[15:58:00] <rich0> I don't patch stuff often, but when I do it is WAY nicer to have user-patches than to hack away at things with the ebuild command.
-[15:58:06] <ulm> e.g. in virtuals you won't want it
-[15:58:20] <rich0> What is "custom" about it?
-[15:58:33] <rich0> ulm: good point
-[15:58:46] <dberkholz> is the PM going to call out to epatch in the eclass?
-[15:58:57] <blueness> dberkholz, i don't get your reasoning, rich0 said it for me "it is WAY nicer to have user-patches than to hack away at things with the ebuild command"
-[15:59:01] <rich0> dberkholz: probably not - we'd need 4a to do it.
-[15:59:05] <dilfridge> well, I definitely would not want to add the full current epatch to the pm, but a simpler variant should be ok, since patching is pretty central to our stuff
-[15:59:09] <dberkholz> and 4a is what i hate
-[15:59:19] <rich0> user patches would be -p1 only
-[15:59:25] <_AxS_> ulm: rich0: if epatch_user's new equiv is added to default src_prepare on its own, what about the case where build systems get patched and need to be regen'ed ?  do we leave that to the end-user to figure out or will this function need smarts in order to either (a) accomodate or (b) warn?
-[15:59:45] <dilfridge> the PATCHES array is what everyone working with kde / cmake loooves
-[15:59:48] <dberkholz> this whole "let's add a worse, less flexible patch function that's harder to change and then keep a more functional duplicate version in the tree" just seems awful
-[16:00:13] <blueness> dberkholz, hmmm ...
-[16:00:21] <blueness> rich0, can we table this one for next week
-[16:00:27] <ulm> _AxS_: there's no way of adding eautoreconf to an ebuild where it's not provided already
-[16:00:28] <rich0> dberkholz: how else would you propose doing user patches, or do we just not do it?
-[16:00:37] <rich0> blueness: we're going to table voting regardless
-[16:00:46] <blueness> rich0, okay, so just discussion
-[16:00:48] <rich0> So we can discuss a bit longer or break as we see fit
-[16:00:52] <ulm> _AxS_: unless you want to inherit autotools everywhere
-[16:00:55] -*- blueness needs time to think
-[16:01:18] <rich0> We're at 4 - so I'll officially call the meeting, to convene next week.  We can continue to chat until we get tired of it, and discuss on lists/etc as necessary before next week.
-[16:01:19] <_AxS_> ulm: true, and i expect logic to determine if configure.ac / any-other-build-system-file-needing-preparation is modified would be overly complicated too, to trigger an ewarn/eerror/etc
-[16:01:29] <rich0> Err, 20:00
-[16:01:32] <dberkholz> rich0: if that's the cost, i don't want to pay it
-[16:01:48] <dberkholz> one option i keep toying with is whether we could move default phase functions out into the tree
-[16:02:01] <ulm> well, there is a reason why this was rejected from EAPI 5 already ;)
-[16:02:16] <dberkholz> but not sure how feasible it is, and obviously it means anyone not based on gentoo-x86 would need a copy
-[16:03:41] <dberkholz> anyway, gotta run.
-[16:03:45] <_AxS_> dberkholz: ?  you mean, revive base.eclass and implement there?
-[16:04:05] <rich0> dberkholz: honestly, in my ideal word you'd be able to express an ebuild without anything other than a variable assignment, or in xml/whatever.  We'd never get that far, but that is the direction I'd prefer.
-[16:04:11] <rich0> More declarative, less imperitive.
-[16:04:32] <rich0> Ok, all who want to keep chatting are welcome to do so - open floor on this.
-[16:04:44] <rich0> To the rest, thanks - we covered a lot!
-[16:04:58] <rich0> I'll take care of log/summary, including subsequent discussion.
-[16:05:33] <dilfridge> Cheers for cheering, err chairing :)
-[16:05:42] <rich0> I might start a thread on the whole eclass vs PMS issue.  That alone is worth some input.
-[16:06:11] <ulm> rich0: ebuilds in xml? I thought we were past that mistake
-[16:06:21] <rich0> ulm: has it been done?
-[16:06:26] <ulm> it was called zynot
-[16:06:42] <ulm> google for it ;)
-[16:07:05] <rich0> I didn't realize they used xml packages.
-[16:07:43] <rich0> I posted ages back (during the whole EAPI extension debate) that I do think we should be able to have a way to get rid of the ebuild==bash thing, but I'm not in any rush to get there.
-[16:08:07] <rich0> CGI for the PM.  :)
-[16:08:41] <rich0> emerge <whatever this webservice sends you>
-[16:09:02] <ulm> that's called an app store ;)
-[16:09:45] <rich0> So, anything else to discuss here?  I think a lot of this comes down to philosophy.  I just see user_patches as incredibly useful and really a potential distinctive feature for a source-based distro.
-[16:10:01] <rich0> If I were selling Gentoo, it would be something I'd want on my features list.
-[16:10:19] <blueness> rich0, what about next years election, is someone on that?
-[16:10:27] <rich0> I can't see floating this on gentoo-user and getting a lot of, "no, I don't care if Gentoo makes it easier for me to patch stuff without forking an ebuild."
-[16:10:40] <rich0> blueness: I'll ping them.  I know they know, but somebody has to do it.
-[16:10:51] <rich0> It is time to start nominations.
-[16:11:02] <blueness> rich0, the user_epatch is more than just users patching
-[16:11:18] <blueness> there are lots of patches for uclibc and musl that are unlikely to get into the tree
-[16:11:25] <rich0> jmbsvicetto: ^^^
-[16:11:36] <blueness> so i put them in /etc/portage/patches during stage builds
-[16:11:51] <blueness> not uclibc anymore which is purely gentoo tree now after some work
-[16:12:11] <rich0> blueness: that makes me wonder if official patchsets controlled by something USE-like might be a later extension of this
-[16:12:30] <blueness> yeah i can see that
-[16:12:40] <rich0> openssh has USE=hpn by default
-[16:12:56] <rich0> Might be better to use USE for enable/disable/etc and something else for patches.
-[16:14:02] <_AxS_> rich0: i agree with you that user_patches is useful, but we need to make it work for all cases for it to continue to be useful.  if the patch touches configure.ac we can't leave users hanging to figure out why their patch didn't work properly, and end up having to overlay the ebuild anyhow...
-[16:14:37] <_AxS_> *OR*, we do have that, and make it very clear that if a patch modifies the build system then it need to result in overlaying.  and e(qa)warn appropriately.
-[16:14:46] <rich0> Good point.
-[16:14:57] <rich0> We need to either not guarantee that you can patch the build system.
-[16:15:13] <rich0> Or we need to specify that ebuild authors always have to reconfigure the build system if appropriate.
-[16:15:24] <rich0> I don't see how we can do that in the default function, since not all is autotools/etc.
-[16:15:32] -*- _AxS_ is leaning to the latter, since a build system patch that adds features will probably need some src_configure additions too
-[16:16:12] <rich0> Maybe we should just rule out build-system changes?
-[16:16:30] <rich0> If I were doing agile I'd say that we'd do that in the next sprint.  :)
-[16:16:50] <rich0> How often do people really want to change the build system?
-[16:16:59] <rich0> I can't really see using user patches for huge patch sets.
-[16:17:17] <rich0> If you're going to fork upstream, just fork it.
-[16:17:39] <_AxS_> rich0: well, most of my patches end up being build system related, but as a dev i guess that's where i tend to look to make changes...
-[16:19:36] <rich0> true, I never really thought of this as a way to test out ebuild fixes/etc.
-[16:19:44] <rich0> But as a dev you can always fix the ebuild to reconfigure/etc.
-[16:20:18] <rich0> I think this feature needs a bit more work to lay out expectations.
-[16:20:46] <rich0> It isn't enough to tell everybody to call the new function.  You have to lay out what they need to accomodate in terms of patch impact.
-[16:21:21] -*- _AxS_ nods ..  we already have epatch_user in place and a lot of packages -have- adopted that.  but to get full coverage....
-[16:22:17] <rich0> The question is whether all ebuilds that call apply_user_patches or whatever re-configure after doing so.
-[16:22:26] <ulm> epatch_user is a good example for a quick hack that has outgrown its purpose
-[16:22:28] <rich0> If the package didn't otherwise need to fix autotools, then it might lack that step.
-[16:22:47] <ulm> it was just a hack, added to eutils without much design
-[16:22:51] <rich0> ulm: agree, but the fact that it is so darn useful makes me want to come up with the real solution
-[16:23:46] <ulm> there cannot be a perfect solution
-[16:24:03] <ulm> some patches inevitably require other changes to the ebuild
-[16:24:10] <rich0> ulm: the story of the project I'm working on when I'm not in council meetings...
-[16:24:33] <ulm> e.g. addition of features will often require additional dependencies
-[16:24:37] <ulm> or USE flags
-[16:26:23] <ulm> brb
-[16:33:17] <rich0> ulm: I need disappear myself.  Let's bikeshed this on-list and see if we can get it to a workable state.  I'd be interested in what features the community wants.  No need to over-do this.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140617-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20140617-summary.txt
deleted file mode 100644
index 864e6461f1..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140617-summary.txt
+++ /dev/null
@@ -1,90 +0,0 @@
-Summary of Gentoo council meeting 17 Jun 2014
-
-
-
-Roll call
-============
-
-Present: blueness, creffett (proxy for williamh), dberkholz, dilfridge, rich0, scarabeus, ulm
-
-
-
-Approve Preliminary EAPI 6 Features
-===================================
-The rest of the EAPI6 were discussed and voted on.  Vote results listed here:
-
-User patches
-The council endorses an eapply_user function in the PM to apply user
-patches in EAPI6.  This will be called by the default src_prepare, and
-must be called once if src_prepare is overrided by either a non-virtual
-ebuild or eclass.
-Aye: blueness, creffett (proxy for williamh), dilfridge, rich0, scarabeus, ulm
-Nay: dberkholz
-Passed
-
-PATCHES support in default src_prepare
-bug #463692
-(This item was re-visted in light of user patches being approved)
-Aye: blueness, creffett (proxy for williamh), dilfridge, rich0, scarabeus, ulm
-Nay: dberkholz
-Passed
-
-Patch applying function in package manager
-bug #463768
-Needed for PATCHES support and user patches
-This would duplicate epatch() from eutils, in simplified form.
-Name "eapply" has been suggested.
-(This item was not voted upon, as it was considered implied by the
-acceptance of the other two patch features.)
-
-EJOBS variable
-bug #273101
-Nay: blueness, dberkholz, rich0, ulm
-Abstain: creffett (proxy for williamh), dilfridge, scarabeus
-Defeated
-
-Source eclasses only once
-bug #422533
-Nay: blueness, creffett (proxy for williamh), dberkholz, dilfridge, rich0, ulm
-Abstain: scarabeus
-Defeated
-
-HDEPEND: host dependencies for cross-compilation
-bug #317337
-Nay: blueness, dilfridge, scarabeus
-Abstain: creffett (proxy for williamh), dberkholz, rich0, ulm
-
-Directory support for package* and use*
-bug #282296
-Not intended for gentoo-x86 tree (at this time), only to be used in overlays
-Aye: blueness, creffett (proxy for williamh), dberkholz, dilfridge, rich0, scarabeus, ulm
-
-
-Max EAPI Count in Tree / Min Time Between EAPI
-==============================================
-See the log for full discussion, but the Council felt that since future
-Councils already need to approve new EAPIs, they can decide at that time
-whether doing so is appropriate.
-
-Should the council set a limit on # of EAPIs?
-Nay: blueness, creffett (proxy for williamh), dberkholz, dilfridge, rich0, scarabeus, ulm
-
-Should the council set a minimum time between EAPIs?
-Nay: blueness, creffett (proxy for williamh), dberkholz, rich0, scarabeus, ulm
-Abstain: dilfridge
-
-
-Semi-official Dev-hosted Services
-=================================
-The Council accepted this provided that the name assignments make it
-clear what is and isn't official. *.dev.gentoo.org and *.labs.gentoo.org
-were given as possible suggestions.
-
-Aye: blueness, dberkholz, dilfridge, rich0, scarabeus, ulm
-Abstain: creffett (proxy for williamh)
-
-
-
-Meeting called and will be continued on 24 Jun 2014 at 19:00 UTC.
-
-Summary submitted by Richard Freeman <rich0@gentoo.org>
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140617.txt b/xml/htdocs/proj/en/council/meeting-logs/20140617.txt
deleted file mode 100644
index 8324301d5d..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140617.txt
+++ /dev/null
@@ -1,371 +0,0 @@
-[15:00:34] <blueness> brb in 1 minute, i need coffee!
-[15:01:23] <rich0> ok.  Let's do roll call in the meantime
-[15:01:47] -*- dilfridge here
-[15:01:52] -*- creffett|irssi here for WilliamH
-[15:02:07] <creffett|irssi> (note that I have to leave in 1hr though)
-[15:02:24] <rich0> I have to leave in an hour as well
-[15:02:37] <rich0> dberkholz, scarabeus, ulm?
-[15:02:41] -*- ulm here
-[15:04:35] <rich0> dberkholz, scarabeus?
-[15:04:40] <rich0> Also, blueness, are you back?
-[15:04:57] <rich0> Let's go ahead and get started, and I'll mark absent as appropriate.
-[15:05:06] <rich0> https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_6_tentative_features
-[15:05:08] <blueness> back
-[15:05:13] <ulm> do we have a quorum?
-[15:05:23] <rich0> We have 5
-[15:05:26] <rich0> That should be fine.
-[15:05:26] <ulm> k
-[15:05:50] <rich0> So, we left off on 4b.
-[15:06:01] <dberkholz> hi, sorry
-[15:06:11] <rich0> I did circulate my thoughts on the -dev list, hopefully most got a chance to read that thread.
-[15:06:17] <rich0> dberkholz: no problem.
-[15:06:18] -*- scarabeus here
-[15:06:21] <creffett|irssi> 4b being user patches?
-[15:06:25] <rich0> Excellent - we're 7/7 then .
-[15:06:27] <rich0> yes.
-[15:06:30] <creffett|irssi> kk
-[15:07:00] <rich0> Last week we were basically divided on the matter of putting patching at all in EAPI vs leaving it in Eclass.
-[15:07:07] <rich0> Do we want to continue discussions on that?
-[15:07:30] <dilfridge> one line from me
-[15:07:30] <rich0> For my part, I don't feel any differently.  If anybody does want to add anything further please do so.
-[15:07:50] <ulm> to repeat what I said in the ML, I'd go for eapply_user in default_src_prepare()
-[15:07:50] <rich0> No need to rehash otherwise.  dilfridge, go ahead...
-[15:08:15] <dilfridge> applying patches is something as fundamental for us as e.g. unpacking the distfiles, so it should probably be treated in a similar way
-[15:08:23] <ulm> and if an ebuild/eclass defines its own src_prepare then it can call the function in an appropriate place
-[15:08:35] <rich0> ulm: that is basically the proposal on the wiki
-[15:08:48] <blueness> we'd just have to make sure we don't double patch
-[15:09:10] <ulm> rich0: sure, I've written that wiki page
-[15:09:12] <rich0> Presumably the PM could catch double-calls, or failures to call, and treat either as an error.
-[15:09:25] <scarabeus> we already do catch doublecalls
-[15:09:30] <scarabeus> even in eclasses
-[15:09:37] <scarabeus> so it should be quite easy
-[15:09:46] <dberkholz> the analogy i imagine here is languages like python. there's a core language definition, which is small, and a standard library + 3rd-party ecosystem (both of which i consider analogous to eclasses) that are imported on-demand
-[15:09:48] <blueness> to be clear, we are just talking about applying patches, not running autoreconf or anything like that, correct?
-[15:09:57] <ulm> blueness: yes
-[15:10:01] <scarabeus> yes just patches
-[15:10:06] <dilfridge> yes. patches only.
-[15:10:21] <dberkholz> in fact in the python case, guido's encouraging fewer things to be pulled into the standard library because that's basically where they go to die (e.g. requests)
-[15:10:32] <rich0> Yes, autoreconf would be up to the ebuild to do, but honestly build system patching seems like a nice-to-have, and not something that we should guarantee to work.
-[15:10:33] <blueness> so if someone wanted to do eautoreconf, they'd have to apply the patches manually?
-[15:11:06] <dilfridge> src_prepare() { default ; eautoreconf }
-[15:11:14] <rich0> blueness: well, we could mandate that all ebuilds eautoreconf or equiv every time just in case a user patch is there, but that seems a bit overkill.
-[15:11:15] <mgorny> small note from me: i think patching is the last 'unique' thing base.eclass does, so adding that to EAPI would be the final nail in its coffin
-[15:11:18] <blueness> i guess we don't have to get into implmenetation details, but we should be clear about the relationship between th two
-[15:11:43] <rich0> I'm indifferent, but I don't think we have to support build system patching.
-[15:11:56] <ulm> rich0: not by default
-[15:12:03] <creffett|irssi> wait, the PMS patch specifies that it returns nonzero if it did something
-[15:12:04] <rich0> Can we safely even do that in the default phase?  Not everything uses autotools.
-[15:12:18] <ulm> rich0: we cannot
-[15:12:21] <dilfridge> no we can't and we should not
-[15:12:23] <blueness> yeah you mean not be default because of couse we have to do build system patching!
-[15:12:32] <creffett|irssi> so it seems perfectly reasonable to me to have autoconf-based ebuilds do something like if eapply_user, then eautoreconf
-[15:12:55] <rich0> creffett|irssi: I'd make that an encouraged practice, but not something part of PMS/repoman.
-[15:13:07] <dilfridge> you mean like eapply_user && eautoreconf ?
-[15:13:11] <rich0> If the ebuild does eautoreconf it should do it after user patching.
-[15:13:12] <creffett|irssi> er
-[15:13:12] <creffett|irssi> yes
-[15:13:13] <creffett|irssi> right
-[15:13:34] <creffett|irssi> rich0: concur, I was just saying that that seems to me like a workable way to handle eautoreconf
-[15:13:37] <blueness> what dilfridge gave above is good -> src_prepare() { default ; eautoreconf }
-[15:14:09] <rich0> blueness: sure, I just wouldn't mandate it.
-[15:14:15] <blueness> correct
-[15:14:18] <rich0> That can be EAPI7.  :)
-[15:14:21] <dilfridge> fine with me
-[15:14:38] <rich0> dberkholz: I'm not ignoring you, btw.  :)  I just think the pros outweigh the cons in this case.
-[15:15:01] <rich0> Anything further?
-[15:15:05] <ulm> we must decide on two questions here: 1. do we want an eapply_user function in the PM, and 2. should it be called in default_src_prepare
-[15:15:26] <dilfridge> and there is a good point in keeping the patch function simple (i.e. no dir level detection), but I think we all agree on that
-[15:15:30] <rich0> How about we vote on doing both, and then take them separately if that is a problem.
-[15:15:38] <rich0> I don't think anybody here favors one but not the other.
-[15:15:47] <dberkholz> rich0: ha. y'all are welcome to your point of view, that's why we have votes. if i'm on the minority side, i'll get up and move on to the next thing.
-[15:15:59] <rich0> :)
-[15:16:12] <ulm> rich0: yeah, maybe 1. without 2. doesn't make much sense
-[15:17:05] <rich0> Ok, then how about this proposal: "The council endorses an eapply_user function in the PM to apply user patches.  This will be called by the default src_prepare, and must be called once if src_prepare is overrided by either an ebuild or eclass."
-[15:17:11] <rich0> Is that reasonable to vote on?
-[15:17:35] <scarabeus> 1) without 2) as some eclass why not
-[15:17:45] <creffett|irssi> *overridden, but otherwise fine
-[15:17:53] <dilfridge> s/^/in EAPI 6/
-[15:17:59] <ulm> rich0: s/must/should/ please
-[15:18:26] <rich0> Should, not must?
-[15:18:29] <ulm> e.g. virtuals need not call it
-[15:18:39] <rich0> I think src_prepare should die if it isn't called sometime.
-[15:18:48] <rich0> Do virtuals override src_prepare?
-[15:19:13] <rich0> I see your point though.
-[15:19:25] <ulm> most don't, and we have to account for that in default_src_prepare
-[15:19:33] <ulm> but it's a detail
-[15:19:36] <rich0> So the default src_prepare will figure out if it is a virtual?
-[15:19:47] <creffett|irssi> I don't see why it matters, there is no use case for patching a virtual anyway
-[15:19:51] <rich0> I think the intent is though that it be mandatory for non-virtuals.
-[15:20:03] <ulm> something like test for empty ${S} I guess
-[15:20:22] <dilfridge> well that just makes no patch apply
-[15:20:22] <blueness> um ... if you force patching in a virtual, and there are no patches to apply, its a moot point
-[15:20:45] <rich0> The council endorses an eapply_user function in the PM to apply user patches in EAPI6.  This will be called by the default src_prepare, and must be called once if src_prepare is overrided by either a non-virtual ebuild or eclass.
-[15:20:59] <blueness> sure
-[15:21:01] <rich0> I think we're getting into detail though.
-[15:21:16] <blueness> yeah i think the non-virtual is overkill, but okay
-[15:21:30] <rich0> I'd probably just call it everywhere and test in the eapply_user function...
-[15:21:38] <rich0> Ok, let's vote then:
-[15:21:39] <rich0> The council endorses an eapply_user function in the PM to apply user patches in EAPI6.  This will be called by the default src_prepare, and must be called once if src_prepare is overrided by either a non-virtual ebuild or eclass.
-[15:21:43] -*- rich0 yes
-[15:21:47] -*- ulm yes
-[15:22:07] -*- dilfridge yes
-[15:22:09] -*- creffett|irssi yes, winging it here since I have no voting instructions
-[15:22:22] <blueness> yes
-[15:22:44] <rich0> dberkholz, scarabeus?
-[15:23:33] <dberkholz> so the council encourages PMs to do a thing that they may or may not do?
-[15:23:45] <dberkholz> i'm confused what endorse is supposed to convey
-[15:24:00] <scarabeus> yes
-[15:24:02] -*- scarabeus yes
-[15:24:05] <rich0> Wording is a bit clumsy - it goes into EAPI6.
-[15:24:11] <rich0> But we're not really approving EAPI6.
-[15:24:24] <rich0> So, final call will be for the next council to approve post-implementation.
-[15:24:36] <dberkholz> no, consistent with my previous opinion
-[15:24:42] <rich0> ok, passes 6-1.
-[15:24:44] <ulm> eapply is implied by eapply_user, so IMHO no need to vote on 4a
-[15:24:52] <rich0> Agree.
-[15:25:00] <rich0> ulm, you also asked to revisit 1d
-[15:25:09] <ulm> yes, please
-[15:25:22] <rich0> Since 1d makes more sense in light of 4a being in.
-[15:25:25] <ulm> I'd like to change my vote on this, now that we have 4a
-[15:25:33] <rich0> Ok, do we need more discussion on 1d:
-[15:25:35] <blueness> ulm, i agree too
-[15:25:45] <rich0> PATCHES support in default src_prepare
-[15:25:45] <rich0> bug #463692
-[15:25:47] <willikins> rich0: https://bugs.gentoo.org/463692 "[Future EAPI] Provide PATCHES array support in default phase of src_prepare"; Gentoo Hosted Projects, PMS/EAPI; CONF; scarabeus:pms-bugs
-[15:26:15] <rich0> We already discussed last week, so mainly I'm concerned if anything has changed, or if those not present last week want to comment.
-[15:26:24] <rich0> If not, let's vote on 1d.
-[15:26:29] <rich0> Going once...
-[15:26:36] <ulm> scarabeus has filed that bug :)
-[15:26:50] <rich0> Ok, let's vote on 1d then - PATCHES support:
-[15:26:51] -*- rich0 yes
-[15:26:56] <blueness> yes
-[15:26:59] -*- ulm yes
-[15:27:05] -*- dilfridge yes
-[15:27:06] -*- creffett|irssi yes
-[15:27:32] <rich0> dberkholz, scarabeus?
-[15:27:52] <blueness> *sigh*
-[15:28:05] <dberkholz> crap, lost my connection.
-[15:28:16] <dberkholz> i'm going to keep voting no on the patches stuff
-[15:28:16] <rich0> did you catch the poposal?
-[15:28:19] <scarabeus> yarp
-[15:28:22] <rich0> dberkholz: np
-[15:28:29] <rich0> ok, passes 6-1 this time.
-[15:28:38] <rich0> We're done with patching!
-[15:28:46] <rich0> 4c is next:
-[15:28:46] <dilfridge> :)
-[15:28:52] <rich0> EJOBS variable
-[15:28:52] <rich0> bug #273101
-[15:28:54] <willikins> rich0: https://bugs.gentoo.org/273101 "Need for a variable to set the number of parallel jobs"; Gentoo Hosted Projects, PMS/EAPI; CONF; flameeyes:pms-bugs
-[15:29:01] <dberkholz> yes
-[15:29:18] <rich0> I put my two cents on the list-  leaning towards no since nobody is really stepping up to sponsor this.
-[15:29:24] <ulm> multiprocessing.eclass has makeopts_jobs() and makeopts_loadavg() functions
-[15:29:29] <rich0> I don't have a problem with it - it just hasn't been active in years.
-[15:29:42] <ulm> no need for another variable IMHO
-[15:30:11] <rich0> I think it isn't a bad idea, but it needs some bikeshedding and I don't want to have something in the EAPI if somebody isn't enthusiastic about it.
-[15:30:12] <ulm> in addition, the feature seems to have lost its champion
-[15:30:15] <rich0> Anybody feel differently?
-[15:30:41] -*- dilfridge is indifferent here
-[15:30:46] <rich0> Going once...
-[15:30:58] <rich0> Ok, let's vote - 4c - EJOBS
-[15:31:01] -*- rich0 no
-[15:31:02] -*- ulm no
-[15:31:05] <blueness> no
-[15:31:06] -*- dilfridge abstain
-[15:31:20] <dberkholz> makeopts_jobs() looks fine and fits my POV on where things should live
-[15:31:22] <dberkholz> so no
-[15:31:35] <rich0> scarabeus, creffett|irssi?
-[15:31:41] <scarabeus> not sure about this one
-[15:31:46] <creffett|irssi> abstain
-[15:31:51] <scarabeus> ok so abstain :)
-[15:32:24] <rich0> ok, defeated 0-4 with 3 abstentions
-[15:32:40] <rich0> 4d - Source eclasses only once - bug #422533
-[15:32:41] <willikins> rich0: https://bugs.gentoo.org/422533 "[Future EAPI] Source eclasses only once"; Gentoo Hosted Projects, PMS/EAPI; CONF; mgorny:pms-bugs
-[15:33:20] <ulm> a working solution is already in place in eclasses
-[15:33:39] <rich0> tend to agree - I think the need for this has largely passed
-[15:33:55] <blueness> yeah  != "recur -_+^+_- spank"
-[15:33:58] <rich0> Nobody on the list seemed to think it is still needed
-[15:34:17] <ulm> blueness: we could bikeshed the variable value :)
-[15:34:18] <blueness> i'm ready to vodte
-[15:34:20] <rich0> Anything else before we bote?
-[15:34:28] <rich0> And when we're done boating, vote?
-[15:34:31] <creffett|irssi> no, go ahead and goat
-[15:34:38] <rich0> ok, vote - 4d:
-[15:34:40] -*- rich0 no
-[15:34:42] -*- ulm no
-[15:34:43] <blueness> no
-[15:34:46] <dberkholz> i snort no
-[15:34:49] -*- dilfridge no
-[15:34:50] -*- creffett|irssi no
-[15:35:04] <rich0> scarabeus?
-[15:35:20] <scarabeus> nop
-[15:35:32] <rich0> ok, defeated 0-6 with one abstention
-[15:35:39] <rich0> next 4e - HDEPEND: host dependencies for cross-compilation
-[15:35:39] <rich0> bug #317337
-[15:35:42] <willikins> rich0: https://bugs.gentoo.org/317337 "[Future EAPI]: HDEPEND for classifying build time dependencies as host or target ones"; Gentoo Hosted Projects, PMS/EAPI; CONF; ambrop7:pms-bugs
-[15:35:46] <dilfridge> sigh
-[15:36:23] <creffett|irssi> I'm just going to go ahead and pre-abstain on this one...
-[15:36:54] <scarabeus> :D
-[15:37:03] <rich0> I don't have a problem with it.
-[15:37:04] -*- scarabeus is not exactly convinced by this proposal
-[15:37:08] <ulm> there is a proof of concept implementation in portage for this one
-[15:37:10] <rich0> It didn't get much list traffic though.
-[15:37:39] <rich0> Low list traffic = low interest...
-[15:37:48] <dilfridge> the distinction makes sense... but the problem is once again that it increases ebuild complexity, and most devs dont care about crosscompilation
-[15:38:01] <ulm> rich0: there's some recent activity in the bug thouhg
-[15:38:04] <ulm> *though
-[15:38:04] <rich0> True
-[15:38:05] <scarabeus> it also demands rewrite of everything
-[15:38:18] <scarabeus> so the dep change should be thought more of and include all possible cases
-[15:38:27] <scarabeus> as in "we are rewriting everything so make it damn count"
-[15:38:29] <rich0> Well, people could still blindly stick stuff in DEPEND, and at least it gives a way to fix things for those who do care about cross-compiling.
-[15:39:15] <rich0> scarabeus: this is the classic partial solution dilema.  Do we make things worse by making them only a little better?
-[15:39:29] <blueness> rich0, correct it would mean you have DEPENDS in there that you don't necessarily need but could
-[15:39:44] -*- ulm points to https://wiki.gentoo.org/wiki/Future_EAPI/New_dependency_types
-[15:39:53] <dilfridge> Ø
-[15:40:50] -*- creffett|irssi thinks that DEPEND changes should be thought through top-down if we're going to do them
-[15:40:51] -*- scarabeus still thinks when we overhaul we should do it properly
-[15:40:53] <scarabeus> not just one thing
-[15:40:54] <creffett|irssi> ^^
-[15:41:00] <ulm> can we just vote? EAPI 6 will be reiterated in any case
-[15:41:09] <creffett|irssi> if we're going to change the deps, let's actually think it through first, not just slap dep types on
-[15:41:18] <rich0> ok, are we fairly settled?
-[15:41:20] <dilfridge> that makes sense
-[15:41:36] <rich0> Ok, vote - 4e - HDEPEND:
-[15:41:39] -*- rich0 abstains
-[15:41:43] -*- ulm abstain
-[15:41:45] -*- dilfridge no
-[15:41:48] -*- blueness no
-[15:42:01] -*- creffett|irssi abstain
-[15:42:12] <rich0> dberkholz, scarabeus?
-[15:42:27] <dberkholz> abstain
-[15:42:52] <scarabeus> no
-[15:42:58] <rich0> Ok, defeated 0-3 with 4 abstentions.
-[15:43:00] <dberkholz> i think the concept is useful but am not convinced by the implementation
-[15:43:15] <scarabeus> no for me in this state simply :)
-[15:43:18] <scarabeus> but the idea is solid
-[15:43:23] <rich0> Last EAPI6 item - 4f - Directory support for package* and use*
-[15:43:23] <rich0> bug #282296
-[15:43:25] <willikins> rich0: https://bugs.gentoo.org/282296 "Allow directories for use.* and package.* entries in profiles"; Gentoo Hosted Projects, PMS/EAPI; CONF; rbu:pms-bugs
-[15:43:26] <creffett|irssi> I don't want to vote no because I'm not opposed to HDEPEND per se, just want it to be part of a bigger thinking-through
-[15:43:39] <rich0> creffett|irssi: ++
-[15:44:34] <scarabeus> isn't this code in there for quite while? ^ :)
-[15:44:47] <ulm> scarabeus: yeah, code exists
-[15:44:57] <rich0> It isn't in PMS, so it can't be dependend on.
-[15:44:59] <ulm> not activated for current EAPIs IIUC
-[15:45:16] <rich0> I think it makes sense.
-[15:45:41] -*- scarabeus is in favor
-[15:45:53] <blueness> i'm ready to vote
-[15:46:02] <rich0> ok, any discussion?
-[15:46:04] <ulm> I would be opposed against such directories in gentoo-x86, but as PM feature it won't harm
-[15:46:05] <rich0> Going once...
-[15:46:21] <rich0> Ok, to clarify we're voting on this going in EAPI6, not into the tree.
-[15:46:31] <rich0> That should be a separate discussion, and nobody is asking for it now.
-[15:46:57] <rich0> Ok, vote - 4f - directory for package* / use* in EAPI6, but not in gentoo-x86 tree:
-[15:47:00] -*- rich0 yes
-[15:47:04] <creffett|irssi> yes
-[15:47:04] -*- dilfridge yes
-[15:47:06] -*- scarabeus yes
-[15:47:14] -*- blueness yes
-[15:47:15] -*- ulm yes
-[15:47:31] <dberkholz> yes
-[15:47:37] <rich0> Ok, passes 7-0
-[15:47:45] <dberkholz> assuming the "but not" means "not today" rather than "definitely excluded"
-[15:47:46] <rich0> Second agenda item then.  :)
-[15:47:50] <ulm> rich0: that's efficient chairing today :)
-[15:47:54] <rich0> dberkholz: ++
-[15:48:07] <rich0> Gotta get through this meeting before our term ends.
-[15:48:10] <dilfridge> dberkholz++
-[15:48:21] <rich0> Max count on EAPI, and min time between EAPIs.
-[15:48:31] -*- creffett|irssi gets ready to start reading the phonebook to stall for time
-[15:48:52] <rich0> I put my 2 cents on the list.  I don't see any value in trying to make a rule the next council is free to ignore.  I think it is a good principle, and we've already started deprecating EAPIs.
-[15:49:01] <rich0> But I intend to vote no for these.
-[15:49:16] <ulm> right, future councils won't be bound by any vote that we take here
-[15:49:16] <rich0> The council approves EAPIs, and can consider the # and time when they do so.
-[15:49:27] <dilfridge> it's not so important and not worth a long discussion, and rich0 is of course right
-[15:49:43] -*- creffett|irssi isn't really a fan, would be interested in getting more project-wide effort to EAPI bump stuff, but don't see a need to cap time or number
-[15:49:44] <rich0> Ok, any other discussion?
-[15:50:00] <creffett|irssi> but that's more a question for my QA hat :)
-[15:50:06] <dberkholz> i don't find it necessary
-[15:50:18] <scarabeus> we could actively encourage the switch from almost dead eapis (1 come to my mind) but no hard deadlines
-[15:50:20] <dberkholz> and i think the min time one is absolutely absurd
-[15:50:32] <dberkholz> are we innovating so fast that we need to slow it down?
-[15:50:53] <creffett|irssi> kill 1, kill 2, move away from 0 on the non-base-system stuff at least
-[15:51:06] <rich0> Ok, vote separately to avoid double-negatives 
-[15:51:25] <rich0> Ok, vote - should the council set a limit on # of EAPIs?
-[15:51:29] -*- rich0 no
-[15:51:32] -*- ulm no
-[15:51:35] <creffett|irssi> no
-[15:51:40] -*- dilfridge abstains
-[15:51:40] -*- blueness no
-[15:51:42] <dberkholz> no
-[15:52:05] <rich0> scarabeus?
-[15:52:10] <scarabeus> no
-[15:52:12] <rich0> defeated 0-6, with one abstention.
-[15:52:19] <scarabeus> :P
-[15:52:22] <rich0> Ok, vote - should the council set a minimum time between EAPIs?
-[15:52:24] -*- ulm no
-[15:52:24] -*- rich0 no
-[15:52:26] <creffett|irssi> no
-[15:52:29] -*- blueness no
-[15:52:30] -*- dilfridge no
-[15:52:32] <dberkholz> no
-[15:52:58] <rich0> scarabeus?
-[15:53:01] <scarabeus> no
-[15:53:06] <rich0> defeated 0-7
-[15:53:10] <scarabeus> damn you type so fast i cant scroll buffer
-[15:53:18] <rich0> Agenda item 3...  :)
-[15:53:26] <rich0> actually, first.
-[15:53:37] <rich0> Agree to re-convene same time next week if we don't finish?
-[15:53:40] <rich0> which seems likely...
-[15:54:05] <rich0> A few of us have hard stops at the hour it seems.
-[15:54:14] <scarabeus> wfm
-[15:54:19] <creffett|irssi> sure, no idea if I'll be back in William's seat though
-[15:54:19] <blueness> i'm overheating!
-[15:54:22] <dilfridge> fine with me
-[15:54:25] <dberkholz> might work.
-[15:54:27] <blueness> 27oC here in buffalo
-[15:54:41] <ulm> not sure if I can make it next tuesday, but if not then I can find a proxy
-[15:54:43] <blueness> creffett|irssi, nice having you though
-[15:54:43] <rich0> Ok, we may or may not get to vote, but at least discuss the semi-official dev services.
-[15:55:05] <creffett|irssi> blueness: thanks
-[15:55:06] <dberkholz> i support it as long as it's in an obvious subdomain, like *.dev.g.o
-[15:55:31] <rich0> We're really just talking endorsement, it needs some bikeshedding.
-[15:55:37] <rich0> I'm with dberkholz
-[15:55:56] <rich0> And that is the proposal anyway.  Infra seemed ok with it as I recall
-[15:56:06] <dberkholz> i definitely do not support if every visitor can't clearly differentiate between an official gentoo-provided service and the box under my desk
-[15:56:07] <ulm> is there enough manpower in infra for such a thing?
-[15:56:08] <rich0> creffett|irssi: you weren't CC'ed on some off-list discussion
-[15:56:19] <creffett|irssi> rich0: I imagine not
-[15:56:25] <rich0> Well, the only thing infra would do is maintain the DNS entry.
-[15:56:38] <dilfridge> I'm fine with *.dev.g.o as suggested by robbat2, could also imagine somthing like *.labs.g.o
-[15:56:45] <rich0> And we'd have rules/guidelines devs would have to follow.
-[15:56:58] <rich0> I like the labs idea, actually.
-[15:57:10] <creffett|irssi> it's like google labs, but gentoo labs
-[15:57:14] <blueness> hmm ... labs ... sounds like physics ;)
-[15:57:16] <dilfridge> :)
-[15:57:30] <rich0> Well, should we try for a record and vote?
-[15:57:40] <rich0> Any more discussion?
-[15:57:48] <blueness> but not these kinds of labs -> https://www.google.com/search?q=labs&client=firefox-a&hs=OvL&rls=org.mozilla:en-US:official&source=lnms&tbm=isch&sa=X&ei=q52gU5WPDebf8AHNh4CgDw&ved=0CAgQ_AUoAQ&biw=1920&bih=894
-[15:57:51] <dberkholz> ready to vote
-[15:57:58] <dilfridge> woof
-[15:58:14] <rich0> Proposal: The council endorses the proposal for Semi-official Dev-hosted Services - details to be worked out on-lists/etc.
-[15:58:16] <rich0> vote:
-[15:58:22] <dberkholz> yes
-[15:58:22] -*- rich0 yes
-[15:58:24] -*- blueness yes
-[15:58:24] -*- creffett|irssi abstain
-[15:58:27] -*- dilfridge yes
-[15:58:32] -*- ulm yes
-[15:58:39] <rich0> scarabeus?
-[15:58:55] <dberkholz> i'll also vote on glep 62 in the last 2 minutes =)
-[15:59:05] <dberkholz> especially if it saves me another meeting
-[15:59:29] <rich0> I can't stay late, so I'm not sure we can do it.  I'm fine with hashing it out on the list and voting in a bug though.
-[15:59:41] <rich0> Or I can vote before we discuss and somebody else can chair.
-[15:59:55] <rich0> scarabeus?  semi-official dev services vote?
-[15:59:59] <dberkholz> i've gotta run in the next 5 min anyhow.
-[16:00:12] <rich0> Ok, we'll close as soon as I get scarabeus's vote.
-[16:00:35] <rich0> Motion passes 5-0 with one abstention and one missing vote otherwise.
-[16:00:54] <scarabeus> yes
-[16:01:06] <rich0> Ok 6-0 with one abstention.
-[16:01:09] <rich0> Thanks :)
-[16:01:13] -*- rich0 bangs the gavel
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140624-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20140624-summary.txt
deleted file mode 100644
index 7c0563c727..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140624-summary.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Summary of Gentoo council meeting 24 Jun 2014
-
-
-Roll call
-============
-
-Present: blueness, dilfridge, rich0, williamh
-Absent: dberkholz, scarabeus, ulm
-
-
-IUSE_RUNTIME / GLEP 62
-======================
-
-See the logs for full discussion.
-
-There will likely be a need for some bikeshedding on the lists as it
-comes time to implement this, as we set guidelines on when this feature
-should be used.
-
-"The council accepts IUSE_RUNTIME for implementation in EAPI6 as
-outlined in GLEP 62.  The actual GLEP will be approved when EAPI6 is
-approved as part of PMS."
-
-Aye: blueness, dilfridge, rich0, williamh
-Passed
-
-
-Bugs assigned to Council
-========================
-
-dberkholz and betelgeuse are reminded to upload their summaries and link
-on the council page.
-
-
-Open floor
-==========
-
-Only item brought up was general celebration that our term is finally
-ended, and those of us who return are looking forward to it!
-
-
-Summary submitted by Richard Freeman <rich0@gentoo.org>
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140624.txt b/xml/htdocs/proj/en/council/meeting-logs/20140624.txt
deleted file mode 100644
index 1f579606f4..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140624.txt
+++ /dev/null
@@ -1,180 +0,0 @@
-[15:04:39] <rich0> roll call :)
-[15:04:48] -*- dilfridge here
-[15:04:56] -*- WilliamH here
-[15:05:00] <rich0> blueness, dberkholz, scarabeus, ulm?
-[15:06:14] <blueness> rich0, png
-[15:06:21] <blueness> sorry almost forgot!
-[15:06:25] <rich0> np :)
-[15:06:32] <rich0> 3rd time might be the charm for finishing our term!
-[15:06:38] <blueness> yep
-[15:06:48] <rich0> Ok, let's get started and hopefully dberkholz, scarabeus, and ulm will catch up.
-[15:06:55] <rich0> GLEP 64
-[15:06:56] <blueness> yep
-[15:06:59] <rich0> Err, GLEP 62.
-[15:07:43] <rich0> Thoughs?
-[15:07:46] <rich0> Thoughts?
-[15:08:00] <rich0> https://wiki.gentoo.org/wiki/GLEP:62
-[15:08:00] -*- WilliamH is looking for the glep
-[15:08:19] <blueness> reading
-[15:08:37] <rich0> mgorny: ping, FYI - your GLEP is under discussion...
-[15:09:21] <rich0> I like the fact that it avoids polluting @world 
-[15:09:46] <dilfridge> I like the whole idea, I just think the detail description of the algorithm is not really making sense under "Reference implementation"
-[15:10:15] <rich0> Well, it obviously isn't an actual implementation - more of a design.
-[15:10:28] <dilfridge> yeah, sure,
-[15:10:34] <rich0> I'd probably have this section updated once an actual implementation is done.
-[15:10:44] <dilfridge> but I think this is more something that should come out of writing the code
-[15:10:47] <dilfridge> exactly
-[15:10:48] <blueness> dilfridge, yeah i don't see that as bad, its an outline of what IUSE_RUNTIME entails
-[15:11:21] <rich0> So, we can approve the GLEP, except that the reference implementation can be updated once actually implemented.  :)
-[15:11:24] <WilliamH> I'm sure this was discussed and I missed it, why is this a glep instead of a feature for a new eapi?
-[15:11:26] <blueness> rich0, i guess the point is if a package installs a perl script, you and you add IUSE_RUNTIME=dev-lang/perl then perl is NOT pulled in?
-[15:11:32] <blueness> err ... not exactly
-[15:11:54] <blueness> but some flag which pulls in perl
-[15:11:56] <rich0> WilliamH: it wasn't discussed.  Probably was just propsoed this way since GLEPs used to be the way these things were done.
-[15:12:21] <dilfridge> ulm had something to say about this
-[15:12:57] <dilfridge> as far as I can remember, his argument originally was "it's 100% backward compatible and could even in theory be added independent of eapi"
-[15:13:04] <WilliamH> blueness: as an example, logrotate could be a use flag aas long as it were in IUSE_RUNTIME.
-[15:13:28] <blueness> this is the point -> enabling or disabling any of the flags must not involve rebuilding the package,
-[15:13:32] <dilfridge> exactly
-[15:13:48] <blueness> okay i get it now, i'm okay with it
-[15:13:56] <rich0> exactly - perl wouldn't be pulled in unless you enabled the perl USE flag.  If you enabled it later then perl would be pulled in, but the package wouldn't rebuild.
-[15:14:14] <blueness> right
-[15:14:17] <rich0> If you disabled it later then perl isn't pulled in, though it won't go away if something else pulls it in, obviously
-[15:14:30] <rich0> Any issues with the actual proposal?
-[15:14:54] <blueness> not really, i also don't see the 'reference implementation' as a problem
-[15:14:56] <rich0> There is the GLEP vs EAPI6 bit - probably does make more sense as part of the EAPI, though I'm not opposed to having the GLEP as well.
-[15:15:30] <dilfridge> the "Reference implementation" section is not a problem, I just would not see it as "close to final", more as a roadmap
-[15:15:47] <WilliamH> Yes this is more of a roadmap.
-[15:16:31] <dilfridge> one suggestion would be, if an implementation in portage is ready in time, consider it for EAPI=6, otherwise postpone for later (this should not hold up the EAPI)
-[15:16:33] <rich0> Do we just want to approve it for EAPI6?
-[15:16:53] <blueness> sure if we approve the gleb
-[15:16:56] <blueness> glep
-[15:17:03] <rich0> dilfridge: makes sense - I'd probably leave that up to the PMS/portage teams or the next council
-[15:17:13] <blueness> unless you think it will hold up eapi=6 and we don't want that
-[15:17:26] -*- WilliamH isn't in favor of retroactively applying it to older eapis either.
-[15:17:42] <rich0> No, I'd just make it work for new EAPIs unless all the PMs chime in that it isn't an issue.
-[15:17:53] <rich0> That's the whole point of PMS.
-[15:17:59] <dilfridge> not retroactively
-[15:18:38] <rich0> Granted, the proposal is basically designed to handle that - older PMs would ignore the IUSE_RUNTIME and just treat it as a use flag.
-[15:18:46] <rich0> So, the dependency would work fine, it would just trigger a rebuild when it changes.
-[15:18:51] <dilfridge> well, it's not an issue in terms of definition or functionality, just in matters of convenience (if a pm does not respect IUSE_RUNTIME people end up with an insane number of rebuilds)
-[15:19:14] <rich0> So, in that sense it could potentially go into EAPI6 even if portage isn't ready.
-[15:19:14] <dilfridge> (assuming that IUSE_RUNTIME is widely accepted)
-[15:19:40] <dilfridge> hmm
-[15:19:44] <rich0> If it gets rid of einfo spam, more power to it!  :)
-[15:20:31] <rich0> Ok, do we just want to include it in EAPI6 then?  We can save appropving the GLEP until the rest of EAPI6 is ready to be approved?
-[15:20:50] <dilfridge> we can add it to the list of planned EAPI6 features, yes
-[15:20:55] <rich0> EAPI6 itself gets its real approval when PMS is submitted to the next council.
-[15:21:26] <rich0> I think any of the items we included in EAPI6 are at the discretion of the PMS team if for whatever reason the PMs can't implement all of them.
-[15:21:34] <WilliamH> We should probably find out from the portage guys a rough idea of whether it will hold up EAPI 6?
-[15:21:38] <rich0> That is why this isn't a final approval.
-[15:22:25] <rich0> WilliamH: I don't see this as a hard commitment to anything.  This is just a process to get rid of EAPI6 items that we don't want so that people don't implement them only to have the next council reject them.
-[15:23:00] <rich0> Granted, I guess they could still do that.  :)
-[15:23:00] <blueness> WilliamH, who are the portage guys these days?
-[15:23:00] <blueness> ie who's the lead?
-[15:23:09] <dilfridge> blueness: dol-sen
-[15:24:03] <rich0> My personal recommendation would be to include, and then let the portage guys reject it later.  Anything not implemented would be dropped from the final EAPI6.
-[15:24:10] <blueness> rich0, let's add it, they can always amend later
-[15:24:17] <rich0> blueness: ++
-[15:24:23] <blueness> <mid-air!>
-[15:24:29] <rich0> Really we're just saying htat it is "approvable"
-[15:25:11] <dilfridge> sounds good
-[15:25:16] -*- dilfridge approves
-[15:25:22] <blueness> call the vote!
-[15:25:33] <rich0> Ok, so how about "The council accepts IUSE_RUNTIME for implementation in EAPI6 as outlined in GLEP 62.  The actual GLEP will be approved when EAPI6 is approved as part of PMS."
-[15:25:37] <rich0> vote!
-[15:25:43] -*- rich0 yes
-[15:25:47] -*- blueness yes
-[15:25:53] -*- dilfridge yes for glep 62 
-[15:25:58] -*- WilliamH yes
-[15:26:11] <rich0> ok, passes 4-0 with 3 absent.
-[15:26:27] <rich0> That brings us to bugs.
-[15:26:33] <dilfridge> yawn
-[15:27:24] <rich0> dberkholz: write your summaries!
-[15:27:54] <rich0> blueness: I think the last one is yours?
-[15:28:02] <blueness> which bug?
-[15:28:12] <WilliamH> I need to ask a quick question about the rules of the glep though.
-[15:28:13] <rich0> bug 477030
-[15:28:14] <willikins> rich0: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council
-[15:28:26] <rich0> WilliamH: sure, we're just about at AOB anyway
-[15:28:38] <blueness> rich0, all my summaries are posted afaik
-[15:28:40] <blueness> let me look
-[15:28:53] <rich0> you're right
-[15:29:02] <WilliamH>  I guess my logrotate example is wrong, because of rule 3.
-[15:29:09] <rich0> Unless you were responsible before you joined the council
-[15:29:17] <rich0> 2013-06-11
-[15:29:20] <rich0> It was the last council
-[15:29:31] <rich0> I just was looking at your bug comment
-[15:29:31] <dilfridge> betelgeuse
-[15:29:50] <rich0> Ok, just say it three times and hopefully it will happen.
-[15:29:56] <blueness> rich0, oh that was me being a newbie ;)
-[15:29:57] <dilfridge> :D
-[15:30:00] <WilliamH> I was thinking we could use this to reinstate use flags for things like logrotate, xinetd, etc.
-[15:30:06] <dilfridge> brb
-[15:30:29] <rich0> WilliamH: what is the problem with that?
-[15:30:43] <rich0> Which rule 3?  flags listed in IUSE_RUNTIME must not be referenced in phase functions, DEPEND, LICENSE or SRC_URI,
-[15:30:43] <rich0> ?
-[15:30:53] <WilliamH> rich0: right.
-[15:31:02] <rich0> why would logrotate be part of those phases?
-[15:31:09] <rich0> It would be an RDEPEND.
-[15:31:21] <WilliamH> if use logrotate; then
-[15:31:29] <WilliamH> # install logrotate config files
-[15:31:29] <rich0> You install the logrotate script unconditionally, and then pull in logrotate conditionally as an RDEPEND.
-[15:31:30] <WilliamH> fi
-[15:32:01] <rich0> This would only manage dependencies, not what actually gets installed.
-[15:32:05] <rich0> That is the key to IUSE_RUNTIME.
-[15:32:11] <WilliamH> rich0: logrotate isn't an rdepend, the package doesn't need it to run.
-[15:32:28] <rich0> You don't use IUSE_RUNTIME with things the package NEEDS to run.
-[15:32:39] <rich0> It is for things that optionally improve the package.
-[15:32:48] <WilliamH> rich0: right, so you can't put logrotate in rdepend.
-[15:32:49] <rich0> I need to dig up some examples.
-[15:33:05] <rich0> WilliamH: why not?  It is a suggested dependency, basically.
-[15:33:13] <floppym> I think it would be a bad idea to add IUSE_RUNTIME="logrotate systemd openrc ..." to every packages.
-[15:33:29] <rich0> Myabe logrotate isn't a great example.
-[15:33:34] -*- WilliamH agrees with floppym
-[15:33:51] <rich0> I forget what the last package I installed was that had about 10 lines of einfo about useful stuff I could optionally install.
-[15:34:07] <floppym> net-misc/netctl is a good example.
-[15:34:53] <rich0> Good one
-[15:35:49] <rich0> systemd has some
-[15:35:56] <rich0> sys-apps/systemd-ui: for GTK+ systemadm UI and gnome-ask-password-agent
-[15:36:05] <rich0> dracut has a laundry list
-[15:36:07] <dilfridge> logrotate is a bad example, since in that case the idea originally was to control installation of a small file
-[15:36:27] <dilfridge> (which is not possible if you dont reinstall on switching useflag)
-[15:36:32] <rich0> in this case it wouldn't be about controlling the file installation, but about pulling in logrotate itself.
-[15:36:36] <dilfridge> yep
-[15:36:50] <rich0> dracut is actually a pretty good example
-[15:37:14] <rich0> http://pastebin.com/4cfwVqSb
-[15:37:27] <WilliamH> In that case, I would not suggest logrotate as a use flag still.
-[15:38:10] -*- WilliamH still doesn't like that we force users to use install_mask if they want to get rid of small files like that.
-[15:38:42] <rich0> Anything else on this?  I'm not hearing that we want to actually revisit the vote...
-[15:38:54] <rich0> I'd definitely like to get to open floor this week!  :)
-[15:39:22] <blueness> i'm good, this was more of a clarification for me
-[15:39:42] <rich0> Sure, and the bonus of this is that it gives everybody more stuff to fight over in six months!
-[15:39:42] <WilliamH> heh we can move on.
-[15:39:57] <rich0> Thus ensuring we or our replacements still have a job to do...
-[15:40:05] <rich0> Ok, open floor then.
-[15:40:09] <rich0> And any other business.
-[15:41:01] -*- rich0 enjoys the crickets...
-[15:41:19] <dilfridge> let me just state that I think this was a productive year :)
-[15:41:36] <blueness> i think so too
-[15:41:44] <blueness> now i have to sit down and write my glep
-[15:41:48] -*- WilliamH agrees
-[15:41:54] <rich0> Yes, I was pretty happy with how things went.  
-[15:42:49] <rich0> Ok, then I guess we'll wrap up.  It has been great serving with all of you!
-[15:42:59] <WilliamH> Same here. :-)
-[15:43:10] <blueness> Handshakes all around!
-[15:43:16] <rich0> Who knows, maybe a few of us will get to repeat the adventure.  The lists are much quieter than they were last election.
-[15:43:18] <dilfridge> Yep, thank you all! same from me!
-[15:43:59] <blueness> well some of us are running again so maybe we'll see one another again
-[15:44:08] <blueness> <mid-air!>
-[15:44:14] <rich0> Ok, then we're officially done barring any emergencies, and anybody who can find me after the meeting is welcome to a free drink.  :)
-[15:44:15] -*- WilliamH is curious how many have accepted their nomminations so far...
-[15:44:16] <blueness> WilliamH, i was going to ask jmbsvicetto that very question
-[15:44:21] <blueness> the business that anyone can nominate did not turn out so bad
-[15:44:31] <blueness> the fact that you *have* to accept stopped the madness
-[15:44:49] <dilfridge> https://www.gentoo.org/proj/en/elections/council/2014/council-201406-nominees.xml
-[15:45:05] <rich0> blueness: yup - I raised the question just so that we didn't get any birthers after somebody gets elected and it is pointed out that no dev nominated them.  :)
-[15:46:25] <rich0> Lots of incumbents this year - we're gluttens for punishment!
-[15:46:30] <rich0> err, gluttons
-[15:46:46] <rich0> Good thing I'm not running on a platform of being an ispell replacement
-[15:48:01] <rich0> Ok, well, we're officially dismissed.  I'll post the logs/summary.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140725-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20140725-summary.txt
deleted file mode 100644
index 29ae7e469a..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140725-summary.txt
+++ /dev/null
@@ -1,72 +0,0 @@
-Summary of Gentoo council meeting 25 July 2014
-
-Agenda
-======
-1. Roll call
-2. Vote for holding meetings every 2nd Tuesday of the month at
-   19:00 UTC
-3. Vote for continuing last council's workflow considering sending
-   call for agenda items (2 weeks in advance), sending the agenda
-   (1 week in advance) and have the meeting focussed, e.g., have major
-   discussions on -project ML prior to the meeting
-4. Appoint chairman for this term's meetings
-5. Open bugs with council involvement
-6. Open floor to council members to introduce themselves to the
-   others, and/or raise issues they would like to deal with
-7. Open floor to community
-
-
-Roll call
-=========
-Present:
-blueness, dberkholz, dilfridge, radhermit, rich0, ulm, williamh
-
-Vote for schedule of meetings
-=============================
-Meetings will be every 2nd Tuesday of the month at 19:00 UTC.
-- Accepted unanimously.
-
-Vote for continuing last council's workflow
-===========================================
-We shall send a call for agenda items two weeks in advance and we
-shall send the agenda one week in advance. We aim to have the meeting
-focussed, e.g., have major discussions on the -project mailing list
-prior to the meeting.
-- Accepted unanimously.
-
-Appoint chairman for this term's meetings
-=========================================
-There was consensus on the following provisionary list:
-   July, August, September:     ulm
-   October, November:           rich0
-   December, January, February: dilfridge
-   March, April:                radhermit
-   May, June:                   blueness
-
-Open bugs with council involvement
-==================================
-- Bug 424647 "archives.gentoo.org: Broken URLs for e.g.
-  gentoo-dev-announce and others" [1]
-  No action by the council, for the time being.
-- Bug 477030 "Missing summary for 20130611 council meeting" [2]
-  No progress.
-- Bug 503382 "Missing summaries for 20131210, 20140114, and 20140225
-  council meetings" [3]
-  Action: dberkholz will commit the missing summaries in August.
-
-Open floor to council members
-=============================
-See full log.
-
-Open floor
-==========
-No issues were raised.
-
-Next meeting date
-=================
-Tuesday, 12 Aug 2014, 19:00 UTC
-
-
-[1] https://bugs.gentoo.org/show_bug.cgi?id=424647
-[2] https://bugs.gentoo.org/show_bug.cgi?id=477030
-[3] https://bugs.gentoo.org/show_bug.cgi?id=503382
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140725.txt b/xml/htdocs/proj/en/council/meeting-logs/20140725.txt
deleted file mode 100644
index 1cd3ef9cae..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140725.txt
+++ /dev/null
@@ -1,228 +0,0 @@
-<blueness> time!                                                        [20:58]
-<rich0> I can hardly wait!                                              [20:59]
-<blueness> Fri Jul 25 19:00:26 UTC 2014
-<ulm> who wants the chair?                                              [21:00]
-<ulm> otherwise, I can do it, since I've sent the announcement
-<rich0> I'd like to nominate blueness, dberkholz, dilfridge, radhermit, ulm,
-        and WilliamH for the chair.
-<radhermit> you chairing sounds fine to me
-<blueness> where's the agenda?                                          [21:01]
-<ulm> http://article.gmane.org/gmane.linux.gentoo.project/3912
-<ulm> in the topic too
-*** dberkholz|mob (~dberkholz@gentoo/developer/dberkholz) has joined channel
-    #gentoo-council
-*** ChanServ (ChanServ@services.) has changed mode for #gentoo-council to +o
-    dberkholz|mob
-<ulm> nobody?                                                           [21:02]
-* ulm takes it then
-<helium-3> Oh yeah
-<helium-3> Here
-<ulm> roll call
-<dberkholz|mob> Hi
-* rich0 is here
-<radhermit> I'm here
-<ulm> WilliamH?
-<blueness> here                                                         [21:03]
-<ulm> does anyone have williamh's phone number?
-<blueness> nope sorry                                                   [21:04]
-<blueness> i probably should get it because i'm in the US
-<creffett|irssi> ulm: rich0 has it, if memory serves
-<rich0> hang on                                                         [21:05]
-<blueness> brb in 2 minutes, i must run to the washroom
-<rich0> we actually exchanged numbers last term.  Probably a good idea to
-        repeat that
-<rich0> I sent him a text                                               [21:06]
-<ulm> rich0: thanks
-<ulm> anyway, let's start
-<ulm> Vote for holding meetings every 2nd Tuesday of the month at 1900 UTC
-<ulm> anyone wants to discuss this?
-* WilliamH is here                                                      [21:07]
-<WilliamH> sorry folks
-<rich0> I'm fine with that time as-is.
-<ulm> good, we're complete then
-<ulm> so let's vote
-* WilliamH is fine with that time
-<ulm> motion is "hold meetings every 2nd Tuesday of the month at 19:00 UTC"
-* ulm yes                                                               [21:08]
-* radhermit yes
-* WilliamH yes
-* dilfridge yes
-<dberkholz|mob> Yes
-<dilfridge> now really here, was still running home with a big bag from
-            McDo...
-<blueness> yes
-* rich0 yes
-<ulm> unanimous
-<ulm> next topic                                                        [21:09]
-<ulm> continue last council's workflow
-<ulm> i.e. call for agenda 2 weeks in advance
-<ulm> agenda 1 week in advance
-<ulm> discussions in -project ML prior to meeting
-<blueness> i thought that worked very well                              [21:10]
-* WilliamH agrees
-* dilfridge agrees
-<radhermit> sounds fine
-<dberkholz|mob> wfm
-* ulm agrees too
-<rich0> fine here
-<blueness> yes
-<ulm> k
-<ulm> I take this as unanimous                                          [21:11]
-<radhermit> as the token new guy, where are agenda items tracked? informally
-            on the lists?
-<ulm> it used to be on the lists
-<ulm> and then of course collected in the agenda that is sent out
-<blueness> radhermit, i would create a text file which i put them up and then
-           mention to people to look there to make sure i was correclty
-           representing stuff
-<radhermit> got it, thanks                                              [21:12]
-<blueness> then i would mail it out
-<ulm> next topic?
-<ulm> appoint chairs for this council's term
-<ulm> we used to do two or three in a row                               [21:13]
-<blueness> i'd like to do jun and july if possible
-* dilfridge volunteers dec jan feb
-* ulm volunteers for august and september
-<rich0> I can do oct nov
-<ulm> blueness: there won't be july 2015 I think                        [21:14]
-<blueness> okay then i'll do august or may
-* radhermit can do march/apr
-<blueness> i'd like to do them when i'm not teaching
-<rich0> I'm flexible in any case - just give me whatever two months that are
-        open :)
-<ulm> so we have
-<rich0> Those with preferences can get them first
-<ulm> august: ulm / blueness
-<ulm> september: ulm                                                    [21:15]
-<ulm> oct: rich0
-<ulm> nov: rich0
-<ulm> dec: dilfridge
-<ulm> jan: dilfridge
-<ulm> feb: dilfridge
-<dberkholz|mob> June? Looks open
-<ulm> mar: radhermit
-<ulm> apr: radhermit
-<ulm> may: blueness                                                     [21:16]
-<ulm> june?
-<dberkholz|mob> Let blueness grab it too
-<ulm> blueness: can you take may and june?
-<blueness> i orginally suggeseted jun
-<blueness> ulm, yes may and jun is fin
-<blueness> so its july we don't have a meeting?
-<ulm> blueness: I take august?                                          [21:17]
-<blueness> because of elections?
-<ulm> blueness: july 2015 would be next term I think
-<ulm> as it is for today
-<WilliamH> Yes
-<blueness> ah okay
-<ulm> anything else for this topic?                                     [21:18]
-<ulm> next: open bugs
-<dilfridge> heh                                                         [21:19]
-<blueness> are there any?
-<ulm> bug 424647
-<willikins> ulm: https://bugs.gentoo.org/424647 "archives.gentoo.org: Broken
-            URLs for e.g. gentoo-dev-announce and others"; Gentoo
-            Infrastructure, Other; CONF; darkside:infra-bugs
-<ulm> not much we can do there
-<ulm> anyone wants to comment on this one?                              [21:20]
-<ulm> seems not
-<ulm> bug 477030
-<willikins> https://bugs.gentoo.org/477030 "Missing summary for 20130611
-            council meeting"; Doc Other, Project-specific documentation; CONF;
-            ulm:council
-<ulm> also no progress there                                            [21:21]
-<ulm> bug 503382
-<willikins> https://bugs.gentoo.org/503382 "Missing summaries for 20131210,
-            20140114, and 20140225 council meetings"; Doc Other,
-            Project-specific documentation; CONF; ulm:council
-* dberkholz|mob coughs
-<ulm> dberkholz: this one is for you :/
-<ulm> any ETA?
-<dberkholz|mob> I have 2 done, need to read through the irc log for the third
-                                                                        [21:22]
-<dberkholz|mob> Got 3 weeks vacation in August so probably then
-<ulm> can you commit the two that are finished?
-<dberkholz|mob> Sure                                                    [21:23]
-<ulm> k
-<ulm> any bugs that I've missed?
-<ulm> next: open floor to council members                               [21:24]
-<blueness> one point
-<blueness> we should have a file where we keep our phone numbers
-<blueness> in secret somewhere
-<ulm> would a secret bug do?
-<blueness> i'm afraid i'm pretty busy this year and may need a "gentle"
-           reminder
-<WilliamH> blueness: I think we have to keep those individually...
-<blueness> ulm, yes perfect                                             [21:25]
-<blueness> WilliamH, you think?
-<WilliamH> Hmm, a bug might work... but can we restrict it to council members
-           only?
-<dilfridge> file, gpg-enc better
-<WilliamH> dilfridge: probably so.
-<WilliamH> Really though I think it should be up to us individually to keep
-           something like that...                                       [21:26]
-<ulm> dilfridge: can you take care of the file?
-<dilfridge> yes
-<ulm> good
-<blueness> WilliamH, even an encrypted email to all of us
-<blueness> then i can program them into my phone
-<blueness> i just know we're going to need to call one another occasioally
-                                                                        [21:27]
-<ulm> any other items you want to raise?
-<ulm> or introduce yourself?                                            [21:28]
-<blueness> blueness = Anthony Basile = buffalo NY USA
-<blueness> prof by day, gentoo dev by night
-<WilliamH> I'm William Hubbs, and I"m in Irving TX. Mostly I'm a gentoo dev
-           these days.                                                  [21:29]
-<WilliamH> I am the primary maintainer for OpenRC, and a member of base-system
-           and accessibility.                                           [21:30]
-<WilliamH> and the accessibility lead.
-<dilfridge> dilfridge = helium-3 = Andreas Hüttel, Regensburg, Germany  [21:31]
-<dilfridge> physics researcher by day and night, gentoo dev in between :)
-<dilfridge> kde (not so much anymore), perl, office, printing, various things
-<rich0> rich0 = Rich Freeman, Souderton PA (just outside Phladelphia)   [21:32]
-<rich0> When not posting excessively on the lists I'm a Business Analyst by
-        day, and maintain misc packages by night
-<ulm> ulm = Ulrich Müller, Mainz, Rhineland-Palatinate, Germany         [21:33]
-<ulm> physicist working at a university
-<ulm> maintaining Emacs packages and eselect. Member of QA, PMS, and licenses
-      teams.
-<radhermit> radhermit = Tim Harder -> moving near Boston MA USA soonish to
-            work on embedded hardware and Linux support for ADI
-<blueness> i <3 embedded                                                [21:34]
-<radhermit> maintain too much stuff and recently poking at
-            pkgcore/snakeoil/etc
-<blueness> three physicists ... my ph.d. is in physics
-<rich0> Does passing p-chem count?                                      [21:35]
-<dberkholz|mob> I did biophysics. Which is like physics but not at all
-<dberkholz|mob> Now I do research about trends in tech.                 [21:36]
-<ulm> are we done with this topic?                                      [21:37]
-<dilfridge> yeth, I think
-<ulm> open floor to community
-<blueness> rich0, dberkholz sorry, we are purists!                      [21:38]
-<dilfridge> :)
-<ulm> hehe
-<blueness> dilfridge, is closest with He-3
-<dberkholz|mob> Have you seen that xkcd
-<blueness> i feel a xkcd comic coming on
-<blueness> lol!
-<blueness> yes i was just thinking about that!                          [21:39]
-<dilfridge> http://xkcd.com/435/
-<blueness> yep                                                          [21:40]
-<blueness> ulm, what sort of physics do you do?
-<ulm> blueness: hadron and nuclear physics
-<blueness> experimental or theory?
-* radhermit was/is a math guy, just didn't want a job in that area :P
-<ulm> experimental                                                      [21:41]
-<blueness> radhermit, don't math people just wind up coding?
-<radhermit> lots of them
-<dberkholz|mob> Looks like we're good on the meeting. Happy to keep chatting
-                but why don't we close
-<ulm> yeah, I don't see any open floor topics from the community        [21:42]
-<ulm> next meeting will be August 12th
-<ulm> and I'll chair again
-<ulm> this meeting is closed
-*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
-    "Next meeting: Tuesday, 12 Aug 2014 19:00 UTC |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 |
-    http://wiki.gentoo.org/wiki/Project:Council"                        [21:43]
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140812-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20140812-summary.txt
deleted file mode 100644
index 3678e10c3c..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140812-summary.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-Summary of Gentoo council meeting 12 August 2014
-
-Agenda
-======
-1. Roll call (5 minutes)
-2. Handling of bash-completion [1] (10 minutes)
-3. Phase functions in eclasses [2] (5 minutes)
-4. Games team policies [3] (15 minutes)
-5. Dynamic dependencies in Portage [4] (10 minutes)
-6. Additional features for EAPI 6 [5] (10 minutes)
-7. Open bugs with council involvement (5 minutes)
-   - Bug 424647 - archives.gentoo.org: Broken URLs for e.g.
-     gentoo-dev-announce and others [6]
-   - Bug 477030 - Missing summary for 20130611 council meeting [7]
-   - Bug 503382 - Missing summaries for 20131210, 20140114, and
-     20140225 council meetings [8]
-8. Open floor (10 minutes)
-
-
-Roll call
-=========
-Present:
-blueness, dberkholz, scarabeus (proxy for dilfridge), radhermit,
-rich0, ulm, williamh
-
-Handling of bash-completion
-===========================
-After a short discussion of the topic, a majority of council members
-agreed that it is up to the shell-tools team to resolve the issue.
-dberkholz recommends that the eselect module should be kept, with
-all completions enabled by default but allowing opt-out by users.
-
-Phase functions in eclasses
-===========================
-The council voted unanimously that more discussion of this topic in
-the gentoo-dev mailing list will be needed.
-
-The question was then raised if we should move away from phase
-functions in eclasses altogether. Council members expressed different
-opinions on this. No vote was taken.
-
-Games team policies
-===================
-The discussion focussed upon two issues, namely that the games team
-allegedly tries to enforce policies on packages that they are not
-maintaining, and that they have not responded to some requests for
-joining their team.
-
-The following decisions were taken:
-
-- Motion: "Every developer is allowed to commit and maintain games
-  ebuilds, without the need to ask for permission or review from the
-  games team. The games team does not have authority to override
-  maintainer decisions on packages they don't maintain."
-  Accepted unanimously.
-  Note: This should be understood as clarification of existing policy.
-
-- There is consensus amongst council members that specific policies
-  (e.g., games group, /usr/games hierarchy, and games.eclass) should
-  be settled by the QA team.
-
-- Motion: "The council encourages the games team to accept join
-  requests and elect a lead. In the event they don't elect a lead
-  within 6 weeks, we will consider the team as dysfunctional and thus
-  disband it."
-  Accepted with 6 yes votes and 1 abstention.
-
-- Motion: "The council appoints radhermit as the interim lead of games
-  until the elections are held."
-  Accepted with 4 yes votes and 3 abstentions.
-
-At this point the meeting was adjourned. The council will continue
-with the remaining topics in two weeks.
-
-Next meeting date
-=================
-Tuesday, 26 Aug 2014, 19:00 UTC
-
-
-[1] http://thread.gmane.org/gmane.linux.gentoo.project/3916
-[2] http://thread.gmane.org/gmane.linux.gentoo.project/3918
-[3] http://thread.gmane.org/gmane.linux.gentoo.project/3919
-[4] http://thread.gmane.org/gmane.linux.gentoo.project/3943
-[5] http://thread.gmane.org/gmane.linux.gentoo.project/4002
-[6] https://bugs.gentoo.org/424647
-[7] https://bugs.gentoo.org/477030
-[8] https://bugs.gentoo.org/503382
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140812.txt b/xml/htdocs/proj/en/council/meeting-logs/20140812.txt
deleted file mode 100644
index 3053f6b4fc..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140812.txt
+++ /dev/null
@@ -1,716 +0,0 @@
-<ulm> 19:00 UTC, so let's start                                         [21:00]
-<scarabeus> so guys, did you thought you get rid of me right? :P
-<ulm> roll call
-<dberkholz> hi
-<ulm> blueness: radhermit: rich0: WilliamH:
-<blueness> ulm, yeah lets start
-<radhermit> here
-<blueness> here
-<ulm> scarabeus is proxying dilfridge
-* WilliamH here
-<scarabeus> yep                                                         [21:01]
-* rich0 here
-<ulm> topic: handling of bash-completion
-<ulm> btw, agenda is here:
-      http://article.gmane.org/gmane.linux.gentoo.project/4005          [21:02]
-<ulm> discussion for bashcomp topic is here:
-      http://thread.gmane.org/gmane.linux.gentoo.project/3916
-<ulm> radhermit: you're member of shell-tools?
-<ulm> so do you want to comment?
-<radhermit> member of shell tools, but mostly use zsh :P                [21:03]
-<ulm> heh
-<radhermit> from what I understand, isn't it mostly waiting for someone to
-            step up and do the remaining work (docs, etc)?
-<WilliamH> That was my impression too                                   [21:04]
-<ulm> basically, the conversion to the new scheme was started but got stuck
-* WilliamH thinks the new scheme should follow upstream unless they have a
-  reason not to
-<ulm> and seems there are some issues that need fixing
-<WilliamH> But yes, I think it just got stuck somewhere                 [21:05]
-<ulm> question is if there should be any council action at this point?
-<radhermit> I don't think there is much we can do
-<scarabeus> well it is up to them to sort out, we should prolly match upstream
-            but it simply needs to be finished
-<ulm> we could encourage the team to either finish the transition, or to
-      revert
-<rich0> I think this just needs a champion willing to see it through.  If they
-        get flak we can help with that.
-<rich0> I see no issues with changing things - though there are a few proposed
-        solutions.                                                      [21:06]
-<blueness> i'm not sure what we are being asked to do then?
-<WilliamH> blueness: same here.
-<ulm> "would like to ask for action about how to finally handle
-      bash-completion"
-<rich0> Actually, I thought that just having everything install in the
-        upstream location and using INSTALL_MASK to remove files we don't want
-        made a lot of sense.
-<rich0> The other option IMHO is to install in the upstream location, and then
-        just point bash someplace else using a symlink-like method like
-        eselect uses now.                                               [21:07]
-<ulm> I dislike abusing INSTALL_MASK
-<blueness> agreed
-<rich0> Do people really need to pick/choose completion rules?
-<blueness> INSTALL_MASK is for exceptional things
-<dberkholz> yeah i'm not sure we should make the eselect module go away even
-            with dynamic loading
-<blueness> there's lots and its annoying to pick and choose
-<blueness> dberkholz, how about on by default                           [21:08]
-<dberkholz> but perhaps change the rule to enable by default
-<mgorny> eselect may generate script sourced by bashrc that would disable
-         completions via 'complete -r'
-<dberkholz> +1 blueness
-<ulm> do we agree that it is for the team to sort things out?
-<blueness> ulm, yes
-* WilliamH agrees
-<rich0> yup
-* ulm yes
-<ulm> ok, that's the majority already
-<WilliamH> Someone on the team should move it forward though.           [21:09]
-<ulm> if there are difficulties they can come back to the council
-<WilliamH> I'm not sure that we can do anything specific about that at this
-           point, just commenting for the record.
-<blueness> ulm, what do you mean move it forward?                       [21:10]
-<ulm> more comments on this topic?
-<blueness> oh oh nevernind
-<dberkholz> i would recommend that the team consider keeping the eselect
-            module to address user concerns but enable modules by default and
-            allow disabling
-<dberkholz> should make the dynamic stuff work automagically without removing
-            desired flexibility
-<ulm> dberkholz: o.k., noted for the summary
-<ulm> next topic: phase functions in eclasses                           [21:11]
-<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/3918
-<ulm> look like there was no discussion of this in the mailing lists
-<blueness> ulm, i didn't fully understand the issue is there someone that can
-           speak to it                                                  [21:12]
-<ulm> details are in bug 516014
-<willikins> ulm: https://bugs.gentoo.org/516014 "[Future EAPI] call eclass
-            phase functions from all eclasses by default"; Gentoo Hosted
-            Projects, PMS/EAPI; CONF; chutzpah:pms-bugs
-<dberkholz> i don't understand how concatenating phase functions could ever
-            work.
-<scarabeus> what I got from dilfridge and what I agree is that it is quite
-            intrusive for eapi6 ; and the idea from bug 516014c7 wont work i
-            think
-<willikins> scarabeus: https://bugs.gentoo.org/516014 "[Future EAPI] call
-            eclass phase functions from all eclasses by default"; Gentoo
-            Hosted Projects, PMS/EAPI; CONF; chutzpah:pms-bugs
-<dberkholz> running unpack and patch 5 times in a row?
-<WilliamH> I would rather go the other way to be honest -- turn off
-           export_functions and require the ebuild phase functions to run the
-           eclass phase functions.                                      [21:13]
-<rich0> I have to agree with ciaran here - better to just do utilitiy
-        functions
-<rich0> WilliamH: ++
-<dberkholz> but i could see a use case for repoman warning on non-explicit
-            calls with multiple fulfillers
-<ulm> I suggest that we push this back to the -dev ML for discussion
-<ulm> before we take any action on it
-<rich0> I mean, ebuilds that contain no content are amusing, but...
-<radhermit> yeah, I don't think it got much discussion on the lists yet
-                                                                        [21:14]
-<ulm> radhermit: none at all, it seems
-<WilliamH> What are the rest of your thoughts about going the other direction?
-<blueness> why do we need phase functions?  can we just call ordinary
-           functions from eclasses and get the same results?
-<WilliamH> e.g. no more export_functions?
-<dberkholz> blueness: why do we need default functions at all, even
-            eapi-provided ones?
-<dberkholz> because it makes life easier
-<rich0> I'd be interested in whether some projects would be overly burdened by
-        having to call the eclass functions, but it seems like a good idea
-                                                                        [21:15]
-<ulm> WilliamH: for my packages I'd really suffer
-<blueness> dberkholz, it doesn't though
-<WilliamH> ulm: how so?
-<ulm> many of them define no phase functions at all
-<scarabeus> you guys realize it will blob quite lot all the ebuilds right :)
-<blueness> scarabeus, yeah i can think of a few
-<WilliamH> ulm: imo all ebuilds should have phase functions.
-<rich0> The EAPI functions are really minimalistic though, and if overridden
-        they go away.
-* ulm thinks that the present system just works fine
-<dberkholz> i think the present system could use at a minimum warnings from
-            repoman about multiple definitions                          [21:16]
-<WilliamH> There is too much ambiguity wrt which phase functions are  actually
-           run
-<WilliamH> in the current system
-<scarabeus> i think there can be pitfails but it could be solved by better
-            debuger showing what was actually done in each phase well for the
-            dev :)
-<rich0> A problem is that when everybody writes fancy eclasses that override
-        phase functions, it is harder to use them in combination.
-* WilliamH agrees with rich0
-<rich0> If they all just exported functions, then the ebuild could string them
-        together as makes sense.
-<dberkholz> should PMs be more verbose about exactly which function they're
-            running from where?
-<scarabeus> it would certainly made the debugging issues moot           [21:17]
-<scarabeus> as you would see wtf happened and investigate
-<WilliamH> We have way too many eclasses that override phase functions imo
-<ulm> dberkholz: there's debug-print-function already
-<ulm> only needs to be enabled
-<rich0> Unix principle - do one thing well.                             [21:18]
-<rich0> Functions should be the same way
-<scarabeus> yea but people seem not to see it ;)
-<dberkholz> ulm: and also codified in every eclass etc. seems like not a great
-            way to guarantee it works in the desired fashion
-<ulm> o.k., any concrete motion for this topic?
-<dberkholz> i kind of want a set +x but only on the function level.
-<rich0> I think it does need a bit more discussion.
-<radhermit> more discussion required?
-<radhermit> right
-<rich0> But I'm a proponent of moving away from phase functions in eclass
-                                                                        [21:19]
-<ulm> so, vote for "more discussion required"
-* rich0 agrees
-* ulm yes
-<blueness> yes
-<radhermit> yep
-* WilliamH yes
-* scarabeus yec
-<scarabeus> *yes
-<ulm> dberkholz?
-<blueness> one thing though, is there a consensus that we want to recommend
-           moving away from phase functions in eclasses?                [21:20]
-* WilliamH waould recommend that
-<rich0> blueness: I don't think so, but let's just take that to the list
-<blueness> and should we issue a statement?
-<blueness> k
-<radhermit> is there an example eclass that doesn't override phase functions
-            much right now?
-<rich0> We can all issue opinions there...
-<radhermit> because from ones I've worked with, they override things all over
-            the place
-<WilliamH> rich0: eutils.eclass
-<ulm> blueness: I'd be opposed
-<blueness> radhermit, pax-utils.eclass doesn't                          [21:21]
-<WilliamH> radhermit: ^^
-<dberkholz> ulm: yeah sure
-<blueness> however something like toolchains.eclass is all phase funcs
-<dberkholz> blueness: not from me or ulm
-<rich0> systemd.eclass doesn't.
-<rich0> Many do not.
-<blueness> its a real mix
-<dberkholz> just like eclasses themselves                               [21:22]
-<ulm> that's because we don't distinguish between eclasses and "elibs"
-<WilliamH> The fix for an ebuild if we stopped overriding isn't a big deal.
-<dberkholz> some provide utilities that are of widespread use, others are
-            intended as archetypes for an entire group of packages
-<WilliamH> just write phase functions that call the ones you need
-<ulm> dberkholz: exactly
-<dberkholz> we shouldn't necessarily want to only have one of those two things
-<ulm> can we move on please?                                            [21:23]
-<ulm> next topic: games team policies
-<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/3919
-<ulm> mgorny: you want to say something?
-* WilliamH does after mgorny
-* scarabeus also has somehting ;)                                       [21:24]
-<ulm> well, go ahead
-<mgorny> just short thing
-<mgorny> i believe that games team doesn't have right to enforce the policies
-         they try to
-<mgorny> i'm not sure what's the best thing to do here                  [21:25]
-<mgorny> but i think doing nothing will result only in games progress being
-         quite stalled
-<mgorny> and more contributors resigning
-<mgorny> so i'd like the Council at least to confirm that games team has no
-         right to decide over everything being a game                   [21:26]
-* mgorny ended
-<ulm> they certainly don't have exclusive jurisdiction over games-* categories
-<ulm> so I don't see why they should care about games ebuilds added by other
-      devs
-<scarabeus> to summarize what me and dilfridge thinks (I have some notes from
-            him :P)
-<scarabeus> * games team should never touch package they are not maintaining
-<scarabeus> * games team are not mandatory to be on game packages
-<scarabeus> * the game group is quite moot and rather cause issues (kill it
-            maybe)
-<scarabeus> * there was no public activity from the team actively on the issue
-            much (or i didn't notice)
-<scarabeus> * game team as is should have no power to enforce such policies
-            unless they try to push them over with QA
-<blueness> mgorny, where did they say that publicly and *who* said that
-<dberkholz> yeah, as long as you aren't adding games herd as primary or backup
-            maintainers, i don't see any problem doing whatever         [21:27]
-<dberkholz> i agree with scarabeus re QA involvement being needed to dictate
-            games policy as a whole
-<WilliamH> Here is my thing.
-<WilliamH> I understand that the games team is passively not accepting new
-           members right?                                               [21:28]
-<mgorny> blueness: i heard that on their channel, and you can see that from
-         their activity
-<scarabeus> yes
-<mgorny> they kinda avoid responding in public
-<WilliamH> And iirc we have an offer from calchan to work on games-related
-           things in the tree right?
-<mgorny> WilliamH: yes, they don't reply to join requests
-<rich0> If we just let them do their own thing then that isn't an issue.  They
-        just can't touch ebuilds unless maintainers add them to the herd.
-<scarabeus> what if there will be games2 which gradualy try to take over?
-                                                                        [21:29]
-* WilliamH motions for disbanding the team on the grounds that they aren't
-  accepting new members
-<mgorny> what about existing game ebuilds? i.e. ebuilds which were added long
-         ago, have <herd>games</herd> and see no action for a long time?
-<blueness> yeah i'm not so sure about a games2
-<rich0> mgorny: if somebody wants to actively maintain a package which isn't
-        otherwise actively maintained, I don't see why they can't remove the
-        herd if they don't want it.
-<dberkholz> WilliamH: i don't see that as a valid reason as long as the
-            existing team is active and competition is allowed          [21:30]
-<rich0> I'm not sure why anybody would bother with a games2.
-<rich0> But, in theory competition is allowed
-<radhermit> imo, it seems like people are waiting for the official games lead
-            to say things/accept new members and the lead probably moved on a
-            long time ago
-<scarabeus> rich0: if they CAN'T realisticaly join games1 :)
-<rich0> This isn't QA we're talking about.
-<ulm> radhermit: so they should elect a new lead
-<scarabeus> come on I tried to join games team, did you EVER see me on it, I
-            even gave them gamerlay with contributors they happily ignored
-                                                                        [21:31]
-<ulm> GLEP 39 requires one election per year
-<dberkholz> i think most of the games group concerns are likely addressed by
-            the sound and audio groups. i.e. direct access to hardware
-<scarabeus> ulm: that is mostly ingored
-<radhermit> as a games herd member, I don't care who the leader is and if
-            people want to join, feel free to join
-<dberkholz> err, video/audio
-<bernalex> quick note: I tried sporadically to work with them & help them for
-           5 years as a non-dev.
-<ulm> scarabeus: it's fine if it's ignored as long as things work
-<ulm> scarabeus: in the present case it doesn't                         [21:32]
-<bernalex> never even got either member to acknowledge my existance on IRC or
-           email.
-<rich0> If we're going to let Games have some kind of forceful say over any
-        game whether the maintainer wants them or not, then they HAVE to be
-        open to new members and hold elections
-<rich0> I'm more inclined to just let others do their own thing.  Live and let
-        live.                                                           [21:33]
-<mgorny> but we don't want to let them :)
-<radhermit> really, I think it should be more like other herds, e.g. python
-<scarabeus> actually there are two issues
-<rich0> Letting everybody do their own thing is less intrusive than trying to
-        push games around.
-<scarabeus> 1) state of herd
-<scarabeus> 2) rules herd has
-<ulm> rich0: as I see it, they maintain the ebuilds in the games herd
-<ulm> not all games
-<rich0> ulm: works for me - and they can't go sticking ebuilds in the herd if
-        the maintainer doesn't want them                                [21:34]
-<ulm> right
-<WilliamH> What about the concerns about the games team being non-responsive
-           to new members wanting to join?
-<rich0> If somebody sees a crufty ebuild in the herd and they want to pull it
-        out and work on it, then we can deal with that later, but I'm
-        definitely in favor of those who want to care for things vs those who
-        want to neglect them...
-<ulm> rich0: also I don't see what policy would allow them to enforce use of
-      games.eclass or games user/group, for ebuilds they don't maintain
-                                                                        [21:35]
-<scarabeus> rich0: that looks wrong
-<blueness> rich0, ulm i'd be okay with a statement like that "they can't go
-           sticking ebuilds in the herd if the maintainer doesn't want them",
-           but it would be nice if they had made such a statement publicly
-           otherwise we're acting on hearsay
-<scarabeus> rich0: imagine the situation with python
-<rich0> WilliamH: If we limit them to the games herd and don't force people to
-        put packages in the herd, then we don't have to care so much about the
-        membership.
-<scarabeus> if you would package against python policy then you would get
-            frowned upon by everybody
-<ulm> blueness: that's just normal policy, as I understand it
-<scarabeus> same is for games, the complaint is that the enforced rule is
-            actually bad
-<blueness> ulm, then let's just re-iterated the policy for all herd     [21:36]
-<rich0> scarabeus: sure, but strictly speaking the python team doesn't
-        override maintainers.
-<rich0> For the most part, if you ignore their policies you're just going to
-        be dealing with a broken package.
-<rich0> So, most devs will follow the policies because they just make sense.
-<blueness> scarabeus, rich0 python herd has always asked if they can be added
-           to my dev-python/* packages
-<rich0> blueness: and do you feel like they are only adding negative value
-        when they do?
-<scarabeus> you just said it, the policies make sense to that thing so we obey
-<scarabeus> if it does not we are not happy                             [21:37]
-<rich0> You really only need rules when people can't get along on their own...
-<blueness> rich0, no, i feel they are tracking python related stuff, but that
-           i'm still maintainig
-<rich0> blueness: and if the games team did the same thing, we wouldn't be
-        having this discussion...
-<blueness> its why i like being "second maintainer" on a lot of packages just
-           so i'm on the bug cc list
-<blueness> rich0, correct so games teams must be doing something else, but i
-           don't see it                                                 [21:38]
-<rich0> blueness: offtopic, but it would be nice if people could 'watch'
-        packages without doing that.
-<blueness> i wish games team had spoken up so we could just address them
-<ulm> so, does anyone want to propose a motion?
-<rich0> They require the use of their eclass, which establishes policies like
-        games group, /usr/games, etc
-<mgorny> blueness: they are too arrogant for that                       [21:39]
-<blueness> yeah that's wrong
-<mgorny> didn't you see mr_bones_' reply?
-<blueness> vaguely recall
-<rich0> ulm, I suggest we vote on limiting the games project to the games
-        herd, with maintainers having the final say on whether a package goes
-        in the herd.
-* scarabeus would actually vote on disbanding them even
-* scarabeus is really unhappy about them for years, and he knows it is bad
-  from him                                                              [21:40]
-<rich0> We could just provisionally vote on a few motions, then decide which
-        one to go with if they're contradictory
-<rich0> ie see what has support and then decide which of those options is best
-<rich0> Honestly, if not all games are in /usr/games, games group, etc, then I
-        don't see what the point is                                     [21:41]
-<WilliamH> I have one more question...
-<WilliamH> Say I put a new ebuild in the tree, in a games-* category with just
-           me as a maintainer.
-<WilliamH> that doesn't follow their policy.
-<WilliamH> What happens?
-<WilliamH> Do they leave it alone?                                      [21:42]
-<rich0> WilliamH: today, or in the future?
-<bernalex> one more thing, and I mention this out of personal experience: the
-           games team make gentoo look bad for outsiders who want to become
-           devs because they are interested in games.
-<rich0> today, they would add themselves to the metadata, and fix your ebuild,
-        or maybe remove it
-<ulm> rich0: how about "Every developer is allowed to commit and maintain
-      games ebuilds, without the need to ask for permission or review from
-      games team. The games team does not have authority to override
-      maintainer decisions on packages they don't maintain."
-<WilliamH> rich0: currently.
-<scarabeus> WilliamH: takeover or it will be removed too :) vaguely remember
-<ulm> that's the first two points from mgorny's mail
-<rich0> ulm: fine by me
-<ulm> ^^ please vote                                                    [21:43]
-<rich0> WilliamH: decent chance they'd pkgmove it
-<radhermit> I think we're using "they" a bit much here though, isn't it mostly
-            one person nowadays?
-<rich0> are we voting?
-<rich0> if so
-* rich0 yes
-* ulm yes
-* scarabeus ok
-<radhermit> sure
-<WilliamH> What are we voting?
-<blueness> yes
-<ulm> WilliamH: "Every developer is allowed to commit and maintain games
-      ebuilds, without the need to ask for permission or review from games
-      team. The games team does not have authority to override maintainer
-      decisions on packages they don't maintain."
-<bernalex> WilliamH: they might very plausibly just remove it without offering
-           any explanation.                                             [21:44]
-<ulm> dberkholz? WilliamH?
-<dberkholz> yes
-* WilliamH yes, but that's true with any herd so that's not anything special
-<ulm> WilliamH: right                                                   [21:45]
-<rich0> WilliamH: yup - just clarifying policy
-<blueness> ulm, we might want to say that
-<ulm> blueness: noted
-<ulm> not sure about points 3 to 5 from mgorny
-<ulm> i.e. games group, /usr/games, games.eclass                        [21:46]
-<dberkholz> that's for QA to care about
-<mgorny> yes, sounds like QA could vote about it
-<rich0> ulm: I think what we've done basically deals with the biggest logjam.
-        Agree QA can look more at FHS/etc if they care to
-<radhermit> what do other distros do these days?
-<WilliamH> But, do we need to take any action wrt the games team not
-           responding to join requests?
-<scarabeus> radhermit: for suse/fedora we do nothing :)
-<ulm> ok, so let's delegate the rest to QA
-<radhermit> scarabeus: figured as much                                  [21:47]
-<scarabeus> yep revision of rules should be handled by QA
-<bernalex> WilliamH: if you don't, the games team will continue to reflect
-           very poorly on gentoo.
-<radhermit> I think we just copied what debian (or some distro) did a long
-            time ago
-<ulm> WilliamH: propose a motion
-<radhermit> who needs to respond? I mean, I could but I'm not the leader and
-            just maintain one or two emulators.                         [21:48]
-<scarabeus> debian it was
-<WilliamH> Who is the  games lead?
-<bernalex> vapier lol
-<ulm> WilliamH: vapier
-<scarabeus> damn i have 7secs lag
-<radhermit> no idea, vapier?
-<bernalex> in practice it is mr_bones though.
-<radhermit> right
-<mgorny> vapier is formal but doesn't reply at all AFAIK                [21:49]
-<bernalex> neither does mr_bones
-<mgorny> mr_bones_ sometimes replies
-<WilliamH> I'm open to suggestions for the motion... It sounds like people
-           have wanted to join the team and been passively refused...
-<scarabeus> we could select radhermit as temporary TL whoms job would be to
-            get new members and hold elections                          [21:50]
-* radhermit coughs, I solved that by asking and then just adding myself a long
-  time ago :P
-<radhermit> when no one responded for a while
-<rich0> So, with games herd somewhat "contained" do we need to prod them on
-        the membership issue, or is that moot?
-<dberkholz> i don't think they need prodding.
-<ulm> as was said previously, anyone can create a games2 project        [21:51]
-<WilliamH> ulm: that would be a mess...
-<scarabeus> ulm: and as i asked what would happen if games2 started takeover
-            games1 pkgs
-<bernalex> ulm: again I'd like to raise the issue of PR. competing games teams
-           would make gentoo look really bad, just like the current games team
-           does.
-<scarabeus> the complaints would be valid if the set of rules would be
-            different
-<WilliamH> ulm: that's the same reason I didn't create systemd2 or something a
-           while back.
-<rich0> Is that like competing udev teams?  :)
-<scarabeus> that IS a mess :0                                           [21:52]
-<rich0> Except that udev is hardly a trivial package?
-<scarabeus> ;)
-<bernalex> rich0: isn't neverwinter nights the most non-trivial package in all
-           of portage still lol
-<blueness> scarabeus, rich0 there is a difference between just two competing
-           packages and competing herds
-<ulm> "the council encourages the games team to accept join requests and elect
-      a lead"?                                                          [21:53]
-<blueness> we have lots of competing packages which we deal with virtuals
-<rich0> ulm: I think that is a good starting point.
-<scarabeus> ulm: and if nothing happens?
-<blueness> ulm, i like it
-<radhermit> imo, people should just add themselves and try to come up with a
-            consensus with regards to ideas/changes, go through and update
-            docs, and go from there
-<rich0> If anybody wants to join and can't, they should speak up.
-<rich0> I asked about people who wanted in and couldn't join, and I got
-        crickets.
-<ulm> scarabeus: then we reiterate
-<WilliamH> ulm: then we disband them
-<blueness> radhermit, can't you speak up for the team?
-<rich0> If people want to join, we can help them out.
-<radhermit> my problem is I hardly do much in regards to it
-<blueness> ah                                                           [21:54]
-<radhermit> mr_bones is the main guy
-<mgorny> well, the problem is that people don't want to join the team if
-         that's going to require them to follow the policies they oppose...
-<ulm> so, consensus on: "the council encourages the games team to accept join
-      requests and elect a lead"?
-* ulm yes
-<dberkholz> sure
-* WilliamH thinks we should make that stronger                          [21:55]
-* rich0 yes
-<radhermit> sure
-<ulm> WilliamH: we start with a watchmaker's tool, the sledgehammer will
-      follow later if necessary :)
-<scarabeus> "The council requires games team to elect a lead and allow people
-            to join"
-<WilliamH> "The council encourages the games team to accept join requests, and
-           asks them to elect a lead within 30 days. If they do not, we will
-           disband them."
-<bernalex> mgorny: I have been completely discouraged and lost all interest in
-           joining the current team.                                    [21:56]
-<scarabeus> bernalex: no worries you are not around i gave hope like 3 years
-            ago on that :)
-<ulm> ok, we have a majority for the first motion already
-* WilliamH votes no for the first motion                                [21:57]
-<ulm> so we could just vote on WilliamH's one
-<ulm> i.e. if we make it stronger
-<WilliamH> ulm my motion is:
-<WilliamH> "The council encourages the games team to accept join requests, and
-           asks them to elect a lead within 30 days. If they do not, we will
-           disband them."
-<rich0> what does the "if they do not" pertain to?  Electing a lead, or
-        accepting more people?
-<rich0> Assuming more want to join...                                   [21:58]
-<scarabeus> i guess mr_bones_ can elect himself that should not be that tough
-            so it is not as evil as it seems it just dethrones vapier
-<WilliamH> rich0: hmm
-* dol-sen suggests 30 days is not enough time for that
-<WilliamH> I'm open to suggestions for rewording it.
-<blueness> "In the absense of a lead being elected, we will consider the herd
-           as disfunctional and thus disband it"                        [21:59]
-<ulm> s/herd/team/
-<blueness> or In the event they don't elect a lead
-<radhermit> do people wanting work on games ebuilds really even want a herd
-            anymore if we're moving away from centralized games munging?
-<blueness> let me try again
-<blueness> "In the event they don't elect a lead, we will consider the team as
-           disfunctional and thus disband it"                           [22:00]
-<WilliamH> I think we should ask them to give time for new people to join
-           before they elect a lead...
-<mgorny> radhermit: i think we ought to have a team of dedicated people to
-         help contributors getting game ebuilds into gentoo
-<blueness> that might not be a bad policy in general since a team without a
-           lead is pretty disorganized
-<ulm> blueness: time frame for this to happen? 6 weeks?
-<mgorny> radhermit: we don't own many games and need users for that
-<blueness> ulm, yeah 6 weeks
-<WilliamH> blueness: I think there are small teams without leads...
-<blueness> WilliamH, i still want your piece                            [22:01]
-<rich0> mgorny: I'm fine with that, but people have to step up to be on that
-        team
-<radhermit> mgorny: makes sense
-<rich0> I was kind of hoping to go that route, but I think most are burned out
-        due to the whole conflict
-<blueness> WilliamH, webapp-config is pretty leaderless there wsa only one
-           incident where a leader was needed
-<ulm> so please vote on: "In the event they don't elect a lead within 6 weeks,
-      we will consider the team as disfunctional and thus disband it"
-* blueness yes
-* rich0 yes                                                             [22:02]
-<radhermit> yes
-* WilliamH yes
-* ulm yes
-* scarabeus yes
-<ulm> dberkholz?
-<dberkholz> abstain
-<mgorny> just to be clear, do we have any rules for how team lead should be
-         elected?
-<ulm> 6 yes 1 abstention                                                [22:03]
-<ulm> mgorny: we don't
-<mgorny> e.g. can they re-elect vapier?
-<ulm> sure
-<scarabeus> but iirc tl must ACCEPT the offer first
-<scarabeus> so no reply for being nominated for TL disqualifies you
-<mgorny> i'm a bit afraid the best thing that's going to happen is a new
-         inactive lead...
-<ulm> scarabeus: that's common sense                                    [22:04]
-<ulm> mgorny: then we can reiterate
-<scarabeus> come on even status quo can be punished
-<mgorny> maybe it would be indeed better to disband it, let new people join
-         and elect new lead among themselves
-<scarabeus> lets just give some good faith
-<blueness> mgorny, and encourage new members, so we can revisit his
-<blueness> this
-<bernalex> there sholud be a team lead slacker rule like for council.
-<rich0> mgorny: if people want to join and are being kept out, we can
-        potentially shoehorn them in                                    [22:05]
-<scarabeus> actually i liked my proposal to make radhermit TL and let him
-            coordinate next elections
-<mgorny> i mean, letting all interested people join with a free card, rather
-         than into a team with disliked lead
-<scarabeus> radhermit: i think you can be active there for a bit no?
-<rich0> I'm fine with having an interim lead to essentially moderate new
-        elections
-<scarabeus> at least reading mails for 6 weeks ;)
-<radhermit> heh, I can help poke things along sure
-* WilliamH is fine with radhermit coordinating the election and recruiting new
-  members
-<ulm> we're past the one hour limit already
-<mgorny> as in, 1) people join, 2) new lead is voted amongst all members
-<radhermit> but I'm not anywhere close to the major contributor for games
-            stuff
-<dberkholz> i've gotta run after we're done with this                   [22:06]
-* dol-sen agrees with radhermit as temp lead... It's what I did in portage
-  last Xmas
-<scarabeus> radhermit: but you are just temporary scapegoat seated by council
-            so as far as you are fine by not being elected again in 6 weeks :P
-<bernalex> I say offer hasufell the interim lead position...
-<mgorny> no, hasufell lacks the social skills
-* WilliamH motions that radhermit be the interrum lead of games until the
-  elections are held
-<mgorny> radhermit is a good choice
-<ulm> I cannot make it next tuesday
-<ulm> how about new meeting in two weeks, at august 26?                 [22:07]
-<rich0> He can be the viceroy :)
-<rich0> 26th wfm                                                        [22:08]
-<scarabeus> he can call himself even supreme commander and drink only mojitos,
-            dont care about that :D
-<WilliamH> wfm
-<radhermit> 26th should work for me
-<scarabeus> dilfridge should be back at that point
-<blueness> yep, i can make the 26th                                     [22:09]
-<ulm> blueness: dberkholz: dilfridge|mobile: 26th o.k. as meeting date?
-<blueness> now that i'm teaching again, i have to look at my schedule
-<dberkholz> i may need to find a proxy, not sure yet
-<dberkholz> but go ahead and schedule
-<ulm> k
-<dberkholz> oh btw
-<dberkholz>
-            /var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/20131210-summary.txt,v
-            <--  20131210-summary.txt                                   [22:10]
-<dberkholz> initial revision: 1.1
-<dberkholz>
-            /var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140114-summary.txt,v
-            <--  20140114-summary.txt
-<dberkholz> initial revision: 1.1
-<rich0> dberkholz: ++  :)
-<radhermit> nice work
-<mgorny> WilliamH still had one last motion
-<ulm> "radhermit be the interim lead of games until the elections are held"?
-                                                                        [22:11]
-<mgorny> yes
-<ulm> do we have the authority for this?
-<dol-sen> yes
-<scarabeus> i yes
-<scarabeus> we should
-<ulm> o.k., let's vote on this one
-* ulm abstains                                                          [22:12]
-* rich0 yes
-* radhermit abstains
-* scarabeus acks if radhermit wants it
-<radhermit> I'll help things along, I just don't want to be lead in the future
-<dberkholz> i don't see why we need an interim lead for 6 weeks, we need an
-            election official
-<rich0> best candidate for an interim lead - somebody who is short-term
-<rich0> interim lead can help drum up more life for the team            [22:13]
-<dberkholz> and it would be weird for him to be both at once
-<rich0> accept join requests
-<rich0> etc
-<radhermit> how do herds do official elections?
-<rich0> And if he isn't a candidate for the long-term lead, the can officiate
-        the election
-<rich0> radhermit: up to you to figure out, but I'd just vote by email, or on
-        irc
-<rich0> I don't think it needs to be secret ballot
-<WilliamH> radhermit: there is no global policy
-<rich0> keep it simple                                                  [22:14]
-<radhermit> right, that's why I've seen
-<rich0> but you can do something fancier if you want to
-<radhermit> s/why/what/
-* WilliamH votes yes
-<ulm> so I see 3 yes votes and 2 abstentions
-<ulm> who's missing?
-<ulm> blueness?
-<dberkholz> abstain as well
-<dberkholz> and with that, i've gotta run                               [22:15]
-<scarabeus> blueness: wake up you are tie breaker :D                    [22:16]
-<ulm> hm? seems it's accepted
-<ulm> 3 yes 0 ne 3 abstain
-<scarabeus> ulm: how
-<ulm> s/ne/no
-<scarabeus> i thought you need 4 even with abstains
-<ulm> simple majority                                                   [22:17]
-<ulm> but I agree that 4 yes would be nicer
-<scarabeus> ah ok
-<rich0> scarabeus: if that were true there would be no point in abstain - it
-        would be the same as ano
-<ulm> blueness: ^^
-<ulm> anyway
-<ulm> radhermit: do you accept being interim lead                       [22:18]
-<scarabeus> radhermit: enjoy the shiny hat then :P
-<mgorny> radhermit: now, drop all the policies, quick!
-<radhermit> heh
-<scarabeus> lol
-*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
-    "Next meeting: Tuesday, 26 Aug 2014 19:00 UTC |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 |
-    http://wiki.gentoo.org/wiki/Project:Council"                        [22:19]
-<WilliamH> radhermit: You may want to talk to calchan; he was interested in
-           helping out the games team.
-<scarabeus> gotta run myself, have fun
-<dol-sen> radhermit, it wasn't bad when I assumed interim lead for portage, it
-          just got busy :)
-<radhermit> I'll just try to bring in new blood, start discussions about
-            changing policies, and do an election after people are settled
-<dol-sen> exactly
-<rich0> radhermit: yup - best way to go                                 [22:20]
-<rich0> focus more on building a team, so that the team can figure out what to
-        do
-<dol-sen> it's just with my new team, nobody wanted to be lead ;)
-<blueness> sorry i just got a phone calle
-<bernalex> dol-sen: radhermit: kind of comparable situations. games team is as
-           low on people as portage, I would assume.                    [22:21]
-<blueness> ulm, i'm okay with radhermit being in charge
-<bernalex> & in 6 weeks radhermit will be benevolent dictator for life because
-           nobody else wants to be team lead ;-)
-<ulm> ok, so accepted with 4 yes and 3 abstentions
-<ulm> and I close this meeting
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140826-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20140826-summary.txt
deleted file mode 100644
index 148f98fefb..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140826-summary.txt
+++ /dev/null
@@ -1,84 +0,0 @@
-Summary of Gentoo council meeting 26 August 2014
-
-Agenda
-======
-1. Roll call (5 minutes)
-2. Dynamic dependencies in Portage [1] (15 minutes)
-3. Additional features for EAPI 6 [2] (15 minutes)
-4. Open bugs with council involvement (10 minutes)
-5. Open floor (10 minutes)
-
-
-Roll call
-=========
-Present: blueness, dilfridge, radhermit, rich0, ulm, williamh
-Absent: dberkholz
-
-Dynamic dependencies in Portage
-===============================
-During discussion, is was remarked that some changes, e.g. to
-dependencies in eclasses, could require mass rebuilds of packages.
-
-Vote:
-- "The council asks the Portage team to first outline their long-term
-  plan regarding removal or replacement of dynamic dependencies,
-  before they remove this feature. In particular, tree policies and
-  the handling of eclasses and virtuals need to be clarified."
-  Accepted unanimously.
-
-Note added in proof: The Portage team does not intend to remove
-dynamic dependencies, but only change their default to "off".
-
-Additional features for EAPI 6
-==============================
-The three proposed features were discussed and voted on separately.
-
-- Pass additional --docdir and --htmldir options to configure:
-  Accepted with 5 yes votes and 1 abstention.
-
-- Additional default suffixes for dohtml:
-  Rejected with 5 no votes and 1 abstention.
-
-- Variant of || () that is not runtime-switchable
-  (provisional approval, under the condition that the feature will
-  only be included if an implementation is ready):
-  Accepted unanimously.
-
-Open bugs with council involvement
-==================================
-- Bug 424647 "archives.gentoo.org: Broken URLs for e.g.
-  gentoo-dev-announce and others" [3]
-  No progress.
-  Action: Remove council from CC.
-
-- Bug 477030 "Missing summary for 20130611 council meeting" [4]
-  ulm has written a summary, which is approved.
-  Action: Commit the summary, close bug.
-
-- Bug 503382 "Missing summaries for 20131210, 20140114, and 20140225
-  council meetings" [5]
-  No progress since last meeting.
-
-- Bug 520074 "GLEP 39 rump council privilege escalation in secret
-  meeting" [6]
-  Most council members are of the opinion that this is of little
-  practical relevance.
-  Action: Remove council from CC.
-
-Open floor
-==========
-dilfridge remarks that axs has revbumped all ebuilds in dev-perl to
-EAPI 5. Some more complex ebuilds installing perl modules remain, so
-perl-cleaner is still needed.
-
-Next meeting date
-=================
-Tuesday, 9 Sep 2014, 19:00 UTC
-
-
-[1] http://thread.gmane.org/gmane.linux.gentoo.project/3943
-[2] http://thread.gmane.org/gmane.linux.gentoo.project/4002
-[3] https://bugs.gentoo.org/424647
-[4] https://bugs.gentoo.org/477030
-[5] https://bugs.gentoo.org/503382
-[6] https://bugs.gentoo.org/520074
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140826.txt b/xml/htdocs/proj/en/council/meeting-logs/20140826.txt
deleted file mode 100644
index b9fc59e7e5..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140826.txt
+++ /dev/null
@@ -1,375 +0,0 @@
-<ulm> 19:00, so let's start the meeting                                 [21:00]
-<ulm> agenda is here: http://article.gmane.org/gmane.linux.gentoo.project/4014
-<ulm> roll call
-<radhermit> here
-<rich0> here
-<dilfridge> here
-<WilliamH> here
-<blueness> here
-<ulm> dberkholz?                                                        [21:01]
-<ulm> anyone has donnie's number?                                       [21:02]
-<blueness> lets start
-<radhermit> he sent it to the list
-<radhermit> or alias
-<dilfridge> sent him a text...                                          [21:03]
-<blueness> dilfridge, were you going to compile a list?
-<blueness> :)
-<dilfridge> yes, soon...
-<ulm> anyway, let's start
-<ulm> first topic: dynamic dependencies in portage
-<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/3943
-<dilfridge> wheeee                                                      [21:04]
-<ulm> any opinions?
-<dilfridge> two things from me...
-<rich0> So, I believe the portage team indicated that they plan to remove
-        dynamic deps the way they are now, but to come up with another
-        solution to the rebuild problem.
-<rich0> As long as the latter accompanies the former when it goes mainstream,
-        I don't have a problem with it.                                 [21:05]
-<dilfridge> 1) some eclasses add dependencies which need to be changed every
-            now and then... e.g. minimal perl version in perl-module.eclass,
-            or minimal qt version for kde ebuilds
-<ulm> I'd say this is up to the portage team. they had added the feature, so
-      they can change or remove it as well
-<dilfridge> noone's come up with a real solution for this yet, except for a
-            true mass rebuild
-<WilliamH> There is a solution that mgorny came up with, a new @changed-deps
-           set that would rebuild everything.                           [21:06]
-<WilliamH> with new dependencies
-<dilfridge> yes... wanna rebuild all perl-related ebuilds in your system? :)
-<ulm> WilliamH: IIUC this has the same problem as dynamic dependencies
-<ulm> if the ebuild is gone, the package won't be rebuilt               [21:07]
-<blueness> i haven't seen a solution that satisfies my so i'm not sure what we
-           are resolving here.  i'd say ask the portage team to come up with
-           something.
-<ulm> so it would bite users who haven't upgraded for a long time
-<dilfridge> 2) that said, I dont intend to fully block this move by the
-            portage team, but before it's actually disabled fully, we need a
-            working, reliable alternative and a good idea for the needed
-            workflow and tree policies.
-<blueness> ulm, the ebuild is still in vardb
-<radhermit> as a pkgcore guy, I've never been pro-dynamic deps due a number of
-            issues most of which have been raised in the various threads
-<rich0> dilfridge: ++
-<ulm> blueness: the one with the old dependencies                       [21:08]
-<blueness> ah
-<blueness> yes
-<radhermit> imo, we should really spec out a vdb format
-<rich0> That is my concern.  I'm fine with one step back and two steps
-        forward, but we can't do the latter without plans to do the former.
-<rich0> Err, the other way around :)
-<blueness> radhermit, take a look at https://wiki.gentoo.org/wiki/GLEP:64
-<rich0> Sure, to some extent the portage team should take the lead on this,
-        but this affects the whole tree and how it is maintained.
-<ulm> so, should we ask the portage team to outline their solution, before
-      they remove the current feature?                                  [21:09]
-<dilfridge> this does not so much affect the maintainer of a single package,
-<radhermit> blueness: ah gotcha
-<dilfridge> but much more the people maintaining virtuals and eclasses...
-<Arfrever> There is no consensus in Portage team to remove dynamic
-           dependencies.
-<WilliamH> Arfrever: I thought there was.                               [21:10]
-<dilfridge> Sorry can you type louder, I didn't hear you...
-<radhermit> anyway, I also agree that the support shouldn't just be yanked out
-            of portage since it's been the default for a long time
-<radhermit> and devs have become implicitly used to its mostly hidden workings
-                                                                        [21:11]
-<dilfridge> exactly.
-<rich0> I think a long-term plan would alleviate a lot of concerns.  It isn't
-        enough to say dynamic deps are broken.  We need to talk about what the
-        better solution actually is. I'm sure it will be supported then.
-<ulm> Arfrever: the portage team meeting summary posted on 2014-07-25 says
-      that dynamic dependencies will be turned off
-<dilfridge> right now the bigger surprise is that sometimes dynamic deps dont
-            work...
-<ulm> that's the most official statement we have
-<ulm> so we should go from there                                        [21:12]
-<ulm> anyone wants to come up with a motion?                            [21:13]
-<WilliamH> I'm thinking that if they are turned off by default that will be ok
-           as long as we can turn them on until a fix is developed.
-<WilliamH> We won't know what is broken by them being turned off until they
-           are turned off...                                            [21:15]
-<Arfrever> ulm: This "meeting" was even not announced before it (mailing lists
-           were down). I have received e-mail about announcement of meeting
-           after meeting. Probably very small number of members of team
-           participated in meeting.
-<WilliamH> Arfrever: you should be able to check that by the meeting log if it
-           is posted.                                                   [21:16]
-<ulm> How about this: "The council asks the portage team to outline their
-      long-term plan regarding removal or replacement of dynamic dependencies,
-      before they actually remove this feature."
-<dilfridge> ulm: that plus:
-<blueness> yes
-<dilfridge> "Especially tree policies and the handling of eclasses and
-            virtuals need to be clarified."                             [21:17]
-<Arfrever> (Anyway I am one of Portage team members, who would vote for
-           keeping dynamic dependencies.)
-<ulm> good
-<rich0> wfm
-<ulm> "The council asks the portage team to first outline their long-term plan
-      regarding removal or replacement of dynamic dependencies, before they
-      remove this feature. Especially tree policies and the handling of
-      eclasses and virtuals need to be clarified."
-<blueness> dilfridge, "especially" -> "In particular"  (very minor change but
-           sounds better)
-<ulm> Please vote
-* dilfridge yes
-<blueness> yes
-<radhermit> yes
-<rich0> yes                                                             [21:18]
-<ulm> ok, with blueness's change of wording
-<ulm> yes
-<blueness> yes
-<WilliamH> yes
-<radhermit> sure
-<ulm> unanimous, for the council members present
-<ulm> anything else for this topic?
-<dilfridge> just the remark                                             [21:19]
-<dilfridge> that this is much more critical for slow arches as e.g. arm or ppc
-            where the rebuilds are more time-consuming.
-<ulm> do you want this in the summary?
-* dilfridge pulls up the obligatory remark about a "beowulf cluster of
-  those"...                                                             [21:20]
-<dilfridge> nah, log is enough :)
-<ulm> next topic: additional features for EAPI 6
-<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/4002
-<ulm> mgorny asks us to reopen the list of features                     [21:21]
-<Arfrever> ulm: (It was never closed anyway...)
-<radhermit> were they closed? I didn't think so yet
-<ulm> k
-<ulm> I suggest we discuss features individually                        [21:22]
-<dilfridge> +
-<ulm> 1. passing additional configure options, namely --docdir and --htmldir
-<ulm> I would be in favour of this
-<radhermit> imo, should be fine
-* dilfridge abstains
-<ulm> looks pretty safe
-<WilliamH> should be ok                                                 [21:23]
-<ulm> and mgorny has done a tree-wide scan IIUC
-<ulm> so let's just vote
-* ulm yes
-<radhermit> yes
-* dilfridge abstain
-<blueness> yes
-* rich0 yes
-* WilliamH yes
-<ulm> passes with 5 yes 1 abstention 1 absent                           [21:24]
-<ulm> 2. additional default suffixes for dohtml
-<ulm> IMHO changing the default is pointless
-<WilliamH> What are the requested suffixes?                             [21:25]
-<ulm> it's just a default, and there are options -a and -A to change the list
-      of suffixes
-<ulm> .xml .xhtml .ico .svg
-<ulm> bug 423245
-<willikins> ulm: https://bugs.gentoo.org/423245 "[Future EAPI] dohtml: Extend
-            default list of extensions"; Gentoo Hosted Projects, PMS/EAPI;
-            UNCO; arfrever.fta:pms-bugs
-<ulm> I have some ideas about moving the dohtml function from the PM to an
-      eclass                                                            [21:26]
-<blueness> this is minor, imo.  its harmless to change the default but there's
-           no strong reason to do so.
-<ulm> blueness: well, devs have to learn the difference between EAPIs then
-                                                                        [21:27]
-<dilfridge> right. let's keep it as it is.
-<blueness> ulm, yeah i guess
-<ulm> and you'd have to check the set of installed files for every EAPI bump
-      from 5 to 6
-<ulm> more discussion?
-<ulm> seems not, so let's vote                                          [21:28]
-* ulm no
-* dilfridge no
-<blueness> no
-<rich0> no
-* WilliamH abstains
-<radhermit> no
-<ulm> rejected, 5 no 1 abstention 1 absent
-<ulm> 3. build-time switching variant of || ()                          [21:29]
-<ulm> bug 489458
-<willikins> ulm: https://bugs.gentoo.org/489458 "[Future EAPI] Replace || with
-            something less ambiguous"; Gentoo Hosted Projects, PMS/EAPI; CONF;
-            ciaran.mccreesh:pms-bugs
-<ulm> I would be very much in favour of this feature if there was proof of
-      concept ready
-<rich0> I think mgorny's proposal seemed reasonable enough.
-<dilfridge> well, right now we're only saying what things people should work
-            on... this is not the final decision on EAPI features (since that
-            needs the implementation)                                   [21:30]
-<rich0> ulm: well, that seems to be the point of pre-voting on EAPIs
-<blueness> rich0, you mean comment #14?
-<rich0> blueness: yes
-<ulm> we could provisionally approve it, with the condition that it will only
-      be included in EAPI 6 if an implementation is ready
-<dilfridge> comment 14 is the one to go for, yes
-<rich0> We'll have to re-vote on the final PMS once there is a reference
-        implemenation.                                                  [21:31]
-<dilfridge> ulm: isn't that true for everything right now?
-<rich0> dilfridge: yes
-<rich0> PMS policy is that we don't put stuff in until implemented in portage
-<rich0> This is basically to help devs avoid wasting time on stuff only to
-        have it yanked back out
-<rich0> I think it makes sense to do it this way.
-<ulm> dilfridge: mgorny has implemented everything else in his branch of
-      portage already
-<rich0> People can still work on stuff we vote no on, or not work on stuff we
-        vote yes on.  It just gives them a sense of where we stand.
-                                                                        [21:32]
-<dilfridge> right... but that wasn't the case at the time of the first votes
-            :P
-<ulm> o.k.
-* radhermit will need to look at pkgcore code a bit, but it seems ok-ish
-<blueness> rich0, i agree that this resolves one ambiguity, but to be honest,
-           i can't fully get my head around all the possibilities here, and
-           i'm not sure mgorny's solution really nails everything
-<ulm> so please vote on provisional approvement, with the condition that it
-      will only be included if an implementation is ready
-* ulm yes
-* dilfridge yes                                                         [21:33]
-<blueness> yes
-<rich0> yes
-<radhermit> yes
-<ulm> WilliamH?
-<rich0> blueness: agree that when you get into nesting the actual use gets
-        murky.  However, I think that the rules are straightforward enough.  I
-        guess if you get ||= embedded in || you have to decide if the ||=
-        propagates through.
-* WilliamH yes                                                          [21:34]
-<ulm> rich0: these things are what makes the implementation difficult ;)
-<radhermit> it will probably need some more forceful or better defined
-            boundaries though, I'm assuming that'll happen if it gets into PMS
-<ulm> passes unanimously (1 absent)
-<ulm> we're perfectly in time :)                                        [21:35]
-<ulm> next: open bugs
-<ulm> bug 424647
-<willikins> ulm: https://bugs.gentoo.org/424647 "archives.gentoo.org: Broken
-            URLs for e.g. gentoo-dev-announce and others"; Gentoo
-            Infrastructure, Other; CONF; darkside:infra-bugs
-<dilfridge> I think infra has bigger problems atm...                    [21:36]
-<ulm> yeah
-<ulm> no progress there
-<rich0> agree, but how is this a council issue anyway?
-<ulm> and no action by council
-<rich0> we basically look at this every month and say, yes, it is a problem
-<blueness> heh yeah                                                     [21:37]
-<rich0> Either somebody volunteers to fix it, or maybe we beg the trustees to
-        pay somebody to fix it for us
-<ulm> we could remove council from cc
-<blueness> let's do that
-<ulm> and forget about the problem
-<rich0> I don't think we're adding any value
-<dilfridge> which problem?                                              [21:38]
-<rich0> :)
-<blueness> dilfridge, the broken archives
-<ulm> dilfridge: that we have no archives
-<blueness> email archives
-<dilfridge> ... :)
-<radhermit> pretty sure he was joking
-<ulm> any objections against removing us from cc?
-<dilfridge> no objections.                                              [21:39]
-<rich0> We should use discourse.  :)
-<blueness> ulm, i agree, remove us
-<ulm> next, bug 477030
-<willikins> https://bugs.gentoo.org/477030 "Missing summary for 20130611
-            council meeting"; Doc Other, Project-specific documentation; CONF;
-            ulm:council
-<ulm> I became impatient and wrote a summary :)                         [21:40]
-<ulm> http://www.gentoo.org/proj/en/council/meeting-logs/20130611-summary.txt
-<ulm> asking for approval here
-<blueness> ulm, were you at the meeting?
-<ulm> you should also have received the draft by e-mail
-<ulm> blueness: yes
-<blueness> okay then, do it                                             [21:41]
-<radhermit> looks fine, imo
-<ulm> I don't see any objections                                        [21:42]
-<rich0> I say go ahead
-<ulm> so I'll add the link to the council page
-<blueness> well i have not basis to disagree since i wasn't there
-<ulm> finally, bug 503382
-<willikins> https://bugs.gentoo.org/503382 "Missing summaries for 20131210,
-            20140114, and 20140225 council meetings"; Doc Other,
-            Project-specific documentation; CONF; ulm:council
-<ulm> but donnie is not here :(                                         [21:43]
-<ulm> so again no progress, I fear
-<ulm> hm, there's another bug actually                                  [21:44]
-<ulm> bug 520074
-<willikins> ulm: https://bugs.gentoo.org/520074 "GLEP 39 rump council
-            privilege escalation in secret meeting"; Doc Other, GLEP Changes;
-            UNCO; wking:glep
-<ulm> rich0: you've participated in the discussion there, so do you want to
-      comment?                                                          [21:45]
-<rich0> I think it is much ado about nothing.
-<rich0> :)
-<ulm> yeah, that's my impression too
-* WilliamH agrees
-<ulm> from a theoretical pov he might have a point                      [21:46]
-<rich0> Certainly our rules aren't airtight, but we only lead because
-        everybody recognizes that we lead.
-<blueness> actually, i had a secret meeting yesterday and voted to disband the
-           council, so this is now mute
-<ulm> but I doubt that it has any practical relevance
-<blueness> moot
-<dilfridge> yes... it's very much about codifying common sense, which is
-            something you can spend all eternity on
-<rich0> If we say something that 99% of devs disagree with, they'll just
-        ignore us.
-<blueness> shoudl we have a quorum for other reasons?
-<rich0> Well, we already disband the council anytime half of us don't show up.
-                                                                        [21:47]
-<rich0> So, that seems to be overkill already.  :)
-<WilliamH> Right.
-<blueness> yeah
-<rich0> I don't care for the slacker rule at all, but that is a separate
-        matter.
-<ulm> any action?
-<ulm> remove council from cc?
-<blueness> yeah
-<dilfridge> rich0: I would not mind adding that the council with <=50%
-            attendance can't decide anything, but if that requires an eternal
-            discussion on how to add something, I dont care.
-<rich0> I don't object either, but then you get into the whole argument about
-        who is allowed to edit GLEP 39                                  [21:48]
-<dilfridge> exactly.
-<ulm> dilfridge: it was handled that way when it occured
-* radhermit doesn't care that much, seems people have replied enough on the
-  bug
-<ulm> only once, in 2008
-<dilfridge> yes.
-<rich0> I don't have an issue with just fixing it, but maybe the same folks
-        who like the slacker rule might object.  :)
-<ulm> ok, I'll remove us from cc                                        [21:49]
-<ulm> next, open floor
-<ulm> and we're still in time :)                                        [21:50]
-<dilfridge> meh
-<dilfridge> right.
-<dilfridge> [21:47:28] <_AxS_> done!
-<dilfridge> official commendation to _AxS_ for revbumping all dev-perl to
-            EAPI=5 :)
-<rich0> woot!
-<ulm> great :)
-* WilliamH agrees, that is good news
-<blueness> that was a lot of work                                       [21:51]
-<WilliamH> That obosoletes perl-cleaner right?
-<blueness> so am i to understand this correctly that we won't need
-           perl-cleaner anymore
-<dilfridge> not yet
-<WilliamH> obsoletes *
-<ulm> let's finish EAPI 6 so the perl team won't be put out of work :p
-<dilfridge> WilliamH: there are some ebuilds left (not many), more complex
-            apps that also install perl modules                         [21:52]
-<blueness> dilfridge, what will perl-cleaner be needed for?
-<blueness> i see
-<dilfridge> once these are gone too, we'll ban EAPI<5 in perl-module.eclass
-<dilfridge> then it's obsolete.
-<blueness> what about perl virtuals?
-<dilfridge> well, the new ones are also marked EAPI=5                   [21:53]
-<dilfridge> but there's no hurry there
-<dilfridge> no eclass, nothing to rebuild
-<blueness> i see
-<dilfridge> (and the EAPI makes no difference)
-<ulm> anything else for open floor?                                     [21:54]
-<ulm> seems not to be the case                                          [21:55]
-<ulm> next meeting will be on 2014-09-09
-<ulm> so I'll send the call for agenda items today                      [21:56]
-*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
-    "Next meeting: Tuesday, 9 Sep 2014 19:00 UTC |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 |
-    http://wiki.gentoo.org/wiki/Project:Council"
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140909-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20140909-summary.txt
deleted file mode 100644
index 6696c84490..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140909-summary.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Summary of Gentoo council meeting 9 September 2014
-
-Agenda
-======
-1. Roll call (5 minutes)
-2. Future of dohtml [1] (15 minutes)
-3. Open bugs with council involvement (5 minutes)
-4. Open floor
-
-
-Roll call
-=========
-Present:
-blueness, dberkholz, dilfridge, radhermit, rich0, ulm, williamh
-
-Future of dohtml
-================
-Three votes were taken:
-
-- Should dohtml be banned from the package manager?
-  Accepted unanimously.
-
-- Should dohtml be banned in EAPI 6 already?
-  Rejected (tie vote, 3 yes, 3 no, 1 abstention).
-
-- Deprecate dohtml now, ban it in EAPI 7?
-  Accepted (6 yes, 1 no).
-
-The council notes as an obvious implication that the einstalldocs
-function in EAPI 6 must not use dohtml, but dodoc -r.
-
-There is consensus that dodoc -r should be recommended as replacement.
-The council remains silent about the issue if a substitute in an
-eclass will be needed.
-
-Open bugs with council involvement
-==================================
-- Bug 503382 "Missing summaries for 20131210, 20140114, and 20140225
-  council meetings" [2]
-  The summaries for the 20131210 and 20140114 meetings are done, but
-  20140225 is still missing.
-
-Open floor
-==========
-blueness intends having GLEP 64 ready for a vote in the next meeting.
-
-Next meeting date
-=================
-Tuesday, 14 Oct 2014, 19:00 UTC
-
-
-[1] http://thread.gmane.org/gmane.linux.gentoo.project/4017
-[2] https://bugs.gentoo.org/503382
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20140909.txt b/xml/htdocs/proj/en/council/meeting-logs/20140909.txt
deleted file mode 100644
index 9fcaa814e2..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20140909.txt
+++ /dev/null
@@ -1,262 +0,0 @@
-<ulm> 19:00 UTC, so let's start                                         [21:00]
-<ulm> roll call
-* blueness here!
-<ulm> dberkholz, dilfridge, radhermit, rich0, williamh?
-<dberkholz> hi
-<ulm> helium-3?                                                         [21:01]
-* rich0_ here
-*** rich0_ (~quassel@gentoo/developer/rich0) is now known as rich0
-<radhermit> I'm around
-<ulm> dilfridge and WilliamH still missing                              [21:02]
-* blueness taps his fingers impatiently                                 [21:03]
-<ulm> I've texted dilfridge
-<blueness> k
-<dilfridge> thx :)
-<dilfridge> here
-<ulm> can anyone in the US try to contact WilliamH?
-<dilfridge> and hello from Kyparissia / Kalo Nero                       [21:04]
-<blueness> ulm, i can, but i don't recall getting his number
-<rich0> I'll text him
-<ulm> k
-<blueness> dilfridge, did you ever collect everyone's phone number in one
-           email?
-<rich0> sent
-<dilfridge> not yet, but I can do it during the next days
-<dilfridge> I have 5 more beach days ahead of me...                     [21:05]
-* WilliamH is here sorry folks
-<ulm> ok, we're complete then
-<ulm> agenda is rather short this time:
-      http://article.gmane.org/gmane.linux.gentoo.project/4021
-<ulm> first topic is about the future of dohtml                         [21:06]
-<ulm> http://thread.gmane.org/gmane.linux.gentoo.project/4017
-<WilliamH> kill it with fire
-<rich0> seems like the perfect job for a utility eclass
-<dilfridge> I have no experience with it, but from the mailing list mails I
-            think we should kill it                                     [21:07]
-<ulm> we first have to decide if it should be removed from the PM
-<ulm> then the details
-<blueness> ditto, it seems like it was redundant and overly complex
-<rich0> I think deprecation makes sense.
-<rich0> No rush to get rid of it that I can see.
-<ulm> shall we just vote on the first question?
-<rich0> That creates the demand for an eclass which replaces it.
-<ulm> "should dohtml be banned from the package manager?"               [21:08]
-* WilliamH yes
-<ulm> (no timeframe implied yet)
-* dilfridge yes
-* ulm yes
-* rich0 yes, eventually
-<blueness> has ayes
-<blueness> err .. "yes"
-* radhermit yes
-<ulm> dberkholz?                                                        [21:09]
-<ulm> anyway, I count 6 yes so far                                      [21:10]
-<blueness> i'm grepping the tree now to see what uses it
-<ulm> so we can discuss the next question I think
-<ulm> should it be banned in EAPI 6 already?                            [21:11]
-* WilliamH yes
-<rich0> blueness: 3665 lines from a grep...
-<WilliamH> it would just be part of the migration to eapi 6 to stop using it.
-<ulm> alternative would be to deprecate it now and ban it in one of the next
-      EAPIs
-* dilfridge yes                                                         [21:12]
-* ulm yes
-<WilliamH> ulm: I don't see the advantage of doing that.
-<blueness> ulm, that's what i would like, a deprecation message immediately
-<radhermit> are we going to pass --htmldir or --docdir or whatever in EAPI 6?
-<dberkholz> that's fine
-<ulm> radhermit: yes
-<radhermit> if so, then sure ban it in 6
-<ulm> dberkholz: was this your vote on the first question?              [21:13]
-<ulm> dberkholz: "should dohtml be banned from the package manager?"
-<dberkholz> yes to 1 and yes to 2 via deprecation
-<dberkholz> deprecate in 6, obsolete in 7                               [21:14]
-<ulm> second vote is "should it be banned in EAPI 6 already?"
-<rich0> dberkholz: ++
-<ulm> dberkholz: that's a no to the second vote then?
-<dilfridge> I'm fine with both variants (ban in 6 / deprecate in 6, ban in 7)
-<dberkholz> ulm: no to banned in 6. right.                              [21:15]
-<rich0> I'm in favor of deprecation.  I don't want to see a lack of an eclass
-        as something that slows EAPI6 adoption.
-<ulm> do I count this right?                                            [21:16]
-<ulm> Williamh, ulm, radhermit: yes
-<dberkholz> we should have a deprecation process that's part of the eapi, not
-            just randomly deprecating stuff independent of that
-<ulm> dberkholz, rich0: no
-<ulm> dilfridge: abstain
-<ulm> ?
-<ulm> who's missing?
-<blueness> me
-<blueness> i'm in favor of deprecation in 6, ban in 7
-<ulm> so dberkholz, rich0, blueness: no                                 [21:17]
-<blueness> correct
-<ulm> 3 yes 3 no 1 abstention then
-<ulm> motion doesn't pass
-<WilliamH> neither one passes
-<ulm> the motion was to ban it in EAPI 6                                [21:18]
-<ulm> so, the alternative then
-<ulm> "deprecate dohtml now, ban it in EAPI 7?"
-* ulm yes
-* dilfridge yes
-* WilliamH no because we should ban it                                  [21:19]
-<blueness> yes
-<WilliamH> deprecation will be ignored when people adopt eapi 6.
-* rich0 yes
-<radhermit> have we cleanly deprecated and then dropped similar things before?
-                                                                        [21:20]
-<WilliamH> radhermit: I think we have just dropped some things before, e.g.
-           dosed
-<WilliamH> There wasn't a deprecation eapi for that.
-<WilliamH> We just told people to start using sed -i
-<ulm> radhermit: dosed, dohard                                          [21:21]
-<rich0> The problem with dohtml, is that there isn't really a drop-in
-        replacement for it
-<ulm> AA, KV* varibles
-<ulm> *variables
-<WilliamH> rich0: and as long as we don't drop it there won't be.
-<blueness> rich0, you can use dodoc
-<radhermit> I mean I'm all for having a decent way to deprecate eapi features
-<WilliamH> Yes,  you can use docinto/dodoc                              [21:22]
-<blueness> radhermit, you would just add a warning in portage when its called
-<radhermit> so I'm fine-ish with this
-<ulm> radhermit: will be via a repoman warning probably
-<radhermit> blueness: I'm more thinking how to handle it in pkgcore ;)
-<WilliamH> blueness: and who will ignore the warning?
-<radhermit> but yes
-<WilliamH> Let's just kill the thing... :(
-<blueness> radhermit, yeah i just recently learned about pkgcore!  its your
-           baby                                                         [21:23]
-<ulm> dberkholz: I count you as "yes" from what you said above
-<ulm> so this passes with 6 yes 1 no
-<dberkholz> cool
-<radhermit> I mean I know people will probably just ignore it, but doing the
-            deprecated -> dropped steps for formal specs is generally better
-            imo                                                         [21:24]
-<ulm> I suggest we change order of the laast two questions
-<ulm> should einstalldirs in EAPI 6 use dodoc -r for HTML_DOCS, instead of
-      dohtml?
-<ulm> *last
-<ulm> oops, that's a typo                                               [21:25]
-<ulm> should einstalldocs in EAPI 6 use dodoc -r for HTML_DOCS, instead of
-      dohtml?
-<ulm> einstalldocs is a new function in EAPI 6
-<radhermit> well if we're deprecating things, yes dohtml shouldn't be used
-<radhermit> in the default case                                         [21:26]
-<ulm> IMHO it doesn't make sense to use a deprecated function
-<radhermit> right
-<ulm> do we even have to vote on this one?
-<blueness> ulm just not it as an obvious point
-<blueness> err                                                          [21:27]
-<blueness> ulm just note it as an obvious point
-<ulm> anyone against this? speak up now
-<blueness> its fine
-<dilfridge> sounds ok
-<ulm> k
-<ulm> so, do we need a substitute in an eclass?
-<ulm> dohtml in portage is written in python
-<ulm> so the code cannot simply be copied                               [21:28]
-<blueness> i would have the deprecation notice say "use dodoc -r ..."   [21:29]
-<ulm> does anyone know in what language dohtml in pkgcore and paludis is
-      implemented in?
-<blueness> c++
-<blueness> well c++ in paludis
-<blueness> pkgcore is in python
-<radhermit> pkgcore -> python
-<radhermit> right
-<ulm> blueness: somehow I doubt it for this ebuild helper
-<rich0> Technically you could have a python script as a build-time
-        dependency...                                                   [21:30]
-<ulm> c++, that is
-<blueness> ulm, let me look
-<radhermit> I don't know about paludis
-<ulm>
-      http://git.exherbo.org/paludis/paludis.git/tree/paludis/repositories/e/ebuild/utils/dohtml
-<ulm> so it's in bash
-<ulm> so it could be used (modulo copyright assignment problems)        [21:31]
-<ulm> anyway, that's a detail
-<blueness> yeah but what confused me is its in a Makefile.am too ...    [21:32]
-<blueness> but you're right its written in bash
-<ulm> question is if we want a replacement in an eclass at all
-<radhermit> why do we need one?
-<ulm> I'd say we recommend dodoc -r
-<ulm> and if there's a strong need, someone will come up with an eclass
-      function anyway                                                   [21:33]
-<ulm> we cannot forbid that, I think
-<ulm> any further opinions?
-<rich0> ulm: ++                                                         [21:34]
-<rich0> I think we can deprecate it, and if there is a big unmet need people
-        will fix it.
-<ulm> so how about: "the council does not mandate a replacement function in an
-      eclass"?                                                          [21:35]
-<WilliamH> ulm: I don't think it is necessary for us to state that even.
-<ulm> is "mandate" the right verb?
-<rich0> We don't implement nroff, autotools, etc in an eclass either -
-        packages that need them depend on them.
-<rich0> (well, autotools are in @system I think)
-<blueness> it is the correct verb, but i think we can remain silent on the
-           issue
-<radhermit> why would we remove it and then say it'll go in an eclass?  [21:36]
-<ulm> ok, so we don't say anything about eclasses
-<radhermit> just deprecate -> remove it and people will either move on or
-            complain on the list later :P
-<blueness> right just don't say anything
-<rich0> agree
-<blueness> we are only talking about PMS here, not what someone might upt in
-           an eclass                                                    [21:37]
-<rich0> We can always hash out on the mailing list.
-<ulm> makes sense
-<rich0> We aren't going to stop somebody from coming up with a replacement for
-        dohtml, and on the other hand we can't do anything to force one to be
-        created either
-<ulm> are we done with this topic?
-<ulm> next: open bugs                                                   [21:38]
-<radhermit> pretty much
-<ulm> bug 503382
-<willikins> https://bugs.gentoo.org/503382 "Missing summaries for 20131210,
-            20140114, and 20140225 council meetings"; Doc Other,
-            Project-specific documentation; CONF; ulm:council
-<ulm> dberkholz?
-<ulm> looks like 20131210 and 20140114 summaries are done               [21:39]
-<ulm> btw, would anyone object if I move the index of meeting logs to a
-      subpage in the wiki?                                              [21:40]
-<radhermit> nope                                                        [21:41]
-<ulm> because loading time for the council project page has become rather long
-<blueness> ah good poing
-<blueness> point
-<dilfridge> do it, sounds good                                          [21:42]
-<ulm> so, some progress with this bug
-<ulm> 20140225 summary is still missing
-<ulm> and I'll move the meeting logs to a subpage
-<ulm> open floor then
-<ulm> anything?                                                         [21:43]
-<blueness> one announcement, i think i'll have GLEP 64 ready for voting by
-           next time
-<ulm> k
-<blueness> are there any comments from the council yet, i thin there's been
-           good discussion on the ml
-<blueness> think
-<blueness> (i can't type today!)                                        [21:44]
-<ulm> blueness: I haven't found the time yet for going through it thoroughly
-<ulm> but I'll do so
-<blueness> k                                                            [21:45]
-<dberkholz> ulm: yeah i put those two in the wiki, i had uploaded them before
-            but forgot to head back to the wiki page an hour later to add the
-            link
-<dberkholz> sorry for the crazy lag, i'm on a terrible connection and keep
-            dropping
-<ulm> dberkholz: any ETA for the february summary?
-<ulm> for the next meeting, I expect that we'll discuss einstall removal
-                                                                        [21:46]
-<ulm> ok                                                                [21:47]
-<ulm> seems there's nothing from the community
-<ulm> next meeting is on October 14th                                   [21:48]
-<ulm> who will be chairing?
-<ulm> rich0: the council page says it's you
-<rich0> yup                                                             [21:49]
-<blueness> okay
-*** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council:
-    "Next meeting: Tuesday, 14 Oct 2014 19:00 UTC |
-    http://www.gentoo.org/proj/en/council/utctolocal.html?time=19:00 |
-    http://wiki.gentoo.org/wiki/Project:Council"
-<ulm> this meeting is closed then
-<ulm> thanks all
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20141014-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20141014-summary.txt
deleted file mode 100644
index e984e53ff7..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20141014-summary.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-Roll call
-=========
-
-
-Present: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh 
-Absent: 
-
-
-The future of einstall
-======================
-"Einstall will be removed from EAPI6."
-aye: creffett (proxy for ulm), dberkholz, radhermit, rich0, williamh
-
-
-GLEP 64
-=======
-"We approve GLEP64 as documented at
-https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 with API versioning
-added."
-
-
-aye: blueness, dberkholz, dilfridge, radhermit, rich0
-abstain: creffett (proxy for ulm), williamh
-
-
-Git Migration Issues
-====================
-"do we need to continue to create new ChangeLog entries once we're operating in git?"
-
-No: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh
-
-"The yyyy/ prefix can be dropped from gentoo-news, timing to be
-determined by those implementing the change."
-
-Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh 
-
-Can we drop CVS headers post-migration?
-
-Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh 
-
-"The git migration should produce a separate historical and current
-repository, which can be spliced using git replace, but which are
-otherwise not connected."
-
-Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh 
-
-"we don't see any big remaining obstacles and advise infra / the git
-migration project to proceed at their pace"
-
-Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh 
-
-(Meeting was called due to time, with remaining items to be covered following week.)
\ No newline at end of file
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20141014.txt b/xml/htdocs/proj/en/council/meeting-logs/20141014.txt
deleted file mode 100644
index e012d3781c..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20141014.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-[15:00:07] <rich0> Ok, roll call :)
-[15:00:10] <radhermit> here
-[15:00:15] <WilliamH> here
-[15:00:16] <dberkholz|mob> Sup
-[15:00:49] -*- creffett|irssi here for ulm, unless ulm is here already
-[15:01:02] <rich0> blueness, dilfridge, ulm?
-[15:01:57] <rich0> Ok, let's get started.
-[15:02:04] <rich0> First item, future of einstall
-[15:02:14] <rich0> http://thread.gmane.org/gmane.linux.gentoo.devel/92713
-[15:02:14] <rich0> http://thread.gmane.org/gmane.linux.gentoo.devel.announce/2212/focus=4025
-[15:02:27] <rich0> Should einstall be banned in EAPI6.
-[15:02:32] <rich0> Any comments beyond the lists?
-[15:02:37] -*- creffett|irssi reviews his notes
-[15:02:49] <creffett|irssi> no comments here
-[15:02:54] <WilliamH> none here
-[15:03:27] <radhermit> I don't have anything more to say
-[15:03:32] <rich0> Ok, let's vote then.  "Einstall will be removed from EAPI6."
-[15:04:07] -*- creffett|irssi yes
-[15:04:12] <dberkholz|mob> Yep
-[15:04:13] <radhermit> yes
-[15:04:16] <WilliamH> yes
-[15:04:31] -*- rich0 yes
-[15:04:49] <rich0> Ok, that's all of us
-[15:05:02] <rich0> Next item...
-[15:05:11] <rich0> https://wiki.gentoo.org/wiki/User:Blueness/GLEP64
-[15:05:20] <rich0> Blueness is requesting approval on this.
-[15:05:24] <radhermit> someone want to text blueness?
-[15:05:30] <rich0> good idea
-[15:06:24] <dilfridge> sorry, here
-[15:06:26] <rich0> I just texted him
-[15:06:55] <rich0> Do we want to move on to git?
-[15:07:05] <radhermit> sure
-[15:07:06] <rich0> I'd prefer to give him the option to present.
-[15:07:11] <blueness> here!!!
-[15:07:11] <rich0> Ok, let's move on to git.
-[15:07:16] <blueness> sorry thanks rich
-[15:07:18] <rich0> never mind. :)
-[15:07:22] <blueness> rich0,
-[15:07:24] <rich0> let's do glep64 - I think it will be faster
-[15:07:41] <rich0> blueness: do you have any comments you want to make?
-[15:07:51] <blueness> rich0, just a few points
-[15:07:58] <blueness> its was discussed on gentoo-dev@
-[15:08:14] <blueness> it got feedback for ciarian and incorportated it
-[15:08:28] <blueness> do you need me to repeate the motivation?
-[15:08:39] <rich0> Nah - at least not for me.
-[15:08:42] <rich0> I can read.  :)
-[15:08:52] <rich0> My only real comment is that it is a bit vague - deliberately so.
-[15:09:07] <blueness> this is the latest version -> https://wiki.gentoo.org/wiki/User:Blueness/GLEP64
-[15:09:11] <rich0> I don't mind approving it per se, but do we think that it will go anywhere?
-[15:09:37] <rich0> Ie are the various package managers behind it?
-[15:09:37] <dberkholz|mob> Do we have agreement in theory from PM implementers?
-[15:09:38] <blueness> rich0, i will try to work with ciarian and actually write code
-[15:09:55] <WilliamH> blueness: what about pkgcore?
-[15:09:56] <blueness> i'd like to hear from radhermit and package core
-[15:09:56] -*- dberkholz|mob high-fives rich0
-[15:10:32] <blueness> radhermit, ping ^^^
-[15:10:45] <blueness> also zmedico was in support
-[15:10:46] -*- radhermit is trying to skim through the mailing list thread :)
-[15:10:53] <blueness> radhermit, okay
-[15:10:58] <rich0> It sounds like most of this is in portage, it just needs the API to be written.
-[15:11:08] <rich0> From what I know of portage, it won't be hard to do there.
-[15:11:17] <rich0> Just needs commitment to the API.
-[15:11:27] <radhermit> can we version the vdb or something if we start properly specifying it?
-[15:11:40] <radhermit> maybe that's already in the glep
-[15:11:53] <blueness> radhermit, i didn't mention a version to vdb
-[15:12:00] <rich0> This GLEP doesn't really specify the VDB, so much as require an interface to it (without actually specifying it).
-[15:12:17] <radhermit> so mainly it's about standardized file naming?
-[15:12:17] <blueness> for the reason rich0 just mentioned ^^^
-[15:12:24] <rich0> It might not hurt to incorporate some kind of VAPI versioning.
-[15:12:35] <blueness> radhermit and standardizing what's exported
-[15:12:40] <dberkholz|mob> Seems to me that vdb version would be a portage internal matter
-[15:12:47] <rich0> It basically is a spec for the spec.
-[15:12:48] <dberkholz|mob> What I care about is an API version on this
-[15:13:23] <blueness> dberkholz|mob, i can add a sentence to that effect
-[15:13:24] <rich0> dberkholz|mob: ++
-[15:13:30] <dilfridge> good idea
-[15:13:36] <rich0> That should be a part of the API when it is specified.
-[15:13:58] <radhermit> basically what I meant
-[15:14:20] <rich0> It feels a bit odd to approve this other than going along with the general sentiment that it is a good idea, but I have no objections to it.
-[15:14:33] <rich0> It just feels a bit like approving a business case, vs a spec.
-[15:14:51] <blueness> yeah, it turns out now there are not only several packages but also one eclass depending on vdb information from portage, none of which work with other pm's but could
-[15:15:18] <rich0> SELinux and such sounded like a really good use case here.
-[15:15:27] <rich0> You'd want that to work with any PM.
-[15:15:48] <rich0> Or PaX in your example.
-[15:15:58] <blueness> rich0, the way selinux eclass works now is it looks for reverse deps to do the markings
-[15:15:59] <radhermit> mostly I'd like to quit having to read through portage code to make stuff like eix work :)
-[15:16:04] <radhermit> with pkgcore-merged pkgs
-[15:16:35] <rich0> Yeah, I have an EAPI hunter that depends on portage APIs, though to be fair this only pertains to installed packages I believel.
-[15:16:45] <rich0> It might make sense to extend that API to installable packages as well.
-[15:16:46] <blueness> yeah, i didn't even know about pkgcore until recently and it could benefit from this too
-[15:17:06] <rich0> Ok, do we want to vote to approve this?
-[15:17:13] <dilfridge> +
-[15:17:48] <rich0> "We approve GLEP64 as documented at https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 "
-[15:17:56] <rich0> Does that work?
-[15:18:00] <blueness> sure
-[15:18:10] <rich0> You can promise not to change it too much.  :)
-[15:18:13] <rich0> Ok, let's vote.
-[15:18:17] <blueness> o
-[15:18:21] -*- rich0 yes
-[15:18:26] <dilfridge> yes
-[15:18:27] -*- blueness yes
-[15:18:32] -*- creffett|irssi abstain
-[15:18:36] <dberkholz|mob> Yes + API version
-[15:18:45] -*- WilliamH abstain
-[15:19:09] <radhermit> yes with API version stuff
-[15:19:28] <blueness> ulm, ?
-[15:19:37] <radhermit> creffett|irssi is ulm
-[15:19:49] <rich0> Ok, that's everybody - 5-0
-[15:20:03] <rich0> And that includes the API version - I'll note that in the sumary.
-[15:20:21] <blueness> rich0, and everyone, i think that just a one sentencer no?
-[15:20:26] <rich0> I'll document it as: "We approve GLEP64 as documented at https://wiki.gentoo.org/wiki/User:Blueness/GLEP64 with API versioning added."
-[15:20:33] <rich0> blueness: wfm
-[15:20:52] <rich0> Ok, now the fun topic.
-[15:20:54] <rich0> Git migration
-[15:21:11] <dilfridge> wheee
-[15:21:14] <blueness> shudder
-[15:21:19] <rich0> My personal goal here would be to get opinions recorded anywhere we think they matter.
-[15:21:25] <rich0> We're not going to bikeshed every detail.
-[15:21:39] -*- mgorny is around to help :P
-[15:21:41] <rich0> But, if there are things that we feel must be in place to do a migration, we should try to get them documented.
-[15:21:44] <rich0> That is my sense of it.
-[15:21:48] -*- WilliamH thinks we need to stop waiting for a perfect world and get it done ;-)
-[15:22:05] <rich0> Any other comments before we dive in?
-[15:22:34] <creffett|irssi> bring it on!
-[15:22:44] <rich0> The first question in the agenda, is do we need to continue to create new ChangeLog entries once we're operating in git?
-[15:22:54] -*- WilliamH no
-[15:22:59] <dilfridge> no
-[15:23:02] <rich0> no
-[15:23:07] <creffett|irssi> nope.
-[15:23:09] -*- blueness no
-[15:23:18] <dberkholz|mob> hell no
-[15:23:43] <radhermit> no
-[15:23:51] <rich0> Ok, well, let's just call that a vote.  :)
-[15:23:52] <dilfridge> !
-[15:24:26] <rich0> Ok, let's skip "are we done yet" and move that to the end after we tackle all the specifics
-[15:24:34] <rich0> Can yyyy/ prefix be dropped from gentoo-news?
-[15:24:44] <rich0> We've been through that one once before.
-[15:24:54] <rich0> http://archives.gentoo.org/gentoo-dev/msg_00f0a83b760b78c1baf32f118d1cb008.xml
-[15:25:01] <rich0> https://bugs.gentoo.org/show_bug.cgi?id=523828
-[15:25:23] <rich0> mgorny: will dropping this still make your life easier with metadata?
-[15:25:38] <mgorny> rich0: a bit
-[15:25:59] <mgorny> i just find it utterly stupid that 'reading' and 'writing' formats are different
-[15:26:06] <rich0> ++
-[15:26:11] <dilfridge> drop it
-[15:26:27] <rich0> Any opposing commentary?
-[15:26:38] <blueness> nah, no contraversy here
-[15:26:46] <dberkholz|mob> Nope
-[15:26:49] <blueness> who needs to implement this infra?
-[15:27:07] <mgorny> someone commit to repo + infra change the script used for gen
-[15:27:32] <rich0> Ok, let's vote "The yyyy/ prefix can be dropped from gentoo-news, timing to be determined by those implementing the change."
-[15:27:44] <rich0> Does that work?
-[15:27:44] -*- blueness yes
-[15:27:47] -*- rich0 yes
-[15:27:50] -*- creffett|irssi yes
-[15:27:50] -*- WilliamH yes
-[15:27:51] <dilfridge> yes
-[15:27:59] <radhermit> yes
-[15:28:04] <dberkholz|mob> Sure
-[15:28:49] <rich0> ok
-[15:29:10] <rich0> Ok, going in order of controversy...
-[15:29:15] <rich0> Can we drop CVS headers post-migration?
-[15:29:24] -*- WilliamH yes
-[15:29:29] -*- rich0 burn with nuclear fire
-[15:29:31] <dilfridge> yes please
-[15:29:33] <creffett|irssi> KILL IT
-[15:29:38] <blueness> heh
-[15:29:41] <WilliamH> I don't think ghere is an equivalent to that in git.
-[15:29:43] <creffett|irssi> er, I mean, yes
-[15:30:24] <rich0> dberkholz|mob, radhermit - care to make it a vote?
-[15:30:37] <rich0> blueness: also?
-[15:30:39] <dberkholz|mob> Yes pls
-[15:30:48] <radhermit> kill it of course
-[15:31:06] <rich0> blueness: heh==yes?
-[15:31:18] <blueness> yes
-[15:31:23] <dilfridge> heh we're fast :)
-[15:31:33] <rich0> ok
-[15:31:39] <rich0> Now a bit more controversy.
-[15:31:49] <rich0> Should we have separate git trees for historical vs current portage (with no parent commit reference from the one to the other)?  
-[15:32:02] <rich0> http://thread.gmane.org/gmane.linux.gentoo.project/4030/
-[15:32:37] <creffett|irssi> rich0: here's my question -- if someone did want to join the two trees locally, how much work would it be?
-[15:32:43] <dilfridge> if we can arrangeit that they can be combined seamlessly into one, yes
-[15:32:51] <dberkholz|mob> I would prefer a spliceable one
-[15:32:55] <rich0> mgorny: you probably have more git replace experience than I
-[15:33:19] <mgorny> git fetch history-remote; git replace ${first_commit_id} ${history_commit_id}
-[15:33:23] <rich0> I'd think you could just fetch a second origin into another branch and then git replace the one into the history of the other
-[15:33:29] <mgorny> (or teh other way around :P, easy to put on wiki)
-[15:33:47] <radhermit> I'd vote for spliceable too
-[15:33:55] <rich0> Yeah, you'd make the last commit in the history repo = the first commit in the active tree when doing a history
-[15:33:55] <dilfridge> means?
-[15:34:06] <radhermit> meaning you can graft the old tree onto the new one
-[15:34:12] <rich0> radhermit: exactly
-[15:34:14] <radhermit> if you want a giant, historical repo
-[15:34:24] <WilliamH> Which ever one can get us up and running sooner. ;-)
-[15:34:33] <rich0> Git will treat references to the first commit in the current tree as if it pointed to the last commit in the history tree.
-[15:34:33] <creffett|irssi> so it's fairly simple to do the join if someone wants to?
-[15:34:39] <radhermit> the old graft can technically be done later
-[15:34:39] <rich0> So it would appear to have a continuous history.
-[15:34:45] <mgorny> creffett|irssi: yes, only time consuming for fetch :)
-[15:34:53] <creffett|irssi> mgorny: okay
-[15:34:58] <creffett|irssi> then yes, separate is fine with me
-[15:35:01] <dilfridge> radhermit: dberkholz|mob: I don't understand what your "spliceable" version does different
-[15:35:06] <WilliamH> I have a question...
-[15:35:06] <blueness> rich0, what's the gain on the divisionb between historical and current?
-[15:35:14] <rich0> blueness: I outlined that in my post.
-[15:35:22] <blueness> k
-[15:35:25] <rich0> The current historical migrations have issues.
-[15:35:43] <rich0> If we improve on them, then the original "official" migration turns into baggage.
-[15:35:55] <dilfridge> blueness: we can start immediately and care about the exact history later
-[15:35:56] <rich0> You could still splice a new migration over the old one.
-[15:36:05] <WilliamH> So, if we have two trees: one would contain the history before the migration, and we would update the other from that point forward not worrying about the historical tree right?
-[15:36:14] <mgorny> blueness: 1.5G
-[15:36:24] <rich0> It also sidesteps arguments over whether the current migration is good enough, and makes the migration MUCH faster.
-[15:36:25] <dilfridge> WilliamH: basically, yes. we start from a current point.
-[15:36:26] <mgorny> 70M is 'current' afresh and grows
-[15:36:29] <mgorny> 1.5G is historical and grows
-[15:36:30] <blueness> so speed size and simplicity
-[15:36:57] <blueness> what happens in the far future when it gets 1.5GB again, can it be sliced again?
-[15:36:57] <dberkholz|mob> Ah I hadn't tracked the work on git replace. I'm fine with that
-[15:36:57] <dilfridge> the conversion of the cvs history becomes a non-blocker, and non-critical project
-[15:37:16] <rich0> exactly.  I'd still run the best migration that I could.
-[15:37:32] <rich0> But, issues with it don't hold things up, and it could be improved on later.
-[15:37:54] <rich0> Any other questions/concerns?
-[15:38:10] <dilfridge> git question, if you end up pulling two separate histories, is there a way to prune the old, unused objects?
-[15:38:16] <dilfridge> mgorny: ^
-[15:38:36] <WilliamH> I think "git gc" will do that.
-[15:38:37] <dilfridge> (not important now, just curiosity)
-[15:38:42] <mgorny> dilfridge: there will be no unused objects if you merge them via replace
-[15:38:55] <dilfridge> ok
-[15:38:56] <mgorny> unless you mean after removing the history replace, then gc should catch them
-[15:39:02] <dilfridge> ok
-[15:39:03] <dilfridge> good
-[15:39:25] <rich0> Yeah, the beauty of having separate repos is that you can easily get rid of the 750k bad commits if you have 750k better ones to replace them with.
-[15:39:42] <dilfridge> hehe
-[15:39:56] <rich0> The converted repository is pretty impressive, for all its faults.  :)
-[15:40:04] <rich0> Something like 3M objects I think.
-[15:40:27] <rich0> Ok, anything else before we vote?
-[15:40:33] <blueness> i'm good
-[15:40:48] <mgorny> if you mean having history1 repo and replacing part of it with history2, then objects from both repos will have to be kept
-[15:40:53] <dberkholz|mob> I just want to make sure that the join gets tested, but I'm assuming that will happen
-[15:41:07] <mgorny> dberkholz|mob: i've already tested it initially
-[15:41:09] <rich0> "The git migration should produce a separate migrated and current repository, which can be spliced using git replace, but which are otherwise not connected."
-[15:41:11] <dberkholz|mob> Awesome.
-[15:41:20] <rich0> Any issues with the wording?
-[15:41:31] <dberkholz|mob> What does "current" mean
-[15:41:32] <rich0> The "which can be spliced with git replace" should cover the testing concerns.
-[15:41:40] <dberkholz|mob> Last year, last X commits to each file, etch
-[15:41:45] <rich0> Maybe historical and current ?
-[15:41:47] <dberkholz|mob> etc*
-[15:42:07] <rich0> Current means basically what you have in /usr/portage, really.
-[15:42:10] <mgorny> newest version snapshot
-[15:42:14] <rich0> Minus metadata/etc.
-[15:42:14] <dberkholz|mob> And i'd go with s/migrated/historical/ , "full history" or something like that
-[15:42:15] <mgorny> 'cvs up -dP'
-[15:42:20] <rich0> Agree
-[15:42:23] <mgorny> with some cleanup
-[15:42:27] <dberkholz|mob> Oh a funtoo style thing with zero history
-[15:42:35] <mgorny> that's the safe way of ensuring that we don't end up starting with broken repo
-[15:42:35] <rich0> "The git migration should produce a separate historical and current repository, which can be spliced using git replace, but which are otherwise not connected."
-[15:42:39] <mgorny> like current history migration causes
-[15:43:15] <rich0> Well, we can at least get the CURRENT tree right with the migration.  It is identical now.
-[15:43:25] <rich0> Go one commit back and it is less so.
-[15:43:35] <rich0> Ok, if no issues with the wording...
-[15:43:51] <rich0> Let's vote: "The git migration should produce a separate historical and current repository, which can be spliced using git replace, but which are otherwise not connected."
-[15:43:55] -*- rich0 yes
-[15:44:10] -*- blueness yes
-[15:44:18] <radhermit> yes
-[15:44:21] <creffett|irssi> yes
-[15:44:30] -*- dilfridge yes
-[15:44:31] -*- WilliamH yes
-[15:44:44] <dberkholz|mob> k
-[15:44:56] <rich0> ok, 7-0
-[15:45:13] <rich0> That brings us to, "are we done yet?"
-[15:45:37] <rich0> Are there any other high-level blockers we should consider, beyond just getting everything implemented and coordinated with infra, the migration team, etc?
-[15:45:59] <dberkholz|mob> Beyond implementation. Like that's a minor issue. heh
-[15:46:05] <dilfridge> mgorny: how's the status of whatever server-side hooks we need?
-[15:46:07] <rich0> Also, what do we want the actual migration to look like?  Do we need to approve the final cutover, etc?
-[15:46:23] <dberkholz|mob> It would be helpful if we could open up whatever backend code possible to enable more people to easily work on it
-[15:46:37] <rich0> dberkholz|mob: ++ that is a problem with our current infra I think.
-[15:46:42] <blueness> dberkholz|mob, yeah i'd like to see that
-[15:46:46] <rich0> No reason the hooks/etc can't be FOSS.
-[15:46:53] <mgorny> dilfridge: mostly done, i think infra will handle the remaining updates
-[15:46:55] <rich0> Obviously passwords/configs/etc can be private.
-[15:47:22] <dilfridge> is anyone from infra around who cares to comment? _robbat21irssi?
-[15:47:45] <rich0> Making this FOSS would help a lot with anybody interested in "rolling your own Gentoo" 
-[15:47:59] <mgorny> my code is on github, i think
-[15:48:01] <mgorny> or bitbucket ;P
-[15:48:11] <rich0> mgorny: I believe so.  
-[15:48:49] <dilfridge> ok, let's consider a wurst-case scenario
-[15:49:03] <rich0> dilfridge: systemd eats the repo?  :)
-[15:49:04] <blueness> mgorny, email the community whree the hooks are so we can take a look at them
-[15:49:07] <dilfridge> mgorny: if things fail badly, can we go back to cvs?
-[15:49:25] -*- radhermit is going afk for a bit
-[15:49:25] <dilfridge> (not that I want to, this is merely contingency planning)
-[15:49:25] <mgorny> they were linked in my mails :P
-[15:49:36] <rich0> dilfridge: that would be painful, at least if you wanted to preserve all the individual commits.
-[15:49:44] <creffett|irssi> dilfridge: we would need a way to go git -> CVS to dump the history back into CVS
-[15:49:44] <mgorny> dilfridge: i guess so though 'over dead commit access' of many people :)
-[15:49:50] <rich0> If we want to do some kind of big test, better to do it first.
-[15:50:12] <creffett|irssi> dilfridge: you could compromise, get a git->CVS bridge and keep the old CVS repo around for a little while until we're sure the bugs have been ironed out
-[15:50:14] <dilfridge> preserving individual commits is second order problem, first priority would be to keep us functional.
-[15:50:19] <dberkholz|mob> Can we stand up a beta, tell people to play with it for a week or so, then do the real cutover
-[15:50:34] <dberkholz|mob> Or is our infra setup not able to cope with that kind of duplication
-[15:50:44] <rich0> Well, having a read-only cvs for reference for a while makes sense.  We can keep a CVSROOT tarball forever, basically.
-[15:50:48] <dilfridge> in this emergency case I'd be happy enough with seeing one big cvs commit "forward one week"
-[15:51:06] <rich0> dberkholz|mob: we're basically doing the beta on github already.
-[15:51:19] <rich0> I suppose it could be done on infra as well.
-[15:51:22] <dberkholz|mob> Yeah but it's not full fledged
-[15:51:27] <dberkholz|mob> That's a repo test, not a full distribution test
-[15:51:43] <rich0> It certainly doesn't involve mirrors and all that.
-[15:51:49] <mgorny> excelsior has all the git+rsync bits
-[15:51:49] <rich0> Were you thinking full-scale end-to-end?
-[15:51:53] <dilfridge> not sure how it could be full-fledged without switching e.g. the rsync mirror generation etc
-[15:52:05] <dilfridge> and that would also affect our users, so no beta
-[15:52:07] <dberkholz|mob> Don't need full scale, but at least full stack
-[15:52:11] <rich0> We do generate all the way up to rsync trees though.
-[15:52:24] <rich0> We can try to aggressively promote them.
-[15:52:27] <dilfridge> sounds good.
-[15:52:34] <WilliamH> So are we keeping rsync after the migration (I'm confused about that part)
-[15:52:40] <mgorny> yes
-[15:52:45] <mgorny> users can choose between git & rsync
-[15:52:47] <rich0> Though all users can really do is sync them.  Unless we systematically sync all cvs commits it won't be the same as cvs.
-[15:53:04] <rich0> mgorny: ++ - at least for now.
-[15:53:14] <rich0> I think we should just generate the existing rsync, webrsync stuff.
-[15:53:18] <rich0> Allow git as another option.
-[15:53:24] <mgorny> this also means end users will not notice much of a difference
-[15:53:24] <rich0> Then maybe consider more change down the road.
-[15:53:38] <mgorny> except for disappearing changelogs and possibly resigned manifests
-[15:53:45] <blueness> hmm ... will there be a delay between developer commits and staging to the mirrors like there currently is?
-[15:54:23] <rich0> blueness: there would have to be some
-[15:54:35] <rich0> mgorny: any idea what it would be?
-[15:54:37] <mgorny> depends on exact implementation
-[15:54:49] <rich0> It shouldn't be any worse than what we have now, at least.
-[15:54:49] <blueness> we should try to keep one, just in case
-[15:54:55] <mgorny> right now, there's ~3 minutes between dev git & master rsync, i think
-[15:54:57] <rich0> I'd think that git will sync faster if nothing else.
-[15:55:06] <mgorny> mirrors could fetch more often than rsync
-[15:55:12] <mgorny> than with rsync*
-[15:55:13] <dberkholz|mob> With git we could take a more push-driven approach
-[15:55:20] <rich0> cvs syncing requires a full tree traversal.  git syncing is a lot smarter.
-[15:55:21] <dberkholz|mob> Instead of 30 minute cron jobs or whatever
-[15:55:37] <rich0> (you basically have COW at each level of the tree)
-[15:56:20] <rich0> Ok, I have a hard stop in 4 mins.
-[15:56:26] <rich0> Anything else on this?
-[15:56:37] <rich0> I guess my question is, what next from us?
-[15:56:43] <rich0> Do we need to approve some final cutover plan?
-[15:56:51] <mgorny> 'd love to have games team decision today thouhg :P
-[15:56:55] <rich0> Or do we just leave it up to infra and the migration team to just tell everybody what to do?
-[15:57:21] <rich0> I don't necessarily mind if the rest continue on without me, but somebody else would have to chair that.
-[15:57:30] <rich0> But, if we can wrap up git...
-[15:57:45] <rich0> Does anybody feel that we need a final council vote on "all systems go?"
-[15:57:48] -*- WilliamH thinks we really can't do anything more at this point.
-[15:57:55] <rich0> Or can we just hand over the keys?
-[15:58:10] <dilfridge> we need to take the step at some point.
-[15:58:14] <dilfridge> so why not now.
-[15:58:20] <rich0> Obviously we can step in off-schedule if we see cause to panic.  :)
-[15:58:22] <blueness> i'd like to hear from infra about this
-[15:58:27] <dilfridge> that said, *some* input from infra would be nice.
-[15:58:30] <blueness> since they have to brunt the work
-[15:58:40] <rich0> Well, nothing happens until they do something anyway.
-[15:58:40] <blueness> dilfridge, collision!
-[15:58:47] <dilfridge> :]
-[15:58:58] <blueness> rich0, yeah but we really need to know if they're okay with this plan
-[15:59:06] <rich0> I was thinking more in terms of whether we can just let infra and the git migration project run with the rest.
-[15:59:24] -*- WilliamH doesn't see any reason not to
-[15:59:40] -*- creffett|irssi needs to go shortly as well
-[15:59:46] <rich0> Ok, I think we're basically all for moving forward, but we just want to make sure that infra is coordinated.
-[15:59:49] <dilfridge> why not... we could just do a vote along "we don't see any big remaining obstacles and advise infra / the git migration project to proceed at their pace"
-[16:00:05] <rich0> dilfridge: I'm fine with that.
-[16:00:08] <rich0> Any strong objections?
-[16:00:15] <blueness> not really
-[16:00:27] <rich0> Ok. Let's vote, I have to RUN!  :)
-[16:00:27] <creffett|irssi> no objections
-[16:00:29] -*- rich0 yes
-[16:00:31] -*- creffett|irssi yes
-[16:00:34] -*- dilfridge yes
-[16:00:34] -*- blueness yes
-[16:00:38] -*- WilliamH yes
-[16:00:44] <dberkholz|mob> ye
-[16:00:45] <dberkholz|mob> s
-[16:00:56] <dilfridge> rich0: shall I take over or do we postpone the rest?
-[16:01:05] <dberkholz|mob> I've gotta run too, as did somebody else
-[16:01:06] <rich0> radhermit ?
-[16:01:13] <rich0> I suggest we adjourn.
-[16:01:13] <dilfridge> ok then postpone I guess
-[16:01:16] <rich0> Next week?
-[16:01:20] <blueness> next week
-[16:01:24] -*- WilliamH is fine with next week
-[16:01:24] <dilfridge> next week
-[16:01:49] <dberkholz|mob> wfm
-[16:02:00] <rich0> Ok, we are adjourned until next week.  Radhermit, ping me with your vote on the last bit.  :)
-[16:02:17] <rich0> I'll post log/summary
-[16:02:20] <rich0> Thanks, all!
-[16:02:32] <rich0> sorry, mgorny
-[16:02:40] <rich0> games + herds next time
-[16:02:42] <rich0> adios
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20141021-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20141021-summary.txt
deleted file mode 100644
index 3ba9d84602..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20141021-summary.txt
+++ /dev/null
@@ -1,57 +0,0 @@
-Roll call
-=========
-
-Present: blueness, dilfridge, radhermit, rich0, ulm, williamh 
-Absent: dberkholz
-
-
-Deprecating and killing the concept of herds
-============================================
-"The council is in favor of retiring herds, allowing non-maintainer
-aliases to exist, and having a way to distinguish between individuals,
-projects, and non-maintainer aliases in metadata.xml.  The details of
-how to implement this will be worked out in the lists before the next
-meeting."
-
-Aye: blueness, dilfridge, radhermit, rich0, ulm, williamh 
-
-
-Status of Games Team
-====================
-"Council deferrs to radhermit to continue working with the games team on
-the organization issues for another month.  Council will reach out to
-QA/Treecleaners and support their reviewing games packages as any other
-as far as bugs/security/QA/etc goes."
-
-Aye: blueness, dilfridge, radhermit, rich0, ulm, williamh 
-
-
-
-Status of Projects
-==================
-1) the multilib porting and subsequent disposal of emul-... packages
-2) the migration of project web pages to our wiki
-
-http://thread.gmane.org/gmane.linux.gentoo.devel.announce/2212/
-
-See meeting log for further details.  No actions by council.
-
-
-Bugs assigned to Council
-========================
-
-(5 minutes)
-
-Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council meetings
-
-dberkholz is reminded to follow-up...  
-
-
-Open floor
-==========
-
-(5 minutes)
-
-
-
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20141021.txt b/xml/htdocs/proj/en/council/meeting-logs/20141021.txt
deleted file mode 100644
index 28360bc736..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20141021.txt
+++ /dev/null
@@ -1,405 +0,0 @@
-[15:00:23] <rich0> Ok, I have 19:00 on my watch.
-[15:00:27] <rich0> Roll call...
-[15:00:32] -*- ulm here
-[15:00:36] -*- WilliamH here
-[15:01:20] <rich0> blueness, dilfridge, radhermit?
-[15:01:20] <radhermit> here
-[15:02:45] <rich0> I just sent a text to dberkholz
-[15:02:59] <dilfridge> here
-[15:03:07] <rich0> Ok, just blueness
-[15:03:44] <blueness> here!
-[15:03:55] <blueness> shit i got busy in another channel
-[15:03:58] <blueness> but i'm ready :)
-[15:04:06] <rich0> Ok, let's get started - no word from dberkholz but I did text him.
-[15:04:09] <blueness> and there's the text :)
-[15:04:15] <blueness> at least this time i wasn't asleep
-[15:04:43] <rich0> Ok, same agenda, but we're up to Deprecating and killing the concept of herds
-[15:04:55] <rich0> Looks like mgorny is at the center of every agenda item today.  :)
-[15:04:57] <WilliamH> kill them with fire and nukes
-[15:05:11] <blueness> WilliamH, no kill them with loooove
-[15:05:17] <rich0> Nah, nukes are reserved for cvs keywords.
-[15:05:26] <blueness> ah yes
-[15:05:29] <dilfridge> not kill but correct the definition (people not packages)
-[15:05:37] <ulm> I'm o.k. with killing herds, as long as we keep a distinction in metadata if the maintaining entity is a person or a team
-[15:05:38] <blueness> okay i'm all for killing herds, but two things
-[15:06:00] <blueness> 1) we keep the mail aliases somehow so that we can track packages
-[15:06:04] <WilliamH> ulm: you can tell that in the <maintainer> tags
-[15:06:14] <blueness> so maybe change <herd> to just <email>
-[15:06:24] <dilfridge> <maintainer><email>kde@gentoo.org</email><name>Gentoo KDE team</name></maintainer>
-[15:06:31] <dilfridge> compare this ^ to
-[15:06:36] <dilfridge> <herd>kde</herd>
-[15:06:38] <blueness> i like that
-[15:06:48] <rich0> Would we require all packages to have a maintainer or project listed to be considered maintained?
-[15:06:54] <WilliamH> dilfridge: nuke the <herd> tag
-[15:06:57] <ulm> dilfridge: that's not what the DTD defines as name
-[15:07:00] <rich0> That is, just an alias isn't good enough unless it is a real project?
-[15:07:01] <blueness> 2) we need to really figure out what the relationship between herds and projects are
-[15:07:02] <WilliamH> dilfridge: it is unnecessary
-[15:07:05] <ulm> name is for a person
-[15:07:27] <blueness> i don't even know what teams i'm on anymore because i've just been working with herds aka mail aliases
-[15:07:35] <WilliamH> blueness: herds are groups of packages, maintained by devs who are members of projects.
-[15:07:36] <dilfridge> if we can come up with a similarly concise metadata fomulation then I am for nuking something. I'm not happy to blow up all metadata files to infinity.
-[15:07:46] <radhermit> so this doesn't kill herds, just changes metadata? I'm fine with that, never liked the 2nd layer of redirection
-[15:08:13] <blueness> radhermit, that's my understanding
-[15:08:14] <ulm> dilfridge: +1
-[15:08:15] <WilliamH> blueness: for example, the accessibility project maintains the accessibility and gnome-accessibility herds.
-[15:08:19] <blueness> so we're really not loosing any data
-[15:08:21] <rich0> I think we're all for simplifying things here.  I'm not quite sure we are solid on what we want to change TO.
-[15:08:40] <dilfridge> a) keep metadata.xml somehow short and concise.
-[15:08:55] <radhermit> just use straight email addresses in metadata only
-[15:09:01] <ulm> WilliamH: same for emacs team, it maintains emacs and xemacs herds
-[15:09:08] <dilfridge> b) kill the concept "herds=sets of packages" (because noone uses it like that)
-[15:09:19] <blueness> on point b correct
-[15:09:42] <WilliamH> The <herd> tag should go
-[15:10:11] <ulm> WilliamH: replace it by <project> or <team>?
-[15:10:13] <dilfridge> which leads us to - what else is needed after a) and b) is done? redefine former herds as teams?
-[15:10:23] <rich0> Should metadata have a way to distinguish between personal and alias emails?  Can alias emails be "maintainers" unless they're projects?  Where do non-maintaining aliases go?
-[15:11:00] <rich0> dilfridge: I think we should define where we want to be.  Getting there is a simpler problem.
-[15:11:14] <dilfridge> we could introduce a <team> tag that goes to a xxx@gentoo.org alias
-[15:11:23] <blueness> dilfridge, that would be better
-[15:11:26] <dilfridge> same usage as herd today
-[15:11:33] <mgorny> why extra tags? <maintainer type="xxx">
-[15:11:41] <rich0> mgorny: ++
-[15:11:44] <rich0> That was my thought.
-[15:11:47] -*- WilliamH agrees with mgorny here, why keep tags?
-[15:11:51] <blueness> i've got this gut feeling that we need to define the existing and members so we know who is taking care of what packages
-[15:11:54] <dilfridge> because it's an extra 20 characters that I have to type.
-[15:11:54] <radhermit> <maintainer type="bot">
-[15:12:02] <rich0> But what about aliases that aren't maintainers?  Do we want to ban them?  Only true projects can have aliases?
-[15:12:17] <blueness> we want aliases that are not maintaiers
-[15:12:25] <dilfridge> sure
-[15:12:27] <WilliamH> dilfridge: here specifically does *not* go to an email@g.o I don't think, you have to look it up in herds.xml
-[15:12:34] <WilliamH> s/here/herd/
-[15:12:38] <rich0> Maybe the tag should be <email type="maintainer">
-[15:12:42] <dilfridge> WilliamH: yes, but that's an abomination
-[15:12:56] <blueness> rich0, interesting idea
-[15:12:59] <dilfridge> one level of indirection beyond sanity
-[15:14:16] <rich0> So, some principles.  Get rid of herds.  Have email in metadata, and have a way to tell if the email is personal, proejct, or just non-maintaining alias.
-[15:14:21] <ulm> just rename <herd> to <team>
-[15:14:26] <WilliamH> Ok, a maintainer tag contains a name and an email... that email could be an alias, just like we do now...
-[15:14:35] <ulm> no attributes or other such xml abominations
-[15:14:36] <dilfridge> rich0, ulm: ++
-[15:15:00] <mgorny> ulm: that's extra work for no benefit
-[15:15:02] <blueness> rich0, yeah that sounds okay
-[15:15:03] <rich0> ulm: what is a "team"?  :)  Just an email address, that may or may not be a project, and which may or may not maintain a package?
-[15:15:15] <dilfridge> with the distinction that <team>x</team> directly maps to x@gentoo.org without exceptions
-[15:15:22] <ulm> mgorny: we'll have to update the dtd in any case
-[15:15:31] <rich0> Ok, is our goal to fully spec this out today, or do we want to punt on the details and resolve next meeting?
-[15:15:43] -*- WilliamH is against a team tag
-[15:15:46] <rich0> Maybe we just vote on the direction, and then let the DTD be fixed on the lists or something.
-[15:15:49] <ulm> rich0: a team is the group of devs maintaining what is currently called a herd
-[15:15:50] <blueness> rich0, this is too complex for me to think on the fly
-[15:16:03] <WilliamH> just use a maintainer tag...
-[15:16:08] <rich0> blueness: that is my concern - I don't just want to bikeshed the solution in 10mins.
-[15:16:12] <WilliamH> maintainers can be aliases...
-[15:16:33] <rich0> We can vote on the general direction and requirements, but then let the implementation be worked out on the lists with a final vote.
-[15:16:38] <rich0> We can also propose a migration plan on the lists.
-[15:16:51] <rich0> Until today we didn't really know where everybody stood on it.
-[15:17:05] <dilfridge> please migrate after git, it will make it so much more sane
-[15:17:08] <rich0> That would be my proposal.  
-[15:17:28] <WilliamH> That's reasonable because it could all be done in one commit.
-[15:17:42] <rich0> ++ - Git will be done next Tuesday anyway.  :)
-[15:17:49] -*- rich0 ducks
-[15:17:50] <WilliamH> heh
-[15:17:52] <radhermit> heh ok
-[15:18:13] <ulm> while we're at it, we could also make the maintainer tag for individual devs more concise
-[15:18:24] <ulm> nick should be enough for gentoo devs
-[15:18:39] <dilfridge> true
-[15:18:40] <rich0> ulm: what about proxies?
-[15:18:45] <rich0> Shoudl they get a different tag?
-[15:18:50] <rich0> (or attribute)
-[15:18:59] <radhermit> do we need to bikeshed this all now?
-[15:18:59] <rich0> I'm thinking about software that has to parse this stuff.
-[15:18:59] <ulm> rich0: they would keep full e-mail addresses of course
-[15:19:05] <radhermit> seems like something for lists
-[15:19:11] <WilliamH> rich0: I'm not sure that's necessary, because you can list multiple maintainers
-[15:19:14] <dilfridge> no @ -> dev
-[15:19:16] <rich0> radhermit: ++
-[15:19:20] <dilfridge> ++
-[15:19:21] <ulm> yeah, let's discuss it on lists
-[15:19:21] <blueness> http://dpaste.com/1J2YMFS
-[15:19:29] <rich0> Ok, then how about this for a quick summary:
-[15:19:32] <blueness> ^^ this seems to be what we are all saying
-[15:19:42] <mgorny> also note that metadata.xml is not only for gx86 but also for other repos
-[15:19:45] <mgorny> including non-gentoo
-[15:20:07] <WilliamH> mgorny: all we have to be concerned about is gentoo-x86
-[15:20:24] <rich0> "The council is in favor of retiring herds, allowing non-maintainer aliases to exist, and having a way to distinguish between individuals, projects, and non-maintainer aliases in metadata.xml.  The details of how to implement this will be worked out in the lists before the next meeting."
-[15:20:43] <blueness> yes!
-[15:20:47] <blueness> perfect
-[15:20:47] <ulm> +1
-[15:20:51] -*- WilliamH yes
-[15:20:54] <radhermit> yes
-[15:20:57] -*- rich0 yes
-[15:20:57] -*- ulm yes
-[15:20:57] <dilfridge> yes
-[15:21:19] <rich0> Ok, I think that is all six of us
-[15:21:44] <rich0> Ok, recorded.
-[15:21:46] <rich0> Next topic.
-[15:21:51] <rich0> Status of Games Team
-[15:22:05] <rich0> Looking at the past summary, I believe radhermit was going to try to coordinate an election.
-[15:22:06] <radhermit> I sent one email, probably should have sent a followup one at some point
-[15:22:13] <radhermit> but that didn't happen
-[15:22:35] <radhermit> and no election happened because no new members stepped forward afaik
-[15:23:03] <WilliamH> So should we disband the team and assign everything to m-n then?
-[15:23:12] <rich0> I guess my question is whether the urgency to do something is the same?
-[15:23:15] <blueness> there's no real way of asking "who's on such and such a team" is there?
-[15:23:17] <dilfridge> WilliamH: would that help?
-[15:23:38] <rich0> We did give the go-ahead for people to avoid the team if they felt the need.
-[15:23:48] <rich0> So, it should be less of a barrier to progress.
-[15:23:50] <radhermit> I'll probably be in the same room as the current team leader sometime later today if that helps anything :P
-[15:23:55] <WilliamH> blueness: the project page should list the members
-[15:24:05] <radhermit> if you want me to force him to relinquish his crown ;)
-[15:24:20] <blueness> radhermit, how is that?
-[15:24:29] <blueness> i'm not even sure who's who on that team
-[15:24:33] <radhermit> We're both located near Boston
-[15:24:36] <dilfridge> https://wiki.gentoo.org/wiki/Project:Games
-[15:24:49] <blueness> oh mike
-[15:25:05] <radhermit> afaik, vapier probably doesn't care about being lead in games anymore
-[15:25:05] <ulm> heh, they moved the project page to the wiki?
-[15:25:10] <radhermit> I can ask him though
-[15:25:21] <dilfridge> btw that page is incorrect as per council decision
-[15:25:30] <dilfridge> "The Gentoo Games Project manages all games that are added into the Portage tree."
-[15:26:04] <rich0> radhermit: I definitely think you should talk to him if you have the opportunity.  
-[15:26:10] <rich0> I'd be interested in how he feels about things.
-[15:26:23] <dilfridge> it was migrated by creffett|irssi by the way, most likely together with a bunch of others
-[15:26:30] <rich0> I don't want to block somebody from contributing - really most of this issue is about making sure games doesn't block others from contributing.
-[15:27:07] <blueness> mgorny, is my understanding correct that games is blocking the removal of emul-* stuff which is blocking multilib stuff from progressing?
-[15:27:22] <mgorny> not anymore
-[15:27:23] <radhermit> uh, I don't think so
-[15:27:27] <mgorny> multilib team did all the work for them
-[15:27:30] <radhermit> multilib should just fix stuff
-[15:27:33] <radhermit> since they want it done
-[15:27:39] <mgorny> though most of the dependencies are still insane
-[15:27:42] <radhermit> like how most stuff works in the tree
-[15:28:05] <blueness> okay so isn't that the original issue with that team?  i mean if the original problem is gone, can we just leave it alone?
-[15:28:10] <blueness> or are there other issues?
-[15:28:26] <mgorny> did they solve the 10-year security issue?
-[15:28:27] <rich0> blueness: that is what I'm thinking.  I don't want to just outright disband the team if they're doing something and they aren't really a problem.
-[15:28:29] <radhermit> people mentioned wanting to rework how games were installed/policies/etc
-[15:28:32] <mgorny> about nethack?
-[15:28:53] <rich0> mgorny: I guess I'd ask whether anybody else wants to solve that issue.  If games is standing in the way that is one thing.
-[15:28:54] <blueness> hey! leave nethack alone ... its legendary!
-[15:28:58] <blueness> j/k
-[15:29:12] <WilliamH> <qa hat on> There are a number of games that are hard masked in the tree because of security issues. these are closed-source binaries so will probably not be fixed. </qa hat>
-[15:29:18] <radhermit> imo, if people are serious about changing stuff just join and start discussing more
-[15:29:22] <mgorny> it's not nethack being broken, it's games.eclass install of it
-[15:29:32] <rich0> WilliamH: If they're hard-masked, then it isn't a problem, right?
-[15:29:48] <rich0> If something is truly broken and isn't maintained, then that is a treecleaning issue.
-[15:29:50] <blueness> mgorny, okay thanks for that clarification
-[15:29:58] <WilliamH> rich0: what's the point of them being in the tree if they are hard masked for security and have been for years?
-[15:30:07] <rich0> WilliamH: do they still work?
-[15:30:14] <rich0> Maybe people still want to use it?
-[15:30:26] <blueness> mgorny, can we have a clear list of what's wrong with games team and then we can decide whether or not to leave lying dogs alone
-[15:30:55] <rich0> I'll buy that nethack is doing something wrong.  The question is, is somebody gong to fix it, or are we talking about treecleaning nethack/
-[15:30:56] <blueness> if the problems are big, we already get the picture that there's no movement there, we'll just disband and treeclean
-[15:31:00] <WilliamH> rich0: I'm not saying people shouldn't use it if they want to, I'm just questioning why it is still in the main tree instead of an overlay?
-[15:31:18] <blueness> WilliamH, that's a good idea, move it to an overlay
-[15:31:20] <ulm> blueness: it's all in mgorny's e-mail message, requiring an agenda item for a previous meeting
-[15:31:35] <ulm> mgorny: do you have a pointer to it?
-[15:31:37] <rich0> WilliamH: I get that, but why not allow it in the main tree?  Does it hurt anything?
-[15:31:42] <mgorny> ulm: a minute
-[15:31:49] <blueness> ulm, mgorny i read it but i need a reminder
-[15:31:49] <mgorny> i think it's still in qa agenda
-[15:32:23] <WilliamH> rich0: we should unmask if it is going to stay in the main tree; p.mask should not be permanent.
-[15:32:28] <rich0> Making all of games m-n won't make the bugs disappear.
-[15:32:35] <ulm> mgorny: this on, I think: http://thread.gmane.org/gmane.linux.gentoo.project/3919
-[15:32:35] <mgorny> http://article.gmane.org/gmane.linux.gentoo.project/3919
-[15:32:36] <blueness> rich0, if there's a real problem(s) here, then let's act by saying we're give QA the power to move that stuff to an overlay and disband the game team
-[15:32:38] <ulm> *one
-[15:32:39] <rich0> WilliamH: I don't see why not, but we can take that offline.
-[15:32:44] <ulm> heh :)
-[15:33:07] <rich0> I'm not sure that there is a policy against having masked security problems in the tree permanently.
-[15:33:14] <rich0> As long as they build/etc.
-[15:33:19] <mgorny> but QA's dead!
-[15:33:24] <mgorny> we need to disband it too :P
-[15:33:29] <WilliamH> mgorny: not completely.
-[15:33:30] <radhermit> ...
-[15:33:32] <dilfridge> how about we state "everyone is free to join games team" instead?
-[15:33:45] <radhermit> didn't I sort of state that already?
-[15:33:50] <mgorny> but seriously, since last failed meeting i don't know if qa can work
-[15:34:04] <dilfridge> hmm? what did I miss this time?
-[15:34:08] <dilfridge> never mind, later
-[15:34:14] <mgorny> i also mailed the -qa@ list about games team, and never got any response
-[15:34:24] <blueness> mgorny, two problems i see: 1) political.  demanding exclusivity.  2) the games.eclass breaking things like LFH
-[15:34:36] <dilfridge> 1) is solved
-[15:34:52] <dilfridge> 2) is solved by solving 1), noone is forced to use games.eclass
-[15:35:00] <dilfridge> what's the problem?
-[15:35:27] <blueness> dilfridge, well there's only one problem remaining and that is a treecleaning of bad packages
-[15:35:41] <rich0> blueness: I suggest we let QA/treecleaners do that per-package.
-[15:35:43] <blueness> if we remove that cruft from the tree than i'd be happy with the state of things
-[15:35:46] <ulm> dilfridge: lack of consistency throughout the tree is an issue
-[15:35:48] <mgorny> well, the problem is that even if not everyone is forced to use it, we end up being inconsistent
-[15:35:50] <dilfridge> ok, but that applies to all packages, not just games
-[15:35:55] <radhermit> it would be nice to do things in a uniform fashion
-[15:35:57] <radhermit> right
-[15:36:07] -*- WilliamH agrees with dilfridge
-[15:36:09] <mgorny> recently gnome team rewrote their packages to use games.eclass
-[15:36:15] <radhermit> seriously?
-[15:36:15] <dilfridge> huh?
-[15:36:15] <mgorny> because someone told them to
-[15:36:26] <dilfridge> that is kinda stupid.
-[15:36:29] <WilliamH> mgorny: who told them to?
-[15:36:34] <mgorny> hasufell, i think
-[15:36:39] <rich0> Still, I don't buy that we can NEVER have a package with a potential security issue in the tree if it is masked.  But, I think we can let QA/tree-cleaners do their job first.
-[15:36:40] <dilfridge> LOL
-[15:36:49] <WilliamH> gees
-[15:36:49] <mgorny> now if i tell them to switch back, we end up in kinda stupid way
-[15:36:57] <WilliamH> mgorny: go for it.
-[15:37:08] <WilliamH> mgorny: they don't need to use games.eclass
-[15:37:35] <rich0> I don't have a problem with people using the eclass.  It just shouldn't be mandatory, and of course that makes it kind of useless.
-[15:37:35] <dilfridge> this is getting slightly bizarr
-[15:37:39] <blueness> rich0, this looks messier than i thought.  how about as a first line of action the council asks treecleaners to focus on games that are abondoned or seroius disrepair
-[15:38:03] <rich0> Well, first line of action is that radhermit chats with vapier, but yes, agree blueness
-[15:38:11] <blueness> rich0, yeah true
-[15:38:15] <rich0> I think we should separate org vs package issues.
-[15:38:18] <WilliamH> blueness: basically we just need to do the work in qa;
-[15:38:21] <radhermit> don't treecleaners scan for all pkgs with tons of open bugs anyway?
-[15:38:26] <WilliamH> blueness: following up on p.mask.
-[15:38:32] <WilliamH> blueness: not just games
-[15:38:34] <radhermit> i.e. they should already be catching things
-[15:38:46] <radhermit> open bugs that are ancient at least
-[15:38:47] <WilliamH> blueness: so I don't think there is any need for the council to do anything on that.
-[15:39:14] -*- WilliamH really isn't part of treecleaners
-[15:39:22] <WilliamH> I can't really speak for how they do things
-[15:39:47] <rich0> So, how about something like this:
-[15:39:47] <ulm> should we make any statement about policy? like games group, or non-FHS directory layout in games.eclass?
-[15:39:50] <ulm> or do we leave this to qa?
-[15:40:07] -*- WilliamH votes leave p.mask to qa
-[15:40:28] <dilfridge> leave it to qa for now, since the question of exclusivity has been decided
-[15:40:30] <radhermit> right, if people have serious issues with certain pkgs, contact qa
-[15:40:34] <radhermit> we don't micromanage
-[15:40:49] <blueness> right
-[15:41:03] <radhermit> if QA is unresponsive... well then
-[15:41:11] <radhermit> find some new QA members? :)
-[15:41:20] <mgorny> i'm the new QA member :P
-[15:41:21] <rich0> "Council deferrs to radhermit to continue working with the games team on the organization issues for another month.  Council will reach out to QA/Treecleaners and support their reviewing games packages as any other as far as bugs/security/QA/etc goes."
-[15:41:38] <mgorny> but i don't feel like stating 'i decide this because nobody else responded and qa was unable to meet properly'
-[15:41:49] <radhermit> heh that is always fun
-[15:42:06] <radhermit> we've had QA dictators in the past... ;)
-[15:42:08] <rich0> is creffett still the QA lead?
-[15:42:17] <WilliamH> rich0: yes
-[15:42:51] <rich0> Is there another election due soon?
-[15:42:58] <rich0> I'd think that would be coming up soon.
-[15:43:00] <dilfridge> december according to schedule, I think
-[15:43:12] <dilfridge> let me look it up
-[15:43:16] <rich0> Maybe we should just ping them and figure out where things stand.
-[15:43:25] <rich0> Thankless job I'm sure.  :)
-[15:43:45] <rich0> In any case, I suggest we defer on games to radhermit and QA/treecleaners for another month.
-[15:43:50] <rich0> Maybe continue to monitor.
-[15:43:56] <ulm> dilfridge: 2013-12-16 was last election
-[15:44:00] <rich0> I don't think anybody wants to take any kind of direct action right now.
-[15:44:02] <dilfridge> yes
-[15:44:19] <rich0> Ok, was my proposal above worth voting on?  We don't necessarily need to vote.
-[15:44:20] <dilfridge> bug 494454
-[15:44:22] <willikins> https://bugs.gentoo.org/494454 "Vote of confirmation QA lead creffett"; Community Relations, Developer Relations; RESO, FIXE; dilfridge:council
-[15:44:23] <rich0> We can just ping them.
-[15:45:05] <dilfridge> rich0: you get a yes from me
-[15:45:07] <rich0> Ok, any objections to moving on in the agenda.
-[15:45:10] <ulm> rich0: voting is ok for me
-[15:45:19] <ulm> moving on, too :)
-[15:45:23] <rich0> ok, then let's vote: "Council deferrs to radhermit to continue working with the games team on the organization issues for another month.  Council will reach out to QA/Treecleaners and support their reviewing games packages as any other as far as bugs/security/QA/etc goes."
-[15:45:27] -*- rich0 yes
-[15:45:30] -*- ulm yes
-[15:45:31] -*- dilfridge yes
-[15:45:35] <radhermit> sure
-[15:45:36] <blueness> yes
-[15:45:36] -*- WilliamH yes
-[15:45:43] <rich0> ok
-[15:45:48] <rich0> next item.
-[15:45:53] <rich0> Status of projects:\
-[15:45:59] <rich0> the multilib porting and subsequent disposal of emul-... packages
-[15:46:12] <mgorny> i replide to the mail
-[15:46:19] <rich0> Anybody want anything further?
-[15:46:21] <mgorny> replied*
-[15:46:26] <rich0> I don't need to see mgorny dance...
-[15:46:37] <ulm> mgorny: any eta for stable unmasking?
-[15:46:43] <mgorny> i'm currently working on finishing qt work for qt folks
-[15:47:00] <mgorny> i think all issues are being worked out, so it's a matter of review + moving to the tree
-[15:47:02] <mgorny> then stabilizations
-[15:47:05] <radhermit> do qt5 work too while you're at it ;)
-[15:47:11] <dilfridge> ugh I see dev-lang/perl in the list :(
-[15:47:12] <mgorny> with arch teams... i'd say 1-2 months :P
-[15:47:33] <dilfridge> ok let's summarize, things are moving ahead.
-[15:47:34] <dilfridge> ok?
-[15:47:39] <radhermit> oh I see we finally have it in the tree masked, nevermind...
-[15:48:13] <dilfridge> https://wiki.gentoo.org/wiki/Multilib_porting_status < the ultimate list
-[15:48:20] <mgorny> qt4 is probably ~1 month too
-[15:48:38] <radhermit> libperl?
-[15:48:43] <dilfridge> yes
-[15:48:45] <radhermit> isn't that dead?
-[15:49:00] <dilfridge> the libperl package is dead, but that's just a library in dev-lang/perl
-[15:49:01] <radhermit> or merged with perl itself
-[15:49:04] <radhermit> right
-[15:49:10] <radhermit> but that list has the actual pkg
-[15:49:14] <mgorny> the emul- list is not 100% necessary
-[15:49:21] <radhermit> alright
-[15:49:22] <mgorny> we only port the packages that are actually necessary
-[15:49:28] <dilfridge> sys-devel/libperl is gone soon.
-[15:49:43] <mgorny> perl won't need to be multilib most likely
-[15:49:47] <dilfridge> phew
-[15:49:47] <mgorny> python may be necessary for samba-5
-[15:49:51] <mgorny> unless we find way around it
-[15:50:07] <radhermit> next up... multilib PMS ;)
-[15:50:27] -*- dilfridge feels like kicking someone :o)
-[15:50:57] <dilfridge> ok about the migration of packages to the wiki
-[15:51:07] <dilfridge> s/packages/project pages/
-[15:51:19] <rich0> dilfridge: go ahead
-[15:51:36] <dilfridge> the silly thing is, being in the metastructure project I'm probably the right person to talk to myself
-[15:52:02] <dilfridge> https://wiki.gentoo.org/wiki/Project:Wiki/Project_Page_Migration_Status
-[15:52:08] <dilfridge> this is the definitive list here
-[15:52:29] <dilfridge> just translating a page is in most cases (imho) trivial
-[15:52:41] <dilfridge> maybe we should propose a deadline?
-[15:53:07] <rich0> dilfridge: after that we disband x86 and amd64?  :)
-[15:53:18] <dilfridge> :P
-[15:54:00] <rich0> I do think a deadline does make sense all the same.
-[15:54:07] <dilfridge> but seriously, it is not too much work per page. of course for one person doing all is a lot of work.
-[15:54:23] <rich0> For obviously-critical projects we may just have to do something, but some of those projects may be defunct.
-[15:55:45] <rich0> Ok, anything else on that?
-[15:55:55] <rich0> Do we want to actually take action?  The agenda is just for status.
-[15:56:09] <dilfridge> status is "stalled in the middle" right now
-[15:56:22] <ulm> maybe send a reminder to the mailing list?
-[15:56:28] <dilfridge> yes, good idea.
-[15:56:38] <rich0> yeah, talk is cheap at least :)
-[15:56:59] <rich0> Ok, next agenda item is bug 503382
-[15:57:01] <willikins> rich0: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
-[15:57:10] -*- rich0 looks around the room
-[15:57:14] -*- blueness smacks head
-[15:57:34] <mgorny> i say disband previous council
-[15:58:10] <rich0> ok, moment of silence observed...
-[15:58:20] <ulm> that was dberkholz
-[15:58:22] <blueness> hd=eh
-[15:58:24] <rich0> yup
-[15:58:27] <blueness> erre heh
-[15:58:30] <rich0> Ok, we'll prod him.
-[15:58:40] <rich0> I don't see him on the list of chairs for this term
-[15:58:48] <dilfridge> :)
-[15:58:53] <rich0> Ok...
-[15:59:00] <rich0> Open floor
-[15:59:06] <rich0> Anybody want to take a shot?
-[16:00:00] <WilliamH> Ok, I have a question about a procedure...
-[16:00:02] <mgorny> i can say that bashcomp2 is progressing fast too :P
-[16:00:10] <mgorny> i filed a lot new bugs today
-[16:00:11] <rich0> WilliamH: go ahead
-[16:00:21] <WilliamH> I know that generally a package needs a last rites and 30 days before removing it from the main tree.
-[16:00:36] <WilliamH> Is that also true for a package that is in p.mask?
-[16:00:42] <rich0> WilliamH: might as well
-[16:00:44] <WilliamH> s/p.mask/p.mask already/
-[16:00:48] <rich0> Unless there is some reason to rush.
-[16:00:57] <rich0> Or unless of course it is already masked for removal.
-[16:01:15] <rich0> My two cents at least.
-[16:01:21] <ulm> WilliamH: I'd keep the 30 days between last rites and removal there too
-[16:01:29] <ulm> but it's a guideline only
-[16:01:34] <dilfridge> I used to give a few days then too, as e.g. sending a last-rites mail "has been masked since..., will be removed in 10 days"
-[16:01:38] <blueness> rich0, et al.  i have to run.  i'll read the backlog
-[16:01:38] <rich0> Obviously copyright issues or such warrant an exception
-[16:01:45] <rich0> blueness: ok, 
-[16:01:51] <WilliamH> dilfridge: that's reasonable.
-[16:02:22] <WilliamH> dilfridge: that's one reason I haven't pushed hard personally to work on p.mask.
-[16:02:33] <WilliamH> dilfridge: I wasn't sure how to go about that.
-[16:02:39] <dilfridge> ok
-[16:03:01] <rich0> Anything else on that?
-[16:03:16] <rich0> mgorny: ++ on bashcomp2.   Just in time for my switch to zsh.  :)
-[16:03:55] <rich0> Anything else for open floor?
-[16:04:36] <rich0> If not, we're done.  Next meeting will be Nov 11
-[16:05:10] <rich0> I'll post the summary shortly, and start the agenda for next month.
-[16:05:13] <rich0> Thanks all :)
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20141111-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20141111-summary.txt
deleted file mode 100644
index faa4cc122b..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20141111-summary.txt
+++ /dev/null
@@ -1,87 +0,0 @@
-Roll call
-=========
-
-Present: blueness, dberkholz, dilfridge, creffet proxy for radhermit, rich0, ulm, williamh 
-Absent: none
-
-
-Validity of Unattached Tinderbox Logs
-=====================================
-Should/may maintainers close bugs that have tinderbox logs passed by URL
-without being attached?
-
-http://thread.gmane.org/gmane.linux.gentoo.devel/93356/focus=93435
-
-"The council recommends that bugs from any developer-run tinderbox not
-be marked invalid based on whether the logs are attached or pointed to
-by a permanent URL.  The council also encourages efforts to automate
-the attachment of tinderbox logs to improve the quality of the bugzilla
-record."
-
-Aye: blueness, dberkholz, dilfridge, creffet proxy for radhermit, rich0, ulm, williamh 
-
-
-Future.eclass
-=============
-Please review the attached future.eclass. Long story short, the idea is
-to provide some of the EAPI 6 feel to EAPI 5 ebuilds.
-
-Quoting the beginning of the DESCRIPTION:
-
-# This eclass contains backports of functions that were accepted
-# by the Council for the EAPI following the EAPI used by ebuild,
-# and can be implemented in pure shell script.
-
-http://thread.gmane.org/gmane.linux.gentoo.devel/93609
-
-"The council does not agree with the concept behind future.eclass as it
-has the potential for confusion.  Efforts would be better focused on
-preparing for EAPI6 and adopting this."
-
-Aye: blueness, dilfridge, creffet proxy for radhermit, rich0, ulm, williamh 
-Abstain: dberkholz
-
-
-Allowing die within subshells in EAPI6
-======================================
-This was suggested late, off-list, and with no list discussion.  I
-recommend deferring any decisions, but if anybody wants to take the
-opportunity to comment they may.
-
-See the log for discussion.  This was referred back to the lists for open 
-discussion before we vote.
-
-
-Deprecating and killing the concept of herds
-============================================
-Follow-up if necessary...
-
-Rich0 will work on his proposal further.  There isn't anything ripe for a 
-decision yet.
-
-Status of Games Team
-====================
-Follow-up if necessary...
-
-The council agreed to re-iterate the call for volunteers and for QA to
-take action where necessary.  However, there are no new decisions.
-
-
-Bugs assigned to Council
-========================
-
-(5 minutes)
-
-Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council meetings
-
-dberkholz reports that he is 2/3rds done with this.
-
-
-Open floor
-==========
-
-(5 minutes)
-
-See log for discussion around EAPI6 and install-qa-check.d.
-
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20141111.txt b/xml/htdocs/proj/en/council/meeting-logs/20141111.txt
deleted file mode 100644
index 765bf37b47..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20141111.txt
+++ /dev/null
@@ -1,419 +0,0 @@
-<rich0> ok, let's do roll call. :)
--*- creffett|irssi currently holds the title of "person who has been on the council most without actually being elected to the council"
--*- ulm here
--*- WilliamH here
--*- creffett|irssi here as proxy
-<rich0> I think we're all here.
-<dberkholz|mob> Hi
-<dberkholz|mob> (For roll call)
-<rich0> Ok, hopefully a lighter day today.  First topic
-<rich0> Should/may maintainers close bugs that have tinderbox logs passed by URL without being attached?
-<rich0> (or something to that effect)
-<dberkholz|mob> Nope
-<rich0> Hopefully this will become somewhat moot as there is an effort to go in and add the attachments after-the-fact.
-<creffett|irssi> seems to be largely solved by attachment-adding scripting that people are doing
--*- WilliamH agrees with rich0 
--*- dilfridge here
-<creffett|irssi> but as a general question, I'm with dberkholz|mob on this
-<ulm> no council action required IMO
-<rich0> However, I'm generally not a fan of marking bugs INVALID simply for syntax.
-<rich0> If necessary info is missing that is one thing.  If we don't like how it was done, then fix it.
-<rich0> Do we want to issue a recommendation that bugs not be marked invalid simply due to the way logs are linked vs attached?
-<blueness> leave it at that
-<ulm> that shouldn't become general policy
-<dilfridge> no
-<ulm> we could grant an exception for the tinderbox
-<rich0> The alternative is to say the issue is moot and move on.
-<ulm> but that does not set a precedent
-<dberkholz|mob> Don't let process win over fixing bugs
-<dilfridge> we could say that it's bugwrangler team decision
-<rich0> In general though I think everybody could afford to be a bit more flexible in this case.
-<WilliamH> How about this:
-<rich0> I think it is bigger than bugwranglers.  There is the balance in encouraging tinderboxing (albeit with some limitations) vs reducing the effort to handle bugs.
-<rich0> If we had 47 people doing tinderboxing then I'd say we could be picky about how they do it.
-<rich0> WilliamH: ?
-<WilliamH> The council recommends that bugs from the tinderbox not be marked invalid based on whether the logs are attached or pointed to by a URL.
-<rich0> How about a two part: "The council recommends that bugs from the tinderbox not be marked invalid based on whether the logs are attached or pointed to by a URL.  The council also encourages efforts to automate the attachment of tinderbox logs to improve the quality of the bugzilla record."
-<dilfridge> s/the tinderbox/any developer-run tinderbox/
-<rich0> dilfridge: ++
-<blueness> that's fine
-<ulm> rich0: s/URL/permanent URL/
-<ulm> no pastebins
-<rich0> "The council recommends that bugs from any developer-run tinderbox not be marked invalid based on whether the logs are attached or pointed to by a permanent URL.  The council also encourages efforts to automate the attachment of tinderbox logs to improve the quality of the bugzilla record."
-<dilfridge> ++
-<rich0> Of course, no URL is truly permanent.
-<rich0> But I get the gist.
-<ulm> rich0: yeah, it's about the intention
-<ulm> otherwise, +1
-<rich0> Any other tweaks before we vote?
-<rich0> Ok, let's vote.
--*- rich0 yes
--*- blueness yes
--*- ulm yes
--*- WilliamH yes
--*- creffett|irssi yes
--*- dilfridge yes
-<rich0> dberkholz?
-<dberkholz|mob> Yes
-<rich0> ok, 7-0
-<rich0> next topic
-<rich0> Future.eclass
-<rich0> http://thread.gmane.org/gmane.linux.gentoo.devel/93609
-<WilliamH> kill it with fire
-<rich0> It feels like the whole spam form letter - will make things better for two months and then we're stuck with it.  :)
-<dilfridge> please no
-<ulm> I don't see what problem this would solve, and it potentially adds confusion
-<creffett|irssi> my notes say that I should vote NAK
-<dilfridge> this is not a good idea... helping with specs writing is way better
-<creffett|irssi> and I agree with that
-<rich0> I get the utility factor.  I'm all for utility eclasses in generall, but not for things imminently to be fixed by EAPI
-<rich0> Any contrary opinions?
-<creffett|irssi> it basically splits us into EAPI 5.5 (5+future.eclass) and EAPI 6 (properly implemented in package managers)
-<dilfridge> fuuuuu
-<ulm> features should be either in an eclass or in the PM, not both
-<ulm> if something turns out to live better in an eclass then we should remove the feature from the EAPI 6 list again
-<blueness> yeah i don't get this, why can we just get EAPI 6 out?
-<dilfridge> :)
-<ulm> blueness: I hope that the spec will be ready before xmas
-<rich0> Ok, how about "The council does not agree with the concept behind future.eclass as it has the potential for confusion.  Efforts would be better focused on preparing for EAPI6 and adopting this."
-<dilfridge> sounds good
-<blueness> yes
-<ulm> +1
--*- WilliamH yes
-<rich0> ok, vote
--*- rich0 yes
-<creffett|irssi> yes
--*- ulm yes
--*- WilliamH yes
--*- dilfridge yes
-<rich0> dberkholz|mob: ?
-<dberkholz|mob> Abstain
-<blueness> yes
-<rich0> Ok, 6-0 with one abstention
-<rich0> Next: Allowing die within subshells in EAPI6
-<creffett|irssi> radhermit says "should be discussed more on the lists"
-<rich0> My comment is already in the agenda.  By all means we can share thoughts but I recommend deferring actual voting until it is discussed on-list.
-<ulm> I'd like to first see it solved technically
-<rich0> Maybe we don't even have to vote on it at all if it reaches consensus there.
-<ulm> doesn't make sense to allow die in subshells if it doesn't work reliably
-<dilfridge> I have absolutely no clue about the background. What is it supposed to do when called in a subshell? die or return?
-<ulm> dilfridge: per PMS it's undefined
-<floppym> Currently portage dies at the end of the current phase I beleive.
-<dilfridge> and paludis ignores it? :P
-<ulm> in principle it should die, but then the PM would have to kill the process tree
-<rich0> Short of moving to a language with better exception-handling than bash, I'm not sure we have great options here anyway.
-<ulm> not sure if that can be done in a sane way
-<dilfridge> ulm: it could probably with cgroups, but...
-<rich0> systemd-emerge? 
-<dilfridge> oh dear
-<ulm> dilfridge: yeah, that would open a new can of worms :)
-<WilliamH> heh
-<WilliamH> cgroups != systemd
-<blueness> ulm, how is this die in a subshell supposed to work?  does it do it by return value or by some sort of signal?
-<rich0> WilliamH: I know.  couldn't resist.  :)
-<dilfridge> FEATURES=cgroup Use  Linux  control  group  to control processes spawned by ebuilds. This allows emerge to safely kill all subprocesses...
-<ulm> blueness: no idea, I haven't seen a working implementation so far
-<dilfridge> ^ man make.conf
-<blueness> ulm, well who came up with the idea?
-<WilliamH> I guess the disadvantage of cgroups is it is Linux specific.
-<ulm> blueness: mgorny
-<floppym> mgorny's eclasses abuse it, by accident.
-<blueness> floppym, i'd like to see this, but later
-<blueness> the only sane way i can see is by getting a signal to the portage parent
-<floppym> Well, portage currently does some IPC magic that I'm unfamiliar with.
-<mgorny> well, it's something that definitely can be solved technically
-<rich0> kdbus to the rescue...
-<blueness> i don't feel comfortable voting on something that i don't understand
-<WilliamH> me neither
-<blueness> mgorny, i'd like to see poc
-<dilfridge> this should go to the lists first
-<rich0> we're not going to vote on anything unless somebody feels strongly about it
-<mgorny> poc? portage has it working already
-<rich0> But, whoever cares can read our logs.  :)
-<ulm> can we defer it to mailing lists please?
-<mgorny> i'm not saying the impl is perfect
-<mgorny> but it works
-<ulm> sounds like a topic for gentoo-pms
-<blueness> mgorny, then show me
-<blueness> say look at the code here and here and here
-<mgorny> blueness: didn't any python-r1 ebuild fail for you? :P
-<blueness> please just point out the cod
-<rich0> ulm: ++ - the poc is good but I'd like portage and other PM input on it.
-<mgorny> portage code is not worth showing :P
-<blueness> on the list we can talk later
-<mgorny> but the idea can be relatively simple
-<rich0> Ok, anything else worth discussing here now?
-<WilliamH> Yeah let's defer this to the lists for now
-<mgorny> like passing the parent PID and SIGTERM-ing on it from die
-<blueness> mgorny, let's see it in the lists
-<mgorny> it's just plain IPC
-<blueness> simple enough that you can show it :)
-<mgorny> there's the problem of killing orphans but then, the problem was always there
-<creffett|irssi> mgorny: enough, to the lists with you :P
-<blueness> indeed!
-<ulm> mgorny: it doesn't work in 100% of cases
-<mgorny> what doesn't work?
-<ulm> killing all subprocesses
-<rich0> We can implement this when we implement separate namespaces for emerge.  :)
-<mgorny> and it will never work in 100% of cases
-<rich0> Then you just kill -9 -1 :)
-<mgorny> die in a subshell, processes left in ebuild phases...
-<mgorny> src_compile() { setsid foo; die; }
-<rich0> Ok, to the lists with this.  We can always chat after the meeting or in AOB.  
-<rich0> Likely to end early
-<blueness> thank you
-<rich0> Next topic.  :)
-<rich0> Deprecating and killing the concept of herds - any follow-up here?  I suggest we defer again since we didn't really get too far with it on the lists.
-<WilliamH> Yeah I don't think there is much for us to do here yet
-<ulm> +1 for deferring to lists
-<mgorny> ...
-*** Mode #gentoo-council +o dberkholz|mob by ChanServ
-<rich0> I did send a proposal, but we need to actually get something ready to go before we go ahead with it.
--*- mgorny mumbles something about death of gentoo :P
-<dberkholz|mob> Sigh.
-<mgorny> rich0: btw i liked your proposal
-<mgorny> didn't reply because didn't have any comments
-<blueness> rich0, i think the council needs to have a deprecation scheme spelled out
-<ulm> mgorny: because of herds? that's a tiny problem we have
-<mgorny> yes, we have many big problems nobody bothers to solve
-<blueness> what happens to the current herd info
-<rich0> mgorny: thanks.  Probalby makes sense to maybe proof-of-concept it by running some queries/etc and posting lists of packages/etc.
-<mgorny> we have small problems nobody bothers to solve because they're small
-<rich0> blueness: I did cover that somewhat in my proposal.  I think gathering some data might help with decisions there.  I don't mind talking about my proposal further or others, but I don't think we're ready to pull the trigger this second.
-<rich0> There is no reason that we can't compile the necessary data now.
-<blueness> rich0, i know much of this was discussed, but its scattered (at least in my mind now)
-<blueness> so maybe a summary for the cuoncil meeting when it comes
-<blueness> that'll reduce discussion at that time
-<rich0> blueness: http://permalink.gmane.org/gmane.linux.gentoo.devel/93587
-<rich0> Agree
-<blueness> ty
-<rich0> Let's do a bit more with it and discuss next time.
-<rich0> Anything else on this?
-<rich0> Ok, Status of Games Team - anything worth talking about here?
-<creffett|irssi> radhermit mentioned that vapier said people are free to join the herd if they want
--*- WilliamH has seen absolutely no movement on this
-<WilliamH> creffett|irssi: ok, I didn't know about that.
-<creffett|irssi> and apparently didn't mention anything re games.eclass
-<rich0> We already decided that anybody can maintain a package without games.eclass if they want to.
-<WilliamH> Who is the lead -- I thought it was radhermit?
-<rich0> Maintainers get last word on whether their package goes in the herd.
-<rich0> WilliamH: I believe so
-<ulm> WilliamH: they haven't had a new election yet, AFAIK
-<rich0> Without radhermit I'm not sure we'll get much farther with this.
-<WilliamH> Right.
-<ulm> so radhermit would still be interim lead
-<dilfridge> to be honest, this is not so important anymore (since anyone can add games, and since games don't have to stick to games team policies)
-<rich0> Obviously fixing the games team requires folks to step up, but there are no roadblocks so again not super-urgent.
-<rich0> dilfridge: ++
-<dilfridge> so if anyone wants to join games team, fine, if not, also fine
-<blueness> the original issue, especially revolving around multilib, seems to be resolved
-<blueness> its not blocking anything urget
-<blueness> so maybe just announce open season on games and let people who want join
-<mgorny> the remaining issues were supposed to be solved via QA
-<mgorny> which brings us to the topic of whether QA works :P
-<blueness> if nothinghappens, then let it die of its own accord
-<mgorny> because *nobody* replied to my mail yet
-<blueness> who is QA lead?
-<creffett|irssi> blueness: hi
-<blueness> i thought so
-<dilfridge> so how about we just let the topic (on the council side) rest and have sleeping beauty^H^H^H^H^H^Hgames team rest in the corner?
-<blueness> so creffett|irssi is QA malfunctioning?
--*- creffett|irssi sighs
-<mgorny> (sent 12 Oct)
-<rich0> dilfridge: I'm fine with dropping this until somebody asks us to pick it up again.
-<creffett|irssi> blueness: not so much malfunctioning, but nobody is stepping up to do anything lately, and I don't exactly have the motivation to nudge people constantly to do stuff
-<mgorny> i don't mind lack of specific work but some discussion would be helpful
-<ulm> creffett|irssi: maybe we should have qa team meetings? :)
-<mgorny> otherwise, it's like i declare games.eclass bad because nobody else from QA replied
-<mgorny> and it doesn't seem right to create policies this way
-<creffett|irssi> ulm: I'l leave that discussion for another time
-<rich0> Do we want to put out a call for volunteers for games/QA?
-<blueness> mgorny, suppose you are right and games.eclass is bad, how bad is it to just leave it for now ... this is not a rhetorical question, its is breaking anything seriously?
-<creffett|irssi> games yes, though we've done several of those so far I thought
-<mgorny> at the point, i think not anymoer
-<mgorny> though lack of consistency is bad
-<mgorny> confuses users
-<blueness> mgorny, i understand but since QA is overworked, you may have to choose your battles
-<creffett|irssi> blueness: it's not overworked
-<creffett|irssi> it's underperforming
-<rich0> I'm hesitant to rip off the bandaid until somebody actually steps up and wants to do something serious with games.
-<mgorny> like when we have stuff installed in /usr/lib, /usr/lib/games and /usr/games/lib
-<mgorny> (the last one being gentoo invention)
-<blueness> mgorny, yeah that seems to be the second QA issue (after the multilib problems)
-<ulm> mgorny: follow the fhs when in doubt
-<rich0> If somebody really cares about improving games I'd like them to step up, rather than us just coming in with a club and bashing a few things.
-<rich0> QA is no different - somebody has to step up and care.  :)
-<mgorny> the problem with improving stuff is that many of the games are simply old ebuilds that nobody has distfiles for...
-<dilfridge> well, joining a team requires you to work with other people...
-<blueness> can't QA just cull a bunch of those ancient ebuilds?
-<mgorny> of course, we could just overcommit them all with removing the eclass for the sake of consistency
-<blueness> mask them en masse and be done with?
-<mgorny> but that looks like a request for revert
-<creffett|irssi> blueness: I'd like somewhere to dump all of them
-<blueness> a repo
-<dilfridge> how about we write a tool that generates statistics on installation numbers?
--*- dilfridge runs and hides
-<mgorny> inject a trojan into portage
-<mgorny> also make it open ssh access for us to do more research when necessary
-<blueness> here's what i recommend, let's put a final call out for games herd
-<dilfridge> but seriously, how about having an official overlay for games where the files are not publically available?
-<creffett|irssi> ++
-<ulm> dilfridge: doesn't pfl do that?
-<rich0> I think that it isn't too much for QA to ask that any package that doesn't have freely-accessible DISTFILES be actively maintained by a named individual 
-<blueness> if the falters, then i recommend we ask QA to just deal with the problem in any way they see fit, like mosking and dumping a bunch of ebuilds ot an overlay
-<rich0> Somebody should have to vouch that they actually work.  I'm happy to take somebody's word for it.
-<rich0> However, right now we just have what might be a lot of cruft.
-<creffett|irssi> yes
-<mgorny> dilfridge: that doesn't solve the issue, just shove it under the carpet
-<creffett|irssi> I'd suggest we say "here's a list of no-distfiles games with no maintainer, speak up and say that it works/offer to help or we punt them to overlay"
-<blueness> rich0, the question is who takes care of the cruft?  if there is no games team and no one steps up, then let's see if QA is willing to clean it out
-<rich0> creffett|irssi: ++
-<creffett|irssi> or, you know, punt entirely
-<blueness> yeah that works creffett|irssi
-<mgorny> well, so far the idea is that games team does the commits when user provides necessary changes
-<creffett|irssi> threatening to remove stuff generally seems to motivate people to care for a while :)
-<WilliamH> We also have a lot of games with security masks, and it is known they won't ever be fixed.
-<WilliamH> imo they don't belong in the main tree
-<mgorny> WilliamH: but having those packages makes users happy
-<rich0> At this poitn I think this is a matter of who cares more - those who want to get rid of them, or those who want to keep them.  :)
-<mgorny> like 'i choose gentoo because i can find the packages i want without adding 2 dozen random repos'
-<rich0> Right now it is a battle of apathy.  :)
-<WilliamH> mgorny: that's what overlays are for
-<WilliamH> mgorny: in an overlay they wouldn't have to be masked.
-<creffett|irssi> mgorny: then some of those users need to step up and at least say that the game still works
-<blueness> mgorny, at this point they are a maintenance burdon
-<mgorny> WilliamH: but imagine now, we fix the main tree and remove games.eclass
-<rich0> I don't mind proprietary games in the main tree.  I just want somebody to pretend that they're maintaining them.
-<mgorny> the whole overlay is broken now
-<blueness> there are lots of broken overlays
-<blueness> we are not going to go fix them all
-<mgorny> and that is a problem
-<mgorny> but we're going offtopic now
-<mgorny> i'm going to forget my open floor items!
-<WilliamH> mgorny: not for us, for the overlay maintainer.
-<dilfridge> there are a lot of maintained overlays
-<WilliamH> mgorny: we don't have to worry about overlays.
-<dilfridge> they are all fixing perl ebuilds right now :P
-<rich0> Ok, anything else we actually want to do on games/QA/etc?
-<blueness> rich0, do we have a statement here?
-<mgorny> dilfridge: like the official sunrise project overlay
--*- rich0 wants to save 2 min in the agenda to bug dberkholz about his summaries :)
-<dilfridge> that is a special beast
-<WilliamH> mgorny: that is still independent from the main tree. if it is broken it is up to that project to fix it.
-<dilfridge> and I would even fix some ebuilds there if I could "just commit"
-<blueness> rich0, how about we 1) make a second call for open season on games (as per radhermit) and 2) say if there is no interest games will be culled
-<creffett|irssi> +1
-<rich0> blueness: proprietary games I assume you mean?
-<blueness> rich0, the problematic ones, proprietary are one, but there may be othres
-<blueness> let QA decide
-<dilfridge> I guess with 2) you mean "some games ebuilds will be culled", not "games team will be..."
-<blueness> creffett|irssi, ^^^ does this work for QA?
-<creffett|irssi> blueness: yes
-<blueness> dilfridge, yes, i type faster than i think --- i code that way too :)
-<rich0> I have no issue with that, though it really isn't a change in the status quo.  QA can already cull stuff that is broken.
-<WilliamH> Right, it really isn't a change.
-<blueness> rich0, we should emphasis the degree here maybe?
-<rich0> In fact, didn't we already announce that QA is free to have at the games herd?
-<blueness> i'm not sure, a second more emphatic email might help
-<rich0> "Council deferrs to radhermit to continue working with the games team on
-<rich0> the organization issues for another month.  Council will reach out to
-<rich0> QA/Treecleaners and support their reviewing games packages as any other
-<rich0> as far as bugs/security/QA/etc goes."
-<rich0> That was last meeting.
-<rich0> We could always +2 it I suppose.  :)
-<WilliamH> heh
-<blueness> maybe set a date, one month and QA *will* have at it
-<rich0> Ok, how about this "Council will repeat a call for games volunteers and reiterates that QA is free to cull packages that have quality issues."
-<rich0> blueness: Only QA can commit to that.
-<blueness> creffett|irssi, can you follow up with such a timeline?
-<creffett|irssi> blueness: sure, I can follow up on it
--*- rich0 looks at watch and does not want to have another meeting just for open floor
-<blueness> something like "per the councils decision, we will start culling packages with QA issues starting on ..."
-<rich0> Can we take the rest of this after the meeting closes?
-<rich0> It really is QA speaking, not the council for the rest.
-<blueness> i'm done, i just wanted to get this games thing off the table once and for all
-<rich0> Ok, any need to vote or do you want me to just regurgitate our previous decision?  I suggest that there is nothing new here.
-<blueness> are we on open floor?
-<rich0> blueness: not yet
-<WilliamH> Real quick, I just chatted with creffett|irssi. I am going to start announcing last rites on some of these packages and giving folks a week or two to move them to an overlay.
-<rich0> next topic
-<rich0> WilliamH: thanks
-<rich0> Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council meetings
-<dberkholz|mob> Cool
-<willikins> rich0: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
--*- rich0 glances at dberkholz|mob
--*- blueness shutters!
-<dberkholz|mob> Uhhhhh
-<dberkholz|mob> I'm at a dinner in Berlin right now. Still 2/3 done.
-<rich0> No desert for you...
-<dberkholz|mob> Hope not. I prefer dessert.
-<rich0> Ok, open floor.  :)
-<mgorny> so
-<mgorny> EAPI 6!
-<mgorny> do you think we could drop runtime USE & || stuff from it? :D
-<mgorny> nobody's going to do the work for portage, so there's no point pretending we can have improvement in non-shell area
-<dilfridge> ...
-<WilliamH> If the features aren't ready, they just don't go in. :-)
-<mgorny> and wait till next summer to have EAPI 6
-<ulm> mgorny: runtime USE is approved
-<dberkholz|mob> +1 williamh
-<mgorny> i think all other features are ready already
-<dilfridge> runtime USE would be very nice to have
-<rich0> Really up to the PMS team to recommend if they want to drop anything and get it done.
-<mgorny> and Zac expressed that he'd rather have it deferred for EAPI 7
-<WilliamH> ulm: yes, but there is no implementation, so he is asking that we drop it.
-<ulm> mgorny: || ( ) approved under the condition that an implementation is ready
-<mgorny> i know
-<mgorny> the question is more about runtime USE
-<rich0> We gave pre-approval to a bunch of stuff, but that doesn't commit PMS 100%.
-<WilliamH> right
-<blueness> mgorny, i'd like to hear Zac directly on what he wants to do with it
-<ulm> I'm fine with deferring the two to EAPI 7
-<rich0> blueness: ++
-<rich0> I think this is up to the portage/PMS/etc teams.
-<blueness> yes
-<mgorny> could we then change runtime USE to add the condition like for ||?
-<rich0> The initial approvals are a guideline so that they don't waste time on stuff we won't approve in the end.  
-<blueness> i mean if we approve a feature and portage/pms says, wow, that's almost impossible to code, then what?
-<ulm> maybe remove dohtml in EAPI 6 instead :)
-<rich0> It isn't a commitment.
-<blueness> if the feature is difficult and can't go in with a reasonable amount of time, we'll approave eapi6 without it
-<WilliamH> Right, , the initial approvals do not mean the things we approve must be there in the end.
-<blueness> so let portage come forward with that concern
-<ulm> mgorny: sorry, I didn't get your last comment
-<rich0> Yup, that was the whole reason of not giving the "real" approval until the reference implementation is done.
-<mgorny> i'm going to ask Zac if we could put the current code as eapi6_pre1
-<mgorny> ulm: i was asking if we could just add the same condition to runtime USE: if an implementation is ready
-<ulm> mgorny: let's just drop it for EAPI 6
-<ulm> since also syntax isn't clear yet
-<mgorny> ok
-<mgorny> so we have EAPI 6 ready now!
-<mgorny> :P
-<mgorny> just someone needs to write the PMS text
-<blueness> good no need for future.eclass!
-<ulm> (i.e. IUSE_RUNTIME vs syntax in IUSE)
-<dilfridge> sigh, that was the one feature I was most looking forward to... :|
-<ulm> mgorny: I'm at it for most of the features
-<mgorny> dilfridge: feel free to code it
-<mgorny> Zac's going to give you a hand
-<dilfridge> only if you accept Perl
-<mgorny> i don't mind perl
-<blueness> hey let's rewrite portage in perl :)
-<mgorny> not sure how you integrate it into the portage but that's not my problem
-<WilliamH> or go ;-)
-<mgorny> also https://wiki.gentoo.org/wiki/User:MGorny/Draft:install-qa-check.d
-<dberkholz|mob> Gotta run, folks
-<mgorny> nobody seems to care, portage patches are ready
-<dberkholz|mob> Beer awaits
-<rich0> dberkholz|mob: no problem - no more votes today
-<dilfridge> mgorny: I like it.
-<WilliamH> mgorny: I haven't looked at it, but is that even eapi related?
-<mgorny> loosely
-<dilfridge> mgorny: just that I'd use the same sort of "log levels" for qa as for the normal e* commands, i.e. info, log, warn, error
-<mgorny> it extends ebuild's EAPI
-<blueness> guys i've got to run too
-<rich0> blueness: ok
-<blueness> mgorny, looks good
-<rich0> I'm going to call the official meeting here
-<rich0> But, by all means continue discussion.
-
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20141209-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20141209-summary.txt
deleted file mode 100644
index 887d1536e1..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20141209-summary.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Roll call
-=========
-
-Present: dberkholz, dilfridge, mgorny (proxy for blueness), radhermit, ulm, williamh
-Absent:  rich0
-
-
-Bug 523828: GLEP 42 update: Unify gentoo-news repo and rsync structure
-=========
-
-Noone voiced any opposition to the proposed change (dropping the year subdirectory
-from gentoo-news.git); consensus was to go ahead with it. No formal vote was taken.
-
-
-Open Floor
-=========
-
-Michal Gorny brought up the topic of metadata.xml reorganization, which led to 
-a lengthy discussion. No formal decision was taken, but a lot of ideas were 
-collected for a future elegant and simplified replacement proposal (including 
-e.g. using yaml or moving a default e-mail domain of maintainer addresses to 
-layout.conf).
-
-It was brought up that the QA team lead election is due.
-
-The question was brought up whether helper functions were ever banned officially 
-in global scope. Conclusion was that a) it's been banned from the start in PMS, 
-and b) QA has decided already to explicitly make global-scope 'use*', 
-'has_version' and 'best_version' fatal since EAPI 6. No action by the council 
-needed, only by the portage team.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20141209.txt b/xml/htdocs/proj/en/council/meeting-logs/20141209.txt
deleted file mode 100644
index ea94a7670a..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20141209.txt
+++ /dev/null
@@ -1,239 +0,0 @@
-[20:00:26] -*- WilliamH is here
-[20:00:48] -*- mgorny is here for blueness
-[20:00:58] <dberkholz> hi
-[20:01:08] <radhermit> I'm around-ish
-[20:01:16] <dilfridge|mobile> In the cab 2min from home..
-[20:01:28] <WilliamH> I'm here until 19:30.
-[20:01:57] <dilfridge|mobile> Could any of you please do roll call?
-[20:03:05] <radhermit> sort of just did, unofficially
-[20:03:10] <radhermit> just rich0 and ulm?
-[20:03:43] <ulm> here
-[20:04:17] -*- WilliamH here until 19:30
-[20:04:29] <dberkholz> rich0: ping
-[20:04:57] <mgorny> blueness mentioned rich0 needed a proxy too but he didn't ping me afterwards
-[20:05:08] <radhermit> ah right
-[20:07:10] <dilfridge> ok here again
-[20:07:16] <dilfridge> ok here again
-[20:07:18] <dilfridge> http://article.gmane.org/gmane.linux.gentoo.project/4132
-[20:07:20] <dilfridge> the agenda
-[20:07:34] <dberkholz> i'm actually working on that council summary right now
-[20:07:37] <dberkholz> should get it committed today
-[20:07:38] <dilfridge> :)
-[20:08:03] <dilfridge> so do we have anything to say on bug 523828 ?
-[20:08:08] <willikins> dilfridge: https://bugs.gentoo.org/523828 "GLEP 42 update: Unify gentoo-news repo and rsync structure"; Doc Other, GLEP Changes; CONF; mgorny:glep
-[20:09:16] <dilfridge> I'm all for dropping the yyyy subdir, since we started removing old news items anyway.
-[20:09:46] <dilfridge> as long as it's not hundreds of files, that should not make any problems
-[20:09:49] -*- WilliamH is for droping the subdir as well
-[20:09:53] <WilliamH> dropping *
-[20:10:23] <dilfridge> anyone else?
-[20:10:27] <ulm> we need an updated commit hook
-[20:10:42] <dilfridge> yeah, means coordiation mgorny<>infra
-[20:10:48] <dberkholz> presumably not open source so it's gonna be impossible for anyone to work on it
-[20:10:49] <ulm> yep
-[20:11:10] <mgorny> maybe we'll sync that with gitmig
-[20:11:10] <dilfridge> that doesnt worry me too much since it was already modified once
-[20:11:33] <ulm> mgorny: do it now, one thing less to worry about
-[20:11:55] <mgorny> ok
-[20:12:02] <mgorny> i'll ping infra people about it
-[20:12:12] <dilfridge> do we need a vote?
-[20:12:51] -*- ulm notes that nobody has objected
-[20:13:00] <dilfridge> indeed
-[20:13:12] <dilfridge> so I think this is good to go from our side and we can un-cc council.
-[20:13:33] <dilfridge> last words for this topic?
-[20:13:54] <dilfridge> seems not.
-[20:13:57] <dilfridge> ok 
-[20:13:59] <dilfridge> item 3
-[20:14:03] <dilfridge> open floor
-[20:14:06] <dilfridge> anyone?
-[20:14:38] <mgorny> <herd/> in metadata.xml!
-[20:14:44] <dilfridge> ... 
-[20:14:48] <mgorny> do we want to revisit this?
-[20:15:33] <mgorny> (talking as mgorny, not blueness now :P)
-[20:15:33] <ulm> either leave everything as it is, or get rid of herds
-[20:15:43] -*- WilliamH says nuke herds
-[20:15:54] <ulm> but don't rename it only to a more verbose syntax
-[20:16:00] <mgorny> so herds.xml completely and leave mail aliases?
-[20:16:31] <WilliamH> mgorny: that would be my thought, just make herds into aliases if they aren't already, make them maintainers.
-[20:16:34] <dilfridge> nuke herds as a concept ("groups of packages"), but unify/simplify it as mail aliases
-[20:17:23] <radhermit> I have a question in regards to EAPI 6 now that we have mgorny here too. Did we ever officially include (or vote on) banning global helpers?
-[20:17:27] <mgorny> so no type="" in maintainer?
-[20:17:34] <dilfridge> and find a way to keep metadata.xml <concise type="very"/>
-[20:18:05] <mgorny> if we are to change in backwards-incompat, we should probably switch from XML to JSON
-[20:18:10] <mgorny> or YAML, even better
-[20:18:22] <mgorny> - maintainers: foo@gentoo.org, bar@gentoo.org
-[20:18:30] <mgorny> even without -
-[20:18:47] <dilfridge> mgorny: simpler, introduce a NEW tag that expands its contents to contents@gentoo.org
-[20:19:03] <mgorny> nope, that's a bad idea
-[20:19:13] <dilfridge> why?
-[20:19:32] <mgorny> again it's going in the direction of having more rules
-[20:19:36] <dilfridge> I personally like the (non-doable) <maintainer>dilfridge</maintainer>
-[20:19:53] <mgorny> plus not every ebuild repo is gentoo
-[20:20:09] <ulm> dilfridge: yeah, keep it simple
-[20:20:40] <ulm> <project>eselect</project>
-[20:20:41] <ulm> <team>emacs</team>
-[20:20:45] <dilfridge> right now the <herd>perl</herd> is a short alternative to a very long ...
-[20:20:56] <dilfridge> and I dont want to lose this
-[20:21:01] <mgorny> so well, simplifying it in non-backwards compatible way is second step, i'd say
-[20:21:23] <mgorny> could we focus on the first step which is unifying alias style?
-[20:21:28] <mgorny> maintainer tag*
-[20:21:31] <dberkholz> mgorny: it's not even backwards-incompat to move to yaml, you'd put it in metadata.yaml and could translate
-[20:21:38] <dberkholz> yml rather
-[20:21:59] <ulm> dberkholz: keep the .xml for a transition time?
-[20:22:08] <dilfridge> just disallow having both
-[20:22:29] <ulm> there are some tools/sites using the xml
-[20:22:37] <ulm> packages.g.o I suppose
-[20:22:39] <dberkholz> ulm: pretty much, yeah. server-side translator, if .yml exists it has precedence and might even be able to refuse commits to .xml
-[20:23:34] <dilfridge> I have no problems with using xml, just there are ways of <using>xml</using> and <using type="right now" attribute="indeed><description>xml</description></using>
-[20:23:46] <dilfridge> and yes I forgot to close a bracket
-[20:23:47] <dberkholz> makes it a lot easier to experiment if you can retain backwards compat somehow.
-[20:24:21] <dberkholz> (why xml sucks)
-[20:24:26] <mgorny> so let's summarize:
-[20:24:38] <mgorny> 1. we don't need distinction between herds and projects and developers and other maintainers
-[20:24:39] <ulm> <using><word lang="e<char code="ascii">x</char><char code="ascii">m</char>n><char code="ascii">m</char></word></using>
-[20:24:45] <mgorny> 2. we want to replace metadata.xml with something simpler
-[20:25:19] <ulm> strong no to 1.
-[20:25:21] <WilliamH> mgorny: lgtm
-[20:25:25] <dilfridge> 3. writing out @gentoo.org in every e-mail address sucks for the gentoo repository
-[20:25:39] <mgorny> if we want to, i can convert all metadata.xml to metadata.yml easily
-[20:25:42] <ulm> we need a way to distinguish between teams and individuals
-[20:25:47] <mgorny> the other way would be a bit harder
-[20:25:48] <WilliamH> dilfridge: you can't drop @g.o because of proxy maintainers?
-[20:26:10] <dilfridge> no "@" versus "@" present?
-[20:26:13] <mgorny> ulm: .... but you just said no to keeping herds?
-[20:26:41] <mgorny> dilfridge: that's unprofessional assumption
-[20:26:46] <ulm> mgorny: we don't drop projects and teams
-[20:26:50] <ulm> just herds
-[20:26:57] <mgorny> ulm: so you say we change herd -> team?
-[20:27:10] <mgorny> (or project)
-[20:27:13] <ulm> more or less, yes
-[20:27:23] <dilfridge> mgorny: why? every e-mail address has to contain @. so the repository may as well provide a default domain if it is not given.
-[20:27:58] <mgorny> dilfridge: still, having explicit @gentoo.org does not hurt [11 chars]
-[20:28:10] <mgorny> and people tend to copy metadata.xml when forking ebuilds
-[20:28:12] <mrueg> how about a rewrite hook for lazy devs?
-[20:28:21] <ulm> 11 chars times number of metadata files in the tree
-[20:28:35] <mgorny> ulm: you don't write 100 metadata.xml files every day
-[20:28:45] <mgorny> not to mention it's *not* hard to have a template
-[20:28:52] <mgorny> vim even generates good metadata.xml by default
-[20:28:56] <mgorny> with my e-mail and so on
-[20:29:05] <dilfridge> 18038 metadata.xml in portage
-[20:29:07] <WilliamH> ulm: an individual will more than likely not have the same name as a team.
-[20:29:17] <WilliamH> ulm: or the same email address.
-[20:29:29] <WilliamH> ulm: systemd and openrc come to mind as examples.
-[20:29:55] -*- WilliamH is out taxi is here for dental appointment
-[20:30:08] <dilfridge> good luck
-[20:31:25] <mgorny> ulm: so do you agree with my currently suggested metadata.xml change with just type="developer|team"?
-[20:31:36] <ulm> and project
-[20:31:50] <mgorny> proxies too or just assume they're developer-like too/
-[20:32:10] <ulm> no strong opinion about this
-[20:32:24] <ulm> but don't name it "proxy-maintainer" if you keep them
-[20:32:26] <mgorny> ok
-[20:32:38] <mgorny> so i'll focus on changing this, and then try to preapre a new spec for metadata.yml
-[20:32:45] <mgorny> with short syntax to make people happy
-[20:32:46] <mrueg> developer = single person could be gentoo dev, proxied user or upstream. email ends with gentoo.org => gentoo-dev
-[20:33:54] <ulm> or no domain => default to @gentoo.org => dev
-[20:34:41] <ulm> even could keep the default domain in repos.conf
-[20:34:55] <ulm> I mean layout.conf
-[20:35:10] <dilfridge> yep
-[20:35:20] <mgorny> but that still makes stuff non-standalone
-[20:35:32] <mgorny> people can't copy metadata.xml without losing information
-[20:36:08] <mrueg> mgorny: is this necessary?
-[20:36:19] <mgorny> this happens a lot
-[20:36:20] <ulm> why would you copy metadata.xml from another repo, without fixing maintainer
-[20:36:40] <mgorny> because people fork ebuilds and don't care about metadata? :P
-[20:36:43] <mgorny> not that such metadata is very useful
-[20:36:52] <mgorny> but well-formedness!
-[20:36:59] <dilfridge> do you want to get maintainer mails from a forked ebuild?
-[20:37:27] <mgorny> if it's my bug, why not
-[20:37:30] <mgorny> but i'm weird
-[20:37:38] <mrueg> hm repos.conf idea is sexy because it hides emails
-[20:37:51] <mrueg> which results in probably less spam
-[20:37:55] <dilfridge> I mean the default could well be @doesnotexist.org which is overridden in ::gentoo by @gentoo.org
-[20:37:59] <dilfridge> good point
-[20:38:25] <mgorny> lol @ less spam in gentoo
-[20:38:31] <dilfridge> yeah well
-[20:38:33] <mgorny> we should start by fixing bugzie :P
-[20:38:45] <mgorny> but it's too late i say
-[20:38:48] <dilfridge> brb
-[20:38:53] <dberkholz> i like the default domain in repos.conf
-[20:39:00] <dberkholz> would make life easier for corp repos too
-[20:39:26] <mgorny> we may move on to default maintainer in repos.conf
-[20:39:41] <mgorny> in case of repos such as gnome overlay that are maintained by one team
-[20:40:41] <dilfridge> true
-[20:40:46] <mrueg> thinmetadata :>
-[20:41:12] <mgorny> do we also want to move repo_name to layout.conf?
-[20:41:22] <mgorny> i mean, i think we already state this is the modern layout
-[20:41:47] <mrueg> mgorny: iirc it's deprecated, but there were some tools still checking for it
-[20:42:57] <ulm> PMS requires repo_name
-[20:43:28] <dilfridge> right so this will need a longer process
-[20:43:38] <dilfridge> ok
-[20:43:45] <dilfridge> I think we've collected a lot of ideas
-[20:44:02] <dilfridge> so we should maybe table it for today
-[20:44:25] <dilfridge> anyone still wants to say something about this topicß
-[20:44:26] <dilfridge> ?
-[20:45:05] <dilfridge> seems nto
-[20:45:12] <dilfridge> any other things for the open floor?
-[20:45:38] <ulm> qa elections are due
-[20:45:46] <dilfridge> right
-[20:45:55] <dilfridge> so we should send them a friendly reminder :)
-[20:45:56] <ulm> I haven't seen any applications, so far
-[20:46:23] <ulm> dilfridge: we asked for applications in the last qa meeting
-[20:46:37] <dilfridge> :/
-[20:47:17] <dilfridge> so what's going to happen if there are no applicants?
-[20:48:16] <ulm> that case is not foreseen, I fear
-[20:48:18] <mgorny> we vote unanimously on the old lead
-[20:48:29] <radhermit> revisiting my question, did we ever officially ban global helpers yet for EAPI 6?
-[20:48:36] <radhermit> it's not included on the wiki apge
-[20:48:37] <dilfridge> good question
-[20:48:46] <radhermit> and it's in portage :)
-[20:48:57] <mgorny> radhermit: and in PMS, since EAPI 0 :)
-[20:49:11] <dilfridge> radhermit: I'm checking the logs
-[20:49:37] <radhermit> mgorny: then why does portage check for EAPI when doing that? Or maybe I was imagining things
-[20:49:53] <mgorny> i recall this being discussed somewhere, but i don't remember if it was the Council, QA or just dev-portage
-[20:50:02] <mgorny> radhermit: for backwards compatibility
-[20:50:10] <radhermit> hmm
-[20:50:26] <dilfridge> ok I can't find anything quickly in the summaries
-[20:50:33] <mgorny> we don't want to risk that for some reason uninstall of installed package will die
-[20:50:58] <dilfridge> mgorny: but that's fine if it only dies in EAPI>=6
-[20:51:06] <mgorny> yes
-[20:51:12] <dilfridge> ok
-[20:51:31] <dilfridge> shall we vote on this?
-[20:52:01] <dilfridge> mgorny: radhermit: could you propose a wording please?
-[20:52:16] <mgorny> i don't think we need an extra vote for making portage conform to PMS in next EAPI
-[20:52:34] <mgorny> we would if we were to make it for all EAPIs
-[20:52:54] <dilfridge> I tend to agree, but I also see it as unproblematic, so why not...
-[20:53:11] <dilfridge> radhermit: what do you think?
-[20:53:31] <mgorny> vote: ban calling helpers in global scope in portage starting with EAPI=6
-[20:54:32] <dilfridge> anyone?
-[20:54:45] <ulm> what? vote in open floor?
-[20:54:58] <mgorny> dilfridge wanted some voting today :)
-[20:55:00] <dilfridge> shrug
-[20:55:21] <mgorny> we can pretend to be voting for dilfridge as QA lead
-[20:55:25] <dilfridge> ulm: what's the alternative? discuss on the mailing list that portage should adhere to pms?
-[20:55:42] <ulm> we already had a qa vote for this
-[20:55:53] <dilfridge> ok then I dont care
-[20:55:55] <dilfridge> do it
-[20:55:57] <dilfridge> imho
-[20:56:05] <ulm> so sure, the council can confirm, but what's the point?
-[20:56:14] <mgorny> hmm, didn't QA move some things to council anyway?
-[20:56:19] <mgorny> i don't recall from the meeting
-[20:56:28] <ulm> seems there is general agreement that global helpers should be banned
-[20:56:30] <dilfridge> radhermit: why are you asking about this?
-[20:56:42] -*- dilfridge is thinking what would be affected
-[20:57:08] <ulm> mgorny: you voted yes :)
-[20:57:23] <ulm> or rather, it was unanimous
-[20:57:35] <mgorny> i know but i'm asking if there were other matters maybe
-[20:58:21] <ulm> QA vote was: Making global-scope 'use*', 'has_version' and 'best_version' fatal since EAPI 6
-[20:58:42] <ulm> and we postponed the decision about fatal in previous eapis
-[20:58:51] <dilfridge> ok so a) we're likely not voting on it, and b) I doubt a vote is actually needed, since qa has spoken.
-[20:59:25] -*- dilfridge notes that the one obviousl consumer is toolchain multislot, but qa has likely known about that.
-[20:59:40] -*- ulm shudders
-[20:59:51] <dilfridge> ok 
-[21:00:14] <dilfridge> I'm hungry, so unless anyone now still wants someting reeeeallly important...
-[21:00:40] <mgorny> hmm
-[21:00:56] <mgorny> we can talk about gcc[awt] if you want to
-[21:01:28] -*- dilfridge doesn't really want to...
-[21:01:30] <ulm> dilfridge: it's an art to have a meeting ongoing for a full hour, with an agenda that is essentially empty :p
-[21:01:34] <dilfridge> hehe
-[21:01:38] <dilfridge> ok 
-[21:01:51] <dilfridge> mgorny: if you want that on the agenda, next time.
-[21:01:57] <dilfridge> meeting closed. :P
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20150113-summary.txt b/xml/htdocs/proj/en/council/meeting-logs/20150113-summary.txt
deleted file mode 100644
index add6b68f2e..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20150113-summary.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-Roll call
-=========
-
-Present: blueness, dberkholz, dilfridge, radhermit, rich0, ulm, williamh
-Absent: -
-
-
-Discussion of GLEP39, "unresponsive projects" / "unresponsive project leads"
-=========
-
-It was brought up what to do if a project and / or its lead are unresponsive, 
-in particular if someone wants to co-maintain and help out but e.g. never gets
-a response to e-mails. The specific case in question was toolchain maintenance.
-
-The consensus was that developers should apply for project membership, and if
-no response at all comes within a reasonable timeframe, be bold, add themselves 
-to the project, and start contributing in a resposible and careful way. This 
-explicitly also applies to central projects such as toolchain.
-
-
-Policy for long-term package masks (10 minutes) 
-=========
-
-The question was brought up whether packages can remain masked for an indefinite
-time, e.g. due to QA or security issues, or whether they have to be removed 
-after some time.
-
-After discussion, the following motions were passed: 
-"Packages with security vulnerabilities may remain in tree package-masked for 
-indefinite time, assuming there are no replacements for them and they have 
-active maintainers." (5 yes, 2 no)
-"The security issue must be documented in the mask message, with bug number."
-(6 yes)
-
-
-Bug 523828 "GLEP 42 update: Unify gentoo-news repo and rsync structure"
-=========
-
-Nothing left to do for the council, removed from CC list.
-
-
-Open Floor
-=========
-
-Discussion regarding long-term masked games ensued. A suggestion was to start
-last-rites procedures in selected cases- if noone steps up and / or
-protests with good arguments, then the game is unmaintained and can be removed.
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20150113.txt b/xml/htdocs/proj/en/council/meeting-logs/20150113.txt
deleted file mode 100644
index 46c9b98978..0000000000
--- a/xml/htdocs/proj/en/council/meeting-logs/20150113.txt
+++ /dev/null
@@ -1,352 +0,0 @@
-[20:02:02] <dilfridge> shall we start?
-[20:02:02] <-> ulm_ heißt jetzt ulm
-[20:02:18] <dilfridge> 1. Roll call (5 minutes)
-[20:02:20] -*- dilfridge here
-[20:02:24] <radhermit> here
-[20:02:30] -*- rich0 here
-[20:02:35] <dberkholz|mob> Here
-[20:02:44] -*- WilliamH here
-[20:03:12] <dilfridge> ulm, blueness?
-[20:03:24] <blueness> here
-[20:03:34] <ulm> just in time for the meeting I am having connection issues :(
-[20:03:36] -*- ulm here
-[20:03:43] <dilfridge> ok everyone's here!
-[20:04:03] <dilfridge> 2. Discussion of GLEP39, "lame projects" / "lame project leads" (10 minutes)   http://thread.gmane.org/gmane.linux.gentoo.project/4169/focus=4170
-[20:04:11] <dilfridge> rich0: your moment
-[20:04:32] <rich0> Was that one mine?
-[20:04:35] <radhermit> lame -> unresponsive I assume
-[20:04:43] <dilfridge> err sorry
-[20:04:49] <dilfridge> blueness: your moment :)
-[20:05:02] <blueness> well
-[20:05:02] -*- rich0 breathes a sign of relief
-[20:05:32] <blueness> there was a lot of chatter on the list, but basically i wanted to see what the council thinks we ought to do with lame team leads
-[20:06:07] <blueness> in particular toolchain.  it doesn't have a project page, i'm not sure whos lead, i think its vapier, but vapier isnt' very responsive
-[20:06:29] <blueness> so i want to help with toolchains, but can't interact with its organization
-[20:06:32] <WilliamH> blueness: if it doesn't have a project page it isn't really a project?
-[20:06:39] <dilfridge> in this particular case it's even more complicated since it's no project (no page)...
-[20:06:43] <blueness> no idea, it *is* a herd
-[20:06:49] <WilliamH> blueness: I've seen toolchain as more a subproject of base-system.
-[20:06:51] <dilfridge> and glep39 only talks about projects...
-[20:07:08] <blueness> WilliamH, is it?
-[20:07:15] <rich0> All of these issues are related.
-[20:07:30] <WilliamH> Well, it is more like just a group of maintainers.
-[20:07:36] <rich0> We have lots of loose associations of packages and devs with varying levels of formality, and varying levels of leadership/etc.
-[20:07:37] <WilliamH> udev-bugs is similar.
-[20:07:44] <blueness> glep 39 isn't so much about laying down the law as expectations
-[20:08:02] <rich0> I'll agree with that.  I think there needs to be flexibility.
-[20:08:14] <rich0> Also, I think that to some degree devs need to "be bold" in Wikipedia terms.
-[20:08:28] <rich0> ie not wait around forever for an email response that will probably never come
-[20:08:44] <WilliamH> rich0: I can agree with that... I have personally been cautious about that myself in ways, but you are right.
-[20:08:48] <blueness> rich0, i think some boldness is needed too, but its really hard when you are naturally a "team player' not that i like that erm
-[20:08:51] <blueness> term
-[20:09:17] <dilfridge> the base system project page states that the base system project kinda maintains the toolchain, though it does not list toolchain as one of its herds
-[20:09:23] <blueness> classic bug to illustrated the issue -> https://bugs.gentoo.org/show_bug.cgi?id=516988
-[20:09:23] <radhermit> what exactly are you wanting to do here? rework/redo the toolchain eclass and need feedback?
-[20:09:43] <-- dberkholz|mob (~AndChat19@gentoo/developer/dberkholz) hat das Netzwerk verlassen (Disconnected by services)
-[20:10:23] <blueness> radhermit, no just get some toolchain stuff done, eg the next one is shooting for gcc 4.9.2 stabilizatoin
-[20:10:40] --> dberkholz|mob (~AndChat19@gentoo/developer/dberkholz) hat #gentoo-council betreten
-[20:10:48] <radhermit> so there really hasn't ever been a leader coordinating such things in recent history
-[20:10:50] <WilliamH> blueness: imo if no one responds in a reasonable amount of time add yourself and go for it.
-[20:11:05] <radhermit> just the main gcc maintainer at the time
-[20:11:06] <rich0> Agree with the solution to the immediate problem.
-[20:11:21] <WilliamH> radhermit: yes, it was mostly the gcc maintainer.
-[20:11:21] <rich0> I think the real question is does this need fixing, and can it be fixed?
-[20:11:39] <blueness> radhermit, in part just filling in the nitty griddy stuff with rhill being gone
-[20:11:39] <WilliamH> rich0: I'm not sure there is anything to fix here.
-[20:11:56] <rich0> IMO I think our options are limited.  If somebody doesn't want to actually step up and be a charismatic leader / etc, then at most we can just put barriers in the way of people who don't want to do that.
-[20:12:01] <blueness> the toolchain eclass is there too, but i don't want to focuse on that
-[20:12:09] <radhermit> basically someone needs to step up, and we can't really do anything as a council to effectively make that happen
-[20:12:12] <dilfridge> that is a different porblem
-[20:12:37] <dilfridge> the biggest problem is "trying to join a team, but there is noone who responds"
-[20:12:45] <blueness> radhermit, i'm okay with coordinating it, but vapier is the technical wizard here
-[20:12:52] <WilliamH> blueness: I say go for it; no one is stopping you from adding yourself.
-[20:12:55] <rich0> yup, I don't think not having any toolchain team is better than having one with a non-responsive lead
-[20:13:13] -*- dilfridge has some doubts about the wizard level since the botched dependency fixes
-[20:14:01] <blueness> okay, so zorry and i spoke about this in pm and we'd like to start coordinating toolchain
-[20:14:24] <blueness> so maybe i'll get a page up as a subproject of base system
-[20:14:31] <radhermit> sounds fine to me
-[20:14:31] <dilfridge> sounds good
-[20:14:38] <WilliamH> blueness: nothing is stopping you from formalizing it into a project.
-[20:14:44] <blueness> and then at least there'll be some point-of-contact
-[20:15:14] <WilliamH> blueness: it doesn't have to be a subproject of base-system even imo that's up to you.
-[20:15:22] <blueness> to be honest, i didn't care so much about games team or other teams being disorganized, but its worrisome when toolchain is this way
-[20:15:37] <dilfridge> yes, but it's a repetitive problem
-[20:15:52] <blueness> okay, i don't think we need a motion here or anything, i just wanted to bounce this off the council for feedback
-[20:16:05] <rich0> toolchain, portage at times, sometimes infra.  There are a lot of overworked/understaffed/etc projects that are fairly core to the distro
-[20:16:06] <dilfridge> maybe we should come up with a general idea how to solve it
-[20:16:11] <radhermit> I think teams are disorganized in general, with organization being the rarity here
-[20:16:16] <blueness> zorry and i had a similar situation with hardened back in the day when gengor + solar were fading away
-[20:16:47] <rich0> To some extent it might reflect an attitude that these things are mature and don't need a lot of improvement
-[20:16:48] <dilfridge> scarabeus seems to be missing in action, so office is only me right now...
-[20:17:06] <ulm> isn't it straight forward? apply to join the project/team, and if there is no reply from project members for some time then you just add yourself
-[20:17:11] <blueness> radhermit, if you see vapier in real life, just let him know what i'm up to.  and reassure him we (zorry and i) are only shooting for conservative commits
-[20:17:28] <radhermit> sure, might see him tonight
-[20:17:29] <dilfridge> ulm: that is exactly what I'd suggest to put somewhere in writing.
-[20:18:04] <ulm> lead MIA can be handled in a similar way
-[20:18:08] <radhermit> that's exactly what I've always done... other people are just too hesitant I guess :P
-[20:18:13] <WilliamH> As someone told me, the lead of a project doesn't have to be the technical wizzard. The lead just coordinates the project.
-[20:18:13] <rich0> Agree.  In general if the previous team is unresponsive, just step up and make a new one, etc.
-[20:18:33] <rich0> WilliamH++
-[20:18:46] <radhermit> really the technical wizard types should probably be doing work, not coordinating stuff
-[20:19:21] <blueness> works for me
-[20:19:26] <rich0> Agree.  We don't want people who are outright disruptive, but if somebody wants to quietly do their own thing and it is making Gentoo better, then we should get out of their way.
-[20:19:32] <dilfridge> do we need / want a resolution?
-[20:19:55] <blueness> dilfridge, i don't think we need a motion here
-[20:20:06] <dilfridge> fine with me
-[20:20:08] -*- WilliamH agrees with blueness 
-[20:20:10] <dilfridge> anyone else?
-[20:20:11] <rich0> I think we should try to send out a general mesage though.  It isn't about rules.
-[20:20:20] <radhermit> "Ask if you can add yourself... after X amount of time with no response, add yourself."
-[20:20:23] <radhermit> something like that
-[20:20:26] <blueness> toolchain is important and i want to make sure the council is okay with trying to re-organize it
-[20:20:28] <rich0> radhermit: ++
-[20:20:35] <WilliamH> s/x/a reasonable/
-[20:20:52] <rich0> And they can always escalate to council if there is conflict.  However, if it is person vs wall of silence, the person can just assume the answer is yes.
-[20:21:01] <blueness> radhermit, i almost always agree with that statement, but i'm not so sure when it comes to the more demanding stuff
-[20:21:08] <dberkholz|mob> +1 on that (self-adding w no response)
-[20:21:19] <blueness> eg. i'm not sure if non-response about binutils should mean anyone gets to add binutils!
-[20:21:26] <dberkholz|mob> Making that explicit if it's not yet would be a good thing
-[20:21:30] <radhermit> blueness: if some random person starts breaking important stuff they'll get noticed ;)
-[20:21:36] <blueness> true!
-[20:21:40] <radhermit> and things will become less silent
-[20:21:45] <blueness> yes yes
-[20:21:47] <dilfridge> and qa wakes up
-[20:21:49] <dilfridge> :)
-[20:22:00] <blueness> actually the way i usually add toolchain stuff is keyword masked
-[20:22:01] <rich0> radhermit: agree, right now I think we're erring on the side of too little risk, and not enough is getting done
-[20:22:10] <blueness> so it can't break stuff right away
-[20:22:19] <rich0> If things start breaking then we can deal with that problem
-[20:22:21] <blueness> but its there for testing
-[20:22:37] <dilfridge> ok I think we're all basically of the same opinion.
-[20:22:50] <dilfridge> any completely different statements? if not, ...
-[20:23:11] <blueness> good, so expect some toolchain stuff to be comeing from me and zorry, eg stabilization of gcc-4.9 etc
-[20:23:21] <radhermit> sounds excellent
-[20:23:36] <dilfridge> Next topic... 
-[20:23:36] <dilfridge> 3. Policy for long-term package masks (10 minutes) http://thread.gmane.org/gmane.linux.gentoo.project/4169/focus=4198
-[20:24:04] <WilliamH> Really what I was wanting was to get some folks to step up and update them or fix things.
-[20:24:05] <dilfridge> dunno how much we need to talk there
-[20:24:18] <WilliamH> and that is happening.
-[20:24:31] <dberkholz> i would kinda prefer to see them move to overlays if they're gonna be long-term
-[20:24:48] <radhermit> some issues relate to games that have bundled libs I'm assuming, kind of hard to fix that
-[20:24:48] <dberkholz> and use p.mask for breakage
-[20:24:49] -*- WilliamH tends to agree with dberkholz  to be honest
-[20:25:09] <ulm> as long as a package is actively maintained, I don't have a problem with long-term masks
-[20:25:31] <blueness> ulm, there is one example of where that might make sense
-[20:25:32] <ulm> but we should avoid broken and unmaintained stuff sitting in the tree for years
-[20:25:42] <WilliamH> is taviso still around ?
-[20:25:44] <blueness> paxtest is a package which is *intentionally* broken
-[20:25:47] <dilfridge> as long as there is a good description what the mask is for, I don't mind either (why? impact? duration?)
-[20:25:51] <radhermit> taviso isn't around
-[20:25:53] -*- WilliamH points to the very bottom of p.mask
-[20:26:20] <radhermit> works on google security stuff atm iirc
-[20:26:37] <WilliamH> radhermit: is he still an active gentoo maintainer?
-[20:26:42] <dilfridge> in general masked packages are better gone, but there are valid reasons to keep them around
-[20:26:45] <ulm> WilliamH: nethack? that was discussed on lists
-[20:26:55] <ulm> broken by games policy
-[20:27:11] <WilliamH> no
-[20:27:12] <WilliamH> sorry
-[20:27:16] <radhermit> WilliamH: he's not even a dev afaik
-[20:27:17] <dberkholz> is he even an active gentoo dev? i don't think so
-[20:27:20] <radhermit> retired him
-[20:27:26] <WilliamH> bug 44351
-[20:27:27] <dilfridge> # <klieber@gentoo.org> (01 Apr 2004)
-[20:27:28] <dilfridge> yeah
-[20:27:29] <willikins> WilliamH: https://bugs.gentoo.org/44351 "games-fps/unreal engine vulnerability"; Gentoo Security, Vulnerabilities; VERI, CANT; carlo:security
-[20:28:07] <WilliamH> masked for 11 years now?
-[20:28:20] <dilfridge> actually I wonder if this still runs
-[20:28:26] <ulm> in addition these are cdrom installs, so nobody can check status
-[20:28:49] <mgorny> is unreal free these days?
-[20:28:56] <rich0> that was on the lists
-[20:28:56] <ulm> such stuff should be removed, or moved to an overlay
-[20:28:56] <rich0> yes
-[20:29:10] -*- WilliamH agrees with ulm
-[20:29:12] <rich0> I'm not convinced that games with issues like this can't be in the tree
-[20:29:20] <blueness> i agree with ulm above, the key point is whteher its being actively maintained, not the masking
-[20:29:21] <rich0> However, I think that should only be if they're maintained
-[20:29:35] <rich0> if they're maintainer-wanted and nobody can even tell if they work, then I'm fine with treecleaning
-[20:30:05] <rich0> Anything that isn't open-source should be treecleaned if not maintained - nobody can even vouch for whether it works
-[20:30:16] <WilliamH> Is "This is a fun game so I think it should be kept" valid?
-[20:30:24] <ulm> rich0: +1
-[20:30:27] <ulm> it's a different story if there's a maintainer who can confirm that it still works
-[20:30:44] <WilliamH> ;-)
-[20:30:53] <a3li> just to be clear: something that works but puts users at risk is "maintained" by your definition?
-[20:30:59] <dilfridge> WilliamH: imho not if there's a big security problem with it
-[20:31:00] <rich0> a3li: yes
-[20:31:10] <rich0> I'm fine with it being masked and in the tree.
-[20:31:14] <rich0> Let the user make the choice
-[20:31:19] <radhermit> solution: try last-riting stuff you want to remove and see who cares ;)
-[20:31:38] <WilliamH> radhermit: I did, that's why we are talking about it.
-[20:31:44] <rich0> I'm more concerned with it being unmaintained and untestable than it being insecure
-[20:31:56] <dilfridge> a3li: what's the official security steam statement about keeping security-problematic packages in the tree masked?
-[20:32:01] <rich0> security is a continuum, with risk up to to the user
-[20:32:23] <a3li> dilfridge: practice has been to remove known vulnerable packages for years (n>5); only keep if needed for good reasons
-[20:32:24] <dilfridge> a3li: (or how is it handled now, mostly?)
-[20:32:29] <blueness> what about a package that simulates security risks as part of a test suite?
-[20:32:35] <WilliamH> When I've had security bugs on packages I maintain I've been asked to remove vulmerable versions after the fixed one is stable.
-[20:32:47] <dilfridge> blueness: that doesnt count imho, but it needs to be documented.
-[20:32:50] <a3li> dilfridge: and statement: keep that policy.
-[20:32:51] <rich0> WilliamH: sure, if there is a non-vulnerable version
-[20:32:55] <blueness> dilfridge, it is
-[20:33:04] <rich0> What if latest version is insecure, and this is unlikely to change?
-[20:33:24] <blueness> paxtest intentionlly tries to execute code in the stack, bss, data etc to see if the pax kernel catches the problem
-[20:33:27] <dilfridge> kick, kill, move to overlay
-[20:33:29] <WilliamH> rich0: I disagree with you wrt keeping vulnerable software in the tree (qa hat firmly on)
-[20:33:30] <dilfridge> ?!
-[20:33:31] <ulm> rich0: remove, unless there are good reasons for keeping it
-[20:34:01] <rich0> WilliamH: you're allowed to disagree, but I'm not changing my mind
-[20:34:19] <dilfridge> ok
-[20:34:20] <rich0> ulm: the good reason for keeping it is that it is useful
-[20:34:36] -*- WilliamH disagrees
-[20:35:10] <blueness> security depends on context, so let the user decide
-[20:35:11] <rich0> WilliamH: everything you use has a security vulnerability.  They're just unknown at present.
-[20:35:22] <ulm> on the list, there was the example of sys-block/afacli which depends on a package with security issues, but there is no alternative
-[20:35:40] <dilfridge> "fun game" is in my opinion not a good reason
-[20:35:52] -*- WilliamH agrees with dilfridge 
-[20:35:54] <rich0> what is the alternative to unreal?
-[20:35:58] <ulm> so if it was removed, users would still install it from elsewhere
-[20:36:16] <rich0> ulm: agree
-[20:36:22] <WilliamH> rich0: we aren't saying you can't use it, just that it belongs outside the main tree
-[20:36:25] <dilfridge> ulm: true but not our problem, since we're not providing it
-[20:36:29] <rich0> We're not making anything more secure.  We're just forcing everybody to stick things in overlays
-[20:36:55] <WilliamH> rich0: we are cleaning up the main tree
-[20:36:56] <rich0> WilliamH: you prefer an overlay with no security warnings to an in-tree package with them?
-[20:37:07] <rich0> Why even have a main tree?
-[20:37:14] <radhermit> imo, if we ever move to a more multi-repo centric approach then moving to repos makes sense, currently we're not really pushing that so it doesn't imo
-[20:37:58] <dilfridge> rich0: but we're providing a maintainership / security / ... "guarantee" for the main tree, and for nothing else
-[20:38:22] <rich0> dilfridge: we're not breaking that guarantee
-[20:38:27] <rich0> We clearly disclose that the package is vulnerable
-[20:38:35] <rich0> Which is more info than users would get otherwise
-[20:39:20] <dilfridge> ok
-[20:39:26] <blueness> we have control over the tree and so can assure quality there, but not with repos, so be careful about moving stuff to repos
-[20:39:37] <dilfridge> this is not really going anywhere, we have different opinions
-[20:39:48] <WilliamH> Should we vote on whether packages with security vulnerabilities shoulb be removed from the tree if there are no  fixed versions?
-[20:39:52] <dilfridge> I'd propose a vote:
-[20:40:33] <dilfridge> "may packages with security vulnerabilities remain in tree package-masked for indefinite time?"
-[20:40:48] -*- WilliamH votes no
-[20:40:51] -*- dilfridge no
-[20:40:55] <rich0> I suggest rewording
-[20:40:58] <radhermit> "assuming there are no replacements for them and they have maintainers"
-[20:41:06] <radhermit> tack that on
-[20:41:09] <dilfridge> ok, that is good
-[20:41:10] <blueness> *active* maintainers
-[20:41:16] <rich0> "May maintained packages with security vulnerabilities remain in tree package-masked for indefinite time?"
-[20:41:29] <dilfridge> "may packages with security vulnerabilities remain in tree package-masked for indefinite time, assuming there are no replacements for them and they have active maintainers?"
-[20:41:46] -*- dilfridge votes still no
-[20:41:51] -*- ulm votes yes
-[20:41:54] -*- blueness yes
-[20:41:55] <radhermit> yes
-[20:42:11] <WilliamH> Assuming above, yes.
-[20:42:42] <dilfridge> dberkholz: rich0?
-[20:42:47] <WilliamH> Now my question to the council is, is "games" an active maintainer? I would assume no.
-[20:42:55] <rich0> or radhermit's suggestion
-[20:43:02] <rich0> dilfridge: what?
-[20:43:08] <rich0> lag
-[20:43:12] -*- rich0 yes
-[20:43:58] <WilliamH> Actually, one more thing.
-[20:44:01] <dilfridge> WilliamH: given that I see activity by Mr_Bones updating EAPIs, I would say yes.
-[20:44:41] <WilliamH> looking again at the  mask I cited,
-[20:44:55] <WilliamH> the mask was put there by kleiber and has never been touched.
-[20:45:03] <radhermit> WilliamH: plenty of the games are probably rotting and could be last-rited if Mr_Bones or whoever doesn't step up say they're still maintained
-[20:45:10] <WilliamH> so from that pov, kleiber did the masking.
-[20:45:23] <radhermit> I'm sure he doesn't care about every single game some random dev has added with "games" as the herd and then retired after a few years
-[20:45:42] <WilliamH> radhermit: right.
-[20:45:55] <blueness> when we're done voting, can we have a followup on the resolution
-[20:46:05] <WilliamH> He hasn't stepped up wrt the last rites I posted.
-[20:46:06] <dberkholz> i'd vote no
-[20:46:13] <blueness> i think we should add a few comments if we email this decision out
-[20:46:14] <dberkholz> overlays are fine
-[20:46:27] <dberkholz> (bad connectivity in here, sorry)
-[20:46:37] <radhermit> WilliamH: so CC games/him and wipe them later?
-[20:46:42] <WilliamH> I would add a qualification...
-[20:47:26] <WilliamH> radhermit: why cc games? it was put on g-d-a and dev
-[20:47:32] <dilfridge> ok that means 2x no, 5x yes, motion passed
-[20:47:47] <radhermit> WilliamH: I dunno, you were sounding hesitant
-[20:48:04] <blueness> dilfridge, okay now that we have a yes vote, i think we should also strongly recommend the maintainer communicate the issue to the user
-[20:48:16] <dilfridge> yes
-[20:48:18] <WilliamH> But I think we should be able to push the maintainer to get a fixed version in the tree and remove the old ones.
-[20:48:26] <blueness> say in a pkg_postint say
-[20:48:39] <blueness> there should be some mitigation of the risk
-[20:48:53] <radhermit> how much stronger can you get than a mask stating the vulnerability?
-[20:48:55] <blueness> eg. if you want to play nethack, do it in a sandbox
-[20:48:58] <WilliamH> blueness: if you do that with pkg_postinst it doesn't belong in p.mask.
-[20:49:19] <blueness> sorry your right
-[20:49:23] <WilliamH> p.mask is  not permanent.
-[20:49:24] <blueness> it does say pmasked
-[20:49:33] <blueness> but then we should have the info in the pmask comment
-[20:49:43] <radhermit> if/when people unmask stuff, they should know what they're getting into
-[20:49:44] <blueness> s/info/warning/
-[20:49:57] <radhermit> yes, as long as there's info
-[20:50:01] <WilliamH> If we are going to allow security vulnerable packages to stay in the tree they don't belong in p.mask, use postinst msgs
-[20:50:22] <dilfridge> isn't that exactly what the mask message is for?
-[20:50:25] <radhermit> yes
-[20:50:28] <WilliamH> p.mask is for things that can be fixed.
-[20:50:29] <blueness> radhermit, i'm good, it just slipped my mind that p.mask has that comment when you try to emerge
-[20:51:00] <radhermit> p.mask is for masking things, full stop
-[20:51:10] <WilliamH> I was always taught that p.mask is never permanent.
-[20:51:41] <dilfridge> ok
-[20:51:53] <dilfridge> do we want to make another vote / motion?
-[20:52:08] <creffett|irssi> just to chime in as a security type: which makes more sense, a big warning that says "security issues, unmask at your own risk" or an easily-ignored postinst?
-[20:52:09] <blueness> dilfridge, for the warning?
-[20:52:41] <dilfridge> "the security issue must be documented in the mask message, with bug number"
-[20:52:48] <radhermit> sounds fine
-[20:52:56] -*- blueness yes
-[20:53:05] -*- rich0 yes
-[20:53:07] -*- dilfridge yes
-[20:53:13] -*- radhermit yes
-[20:53:39] -*- ulm yes
-[20:53:41] <dberkholz> of course..
-[20:53:54] <dilfridge> k
-[20:54:00] <dilfridge> anything else to say here?
-[20:54:31] <dilfridge> seems not
-[20:54:32] <WilliamH> I se this as an abuse of p.mask to be honest.
-[20:54:39] <blueness> (ab)use
-[20:55:27] <dilfridge> 4. Open bugs with council involvement (5 minutes)
-[20:55:27] <radhermit> and I wish all games released source code after X number of years
-[20:55:28] <blueness> WilliamH, it really does depend if this just becomes an easy way around trying to fix something or a last resort
-[20:55:39] <WilliamH> http://devmanual.gentoo.org/profiles/package.mask/index.html
-[20:56:27] <dilfridge> blueness: indeed. so let's start lastriting ancient stuff and see what happens.
-[20:56:30] <dilfridge> anyway
-[20:56:32] <dilfridge> 4. Open bugs with council involvement (5 minutes)
-[20:56:38] <dilfridge> bug 523828
-[20:56:40] <willikins> dilfridge: https://bugs.gentoo.org/523828 "GLEP 42 update: Unify gentoo-news repo and rsync structure"; Doc Other, GLEP Changes; CONF; mgorny:glep
-[20:56:49] <dilfridge> any news here?
-[20:57:19] <WilliamH> dilfridge: I agree with you, let's start getting rid of ancient stuff.
-[20:57:40] <dilfridge> since we decided about it last time, maybe we should just un-cc council and leave the execution to, well, some able executioners?
-[20:57:58] <ulm> someone should update that glep
-[20:58:22] <dilfridge> the generation code is more critical
-[20:58:42] <ulm> it's a trivial change
-[20:59:02] <dilfridge> yes but someone needs to do it. wink, wink, wink...
-[20:59:27] <ulm> the proponent? :)
-[20:59:34] <dilfridge> ok seems nothing to do here. 
-[20:59:44] <dilfridge> bug 503382
-[20:59:49] <willikins> dilfridge: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
-[20:59:59] <dilfridge> well, nothing to do here either. just move along please.
-[21:00:15] <dilfridge> 5. Open floor
-[21:00:18] <dilfridge> anyone?
-[21:00:40] <WilliamH> Well, I'll just comment.
-[21:00:55] <WilliamH> Today's debate is a good example of why devs find it hard to be bold and do things.
-[21:01:05] <WilliamH> *sigh*
-[21:02:12] <blueness> i'm not sure bold/courage is the right issue, its more respect
-[21:02:20] <blueness> and coordinating with other devs
-[21:02:32] <radhermit> about masks? I still don't see what the issue is about removing ones if no one cares enough to respond for certain pkgs.
-[21:03:02] <radhermit> that's what last rites are partially for, questioning maintainership
-[21:03:21] <WilliamH> I need to go through the thread again, but I believe I saw someone say that "x is a fun game, so this should be kept in the tree regardless of the risk" a couple of times.
-[21:03:49] <rich0> WilliamH: if it were maintained I'd agree with them
-[21:03:51] <radhermit> if they didn't want to step up and maintain it... too bad I'd say
-[21:03:53] <dilfridge> WilliamH: noone prevents you from starting last rites, and if "someone" doesnt volunteer to maintain it, then "someone" doesn't really count
-[21:03:58] <WilliamH> I also saw one that was "Now there is a new version of x that is gpl'd, but we should keep both."
-[21:04:06] <rich0> dilfridge: ++
-[21:04:26] <rich0> WilliamH: might be worth exploring the reasoning behind such a statement in the latter example
-[21:04:41] <rich0> In general though I'm more about informing users than making choices for them
-[21:05:02] --> keytoaster (~tobias@gentoo/developer/keytoaster) hat #gentoo-council betreten
-[21:05:06] <rich0> Stuff that is just broken or which we can't be sure if it is broken or not, that is a different story.  There is no value to having ebuilds in the tree that don't even build
-[21:05:13] <dilfridge> ++
-[21:05:21] <dberkholz> are you arguing that insecure software isn't broken?
-[21:05:26] <WilliamH> The justification was pretty weak, just like the argument we had a while back about keeping module-init-utils.
-[21:05:48] -*- WilliamH thinks insecure software is dangerously broken
-[21:06:01] <radhermit> insecure software that you aren't able to fix but have to use is broken in a special way :)
-[21:06:26] <dilfridge> and with these words, it's about time... I dont think this further discussion is going anywhere.
-[21:06:37] <dilfridge> new arguments next month please.
-[21:06:46] <WilliamH> What about the "gentoo is about choice" argument?
-[21:06:47] -*- dilfridge bangs the gavel
-[21:07:01] <dilfridge> session closed