rich0 14/06/17 22:25:37 Added: 20140617-summary.txt 20140617.txt Log: Add Council meeting summaries.
Revision Changes Path 1.1 xml/htdocs/proj/en/council/meeting-logs/20140617-summary.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140617-summary.txt?rev=1.1&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140617-summary.txt?rev=1.1&content-type=text/plain Index: 20140617-summary.txt =================================================================== Summary of Gentoo council meeting 10 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 <ri...@gentoo.org> 1.1 xml/htdocs/proj/en/council/meeting-logs/20140617.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140617.txt?rev=1.1&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140617.txt?rev=1.1&content-type=text/plain Index: 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
