21:00:03 O.K., let's start 21:00:05 --- ulm sets mode +m #gentoo-council 21:00:13 * lu_zero murmurs things about xen-fullvirt and clock drifts 21:00:22 --- ulm gives voice to DrEeevil 21:00:32 who's logging? 21:00:42 I do as usual 21:00:44 Many probably are, me included 21:00:59 roll call 21:01:03 here 21:01:05 \o/ 21:01:06 * lu_zero here 21:01:12 * dertobi123 yawns 21:01:18 here, representing solar 21:01:43 Im here 21:02:26 we have too many topics for 60 minutes, so is it o.k. if we extend to 90 min today? 21:02:33 yes 21:02:39 or has anybody to leave sooner? 21:02:39 yes 21:02:43 ulm fine 21:02:48 err, 90 minutes is OK 21:02:54 ok 21:02:56 would be nice if we can make it within 60 minutes 21:03:27 dertobi123: "would be nice"? is this a veto? 21:03:44 dertobi123: unlikely 21:03:48 not a veto, just a "would be nice" 21:03:52 k 21:04:02 ulm I think the idea is to have the extension last the required time 21:04:06 but do try to be active so if we vote ulm doesn't have to wait etc 21:04:07 (less than 30 min) 21:04:09 90 minutes is KO here 21:04:11 OK 21:04:40 I see no objections then 21:04:56 2. Approve summary of October meeting 21:05:07 no summary ready, afaik 21:05:17 so we can skip this topic 21:05:25 anyone want to pickup from tanderson ? 21:05:32 I started work on it, but can't have it ready before tomorrow evening 21:05:50 I can do both previous and this meeting 21:05:54 leio: ok good 21:05:58 thank you =) 21:05:59 leio, thanks 21:06:26 leio: thanks 21:06:26 --- lu_zero gives voice to zmedico 21:06:59 lu_zero: right, let's move to 3. Follow-ups from previous meeting 21:07:14 zmedico: any update on EAPI 3 status? 21:08:39 anyone else? 21:08:49 zmedico maybe didn't expect us to be this fast 21:09:21 there's quite some progress in tracker bug 273620 compared to one month ago 21:10:09 8/20 missing 21:10:16 yeah 21:10:52 the items done are simple and quick 21:11:30 most of the missing ones do not appear this bad as well 21:11:34 right, but obviously there's progress 21:12:11 should we move on? 21:12:30 I think so 21:12:32 Upgrade paths 21:12:34 ulm, yes let's move and maybe get back to this if zac shows up 21:12:41 Calchan: k 21:12:41 I agree 21:13:18 leio: "Upgrade path for old systems" 21:13:23 I personally do not think in-tree versions of python certainly need to be EAPI-0 (but have to be EAPI-1), as presumably the system that is getting updated already has a python installed, so just a version of portage that supports newer EAPI (and its direct and indirect dependencies) need to work with EAPI-0, this includes depending on only a python version that used to be EAPI-0 and available for a long time. The main question in my mind 21:13:23 is deciding how far back we want to support things _now_, and go from there to always support back to that point. Some ideas include making periodic portage tree snapshots and whitelisting necessary system packages for distfiles mirrors, so that it is always possible to upgrade step by step through these snapshots. I will follow-up on gentoo-dev for wider discussion with good initial discussion starting write-up soon 21:14:18 how much ago from today we want to support also related to the bash-3.2 question later in the agenda 21:14:29 relates* 21:14:31 I think the underlying question in all of this is how long we want to maintain upgrade paths, once we know that it's easy to see what was stable this long ago and if anything was broken then we fix it 21:14:53 I would keep main tree in shape for one year. 21:15:06 Then if we can provide snapshots and a guide that would be great. 21:15:17 I'd definitely agree with that 21:15:19 Betelgeuse how many back snapshot/years ? 21:15:20 Would mainly mean someone periodically tries to updgrade form an old snapshot. 21:15:28 as long as it is "simple" like keeping around only one version of all system packages (or all deps of portage) it has a low enough cost 21:15:39 lu_zero: I would say two years. 21:15:49 I have seen many times people trying to update around a year marker 21:15:56 but beyond two years seems two much work 21:16:04 s/two/too/ 21:16:22 we can archive snapshots every - say - three months and it's system packages distfiles 21:16:23 I don't think the cost in keeping support for upgrading from older system is big after we start doing it - users can go step by step, upgrade package manager to 2009 upgrade path snapshot helper, then to 2010, then to 2011, etc 21:16:36 if we just have them incremental (snap0 -> snap1 -> ... -> current stable) 21:16:38 If we have a good schedule for testing upgrades it should be quite simple. 21:16:50 won't take more work but just space 21:16:52 only cost there would be distfiles and snapshot mirroring space 21:16:55 I think someone just needs to take responsibility and start a project for this. 21:17:10 i wouldn't say "we do this for 2 years" - as long as that's working it might be a benefit for people upgrading from much older boxes 21:17:57 dertobi123, as long as the snapshots are being done it's just a matter of disk space on our servers to keep them around 21:18:06 Calchan: exactly, yes 21:18:08 so we agree that we'll keep as many snapshot as possible within our infra/mirror limit or 2 years? 21:18:18 and that is negligible - system is ~100MB per snapshot 21:18:34 so there's no point limiting the storage to 2 years 21:18:58 I'll get a gentoo-dev discussion going in the coming days, summarizing all the current thoughts and ideas 21:19:06 ok 21:19:11 * dertobi123 nods 21:19:12 leio: sounds good 21:19:27 leio: Could you start a project page too while at it? 21:19:34 lu_zero, let's say we require 2 years of snapshots and that beyond that it's infra's decision to keep what's older 21:19:52 Calchan sounds good 21:20:03 * Calchan smells good too 21:20:57 Betelgeuse: maybe after discussion? 21:21:02 leio: sure 21:21:08 leio: just making sure someone follows up 21:21:13 leio: and it's not just discussion and then nothing 21:21:15 Ok, but I'm not confident I can be involved with that project in the longer term 21:21:19 isn't there a 3 year retention requirement with the GPL ? we could sync with that too 21:21:36 that requirement applies to for-profits I think 21:21:44 leio: sure but if you can't find someone just bring it up that we need someone 21:21:45 err, for non-community-distribution 21:21:50 Betelgeuse: nod 21:23:02 anything else for this topic? 21:23:22 we could move 21:23:32 4. Prefix support in main Portage tree 21:23:38 hold on, what's the plan? 21:23:41 Calchan: actually good point, I think the alternative provided by 3c in GPL-2 only covers object code noncommercial distos 21:23:49 distros* 21:24:02 leio starts a discussion on -dev and we vote on the outcome of that next time? 21:24:21 ulm: I think we should vote on the one year tree requirement 21:24:42 to make it explicit 21:24:58 Betelgeuse, would that imply reverting any breakage that wouldn't satisfy the one year tree requirement? 21:25:11 Calchan: yes 21:25:12 --> mpagano (n=mpagano@gentoo/developer/mpagano) has joined #gentoo-council 21:25:19 Betelgeuse, ok, thanks for the clarification 21:25:40 ulm, so do we vote? 21:25:42 I would leave how to handle older than that to the leio started discussion and the resulting proejct 21:25:44 Betelgeuse: can you word the question we should vote on? 21:25:45 I'd find it more reasonable to vote on this next time then 21:26:11 ulm: Ebuild tree should provide upgrade path to a system that hasn't been updated in a year. 21:26:29 Betelgeuse: leio has a point, there was no vote foreseen on the agenda 21:26:50 ulm: You can ask if people are not ready to vote 21:26:54 ulm, so what? let's not find lame excuses for not making progress 21:27:03 ulm: They can just say not ready 21:27:09 ulm: Then we just don't get a majority 21:27:19 ok, let's give it a try then ;) 21:27:20 the proposed wording sounds good to me for a todays vote too. I'd like some "at least" wording though 21:27:24 ulm, great 21:27:45 leio, good point 21:27:50 * dertobi123 agrees with leio 21:28:01 and s/should/must 21:28:23 "Ebuild tree must provide upgrade path for at least one year." 21:28:26 so does everybody with the wording: "Ebuild tree must provide upgrade path to a system that hasn't been updated in at least one year" 21:28:41 or that 21:28:47 since the time of the newer snapshot? 21:29:12 and maybe s/system/stable system/ 21:29:15 this is irregardless of snapshots. Snapshots would provide a way to upgrade from even older systems 21:29:16 since "an year" is a sliding definition 21:29:55 --> grobian (n=grobian@gentoo/developer/grobian) has joined #gentoo-council 21:29:58 lu_zero, sliding, but that means that I any time you don't need to resort to snapshots if you updated in the past year 21:30:02 "Ebuild tree must provide an upgrade path to a stable system that hasn't been updated for one year" would sound good to me 21:30:18 ^^ please vote on this 21:30:24 fine for me 21:30:28 yes from me 21:30:29 ok for me 21:30:30 yes 21:30:34 agreed, leio's wording is clear enough 21:30:38 and I vote yes 21:30:46 my "at least" proposal made it more confusing, sorry :) 21:30:48 I vote yes 21:31:06 DrEeevil? 21:31:30 yes 21:31:41 unanimous then 21:31:48 let's move on 21:31:50 I propose adding in the summary also this: "The council encourages trying to keep ebuild tree upgrade path support for older system than a year as well" 21:32:05 but not important, this will be discussed in the thread I bet. 21:32:16 leio, I would keep that for the thread 21:32:24 --- ulm gives voice to grobian 21:32:38 next topic "4. Prefix support in main Portage tree" 21:33:13 grobian: can you give an outline of the proposal? 21:33:43 ehm, well, it's pretty simple 21:34:03 we propose to simply make a preparation for full prefix support to portage 21:34:19 --> reavertm (n=reavertm@aegv10.neoplus.adsl.tpnet.pl) has joined #gentoo-council 21:34:26 that means that the variables EPREFIX, ED and EROOT will be initialised to the values '', D and ROOT 21:34:51 what are the implications for non-prefix devs? 21:34:52 this gives the advantage that we don't have to set ED and EROOT in every ebuild we require them 21:34:55 and users 21:35:23 --> Innocenti (n=Innocent@ramonvanalteren.xs4all.nl) has joined #gentoo-council 21:35:24 implications are outlined in my earlier mail to -dev 21:35:29 I'm worried about the implications of this being an EAPI feature in relation to the upgrade path concerns and usage of these variables in eclasses 21:36:01 leio: can you be more specific? 21:36:15 grobian, do you have a link in the archives? I can't seem to find it anymore 21:36:17 eclasses use $D, $ROOT and so on 21:36:33 leio: yes 21:36:45 grobian: does it mean we have to substitute all occurences ${D} -> ${ED} and ${ROOT} -> ${EROOT} in ebuilds and eclasses? 21:36:52 the eclasses and ebuilds involved in package manager deptree should remain lower EAPI (EAPI-0 right now) to support upgrading the package manager 21:37:07 ulm: unfortunately not all of them, that's why we need to make a distinction between the two 21:37:29 leio: yes, but we can set ED if ED is not set to D, making them compatible in EAPI0 21:37:36 (and up) 21:37:38 which means portage EAPI-2+prefix provided variables can't be relied upon (upgrade path stuff going to be discussed on gentoo-dev soon). Maybe the eclasses and ebuilds involved in there can define those themselves then 21:38:06 and for those eclasses and ebuilds that are allowed to upgrade EAPI requirements, it is a convenience 21:38:09 leio: that's why we proposed using use prefix || local ED=${D} 21:38:39 ok, so something to just communicate very well if this is accepted 21:38:46 Calchan: I'm searching 21:38:52 grobian, thanks 21:39:15 agenda had some link. That one? 21:39:44 http://article.gmane.org/gmane.linux.gentoo.devel/63527/match=gentoo+prefix+eprefix 21:40:20 yeah, that's the one in the agenda 21:40:26 only on gmane 21:40:34 see that thread for the idea to inject this inter-eapi that will allow to skip to do the conditional ED and EROOT 21:40:40 the details on the need for separate variables slightly still escapes me 21:41:11 leio: look at the make DESTDIR=${D} install example 21:42:16 grobian: Maybe the prefix-vars eclass idea is simpler. It's easier to remove in the future if we have something better. 21:42:33 leio: if you insert the offset in there, you simply get a double offset, because you supplied it during configure too 21:42:33 grobian: If we use an EAPI for uninstall the support stays there for quite a while 21:42:38 Betelgeuse: it's only not possible 21:43:08 grobian: how come? 21:43:15 Betelgeuse: D and ROOT need not to be set when the ebuild is sourced 21:43:33 grobian: I think I got it. The point was that DESTDIR remains $D and the problem happens if you need to access things post make install 21:44:02 leio: yes, you want to avoid writing ${EPREFIX} all the time, hence the shorthand ED 21:44:56 would dobin and similar methods automatically get ${EPREFIX} in front for defaults with a new EAPI? 21:45:19 leio: no, but they would in the Prefix EAPI, as is implemented now 21:46:13 the EAPI we talk about now is just a mere convenience EAPI that allows to avoid lots of conditional code such that Prefix and gx86 can share the same ebuilds 21:46:42 grobian, would that EAPI slot in between EAPI3 and EAPI4? 21:46:44 it basically all needed 21:46:47 the question was if the default locations would be changed in the new EAPI feature you are proposing to be accepted :) And if insinto and such would add $EPREFIX in front automatically, or all such places need to be updated as well. But this is perhaps getting into too much details for this point of time 21:46:51 grobian, or could that be EAPI4? 21:46:51 grobian: only feature being the new variables? 21:46:59 leio: nothing changes for gx86 21:47:36 Calchan: let's postpone the eapi details, we have an extra topic for it 21:47:44 Calchan: we need it now, and very fast, otherwise I'll stop waiting and just add lots of conditional code 21:47:48 s/eapi/eapi numbering/ 21:47:50 but they can't share the same ebuilds if insinto and dobin and so on don't have EPREFIX in front of the arguments 21:48:29 leio: EPREFIX is empty in main tree 21:48:30 ulm: a prefix enabled package manager can do offset installs using those variables 21:48:30 ok, they can if your portage branch does add that automatically for these functions 21:48:42 grobian, how come you need it fast? I understand the workload issue but I think it's not a reason to take chances with the tre 21:49:18 e 21:49:30 Calchan: because we already started doing that, and then zmedico came with this idea, so we suspended for that, because it sounds good to us 21:49:46 grobian your effort could be merged with the multilib idea we more or less discussed the past council? 21:50:11 leio: yes, the prefix portage is doing that exactly, meaning that if EPREFIX='', it behaves as normal portage 21:50:14 grobian which would be a confortable timeframe for you? 21:50:15 grobian, I think the details of prefix and its implications should be reviewed, and I would want to involve QA in that as they're usually the ones picking up the pieces 21:50:22 lu_zero: it's completely unrelated IMO 21:50:45 grobian: To vote on I would like to have the finished spec for the new EAPI text. 21:51:02 When when we have that we should see where we are with EAPI 3. 21:51:03 that's the bare minimum 21:51:03 grobian I see 21:51:06 lu_zero: well, zmedico told me he could do it pretty fast, so that's what I'm counting on 21:51:20 grobian fast as in week but not months 21:51:27 or fast as in yesterday? ^^ 21:51:36 I can still wait a week 21:51:47 what after that? 21:51:57 then I'll just continue I started on 21:52:06 s/on/with/ 21:52:39 grobian, you may want to hold back making major changes to ebuilds you don't maintain 21:52:40 hopefully getting acks from relevant maintainers... 21:52:47 the request is just a minimal change that will be completely transparent for non-prefix users? 21:52:57 Calchan: that's why we get maintainers in the loop 21:53:07 like we wrote in the mail 21:53:14 I don't see a problem with going forward with maintainer blessing in the meanwhile. 21:53:27 lu_zero: yes 21:53:30 grobian, is what you started doing reversible? 21:53:45 For non prefix users at least. 21:53:53 Calchan: yes, by basically sedding ED to D 21:54:12 Betelgeuse: prefix users already have ED and EROOT 21:54:13 basically, but not quite - too short keyword to sed :) 21:54:24 grobian, and are you touching any system packages? 21:54:28 ${D} =P 21:54:39 anyway 21:54:49 Calchan: not yet, but prefix code is already in toolchain*.eclass with ack from spanky 21:54:57 "system packages" is quite relative these days, unfortunately. E.g pam -> pam-base[gnome-keyring] -> gnome-keyring -> ... 21:55:37 we are already behind schedule 21:55:49 so how do we go on from here? 21:56:02 should we vote if council generally supports the idea? 21:56:07 I like the idea of merging prefix with the main portage 21:56:08 grobian, I would agree with the move once this has been properly reviewed, but inflicting us a one week deadline is rather unrealistic 21:56:39 Calchan: we can always benefit from it when it comes later 21:56:54 grobian, benefit of what? 21:57:08 an eapi that we don't need to set ED or EROOT in 21:57:31 I think you're pushing the schedules here 21:57:47 and again I understant the impact on your workload 21:57:54 sorry, I feel I just made a simple request 21:58:09 you could see me coming I guess 21:58:15 7w 30 21:58:20 if the only change is definition of three variables there can't be much danger of damaging anything 21:59:03 --> NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council 21:59:08 if the position of the portage team is of any value to you, I think you should consult them 21:59:20 grobian, I was going to propose that 21:59:50 one thing that bothers me is that it affects past EAPIs 22:00:03 in what way does it do that? 22:00:06 Calchan: no? 22:00:50 mmhhh... this would prove I didn't understant the whole thing correctly 22:01:10 which would mean I'm not ready to vote on this 22:01:21 Calchan: if EAPI="2+prefix" ; then define ED, EROOT, EPREFIX ; fi 22:01:28 we are at this topic since 30 min and I propose to move discussion to -dev ml 22:01:44 since I don't see us converging towards a vote 22:01:57 ulm 4.1 could be voted already 22:02:01 grobian, don't eclasses need to be modified? 22:02:02 grobian: Couldn't we go with having ROOT and D available on global scope immediately? 22:02:31 Calchan: eclasses: yes, take KDE eclasses as example 22:02:55 Betelgeuse: I don't like stacking many things in one, but then I won't mind either 22:03:23 grobian, I will but not now, we're running late with the meeting 22:03:39 the main problem is that 1 week is a pretty short time 22:03:50 let's vote on 4.1 then "Does the council generally support this idea?" 22:04:01 and say if you're not ready 22:04:08 I like the idea 22:04:24 ulm, does that mean the general idea of eventually having prefix in the tree? 22:04:38 Calchan: that's the implication 22:04:40 I support the intention of getting all this into the main tree, but unsure of the first step proposed right now. 22:04:42 in general i like it and want to see it happen, but as the past about 30 minutes proved - there are lots of things to discuss 22:04:58 I support having prefix eventually merged to main tree but I won't vote on EAPis without a written spec. 22:05:07 * ulm also supports the idea in general 22:05:09 Betelgeuse that is 4.2 22:05:31 lu_zero: in my opinion ties back to 4.1 22:05:51 I would vote yes 22:06:08 DrEeevil? 22:06:27 I support the idea and grobian's plan 22:06:34 the timeline is debatable 22:07:09 so we have unanimous support for the general idea, but there's need for additional discussion 22:07:23 let's postpone 4.2 to next meeting then 22:07:28 ok 22:07:41 ok 22:08:05 grobian: you can live with that? 22:08:30 We need a PMS patch, no? 22:08:30 grobian, would you start a discussion on that and make sure we get relevant feedback on this, so that we can vote on this next time? 22:08:33 grobian: and please get the discussion on -dev ml going 22:08:43 sure I can, but may I request you all to do a little bit of homework for next meeting then? That'll save you some time in here ;) 22:09:14 grobian, seriously, your message was posted a bit late for me to research that thouroughly enough 22:09:17 ulm: all questions have been addressed in the mail as far as I can see, so I would request you to put the questions out there, so I can reiterate 22:09:27 Calchan: the original message was on gentoo-dev quite a while ok I think 22:09:48 Betelgeuse, a bit short for me, slow and old brain and all that 22:09:55 plus life 22:09:57 3 weeks, 1 day, 10 hours and 57 minutes ago 22:09:58 Calchan: 3 weeks ago 22:10:05 grobian: o.k., i'll followup on the ml then 22:10:08 3 weeks? ok than, I slacked 22:10:12 next topic: "5. Usage of bash 3.2 features in Portage tree" 22:10:17 grobian: will you write a PMS patch? 22:10:30 leio: if you request me to do so, I'm willing to do 22:10:52 grobian, please do, if we have all material ready for next time it'll be easier 22:11:15 Calchan: ok, I'll do 22:11:18 patrick's message is here: http://archives.gentoo.org/gentoo-council/msg_ed3cba3e0ded55c4e497451af46ea55b.xml 22:11:25 grobian: at some point it will be necessary if the discussion leads to a potential accepting of it, the sooner the better. Things might be clearer for the discussion as well if there's a concrete detailed PMS patch to discuss 22:11:25 grobian, thanks 22:11:27 we've moved on ;) 22:11:39 stop discussing topic 4 please 22:12:03 this issue can easily be answered with the decision we've made in 3.2 22:12:18 right, it's linked to that 22:12:29 is 3.2 stable for at least a year? 22:13:00 DrEeevil: can you answer this? 22:13:08 bash 3.2 has been stable for much more than a year 22:13:22 bash 3.2 was added Oct 2006 and stabled May 2007 22:13:54 that part sounds OK. Now the problem is it being part of EAPI-0 and how amending of that is done as a process 22:14:30 is it that urgent that we can't wait for EAPI3? 22:14:40 unrelated to EAPI 22:14:41 Calchan: You should know global scope issues 22:14:45 please stop confusing things :) 22:14:47 oh right 22:14:49 Calchan: To parse the EAPI out 22:14:49 sorry 22:15:28 leio: We as a council can decide for EAPI 0. 22:15:35 I think we could safely amend pms 22:15:57 if we want to be consequent, we should either revert all usage of 3.2 features in the tree, or allow 3.2 in general 22:16:03 exactly 22:16:12 reverting will be a very unpleasant thing to do 22:16:14 probably it's too late for the first option already 22:16:35 given the fact that we have bash 3.2 stable for >2 years i think this mostly is a non-issue. therefore i'd prefer "fixing" pms and requiring bash-3.2 thus allowing it in general 22:16:48 but we should make sure that this won't happen again for bash 4.0 22:16:51 Let's see for any bash >3.2 features they will be reverted 22:16:54 I'd go with the simpler way 22:17:04 Betelgeuse: exactly 22:17:05 Betelgeuse agreed 22:17:06 is there any chance that we could end up in a situation where we can't parse the ebuild and thus not get the EAPI? 22:17:20 Calchan: bash4 features potentially 22:17:30 bash 3.0/3.2 changes are small enough to be parseable 22:18:20 <-- dabbott|work has quit (Client Quit) 22:18:29 DrEeevil, so why do we care about requiring 3.2 then? 22:18:40 Ideally we would have repoman parsing the ebuilds with a 3.2 parser. 22:18:45 Calchan: because it is actively used 22:19:12 either we allow it (fix PMS) or we don't (fix tree), but having the spec and the product disagree like that is bad 22:19:20 DrEeevil, I would tend to consider that an error if it can't be relied on 22:19:33 Calchan: an error with >150 occurances in eclasses only 22:19:51 DrEeevil, can't be sedded? 22:19:58 Calchan: no, not that easy 22:20:09 and people will not appreciate having good features removed 22:20:09 Calchan: and what would be the point? 22:20:35 ulm, teaching people to not use features they can't rely on? 22:20:51 Calchan: we can do this for bash 4.0 features ;) 22:21:00 ulm: we *should* or better *must* 22:21:06 Calchan: you're about a year late for that 22:21:10 --> Zorry (n=zorry@fu/coder/zorry) has joined #gentoo-council 22:21:21 DrEeevil, so what? 22:21:22 people warned back then and noone seemed to care, so it started to get used more and more 22:21:27 procedural fail. 22:22:02 I think all arguments have been said and we can vote: "Should usage of bash 3.2 features in the Portage tree be a) forbidden (i.e. tree reverted to 3.0), b) allowed (i.e. PMS changed), or should c) the issue be ignored?" 22:22:17 we've been doing (c) for long enough 22:22:31 still is an option 22:22:44 lu_zero: that's why it's listed 22:22:51 i think c is not an option to vote upon 22:23:19 I still don't know what is to be gained by using 3.2, and from what I understand not much if anything 22:23:42 Calchan: I see it mostly as a matter of having a correct specification 22:23:57 if PMS is supposed to have any relevance it needs to document reality 22:24:08 reality already is that we have 3.2 features being used and the only thing we can do about this *now* is to change pms to reflect that behaviour but also to make sure such doesn't happen again with bash-4 22:24:10 which doesn't matter if people don't foolow it like they did 22:24:26 dertobi123: agreed 22:25:01 Calchan: they weren't, in any way, sanctioned 22:25:15 hey, why not use the shiny features! 22:25:19 we may also have a stronger point for forbidding 4.0 features if PMS reflects the real status of the tree 22:25:39 If we can make repoman fail people won't add new features 22:25:50 I bet much of it is just because people don't know/notice 22:26:03 the bash 3.2 features were quite conscious 22:26:09 DrEeevil: PMS authors can't really upgrade the bash version but the council should 22:26:56 so vote please: "Should usage of bash 3.2 features in the Portage tree be a) forbidden (i.e. tree reverted to 3.0), or b) allowed (i.e. PMS changed)" 22:27:03 b 22:27:05 i vote for b 22:27:07 Betelgeuse, I'd agree with you but it's still not a good enough reason to let people not respect a decision previously made by the council 22:27:11 b 22:27:15 b 22:27:20 a 22:27:26 b 22:27:32 b 22:27:38 I'd like to request some general consensus that we shouldn't repeat things like this however 22:27:54 So people can't introduce 4.0 features and then say "PMS should reflect reality!" 22:27:56 I count 1a 6b 22:28:10 tanderson: that was my next point 22:28:15 ulm: Vote on >3.2 features will be reverted please 22:28:24 Betelgeuse: yep 22:28:55 ulm: great, I would likely quit if people tried that one. :p 22:29:02 Calchan: Yes but being able to use 3.2 features is useful 22:29:08 "Should features of >=bash-4 be disallowed and reverted in the tree?" 22:29:09 I'm ok with reverting as well 22:29:32 why not >3.2, just in case 22:29:35 Calchan: The only way of getting there without this that I know of is glep 55... 22:30:03 Calchan: hm, 3.2_p39 > 3.2 22:30:12 give me a proper version spec ;) 22:30:12 or the many counter proposals of glep 55, but lets not go there 22:30:16 Betelgeuse, agreed, but I still have a problem with people not respecting rules 22:31:31 Calchan: Nothing in our docs really teaches what's 3.2 22:31:31 Calchan rules must be clear 22:31:41 Calchan: We don't teach new recruits either 22:31:41 Calchan: I will add a new question based on these votes 22:32:30 Calchan: if there is no enforcement (even after repeatedly pointing out the issue) then there's no motivation to respect the rules 22:32:30 ulm: Ebuilds must be parseable with =bash-3.2* 22:32:43 Betelgeuse: perfect :) 22:33:24 global scope or all of it? 22:33:34 all of it 22:33:37 leio: all of it 22:33:37 all of it 22:33:38 (global scope DEPEND could >bash-4) 22:33:48 ok, just to be clear :) 22:33:50 so please vote on: "Ebuilds must be completely parseable with =bash-3.2*, any use of later bash features will be reverted." 22:33:58 yes 22:34:01 yes 22:34:05 yes 22:34:18 yes 22:34:23 yes 22:34:25 yes 22:34:49 Calchan? 22:34:58 DrEeevil: rules don't get removed simply because noone obeys them 22:35:15 tanderson: that's how democracy usually works 22:35:29 DrEeevil, no that's anarchy 22:35:36 ulm, sorry I lost internet for a while 22:35:54 DrEeevil: In democracy you take the changes to the people in charge who change the rules 22:35:55 I'm ok with the wording although I voted against that 22:36:08 civil disobedience 22:36:12 well 22:36:14 o.k, so 6 yes, 1 no 22:36:17 the rosa parks kind of thing 22:36:26 DrEeevil: is not needed if the system works 22:36:27 people in charge listen to the other people usually 22:36:42 Someone please find out at some point what developer helping features bash-4 would provide to see if we should start thinking of ways how to allow it properly without breaking anything (yes, I realize this will involve glep55 or alternatives, it's for prioritizing work on such a solution or not) 22:36:49 DrEeevil: and you don't see civil disobedience before going to authority do you? 22:37:06 tanderson: you try to ignore the discussions on the mailinglist about a year ago 22:37:08 Calchan: You had a timebox? 22:37:08 you guys can finish this discussion next time you meet at the pub 22:37:18 now... 22:37:20 Any way we are pass 90 mins 22:37:23 tanderson: it was discussed and ignored 22:37:23 we're over time 22:37:25 Betelgeuse, no, just crappy internet at work 22:37:38 can we still discuss topic 6? 22:37:49 or should we postpone it? 22:38:06 We can but I will need to go visit neighbourghs shortly 22:38:17 I will be back in 10 mins 22:38:28 postpone. 22:38:31 I'd rather postpone 22:39:13 can we make sure we keep the discussion on this alive so that next time all we need to do is vote? 22:39:19 Calchan: sure 22:39:35 we should do that more in general by the way 22:39:45 so let's postpone topic 6 "Preservation of file modification times in EAPI 3 " 22:39:52 council metings are not a good time for technical discussions 22:39:56 right 22:40:13 any other business? 22:40:24 When is the next meeting 22:40:26 next meeting. when? who's taking care of the agenda? 22:40:27 who will take chair for the next meeting? 22:40:39 I can if nobody wants 22:40:55 what about december 7th? that's in 4 weeks 22:41:17 general question is if we shall keep the 4 weeks interval 22:41:32 we originally said third monday in month 22:41:48 we may need to start thinking of christmas time, not everybody may be available 4 weeks after dec 7 22:42:09 that is 4th January 22:42:22 we can do december 7th and something mid-january 22:42:36 leio, which proves again that I can't count to 4... ;) 22:43:16 so let's note december 7th 19 UTC, calchan prepares agenda and takes the chair 22:43:23 jan 4th is ok with me although I'll just be flying back from japan after 2 weeks without internet 22:43:35 ulm, ok 22:43:59 leio: you followup on the upgrade path thingy? 22:43:59 Calchan you'll be in tokyo? 22:44:12 ulm: yes 22:44:14 lu_zero, 1h north of tokyo 22:44:21 so, open floor 22:44:23 --- ulm sets mode -m #gentoo-council 22:44:55 Calchan make sure if you could attend the tlug event if you hadn't already ^^; 22:45:15 --- ulm removes voice from DrEeevil grobian 22:45:26 lu_zero, when/where? not sure I can make it though 22:46:11 fyi, reavertm said bash-4 would mostly provide associative arrays (array indexes with strings instead of just numeric indeces), which is probably not very important to have for ebuild/eclasses 22:46:18 ulm: you get to kick me if I don't do so ;) 22:46:42 leio: will do 22:46:54 bash 4 has a tr replacement builtin, which is handy. but since it's only handy for global scope things... 22:47:59 one more thing, can somebody get the automatic council reminders going again? 22:48:23 there used to be a ml posting (by vapier I think) two weeks in advance 22:48:25 maybe someone could contact vapier and ask to tweak the cron script 22:48:38 it's still happening, just with wrong dates at wrong times 22:50:05 hard to cron when the dates are not solid 22:50:23 the one who does the agenda should schedule reminders and send them 22:50:35 or that 22:50:43 but I forgot last time 22:51:09 Calchan: please add a note to your calendar 22:51:27 anyway, seems there are no pressing topics for open floor 22:51:39 so let's call it end of meeting 22:51:46 thanks everybody 22:52:03 Betelgeuse, thanks ;o)