let's start? [21:00] *** willikins (~rbot@gentoo/bot/Willikins) has quit: Ping timeout: 245 seconds Okay! i'm here this time! yes was on a 3-week vacation during the last one, forgot all about it anyone logging? You've been missed Donnie. Glad you made it. i will be proxying for fabian nothing interesting was happening anyways =) dberkholz: More fireworks expected for this one, yes. EAPI 5. [21:01] betelgeuse, scarabeus, williamh? scarabeus was here earlier. [21:03] i am here here does someone have the phone number of williamh? 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] cool, thanks ulm maybe we should find someone to be a secretary so you don't have to do that? [21:06] dberkholz: shouldn't be a problem today I hope so, at least ;) should we proceed? [21:07] yes EAPI 5 features [21:08] list is here: http://article.gmane.org/gmane.linux.gentoo.project/2140 [21:09] before we get into the details.. dberkholz: yes? 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. in the interests of actually getting this out there dberkholz: o.k., but let's see how it goes [21:10] just speaking from past experience with some other EAPIs that have dragged on for more than a year =) [21:11] I suggest that we vote about the features in the first group en-bloc, and do the rest one by one except if someone wants to single out additional things from the first group in fact, I'd like to vote on "econf --disable-silent-rules" and "doheader" separately ;) [21:12] ulm what defines "the first block"? [21:13] I like the --disable-silent-rules for EAPI 5. Just not retroactively. That is moving the goal posts and invites arbitrary breakage on remerge. blueness: http://www.blesk.cz/clanek/zpravy-udalosti/181196/to-je-ale-zradlo-poslanec-radl-ods-ji-rizek-primo-z-lavice-ve-snemovne.html Chainsaw: yeah eapi5+ blueness: see list of eapi 5 features, link in agenda ulm: What that list is *sorely* missing is... plain text summaries of the feature. ulm: I have unified diffs of LaTex (do you expect me to render that in my head?) or long bug reports. [21:14] ulm: Not ideal. okay: i'd like to vote for user-patches and licence groups separately (or that's in the second group i guess) [21:15] Also for future reference is the motivation for features listed somewhere yet? [21:16] Betelgeuse: Vaguely implied in the bug if you're lucky. that should probably go into the devmanual [21:17] sorry, I had lost connection 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 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 Okay. the first vote would be for inclusion of the 12 items listed in http://dev.gentoo.org/~ulm/council-20120911.txt blueness: user patches and license groups are in the second group [21:20] ulm: yes i see that, i can vote for all of part 1 as a block when we are ready for the vote anyone wants to discuss items (out of these 12) separately? [21:21] both spec and Portage implementation are ready for all of them please vote on inclusion of these 12 items in EAPI 5 [21:22] * ulm votes yes * blueness votes yes no objections [21:23] * Chainsaw approves and votes yes * scarabeus yep yes (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...) although can someone repeat what the sub slot stuff is for? I count 6 yes [21:24] Betelgeuse: most ingenious feature of all of them ;) will allow us to get rid of revdep-rebuild and preserved libs [21:25] 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.) Arfrever: good point Arfrever: It will. ulm is extremely organised. * Slot operator dependencies * Sub-slots * Profile IUSE injection [21:26] only took 3 hours to read through all the emails about it =) * At-most-one-of operator for REQUIRED_USE * EBUILD_PHASE_FUNC variable * Mandate GNU find * new* commands can read from standard input * Parsing of the EAPI assignment is mandatory * src_test support for parallel tests * Stable use forcing and masking * Option --host-root for {has,best}_version * usex helper function ^^ all accepted unanimously ulm: seems I missed part of the diff when reading it previously. It was clearer reading it again. [21:27] OK, next one is "doheader helper function" spec and implementation exist however, this was already proposed for EAPI 3 (then called doinclude) and the council had rejected it [21:28] link to previous council summary is here: http://www.gentoo.org/proj/en/council/meeting-logs/20090423-summary.txt Good name, seems clear what it's for. I see no reason not to have it. [21:29] 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] Chainsaw: it certainly won't harm :) the former argument against it was that to many do* functions would confuse new devs ulm: May have been the inclusion of doexample in the same item that did it in? Chainsaw: that's possible [21:31] anyway please vote on inclusion of doheader in EAPI 5 * Chainsaw votes Yes * ulm votes yes Betelgeuse? * scarabeus ++ [21:32] Betelgeuse, blueness? grobian had some issues with block 2 [21:33] blueness: your vote about "doheader"? oh doheader: yes yes With dberkholz having stepped out, I think that's as many votes as we are going to get. [21:34] 5 yes 0 no accepted but should note that a common use case in the tree is to install headers to a subdirectory so the usage will probably be marginal Betelgeuse: yeah same as for dolib ulm sorry an emergency just came up, i have to go help my wife can i give you grobians' wishes? blueness: yes, please [21:35] i'm so sorry her car broke down this is for part 2 -> http://dpaste.com/799573/ blueness: Family always comes first. please do not count this against him, it was a pure emergency thank you gentlemen blueness: so, all no for part 2 from grobian [21:36] thats straight :D and for part 3, in fact OK, next one econf --disable-silent-rules Okay for EAPI 5. *Nothing* gets applied retroactively. *EVER* I suggest that we vote for this one in EAPI 5 first ^^what Chainsaw said [21:37] then discuss the retroactive stuff * Chainsaw votes Yes for --disable-silent-rules in EAPI 5 please vote for "econf --disable-silent-rules" in EAPI 5 yes * ulm votes yes 4 yes and that's all votes we get, I fear [21:38] Sounds unanimous then. yes, accepted for EAPI 5 (quite redux from 7 to 4 :-/) [21:39] scarabeus: Four is more exciting. With an even number of votes you can deadlock. do we want to apply this retroactively to EAPI 4? ulm: NO. no * ulm abstains scarabeus? [21:40] scarabeus? what i said above so no Excellent. Reason prevails. Next? rejected for EAPI 4 we don't have to vote for EAPIs 0 to 3 then [21:41] yea next: "user patches" ulm: You could, but I'm just going to say no louder and more often. no working implementation in Portage so far Controversy as well. Push to EAPI 6. [21:42] and IMHO the spec is incomplete too It's simply not ready, agreed. 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. :( WilliamH: welcome WilliamH: Please e-mail a phone number to the council list if at all possible. [21:43] some of the controversial stuff still left Chainsaw: no problem. 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 Betelgeuse? later *** NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has joined channel #gentoo-council Hey Ned. [21:45] Betelgeuse: that is, no for 5 and include it in later EAPI? ulm: yes ulm: That's how I read it, yeah. rejected for EAPI 5 hi Chainsaw next: "License groups in ebuilds" [21:46] see my alternative proposal i like the alternative that works everywhere * Chainsaw votes No on license groups and Yes on the ulm approach of GPL2+ so no for the point * ulm votes no ulm: should we ask if there is any item that gets support from someone on the list for EAPI 5? From the blueness list of grobian opinions, that is a "no". [21:47] Betelgeuse: yeah, that could speed up things I see nothing remaining that I would vote in. I would say gather it up, polish it for EAPI6 until it shines, and resubmit. [21:48] no support from me for any of the remaining ones 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 scarabeus: Needs a rationale, a summary, etc. [21:49] I don't have an issue with ejobs either. agreed with Chainsaw, ulm scarabeus: You okay to have that in EAPI6, or do you need it now? Chainsaw: it is not needed now, but it should not be forgotten scarabeus: Oh sure, but there are more like that. [21:50] 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... I guess proponents won't forget if they do, it wasn't important ;) [21:51] heh Quite :) In case of 423245, I suggest separate voting on each subfeature. 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... Should that wait until open floor? [21:52] WilliamH: You can ask us now, if you think it will change anything? Also there's time until tagging to change minds I don't know if it will, but I'll throw them out there... about "parsing of the eapi being mandatory..." Betelgeuse: right [21:53] Did the community ever actually come to a concensus on that? WilliamH: Portage already does it since a few weeks WilliamH: there will never be a concensus and that was the original plan ulm: Oh ok, I'm fine with it then. For "stable use forcing and masking." Does the current proposal for [21:54] ulm: I think we are done with items to vote on? ulm: I will need to head our for lunch soon combining e.g. package.use.* and use.* affect anything? I don't have a link but that possibility was discussed on -dev. [21:55] WilliamH: that's not on the list so far and I guess that it will need further discussion ulm: ok [21:56] off thanks people ttyl Betelgeuse about the "doheader" functions... Shouldn't we also have newheader if we have doheader? WilliamH: we do WilliamH: That is listed in the bug. WilliamH: So yes, that will be included :) Oh ok, I didn't see it in the bug. 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] 2 sentences per item is all that's needed. You shouldn't have to go digging like this. Chainsaw: will do, but give me a few days Ok, that's all I had. :-) OK next topic then Open bugs with council involvement ulm: Sure, I don't mean "right this minute". I mean "in future". I see only bug 383467 Not the vote counts still? [21:58] Let me address the elephant in the room. Chainsaw: what? ulm: You seemed to be not against e.g. *.svg. Each filename extension needs separate voting. Can anyone who isn't jmbsvicetto action this? *** spiros (~andyspiro@gentoo/developer/spiros) has left channel #gentoo-council: "Konversation terminated!" Arfrever: we're done with topic 2 [21:59] and no council member has spoken up for dohtml extensions Arfrever: that thing is overly complex and even if ulm acked it it get enough nacks overall ulm: But council failed to properly discuss remaining features. Arfrever: Council said "no to all" to the block that included dohtml. so who is member of elections team, could someone of them fix the bug? Arfrever: Try in EAPI6. [22:00] who volunteers to ping jmbsvicetto about #383467? [22:01] ulm: technically he is staying at my place on the gentoo miniconf, so i can try to beat him to it :P but it will be done on the meeting after next one :P scarabeus: Lock him in a room until it's done? Chainsaw: naah, i will tell him the wifi pw only if he agrees to do it right away [22:02] advanced chinese torture so, we're 10 minutes behind schedule only :) [22:03] I suggest to vote on DEPENDENCIES in EAPI="5", which was not voted on by council yet. Arfrever: Council said "no to all" to the block that included DEPENDENCIES reform. Arfrever: Try in EAPI6. Arfrever: it wasn't even on the list Chainsaw: That block did not include DEPENDENCIES. Arfrever: I am not going to vote "No" all over again just to please you. It was denied. Try in EAPI 6. [22:04] do you all agree so far with the summary in http://dev.gentoo.org/~ulm/council-20120911.txt ? before we go to open floor ulm: Summary approved with no comments. [22:05] looks good ulm: Some descriptions are truncated. of course, I'll scan the log for additional comments that should be included [22:06] ulm: ++ Arfrever: only one of them, actually ulm: 2 should be corrected now * WilliamH agrees with the summary Arfrever: right, two [22:07] I'll complete them for the final summary [22:08] next topic Open floor * Chainsaw switches on the microphone ulm: Add {,package.}use.stable.{force,mask} in descriptions of 2 items. Arfrever: yes ;) [22:09] anything for open floor? I suggest that council change schedule of meetings so that meeting is in each week. [22:10] I think that grossly overestimates the availability of council members. [22:11] Yeah I don't think weekly meetings would work well for the same reason. given that there hasn't exactly been a glut of topics, i don't see the demand we would never join together so often and the councils in past that did it didnt have much fun doing it either [22:12] we can do an extra meeting between regular ones if there's need although there wasn't any need during this term, so far Right, there is nothing that stops us from having extra meetings if we need them. [22:13] anything else for open floor? seems not [22:14] I would like that each council member write rationale for his voting on each rejected feature. What is the word limit on this essay? ulm: https://bugs.gentoo.org/383467 "Council webpage lacks results for 2010 and 2011 elections"; Website www.gentoo.org, Projects; CONF; hwoarang:jmbsvicetto ulm: what a fast bot :D [22:15] yeah :) Because it seems that they failed to understand some features before voting. Arfrever: Then I would suggest that you do not vote for this council again next term. Chainsaw: +1 Chainsaw: Several sentences of rationale per feature would suffice. Chainsaw: he is not developer :-) though he isn't allowed to vote ;) [22:16] I wonder why. I think it's time to close this meeting Yes, that would be good. thank you all for participating bye [22:17] Thanks for hosting ulm. See you later. [21:36:50] Okay for EAPI 5. *Nothing* gets applied retroactively. *EVER* << not totally correct, old-style virtuals were removed retroactively from old EAPIs My appologies for being late. chithead: During my tenure? no chithead: Precisely. chithead: Also retroactive changes are allowed in my EAPIs :) . next meeting will be October 9th [22:18] ulm: I'll be there. * WilliamH will be there