path: root/meeting-logs/20110111.txt

[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