path: root/meeting-logs/20140617.txt

[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