path: root/meeting-logs/20091109.txt

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