19 UTC bash-42 looks like your patchset policy thing didn't make it into the agenda yet let's start roll call * scarabeus aroundy agenda is here: http://article.gmane.org/gmane.linux.gentoo.project/2381 here Chainsaw: still here? :) [21:01] ulm: Yes :) Betelgeuse, WilliamH? [21:02] can someone phone/text them? and not always me, I've done this for the last four meetings [21:06] sorry [21:07] did anyone already take action? [21:08] Do you need me to call Petteri? I don't have William's number jmbsvicetto: yes, please I'll text WilliamH then [21:09] hmm, I got some automated reply as soon as I called Petteri and as you can imagine, finish == chinese to me :P * WilliamH is here [21:10] welcome :) I was just working on an email I'm about to send out, sorry folks. 10 minutes passed, so let's move on [21:11] ook Change to newer Bash version in ebuilds see references in the agenda what exactly do you want to do on the subject? [21:12] vote? too early to vote, I think [21:13] Last time this came up, it was a problem for prefix. nothing to vote there it can be nominated for the eapi and voted then ok, well, I think EAPI6 could have bash-4.2, but that we need to have a portage that reads EAPI line (as opposed to sourcing the ebuild) for at least a year stable Because they had older bash versions on their "main" OS. the main problem is with the upgrade path [21:14] that sums up basically what you wrote in the email thread, ulm i'd defer to grobian on that one. Chainsaw: can't imagine that was prefix there's two dates, EAPI parsing was in stable portage in June 2012 Chainsaw: only can be a problem if we go for deprecation of EAPI0 and stuff and bash 4.2 went stable in March 2012 already i would suggest we put a bash update into its own EAPI, or if there's anything else ready to go then we add that, so we can have it stabilized on or shortly after july 1 (1 yr since stable EAPI=5) [21:15] grobian: The OS X one, from what I remember. grobian: eapi 0 is too big, everything in between can start to die we'll come to eapi deprecation later Chainsaw: yeah, that's a bootstrapping problem e.g. on solaris [21:16] let's stay with bash version scarabeus: agreeed scarabeus: I didn't want to jump ahead to the next agenda item don't want to delay this another 6 months or longer in convoluted EAPI discussions grobian: Would it still be a problem, or can it be managed? grobian: That's really the only argument against that I remember from last round. well, I don't think it's much of a problem, as we manually compile bash prior to the bootstrap [21:17] unless I forgot something myself dberkholz: I'd rather go for longer time than one year here not shorter who said shorter? i would suggest we put a bash update into its own EAPI [21:18] or was the intention to delay bash update until after EAPI 6? i'm assuming you also read that to the end, where i said 1 year since stable EAPI=5 when was eapi=5 stable? [21:19] not shorter than 1 year WilliamH: July 2012 sorry, that was EAPI parsing ok so we are almost at a year then. ulm: ok... [21:20] WilliamH: 2012-12-11 for EAPI 5 ulm: ok [21:21] bah, what i meant was 1 yr since EAPI parsing. so, we see how preparation for EAPI 6 goes, and then come back to bash version depending how long it takes? [21:22] Why not put the bash update in eapi 6? hmmm, you want to apply it outside of eapi? personally i'd prefer the other way around grobian: not outside of EAPI I'd go for EAPI6 EAPI 6 makes perfect sense put it on the list and we could always fall back to mgorny's suggestion, namely forbid bash 4.2 features in global scope for some transition time [21:23] if it delays, we can always scratch it delays till when? let's do something real here because next month we want to approve EAPI6 not really likely of course so, seems like it should be just an EAPI6 item [21:24] grobian: +1 nothing transition or something, because portage will barf more errors if you don't have EAPI-parsing ok, no action for the time being [21:25] move on? yes please oops, I forgot one point [21:26] additional agenda point for patch policy should we add it to today's agenda? I'm against didn't prepare [21:27] grobian: +1 doesn't look so urgent to me, and the agenda is already packed did we discuss eapi deprecation yet? i do have an opinion on the policy, but don't mind delaying for others * scarabeus can talk about it, but basically i can recommend looking on fedora/suse patching, more restrictive the better so, just vote: agenda item to be added? [21:28] * ulm votes no no * WilliamH votes no * scarabeus indiferent ok, 3 times no and one indifferent means that it's not approved [21:29] next point, EAPI deprecation we can come back to patch policy next month [21:30] ok, where do you want to start :) I'm a bit worried that we have 6 different EAPIs in active use we should look on the qa-reports page where is the eapi listing and hard-deprecate those with low numbers soon it will be 7 [21:31] Me too. 0 is out of question for now but others should be phased out http://qa-reports.gentoo.org/output/eapi_usage.txt scarabeus: it makes no sense to start with anything but 0 why? [21:32] because largest difference in features is from newest EAPI to EAPI 0 We could have repoman start complaining if you try to commit something with an old eapi setting. frankly, I've built a toolchain, and I don't want to mess with it e.g. src_prepare and src_configure imo, it's legacy that we need to accept [21:33] moving away from it as much as possible I like deprecation, four years, or four sensical EAPIs I'd suggest that we start differently: there's still the myth that EAPI 0 needs to be kept for system packages for upgrade path grobian: the thing is that some people won't move ebuilds away from it if we don't start at least complaining about it. WilliamH: yeah, but I'm not against that [21:34] i'd just start with a repoman warning on anything but latest stable so the first step would be that we make a statement like "EAPI 0 and 1 are not required for upgrade path, you can move everything to 2." encourage people to move by bugging them or 3 even ulm: i would go for 3 ulm: yeah, probably could say that actually we are bugging them [21:35] * WilliamH agrees with dberkholz the rule is use new eapi no? but they happily ignore it We always encourage the latest eapi so we should start complaining when people aren't using it. scarabeus: if the new eapi doesn't add anything? grobian: Then the EAPI bump should be uneventful. [21:36] grobian: then just bump the eapi= setting and be done with it. grobian: That argument works both ways :) grobian: that is moot now, as eapi5 has the subslots which should be used almost everywhere no no I think a case can be made for EAPI 1 to 4 to emit a EAPI.discouraged warning. you can't just bump eapi without looking IT should not be fatal. s/IT/It/ Chainsaw: why no for 0? [21:37] EAPI 0 is a toolchain requirement. *not grobian: no, but it is up to you to test before you commit. :p in case anyone else wants to see EAPI use visually ... http://www.chartgo.com/create.do?chart=bar&dimension=2d&width=500&height=400&orientation=vertical&title=EAPI+usage&subtitle=&xtitle=EAPI&ytitle=Ebuilds&source=&fonttypetitle=bold&fonttypelabel=normal&labelorientation=horizontal&chrtbkgndcolor=gradientblue&max_yaxis=&transparency=1&labels=1&min_yaxis=&roundedge=1&shadow=1&border=1&xaxis1=0%0D%0A1%0D%0A2%0D%0A3%0D%0A4%0D%0A5&yaxis The Y data field is empty. Y data cannot be empty. or http://monk.ly/10PKS76 Chainsaw: ? [21:38] the discussion always revolves around who is doing the work and why dberkholz: heh, can you plot this against time? ;) I still don't see problems, other than maintenance and cosmetics sure i could. obviously everything is easier in git but can always update my conversion yet people suggest maintainers should forcefully upgrade their packages we can't make them do thay and it makes little to no sense to me either [21:39] hence, deprecating eapis, warning about 1,2,3 seems ok to me dberkholz: Based on your graph, EAPI 1 to 3 is the soft spot that's easy to hit. 4 seems rather new grobian: why not? it would just be part of a revbump or version bump. WilliamH: hehe, src_unpack is not supposed to have epatch in it in EAPI 1+ it makes no sense to warn about EAPI 3 EAPI 3 still is needed for the upgrade path [21:40] grobian: right, but you fix that as part of the eapi migration. ulm: why is that? WilliamH: yeah, which is a lot of work, which is not giving ANY benefit especially when using PATCHES array becomes mandatory for some EAPI because someone thinks that's "cleaner" and it changes NOTHING from the user's point of view [21:41] so why waste scarce developer time? grobian: eapis are not relevant to the user anyway. what problem are we solving? yes ulm: In the interest of building consensus... [21:42] guys, it looks like this discussion is going nowhere ulm: EAPI.discouraged for 1 & 2. grobian: moving away from legacy eapis that we do not need. like was pointed out, we have 6 now, soon to be 7. I'm all for encouraging people (including myself) to get fluent with latest EAPIs ulm: To at least make progress and reduce the total count. grobian: but if repoman doesn't complain people will not do it. ulm: I'd rather make weak progress than a strong stand-still. WilliamH: yeah, and I believe the solution is more in folding, like 2 can be removed, as 3 is a drop-in replacement [21:43] and perhaps we can do 4-5 at some point and deprecate 1 as a whole I'd start with a statement "EAPIs 0 to 2 are no longer required for upgrade path" ^^^^ agreed ulm: which upgrade path are you referring to? [21:44] we only support 1 year back, as i recall dberkholz: upgrade path for outdated users' systems dberkholz: minimum of 1 year ulm: but we only support one year back. with longer support to be discussed, but that discussion never took place [21:45] therefore it does not exist * ulm has looked it up in the old meetings' summaries * WilliamH agrees with dberkholz Anyhow. EAPI 0 is a toolchain requirement. 1 & 2 seem a valid "EAPI.discouraged" target. 3 and above remain untouched for now. [21:46] Can we vote on that? How is eapi0 a requirement? WilliamH: Because toolchain has reported that they need it. Chainsaw: I'd rather grant an exception for toolchain packages it's a requirement until someone talks the toolchain team into updating its eclass or does it for them WilliamH: The matter did not seem negotiable. dberkholz: what would it take to do that? [21:47] ulm: I'd prefer a simpler rule and simpler code in repoman. lots of beer? well, I'm not sure we'd want someone to replace it for them we'd need lots of years to confirm that the new stuff is stable/correct ok, let's do two votes [21:48] wrt repoman, first vote: "EAPIs 0 to 2 are no longer required for the upgrade path of old systems" I wasn't saying it should be a fatal error in there, just a warning. * WilliamH votes yes and second vote "EAPIs 1 and 2 are discouraged, repoman check to be added" first vote, please [21:49] can you define old please ulm: first vote: yes i think that's important to our discussion/vote ulm second vote: yes dberkholz: strike the word "old" if you defined it at our current support window of 1 year, EAPI=3 would also be true dberkholz: in principle, yes [21:50] but I see no reason to deliberately kill off old systems * WilliamH votes that eapi 3 should also be added ulm: Sadly, yes. EAPI0, EAPI1 & EAPI2 are unusable due to python. (First vote) * ulm votes yes on first vote [21:51] Are we adding eapi 3 to the statement for the first vote? WilliamH: let's decide on that afterwards [21:52] otherwise it gets too confusing ok dberkholz: scarabeus: WilliamH: your first vote please http://article.gmane.org/gmane.linux.gentoo.project/2381/me votes yes Chainsaw: Other system packages use higher EAPI than is used in Python. * WilliamH votes yes [21:53] sorry about the paste. ok sound sane, yes dberkholz? yes on both. also, my head hurts from banging it into the table. [21:54] unanimous then second vote I already have a yes from grobian and dberkholz * ulm votes yes [21:55] * WilliamH votes yes vote is: "EAPIs 1 and 2 are discouraged, repoman check to be added" yes [21:56] i would like to propose the same for for EAPI 3. Chainsaw: I guess it's yes from you too? since you suggested it? [21:57] anyway, it's 5 yes votes out of 6, so it's accepted [21:58] so WilliamH's suggestion, third vote: "EAPIs 0 to 3 are no longer required for the upgrade path of systems" i.e. "0 to 3" instead of "0 to 2" ulm third vote: no [21:59] * ulm votes no 3 is too new i think scarabeus: this is a "no"? scarabeus: ok no problem there... *** mpagano (~mpagano@gentoo/developer/mpagano) has quit: Read error: Connection reset by peer what about adding the discouraged warning to eapi 3? too new? it's 3 years old [22:00] ulm: Yes. ulm: My apologies for the delayed response. Chainsaw: that's for the second vote? on the vote, yes ulm: That is for the second vote: "EAPIs 1 and 2 are discouraged, repoman check to be added" second vote unanomously accepted then [22:01] *unanimously EAPI 4 is 2 years old. that's still double our existing support window dberkholz: you are maybe right, even from the graphs t is second least used eapi... dberkholz: it doesn't hurt to be a little conservative there [22:02] a "discouragement" and repoman warning is pretty conservative * WilliamH agrees with dberkholz I understand that code has to be kept around, but we should encourage forward movement otherwise it doesn't happen. [22:03] Chainsaw: scarabeus: WilliamH: your vote on 3, please vote: extend to eapi 3 [22:04] scarabeus: that's a "yes"? thats a yes [22:05] ok :) * WilliamH votes yes and extend to eapi 4... given what dberkholz just said about the age of eapi 4 WilliamH: that would mean that everyone must move to 5 [22:06] That's a no. EAPI3 can be upgraded to a current system. I count 3 yes and 3 no votes awesome1 ! * WilliamH is ok with extending to eapi 3. that's a tie, so it doesn't pass * WilliamH votes yes [22:07] guess we'll have to get Betelgeuse's input later. can we wrap this up, please? we can come back to it in a few months, deprecating 1 2 is already a start Agreed, make a start with a simple unambiguous proposal. [22:08] And build on that later. grobian: will be in the summary and you can comment on it ;) move on? move on yes [22:09] i'm getting short on laptop battery Open bugs with council involvement bug 457000 https://bugs.gentoo.org/457000 "Missing log and summary for 20090122 and 20090625 council meetings"; Doc Other, Project-specific documentation; IN_P; ulm:council betelgeuse had volunteered to look into writing the missing summary for 20090122, but he isn't here [22:10] so I think we should skip this bug ok bug 464250 [22:11] https://bugs.gentoo.org/464250 "Encourage developers to use the latest EAPI"; Doc Other, Devmanual; CONF; ulm:devmanual that was decided in 2011 and yet we seem to have just voted against that huh? assuming encouragement also includes things like discouraging other options not yet implemented in the devamnual dberkholz: encourage != repoman forcing it [22:12] who is responsible for devmanual these days? i am wildly confused how a warning is a forcing ulm: no one said anything about repoman forcing it. grobian: hwoarang is taking care of it grobian: i think markos prod him? well, someone should prepare a patch [22:13] any volunteers? should be easy, just insert these two sentences are they in the bug? [22:14] grobian: yes :) ulm: how is a repoman warning forcing an issue? I'll give it a try then grobian: thanks [22:15] and I'd like to wrap up grobian: ok I have to go ulm: open floor? jmbsvicetto: status update form Zero_Chaos ok [22:16] i'm totally blocking on that just a note new nvidia drivers are released with the support few hours back so i'll give Zero_Chaos a whip to flog me with I am here as well. short version of the update, blocked on dberkholz, he is going to become magically responsive :-) [22:17] and/or I'll involved QA and revisit next month we discussed bug 447566 last month, and there should be status update in the nect meeting *next i just got your 2nd email, totally forgot about the first. ulm: https://bugs.gentoo.org/447566 "x11-drivers/nvidia-drivers-{173.14.36,304.64,310.19,313.18} fails to build with kernel {3.7,3.8}"; Gentoo Linux, Applications; VERI, WONT; vaeth:jer as of yet, the bug is still an issue. ping me like you're playing pinball at least 6 duplicates tagged since last Zero_Chaos: so, go ahead please, but make it short actually best would be to block the darn kernels? (eg state in ebuild what kernels are supported?) [22:18] other than that I know people are short on time, I wanted to give an update that's it. "Still an issue, not being dropped, I am pushing this till there is a resolution" you may all move on or engage me after the meeting close. btw iirc nvidia ignores bugs where the kernel patches are applied (if you are lucky enough and they even care) About the fork, I just want to remind that there are more packages going into (already went into) the tree. So if the issue of having multiple ebuilds to provide the same package interests you (council), you should start paying close attention to this topic we're already over time, so I suggest that we move any discussion on this to e-mail [22:19] considering how long and how heated the discussion was last month I will be here after meeting closes if people want to discuss. I'm defering till after the official meeting for anything more than the status I already provided. thanks, please move on. [22:20] k open floor was the dodocs/edocs/... voted? Zero_Chaos: sorry about the delay, been kinda swamped in gsoc stuff w/ deadlines etc. keep pinging and i will make something happen ssuominen: nope why is that? time ran out? [22:21] Zero_Chaos: be the squeaky wheel oh, btw. now that it's open floor, if you haven't heard, we are in the google summer of code again for our 8th straight year ssuominen: hm, there was no voting on any eapi 6 features yet [22:22] About the "warning" or repoman checks, I think reality has proven that developers won't change EAPI because of that i'm admin with the help of calchan, antarus, g2boojum. so let one/all of us know if you want to help oh... I thought that was supposed to happen in next meeting... I guess not then. my bad either people have time and will to change the EAPI of package or they don't - warnings aren't likely to increase the conversion rate - imho [22:23] you'd be amazed how OCD people are. especially gentoo users. Must... fix... repoman... warning. dberkholz: users might annoy a developer about it, but I think most developers aren't likely to react to that - or at least to react in a "positive manner" [22:24] why would users be running repoman? [22:25] dberkholz: For ebuild submissions? I tell them that's how I'd grade their work. i'm talking about the developer as a gentoo user, of whom many tend to be very picky about having things absolutely perfect anyway i'm at 3% battery so i need to power down [22:26] jmbsvicetto: For new repoman warnings my initial response tends to be "son of a..." followed by an immediate fix. I can't stand committing builds that warn. It's sloppy. dberkholz: Talk later. somehow managed to discharge rather than charge last night for my day at a conference dberkholz: even though we might like perfect, many of us are getting too little free time to deal with EAPI bumps dberkholz: or we rather prefer to spend our time on other issues [22:27] jmbsvicetto: But you have a life now. It's different :) jmbsvicetto: it's a time scale of several years, so eapi bumps don't have to happen very often [22:29] if version bumps are always to the newest eapi, then it's very little additional work because the old ebuilds just go away [22:30] ulm: sure, but I think in reality most bumps are only done when their benefit outweights their cost ulm: so a developer needs an incentive on the newer EAPI (required feature, ease of use, etc), before considering bumping the EAPI when doing a simple package bump let's see if EAPI 5 will change that [22:31] with killer feature of subslots [22:32] btw, about the "subslot" argument, I think that is starting to backfire We're getting too many packages using that in the wrong way and causing everyone to do tons of unnecessary rebuilds jmbsvicetto: it is not backfiring, it is problem of people not reading how it works :/ and what should we do there, we expect the devs to study how it works, it is described quite well [22:33] deja vu. happens everytime new feature comes along, people overuse them jmbsvicetto: I sure that people will learn how to use it correctly scarabeus: it's one of the best documented features we have at least in devmanual, portage man pages, eapi cheat sheet [22:34] Oh and as someone that looks at a few logs of stage building, lately we seem to be going in the wrong direction - the amount of failures, blocks and scary output in portage has increased exponentially!! and quite extensive in each just dropped libpng16 to ~arch, we'll see how subslotting helps ;) folks, we're 35 minutes over time [22:35] We've already run one laptop down, yes. anything very important for the open floor? otherwise, I'd like to close the meeting I'm ready to move on, yes. * Chainsaw plans to turn the laptop off and just read a (paper!) book [22:36] next meeting 14 May, 19:00 UTC betelgeuse will be your chair meeting is closed, thanks everybody Thanks ulm. * Chainsaw waves [22:37] *** ulm (~ulm@gentoo/developer/ulm) has set the topic for #gentoo-council: "next meeting 2013-05-14 | http://www.gentoo.org/proj/en/council/utctolocal.html?time=1900 | http://www.gentoo.org/proj/en/council/"