path: root/meeting-logs/20140311.txt

Mar 11 14:59:01 <blueness>	ping dberkholz dilfridge rich0 scarabeus ulm  williamh
Mar 11 14:59:06 dberkholz dberkholz|mob dilfridge dilfridge|mobile dleverton_ DrEeevil 
Mar 11 14:59:13 <blueness>	dberkholz|mob, mob?
Mar 11 14:59:28 *	ulm here
Mar 11 14:59:30 <dberkholz|mob>	mobile
Mar 11 14:59:38 <blueness>	ah
Mar 11 14:59:44 *	rich0 here
Mar 11 14:59:47 *	dilfridge here
Mar 11 14:59:58 <rich0>	he's ganging up on us
Mar 11 15:00:13 <blueness>	ping scarabeus ulm  williamh
Mar 11 15:00:50 *	ulm still here ;)
Mar 11 15:01:07 <blueness>	scarabeus, WilliamH are missing
Mar 11 15:01:47 <blueness>	let's wait a few minutes (the time it takes me to run downstairs and get tea)
Mar 11 15:02:25 <dberkholz|mob>	Sounds good
Mar 11 15:02:29 *	WilliamH is here
Mar 11 15:03:30 <blueness>	scarabeus, ping last time
Mar 11 15:03:45 <blueness>	let's start
Mar 11 15:03:55 <rich0>	I think we might actually make it through the agenda this time!
Mar 11 15:03:56 <blueness>	agenda: http://dev.gentoo.org/~blueness/council/council_agenda_20140311.txt
Mar 11 15:04:17 <blueness>	If there are no objections we'll proceed to item 1
Mar 11 15:04:29 <blueness>	Vote: GPG signing GLEP 63
Mar 11 15:04:36 <blueness>	https://wiki.gentoo.org/wiki/GLEP:63
Mar 11 15:05:03 <dilfridge>	there was discussion whether we should place in the GLEP only the bare specs or also the howto parts
Mar 11 15:05:04 <blueness>	So we're voting to accept GLEP 63 which should be ready
Mar 11 15:05:22 <dilfridge>	https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1001a
Mar 11 15:05:32 <dilfridge>	^ this is a re-arranged "barebones" version.
Mar 11 15:05:48 <rich0>	I'm fine with accepting it as-is as long as it is understood that it isn't effective/implemented until communications/docs/etc are in place.  Works fine as a reference for design/etc of all that.
Mar 11 15:06:05 <dilfridge>	I prefer the longer version.
Mar 11 15:06:09 <rich0>	Of course, if they do clean up the docs, presumably the docs section of the GLEP should be updated.
Mar 11 15:06:18 <dilfridge>	Just wanted to have something to show up.
Mar 11 15:06:37 <rich0>	But it isn't absolutely required if the intent is to just show the state at the time of review.
Mar 11 15:07:03 <ulm>	I think the documentation should better go to a less rigid part of the wiki
Mar 11 15:07:16 <blueness>	dilfridge, by the longer version you mean the one at https://wiki.gentoo.org/wiki/GLEP:63
Mar 11 15:07:21 <ulm>	so it can be updated more easily, without us voting on it every time
Mar 11 15:07:24 <dilfridge>	blueness: yes.
Mar 11 15:07:28 <rich0>	The biggest issue with docs in a GLEP is that they tend to get crufty.
Mar 11 15:07:33 <dberkholz|mob>	Prefer longer with examples, not necessarily as canonical doc
Mar 11 15:08:18 <rich0>	I'm fine either way - I could see the argument for either approach.
Mar 11 15:08:29 <dilfridge>	_robbat2|irssi: a penny for your thoughts?
Mar 11 15:08:29 <blueness>	Well what came forward last time was to vote on the longer version, so i'm not sure what to do with the shorter one now
Mar 11 15:09:16 <WilliamH>	blueness: the vote is on the longer version...
Mar 11 15:09:32 <ulm>	the shorter version is not so much shorter, btw
Mar 11 15:10:03 <blueness>	Should be proceed with the vote then?
Mar 11 15:10:08 *	dilfridge is fine with voting on the long version.
Mar 11 15:10:08 <blueness>	on the longer version?
Mar 11 15:10:18 <rich0>	wfm
Mar 11 15:10:22 <ulm>	wfm too
Mar 11 15:10:23 <blueness>	waiting
Mar 11 15:11:00 <WilliamH>	I'm also not sure that the official howto for this should be part of the glep...
Mar 11 15:11:05 <ulm>	I'd like to hear robbat2's opinion
Mar 11 15:11:37 <dberkholz|mob>	I'm for longer as I said. Should be clear it's example how to do it now
Mar 11 15:12:00 <dberkholz|mob>	Not docs council must always approve updates of
Mar 11 15:12:03 <blueness>	its unlikely things will change
Mar 11 15:12:05 <rich0>	I view the docs in the GLEP a bit like a "reference implementation" - it doesn't mean it is the version you run.
Mar 11 15:12:17 <rich0>	Granted, they fall considerably short of a reference implementation.
Mar 11 15:12:30 <_robbat2|irssi>	sorry, was in this talk
Mar 11 15:12:39 *	kallamej has quit (Ping timeout: 264 seconds)
Mar 11 15:12:53 <_robbat2|irssi>	and this conference wifi is bad
Mar 11 15:13:16 <blueness>	_robbat2|irssi, did you get the backlog?
Mar 11 15:13:21 <_robbat2|irssi>	i do like the 1001a part
Mar 11 15:13:30 <_robbat2|irssi>	but i think I need to reformat the recommendation chunk
Mar 11 15:13:34 <_robbat2|irssi>	to explain what it's doing
Mar 11 15:13:38 <_robbat2|irssi>	or rather specify
Mar 11 15:13:42 <_robbat2|irssi>	not in a gnupg config file format
Mar 11 15:14:20 <_robbat2|irssi>	then after that, explain why
Mar 11 15:14:25 <_robbat2|irssi>	lastly, in a NEW document
Mar 11 15:14:28 <_robbat2|irssi>	have the gpg config file
Mar 11 15:14:32 <_robbat2|irssi>	along with instructions
Mar 11 15:14:53 <_robbat2|irssi>	is the council in favour of the actual spec contents?
Mar 11 15:14:58 <_robbat2|irssi>	(aside from the format)
Mar 11 15:15:02 <rich0>	In effect, the "bare minimum requirements" are the real policy.  The rest is just howtos, commentary on best practices, etc.
Mar 11 15:15:14 <rich0>	Only the minimum requirements really have any kind of force.
Mar 11 15:15:37 <dilfridge>	suggestion: we vote now that the minimum requirements remain unchanged
Mar 11 15:16:00 <_robbat2|irssi>	i'm wondering if some of the parts in recommendations might be moved to the min requirements
Mar 11 15:16:06 <dilfridge>	ok
Mar 11 15:16:18 <blueness>	its sounds like you two want to work on this more
Mar 11 15:16:23 <blueness>	we can table the vote
Mar 11 15:16:44 *	WilliamH agrees with blueness
Mar 11 15:16:56 <dilfridge>	works for me too, shall we target the next meeting then?
Mar 11 15:17:12 <ulm>	we could have a vote per e-mail if we don't want to delay it by another month
Mar 11 15:17:13 <blueness>	dilfridge, yes, we need to vote to table it though (following roberts rules)
Mar 11 15:17:39 <blueness>	ulm, i'm not sure there's an urgency, but i'm not against an email vote
Mar 11 15:18:10 <rich0>	Those working on implementation shouldn't hold up or anything.  Nobody objects to the policy itself.  This is really about the docs/etc.
Mar 11 15:18:11 <dilfridge>	_robbat2|irssi: your call (I think in general there is agreement with the specs, but we can't formally vote on something unfinished :)
Mar 11 15:18:30 <rich0>	We've been fine on the specs for two months now.
Mar 11 15:18:55 <blueness>	rich0, we wanted to see final language, which is why this keeps getting tabled
Mar 11 15:19:29 <rich0>	blueness: sure - wasn't a complaint.  Just supporting the comment that getting this GLEP approved shouldn't stop anybody from writing infra code, docs, etc.
Mar 11 15:19:38 <dilfridge>	I dont see much disagreement with the specs here...
Mar 11 15:20:54 <blueness>	dilfridge, is the short document sufficient for a vote now, given that we agree with the specs? ie are all the spec in there?
Mar 11 15:21:41 <dilfridge>	in my opinion yes, but robbat2 is the real author.
Mar 11 15:22:00 <blueness>	_robbat2|irssi, ^^^ any opinion on my question
Mar 11 15:22:19 <dilfridge>	my intention was to have the long and short version "identical in specifications, differing in explanation/docs"
Mar 11 15:22:51 <blueness>	i think robbat2 is having net issues
Mar 11 15:23:34 <blueness>	i suggest tabling this with a email vote, initiated by dilfridge when he and robbat2 have sorted it out
Mar 11 15:23:47 <WilliamH>	That's fine with me.
Mar 11 15:24:11 <dilfridge>	ok
Mar 11 15:24:29 <blueness>	table it? dberkholz rich0 ulm 
Mar 11 15:24:38 <ulm>	+1
Mar 11 15:24:40 <rich0>	++
Mar 11 15:24:43 <dilfridge>	+1
Mar 11 15:24:44 <WilliamH>	table it
Mar 11 15:25:08 <blueness>	okay, dilfridge when you're ready, email the group and we'll vote.  otherwise its on the next agenda
Mar 11 15:25:14 <dilfridge>	will do
Mar 11 15:25:24 <blueness>	okay next item: Ban on EAPI 1 and 2 should extend to updating EAPI in existing ebuilds
Mar 11 15:25:43 <blueness>	ulm, you brought this up, do you want to speak to it?
Mar 11 15:26:15 <ulm>	IMHO a "ban" means that once the count of e.g. EAPI 1 ebuilds is down to zero, it should stay there
Mar 11 15:26:37 <ulm>	which isn't the case if changing ebuilds to EAPI 1 and 2 is still allowed
Mar 11 15:27:03 <ulm>	in other words, these EAPIs are on their way out of the tree
Mar 11 15:27:26 <blueness>	ulm, to be honest, i thought that was implicit in what we voted on last time, but i can see how that confusion might arrise because we did say the bans was on "new" ebuilds
Mar 11 15:27:29 <ulm>	so there should be no excuse for adding such ebuilds, or changing others to these EAPIs
Mar 11 15:28:04 <ulm>	blueness: devs are more creative in interpreting the rules than we had imagined ;)
Mar 11 15:28:17 <blueness>	ulm, okay
Mar 11 15:28:23 <mgorny>	ulm: how are we supposed to add slot deps to EAPI=0 ebuilds then?
Mar 11 15:28:29 <WilliamH>	Why would you change an ebuild *to* one of these eapis?
Mar 11 15:28:37 <ulm>	mgorny: update to EAPI 3 or later
Mar 11 15:28:59 <mgorny>	this goes outside of 'acceptable' for touching sb's package
Mar 11 15:29:14 <mgorny>	and this is a lot of unnecessary work for old ebuilds
Mar 11 15:29:18 <ulm>	but you have to change the EAPI anyway, so why not to a supported one?
Mar 11 15:29:37 <mgorny>	because changing 0 -> 1 doesn't require many changes, while 0 -> 3 does
Mar 11 15:29:41 <rich0>	EAPI 0->1 is less work than 0->5 - less phase rewriting/etc.
Mar 11 15:29:48 <blueness>	i see
Mar 11 15:29:55 <blueness>	mgorny, just do it one step at a time
Mar 11 15:29:55 <rich0>	I can see why people would rather do it.
Mar 11 15:29:57 <dilfridge>	file a bug to maintainer (get ignored)
Mar 11 15:30:11 *	kallamej (~kallamej@gentoo/developer/kallamej) has joined #gentoo-council
Mar 11 15:30:42 <blueness>	does anyone have a count of how many ebuilds we're talking here?
Mar 11 15:30:53 <ulm>	less than 300
Mar 11 15:30:57 <ulm>	for eapi 1
Mar 11 15:31:20 <rich0>	If we just made the policy no moving from a non-banned EAPI to a banned one that covers the obvious loophole.
Mar 11 15:31:21 <dilfridge>	EAPI=0 is somewhere around 6000
Mar 11 15:31:45 <ulm>	dilfridge: yeah, but not all of them to be converted to 1
Mar 11 15:31:47 <rich0>	EAPI0 might get an exception.
Mar 11 15:31:59 <rich0>	EAPI0 is almost banned, but we have some details to work out first.
Mar 11 15:32:06 <dberkholz>	so the argument here is that any forward ports to 0 must move forward to at least 3
Mar 11 15:32:11 <dberkholz>	errr. *from 0
Mar 11 15:32:19 <rich0>	I don't see EAPI0->1 as really anything but an improvement.
Mar 11 15:32:46 <dilfridge>	we want to remove EAPI=1 usage, if we allow upgrade 0->1 that will never happen
Mar 11 15:32:58 <ulm>	we could add an exception for updating from 0 to 1 in case of slot dependenies
Mar 11 15:33:15 <rich0>	dilfridge: at the moment EAPI1 doesn't cost us anything, and EAPI0 will not be around forever.
Mar 11 15:33:18 <blueness>	ugh no, that's messy
Mar 11 15:33:27 <ulm>	blueness: it is ;)
Mar 11 15:33:37 *	ulm prefers clear rules
Mar 11 15:34:05 <rich0>	The thing is, we have to bite the EAPI3 bullet sooner or later.
Mar 11 15:34:36 <ulm>	basically, all the ebuilds that are moved from 0 to 1 now have to be touched a second time lateron
Mar 11 15:34:42 <WilliamH>	To me banned is banned. no emore ebuilds should be committed to the tree with a banned eapi.
Mar 11 15:34:52 <mgorny>	ulm: they will be mostly removed later on
Mar 11 15:35:00 <blueness>	rich0, that's why i'm saying we can move at a comfortable pace here
Mar 11 15:35:08 <ulm>	mgorny: honestly, I doubt this
Mar 11 15:35:09 <mgorny>	we need to fix deps in old versions, they don't take more maint than that
Mar 11 15:35:33 <mgorny>	at least the ebuilds i was touching had newer versions with newer EAPI
Mar 11 15:35:43 <rich0>	If the package manager teams were screaming for EAPI relief I could see pushing harder.  Right now they're content.
Mar 11 15:35:53 <ulm>	mgorny: if there's a newer ebuild around for the same pkg, you can take that one as example
Mar 11 15:36:11 <dberkholz>	is it really that much work to bring them forward to 3?
Mar 11 15:36:25 <dberkholz>	most of the stuff you can skip, a tiny bit of function refactoring for 2, eh
Mar 11 15:36:53 <blueness>	dberkholz, i wouldn't have thought it was that much work, but i guess i can see some thorny situations
Mar 11 15:37:12 <blueness>	eapi0 made for some very strange phase coding
Mar 11 15:37:17 <rich0>	dberkholz: certainly more opportunity for trouble with the refactoring.  Not that big a deal, but if I had to edit 50 ebuilds I'd be reluctant to deal with it...
Mar 11 15:37:25 <blueness>	like configuring during compile etc
Mar 11 15:37:27 <mgorny>	when i have like 50 packages to update, i don't want to waste time converting old ebuilds nobody will use...
Mar 11 15:37:48 <blueness>	mgorny, can you give us a deprecation pathway then
Mar 11 15:37:58 *	alexxy has quit (Ping timeout: 240 seconds)
Mar 11 15:37:58 <mgorny>	if you tell me it's fine to leave broken deps in old ebuilds, i'm fine with that
Mar 11 15:38:10 <blueness>	like if we make an exception for a few older ebuild versions until phased out?
Mar 11 15:38:15 <rich0>	Maybe look at it another way - which is worse, treecleaning or having more EAPI1 ebuilds?  I think in practice users would object more to the treecleaning.
Mar 11 15:38:41 <dberkholz>	mgorny: if nobody's gonna use them, why not remove them
Mar 11 15:39:06 <rich0>	dberkholz: That's the whole ain't-broke-don't-fix thing.
Mar 11 15:39:07 *	WilliamH agrees with dberkholz  here. if no one is using the old stuff, remove it.
Mar 11 15:39:24 <rich0>	I'm sure most of it will get treecleaned, but there is some value in delaying that as much as possible.
Mar 11 15:39:25 <mgorny>	because the maintainer believes in keeping old versions and i'm really tired of fighting all the personal preference issues in gentoo?
Mar 11 15:39:40 <dilfridge>	file a bug for the maintainer?
Mar 11 15:39:48 <rich0>	If it IS maintained then LART the maintainer.
Mar 11 15:39:49 *	alexxy (~alexxy@gentoo/developer/alexxy) has joined #gentoo-council
Mar 11 15:40:04 <blueness>	LART?
Mar 11 15:40:11 <dberkholz>	is that like LARP
Mar 11 15:40:18 <rich0>	I think the bigger issue is stuff that isn't maintained, in which case the preferences that matter are those of the folks who actually want to do something about it.
Mar 11 15:40:34 *	Arfrever has quit (Read error: Operation timed out)
Mar 11 15:40:45 <dilfridge>	"Luser Attitude Readjustment Tool"
Mar 11 15:40:49 <blueness>	ahah!
Mar 11 15:40:54 <blueness>	i like that
Mar 11 15:41:11 <ulm>	if the opinion is that it causes to many inconveniences to devs, then our decision on banning EAPIs 1 and 2 was premature and we should revert it
Mar 11 15:41:32 <ulm>	which I'd really dislike though
Mar 11 15:41:38 <blueness>	sound logic
Mar 11 15:42:13 *	WilliamH agrees with what was said above.
Mar 11 15:42:25 <WilliamH>	At some point we are going to have to convert all of this stuff to at least eapi 3.
Mar 11 15:42:36 <dberkholz>	inconvenience to devs isn't just a short term thing
Mar 11 15:42:43 <dberkholz>	it's also about long term maintenance inconvenience
Mar 11 15:42:57 <rich0>	I don't think we need absolutes.
Mar 11 15:43:03 <blueness>	dberkholz, what do you mean?
Mar 11 15:43:07 <rich0>	We don't want people writing new stuff in EAPI1/2
Mar 11 15:43:12 <dberkholz>	having a big stack of EAPIs sitting around is confusing
Mar 11 15:43:28 <dberkholz>	pretty much nobody even remembers what's in what anymore, unless they were around for generation 0
Mar 11 15:43:28 <rich0>	That doesn't mean that using it as a stepping-stone for existing EAPI0 stuff is bad.
Mar 11 15:43:49 <mgorny>	well, in my opinion there's no real issue here
Mar 11 15:44:09 <mgorny>	if people are intentionally doing step-0-to-1 to use banned EAPI, there will be action required
Mar 11 15:44:14 *	WilliamH still thinks that if an eapi is banned it is banned
Mar 11 15:44:21 <rich0>	I'm all for banning EAPI0 as well, just with an exception for the toolchain.
Mar 11 15:44:39 <rich0>	mgorny: ++
Mar 11 15:44:40 <blueness>	rich0, one at a time!
Mar 11 15:45:06 <blueness>	okay has everyone had enough discussion?
Mar 11 15:45:11 <rich0>	We're not robots.  We don't need rules that a robot can follow, or a lawyer for that matter.
Mar 11 15:45:13 <mgorny>	but if there's a bug that needs being fixed quickly and with little effort, i don't see doing temporarily EAPI change a problem
Mar 11 15:45:42 <ulm>	mgorny: it's also about EAPI support in eclasses
Mar 11 15:45:44 <blueness>	mgorny, how would you phrase that as a clean exception to the eapi1/2 ban
Mar 11 15:46:07 <blueness>	so we clearly exclude undesireable 0->1 bumps
Mar 11 15:46:28 <rich0>	Why not this, EAPI1/2 may not be used for ebuilds that are not already in the tree as of this date.
Mar 11 15:46:51 <ulm>	rich0: this would allow 5->1
Mar 11 15:47:03 <blueness>	heh
Mar 11 15:47:29 <dberkholz>	i think rich0 was right about this point, we shouldn't need to explicitly preclude every absurd behavior
Mar 11 15:47:30 <rich0>	EAPI1/2 may not be used for ebuilds unless they are already in the tree using EAPI0 as of this date.
Mar 11 15:47:43 <mgorny>	blueness: if you really feel we need this, how about saying something about timeframe for keeping ebuilds?
Mar 11 15:47:59 <mgorny>	as in, allowing bump from 0 to 1 when ebuild is not intended to be kept more than 30/60 days or so
Mar 11 15:47:59 <ulm>	the thing is, either we trust devs to DTRT, then we don't need a ban
Mar 11 15:48:04 <blueness>	mgorny, i like rich0's wording
Mar 11 15:48:11 <ulm>	or we don't, then we should enforce it in some way
Mar 11 15:48:40 <rich0>	Or more refined, EAPI1/2 may not be used for ebuilds unless they are already in the tree using EAPI0/1/2 as of this date.
Mar 11 15:49:05 <blueness>	how do people feel about rich0's extention to the ban on 1/2 ?
Mar 11 15:49:05 <dilfridge>	is there a good reason for using EAPI=2?
Mar 11 15:49:05 <ulm>	rich0: better ;)
Mar 11 15:49:17 <TomWij>	mgorny: If stabilization of EAPI 1 ebuild takes place it can keep it around for longer; to be more clear, the second stabilization of a non-EAPI 1 ebuild after that can block the EAPI 1 ebuild and keep it in position.
Mar 11 15:49:27 <dilfridge>	I mean, the step from 2 to 3 is minima.
Mar 11 15:49:43 <blueness>	good point
Mar 11 15:49:53 <ulm>	dilfridge: /EAPI/s/2/3/ ?
Mar 11 15:50:00 <rich0>	That is really just the minimum policy.  Devs should move to EAPI5 whenever practical.
Mar 11 15:50:05 <TomWij>	(Just hoping the actual cleaning effort and the effect of stabilization is taken into consideration if you really want to see this go towards 0.)
Mar 11 15:50:05 <rich0>	And implement slot op deps as well.
Mar 11 15:50:44 <mgorny>	and use :<current-slot> whenever no other slot is applicable but this is yet another topic
Mar 11 15:51:21 <dilfridge>	"In case of non-maintainer commits to fix dependencies, EAPI=0 ebuilds may be updated to EAPI=1 to keep the changes at a non-intrusive level, as a temporary workaround."
Mar 11 15:52:15 <blueness>	sounds good to me, is the committee comfortable with discuss/voting on dilfridge's formulation of the exception?
Mar 11 15:52:22 <ulm>	dilfridge: plus the wording from the agenda?
Mar 11 15:52:35 <dilfridge>	why not
Mar 11 15:52:36 <dilfridge>	yes
Mar 11 15:52:38 <rich0>	wfm - that's the tightest possible exception - there is a risk that other exceptions will come up.
Mar 11 15:52:40 <dberkholz>	i don't think we need to add specific policy to say something is allowed that our current vote already says is allowed
Mar 11 15:52:53 <ulm>	"EAPI 1 and 2 are now banned.  This ban should not only be limited to new ebuilds, but should be extended to include updating EAPIs in *existing* ebuilds."
Mar 11 15:53:13 <ulm>	plus dilfridge's suggestion above
Mar 11 15:53:19 <rich0>	ulm: ++ for now
Mar 11 15:53:27 <rich0>	We can revisit if something comes up.
Mar 11 15:53:36 <dberkholz>	this feels like we're getting too specific
Mar 11 15:53:40 <rich0>	Seriously, we need to get to the whitespace ban before we run out of time!  :)
Mar 11 15:53:44 <dilfridge>	lol
Mar 11 15:53:52 <blueness>	okay the motion is: "EAPI 1 and 2 are now banned.  This ban should not only be limited to new ebuilds, but should be extended to include updating EAPIs in *existing* ebuilds.  In case of non-maintainer commits to fix dependencies, EAPI=0 ebuilds may be updated to EAPI=1 to keep the changes at a non-intrusive level, as a temporary workaround."
Mar 11 15:54:17 *	ulm yes
Mar 11 15:54:20 *	rich0 yes
Mar 11 15:54:25 *	dilfridge yes
Mar 11 15:54:26 *	blueness yes
Mar 11 15:54:28 <dberkholz>	no, way too specific
Mar 11 15:54:41 <blueness>	WilliamH, ???
Mar 11 15:54:56 <dberkholz>	what does temporary even mean, does that guarantee someone's going to come back and fix it
Mar 11 15:54:59 *	WilliamH is reading
Mar 11 15:55:22 <rich0>	temporary = not eternal
Mar 11 15:55:24 <dilfridge>	dberkholz: in this context it's more or less a declaration of intent...
Mar 11 15:55:47 <dilfridge>	this is about the most restricted exception that I could come up with
Mar 11 15:55:52 <rich0>	I don't have a problem with the specificity - this isn't the last meeting of the council ever and we can deal with issues that arise
Mar 11 15:55:55 <ulm>	dberkholz: if there are no EAPI 0 ebuilds left, the workaround will end
Mar 11 15:56:04 <blueness>	even without WilliamH vote, it passes
Mar 11 15:56:19 <ulm>	or if the sun expands to a red giant, if that will happen earlier ;)
Mar 11 15:56:31 <dilfridge>	Dalek invasion.
Mar 11 15:56:47 <blueness>	we need to move on to the other issues
Mar 11 15:56:51 <dberkholz>	i'd just define that a banned EAPI means that no new ebuilds or backports are allowed, and in-place edits are discouraged
Mar 11 15:56:58 <dberkholz>	but then again i'm not the chair =)
Mar 11 15:57:15 <blueness>	dberkholz, chairs don't drive discussions ;)
Mar 11 15:57:50 <rich0>	driving discussions isn't always a bad thing...  :)
Mar 11 15:58:01 <ulm>	blueness: by robert's rule, you have to admit us to the floor ;)
Mar 11 15:58:08 <blueness>	yes
Mar 11 15:58:22 <blueness>	its just hard in irc because of timing
Mar 11 15:58:30 *	dilfridge never got to know that robert
Mar 11 15:58:38 <WilliamH>	lol
Mar 11 15:58:48 <blueness>	are we done with this issue?
Mar 11 15:59:02 *	rich0 is remined of attack plan R, R as in Robert...
Mar 11 15:59:08 <blueness>	next: Make all cosmetic repoman warnings fatal
Mar 11 15:59:21 *	WilliamH abstains
Mar 11 15:59:23 <WilliamH>	for the record
Mar 11 15:59:31 <blueness>	WilliamH, okay noted WilliamH 
Mar 11 15:59:35 <WilliamH>	that was for previous issue
Mar 11 15:59:49 <blueness>	WilliamH, understood
Mar 11 16:00:10 <blueness>	okay so this comes from patrick, and he wants all repoman cosmetic warnings to be fatal
Mar 11 16:00:26 <blueness>	discussion?
Mar 11 16:00:44 <ulm>	I've seen way too many false positives for both whitespace and quoting issues, to make these warnings fatal
Mar 11 16:00:53 <rich0>	The only specific suggestion I'd entertain was unused local useflag descriptions in metadata.xml, but I'm not sure if that has any risk of false positives.
Mar 11 16:01:01 <ulm>	fatal for use flag descriptions is fine
Mar 11 16:01:28 <blueness>	i agree with ulm, too many false positives but use flags is fine
Mar 11 16:01:31 <rich0>	I'm also fine with devs forcing that situation anyway if the removal is only temporary.
Mar 11 16:02:02 <ulm>	e.g. patches or config files inlined in here-documents are bound to produce false whitespace warnings
Mar 11 16:02:14 <blueness>	ulm, good point
Mar 11 16:02:19 <dilfridge>	how about this:
Mar 11 16:02:45 <dilfridge>	"make all repoman warnings where with current portage tree no false positives are known fatal"
Mar 11 16:02:59 <blueness>	not sure about that
Mar 11 16:03:04 <rich0>	I think that is pretty broad.
Mar 11 16:03:08 <blueness>	"no false positives" might be vague
Mar 11 16:03:22 <ulm>	dilfridge: that would include -j1
Mar 11 16:03:23 <rich0>	That includes deprecated eclasses, etc.
Mar 11 16:03:41 <rich0>	Warnings are warnings for a reason.
Mar 11 16:03:42 <dilfridge>	true, makes no sense.
Mar 11 16:03:55 <rich0>	Devs need to use their brains.
Mar 11 16:04:18 <ulm>	must we vote about this at all?
Mar 11 16:04:28 <blueness>	if they didn't then we'd just write an ebuild writing utility
Mar 11 16:05:00 <blueness>	ready for the vote?
Mar 11 16:05:02 <ulm>	who in his right mind would see a use flag description warning and not fix it?
Mar 11 16:05:10 <dilfridge>	we could just make an informal request to the portage team to turn the screw in future releases
Mar 11 16:05:22 <blueness>	ulm, i don't always on my overlay when i copy a package form the tree
Mar 11 16:05:43 <ulm>	blueness: yeah, in that situation it makes some sense
Mar 11 16:06:04 <rich0>	Council to repoman: we're tired of being the only ones made to dance...
Mar 11 16:06:04 <blueness>	i only want to change one ebuild, and keep everything else the same, you get the idea
Mar 11 16:06:45 <blueness>	i'm getting the sense the council isn't for this ... no voices in favor
Mar 11 16:06:55 <rich0>	blueness: good point - as an arch tester you get repoman warnings all the time
Mar 11 16:07:03 <blueness>	yep
Mar 11 16:07:11 <blueness>	i did my share of that
Mar 11 16:07:58 <blueness>	okay lets vote: vote yes if you are in favor of "Making all cosmetic repoman warnings fatal" 
Mar 11 16:08:15 *	rich0 no
Mar 11 16:08:17 *	blueness no
Mar 11 16:08:20 *	WilliamH no
Mar 11 16:08:21 *	dilfridge abstains
Mar 11 16:08:40 <blueness>	ulm, dberkholz ???
Mar 11 16:09:18 <blueness>	dberkholz|mob, ulm ???
Mar 11 16:09:30 *	ulm no
Mar 11 16:09:51 dberkholz dberkholz|mob dilfridge dilfridge|mobile dleverton_ DrEeevil 
Mar 11 16:09:59 <blueness>	even without dberkholz the motion fails
Mar 11 16:10:10 <blueness>	okay next item ...
Mar 11 16:10:13 <blueness>	drum roll
Mar 11 16:10:19 <blueness>	Adherence to FHS standards in Gentoo: putting config files int /etc
Mar 11 16:10:49 <blueness>	this also comes from patrick, who wants us to adhere to at least part of FHS standards
Mar 11 16:10:49 <rich0>	I think config files intended to be user-editable should go in /etc.
Mar 11 16:10:55 <blueness>	namely config files in /etc
Mar 11 16:10:57 <blueness>	only
Mar 11 16:11:09 <rich0>	The stuff that was under debate is really just config defaults, intended to be overridden in /etc.
Mar 11 16:11:09 <WilliamH>	Here's the thing.
Mar 11 16:11:23 <WilliamH>	rich0: has it correct.
Mar 11 16:11:42 <rich0>	Every binary has config defaults stored in /usr - you just normally have to edit the C source to change them.
Mar 11 16:11:43 <WilliamH>	These files that are not going in /etc are
Mar 11 16:11:45 <dilfridge>	This kinda conflicts with our policy to stick with upstream. (As much as it pains me.)
Mar 11 16:11:48 <blueness>	(guys, excuse me for a few mins while i run to the washroom)
Mar 11 16:11:59 <WilliamH>	supplied by the packages and are not to be edited by the user.
Mar 11 16:12:01 <rich0>	The newer trend is to move all the constants into a rule file in /usr, and allow overrides in /etc.
Mar 11 16:12:30 <ulm>	config files go to CONFIG_PROTECTed locations like /etc
Mar 11 16:12:36 <ulm>	whereas config defaults are static files and don't need config-protection
Mar 11 16:12:52 <ulm>	so they can go to /usr/share or /lib
Mar 11 16:13:09 <rich0>	Certainly room for user education here, however, as I can see why there is confusion.  IF somebody does edit something in /usr it could get clobbered in an update.
Mar 11 16:13:24 <mgorny>	udev rules are as much config files as .desktop files in /usr/share/applications
Mar 11 16:13:43 <rich0>	If there is stuff config-protected in /usr that might suggest an area for improvement.
Mar 11 16:13:45 <blueness>	back
Mar 11 16:14:06 <rich0>	mgorny: udev rules can be overriden in /etc.  I'm not sure if that is true of .desktop files.
Mar 11 16:14:21 <WilliamH>	mgorny: what the ones are in /lib/udev or /usr/lib/udev are defaults.
Mar 11 16:14:23 <rich0>	I don't really think of desktop files as "configuration" though.
Mar 11 16:14:48 <rich0>	By that logic maybe I want to tweak one of my fonts.  :)
Mar 11 16:14:54 <ulm>	rich0: there are things like /usr/share/gnupg/ and /usr/share/config/, in fact :(
Mar 11 16:15:40 *	Arfrever (~Arfrever@apache/committer/Arfrever) has joined #gentoo-council
Mar 11 16:15:48 <WilliamH>	Patric's goal with this was to force us to move /lib/udev/rules/d/* to /etc/udev/rules.d
Mar 11 16:16:01 <rich0>	I'm flat against doing that with udev rules.
Mar 11 16:16:12 <WilliamH>	s#rules/d#rules.d#
Mar 11 16:16:14 <blueness>	i have to agree
Mar 11 16:16:17 <rich0>	I might feel differently if udev didn't already have an /etc-based solution
Mar 11 16:16:22 <dilfridge>	While a clear separation would be nice, I fear it will force us into an unmaintainable mess of patching.
Mar 11 16:16:23 <ulm>	as long as these files are static they're fine in /lib
Mar 11 16:16:30 <rich0>	we used to do it that way with udev rules
Mar 11 16:16:41 <rich0>	I finally cleaned out the last cruft from that some time ago
Mar 11 16:17:03 <WilliamH>	Also if we did this /usr/lib/systemd/system/* would have to go to /etc/systemd/system/*
Mar 11 16:17:09 *	ulm hopes that nobody will suggest creating /share
Mar 11 16:17:45 *	rich0 ducks
Mar 11 16:18:11 *	WilliamH as against this because it will force a patching nightmare
Mar 11 16:18:51 <blueness>	WilliamH, in eudev i could easily change it from //lib/udev/rules.d to /etc/udev/rules.d but this defeats the stacking structure of config files
Mar 11 16:19:10 <blueness>	we want the default rules to not be touched
Mar 11 16:19:15 <blueness>	these are in /lib/udev
Mar 11 16:19:19 <WilliamH>	blueness: that is what patrick is suggesting. he doesn't like the stacking structure.
Mar 11 16:19:36 <WilliamH>	That's why I'm against this.
Mar 11 16:19:49 <blueness>	WilliamH, the ambiguity hinges on "what is a config file"
Mar 11 16:19:55 <dilfridge>	even KDE has such a stacking structure
Mar 11 16:20:02 <blueness>	are the "default" rules config files
Mar 11 16:20:05 <blueness>	i say no
Mar 11 16:20:08 <ulm>	blueness: no
Mar 11 16:20:10 <rich0>	Honestly, probably best to take FHS issues one-at-a-time
Mar 11 16:20:12 <dilfridge>	(you can define overrides for user config files in /usr)
Mar 11 16:20:16 <ulm>	they are static
Mar 11 16:20:22 <rich0>	I'm sure there are some in the tree, but I'm hard-pressed to think of any big ones.
Mar 11 16:20:45 <rich0>	I don't consider udev/systemd violations of FHS insofar as how they handle config files.
Mar 11 16:21:16 <blueness>	amazingly enough that is one thing systemd does not violate ...
Mar 11 16:21:16 <WilliamH>	rich0: that's why this issue is before us though; Patrick does.
Mar 11 16:21:19 *	blueness ducks
Mar 11 16:21:26 <dberkholz>	i'm not interested in anything we can't get upstream as a build option
Mar 11 16:21:35 <rich0>	WilliamH: well, he's welcome to his opinion  :)
Mar 11 16:21:46 <rich0>	we're not going to ban the practice though
Mar 11 16:22:03 *	WilliamH agrees
Mar 11 16:22:24 <blueness>	okay it sounds to me like the council is against this motion
Mar 11 16:22:35 <rich0>	Hey, if somebody has another example that is causing real problems they can feel free to bring it up, upstream or not.  I just don't see any examples yet.
Mar 11 16:22:40 <blueness>	ready to vote or more discussion?
Mar 11 16:22:51 <rich0>	blueness: stick a fork in it
Mar 11 16:22:54 *	WilliamH ready to vote
Mar 11 16:23:20 <blueness>	okay ... vote for "Adherence to FHS standards in Gentoo: putting config files int /etc".  Vote yes if you want to see all config files in /etc.
Mar 11 16:23:34 *	ulm yes
Mar 11 16:23:41 <WilliamH>	wait
Mar 11 16:23:45 <dilfridge>	hehe
Mar 11 16:23:47 <blueness>	wait
Mar 11 16:24:01 <blueness>	waiting, did i say something ambiguous?
Mar 11 16:24:01 <dberkholz>	i don't think that has enough nuance to it so i'm going to vote no
Mar 11 16:24:02 <ulm>	given that a "config file" is a file intended to be modified by the user
Mar 11 16:24:08 <dilfridge>	one does not simply walk into mordor.
Mar 11 16:24:12 <ulm>	^^ my vote above
Mar 11 16:24:13 <rich0>	Don't like the wording of that.  Ambiguous
Mar 11 16:24:29 <blueness>	sorry guys, my bad, let me reword that given the discussion
Mar 11 16:24:50 <rich0>	How about "Council does not feel additional policy required regarding config files in /etc.  Specific issues not already discussed can be raised in future meetings."
Mar 11 16:25:11 <dberkholz>	i support putting everything in /etc that upstream provides a way, or will accept a way, to put in /etc.
Mar 11 16:25:17 *	WilliamH likes rich0's wording
Mar 11 16:25:32 <blueness>	rich0, i think we need to have something in ther clarifying human editable config files versus default config files
Mar 11 16:25:50 <blueness>	that was the error in my first wording
Mar 11 16:26:15 <rich0>	Council does not feel additional policy required regarding config files in /etc.  In particular packages that place config templates in /usr and allow overriding in /etc are fine. Specific issues not already discussed can be raised in future meetings.
Mar 11 16:26:37 <blueness>	yeah
Mar 11 16:26:41 <WilliamH>	rich0:  s#/usr#/ or /usr#
Mar 11 16:27:03 <blueness>	i was leaning towards patrick's idea until that distinction came to light
Mar 11 16:27:19 <blueness>	okay revote: "Council does not feel additional policy required regarding config files in /etc.  In particular packages that place config templates in /usr and allow overriding in /etc are fine. Specific issues not already discussed can be raised in future meetings."
Mar 11 16:27:30 *	rich0 yes
Mar 11 16:27:31 *	blueness yes
Mar 11 16:27:35 *	dilfridge yes
Mar 11 16:27:41 <ulm>	what about /lib?
Mar 11 16:27:58 <rich0>	Again, if somebody finds some other case they are concerned with they can raise it - upstream-supported or not.  Let's fix actual issues though and not debate theology.
Mar 11 16:27:59 <blueness>	ulm, i think its implicit in there
Mar 11 16:28:02 <ulm>	wasn't it started by files in /lib?
Mar 11 16:28:13 <rich0>	udev rules are in /usr
Mar 11 16:28:23 <blueness>	rich0, no in /lib/udev
Mar 11 16:28:23 <WilliamH>	rich0: no they aren't
Mar 11 16:28:28 <rich0>	ah
Mar 11 16:28:54 <ulm>	so: s#/usr#/lib or /usr/share#
Mar 11 16:29:00 <blueness>	okay waiting for a vote form ulm and dberkholz 
Mar 11 16:29:07 <blueness>	and WilliamH 
Mar 11 16:29:11 <rich0>	"Council does not feel additional policy required regarding config files in /etc.  In particular packages that place config templates in /usr or /lib* and allow overriding in /etc are fine. Specific issues not already discussed can be raised in future meetings."
Mar 11 16:29:25 <blueness>	okay, better
Mar 11 16:29:37 *	ulm yes on rich0's wording
Mar 11 16:29:45 *	WilliamH votes yes on rich0's last wording
Mar 11 16:29:45 *	rich0 yes
Mar 11 16:29:45 *	blueness yes
Mar 11 16:30:07 *	dilfridge yes on rich0's wording
Mar 11 16:30:14 <blueness>	dberkholz, ?
Mar 11 16:30:33 <blueness>	okay rich0 motion carries
Mar 11 16:30:44 <dberkholz>	meh
Mar 11 16:30:52 <blueness>	meh? 
Mar 11 16:30:56 <blueness>	= abstain?
Mar 11 16:31:04 <dberkholz>	i don't care, sure abstain i guess
Mar 11 16:31:08 <blueness>	lol
Mar 11 16:31:14 <dberkholz>	for the record, i don't know if y'all have seen it but here's the fhs 3.0 beta: http://www.linuxbase.org/betaspecs/fhs/fhs/index.html and the announcement: http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs-30-draft-1
Mar 11 16:31:35 <blueness>	dberkholz, interesting, ididn't know that
Mar 11 16:31:38 <blueness>	i'll be sure to look
Mar 11 16:31:51 <blueness>	okay next item
Mar 11 16:31:52 <dberkholz>	it's surprisingly hard to chase down
Mar 11 16:31:57 <blueness>	Bugs assigned to Council
Mar 11 16:32:08 <blueness>	Bug #503382 -  Missing summaries for 20131210, 20140114, and 20140225 council meetings
Mar 11 16:32:10 <willikins>	blueness: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
Mar 11 16:32:11 <dberkholz>	summaries are in progress from my meetings
Mar 11 16:32:15 <blueness>	Bug #477030 - Missing summary for 20130611 council meeting
Mar 11 16:32:17 <willikins>	blueness: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council
Mar 11 16:32:31 <blueness>	so we have some missing summaries
Mar 11 16:32:45 <dberkholz>	i mostly finished them but haven't yet gotten them finalized and committed
Mar 11 16:32:51 <dilfridge>	!note betelgeuse bug 477030
Mar 11 16:32:51 <willikins>	fine, dilfridge
Mar 11 16:32:52 <dberkholz>	we need a secretary again
Mar 11 16:33:20 <ulm>	hadn't someone volunteered for the 20130611 summary?
Mar 11 16:33:39 <blueness>	ulm, i thought it was under control, but i don't know what's going on there
Mar 11 16:34:16 <blueness>	wasn't someone going to chase down betelgeuse?
Mar 11 16:34:36 <ulm>	scarabeus wanted to do this
Mar 11 16:34:39 <blueness>	k
Mar 11 16:35:08 <blueness>	yeah i remember now, but he's awal
Mar 11 16:35:10 <blueness>	awol
Mar 11 16:35:31 <ulm>	so looks there's no progress on the 2013 one, and donnie's summaries are on their way
Mar 11 16:35:37 <blueness>	yep
Mar 11 16:35:46 <blueness>	i'll do mine right after the emeting
Mar 11 16:36:01 <blueness>	okay let's move on to the last item: open floor
Mar 11 16:36:05 <blueness>	any new business?
Mar 11 16:36:54 <blueness>	anything?
Mar 11 16:37:31 <blueness>	if there's nothing else then meeting ajourned
Mar 11 16:37:50 <blueness>	thanks everyone: dberkholz
Mar 11 16:37:50 <blueness>	dilfridge
Mar 11 16:37:50 <blueness>	rich0
Mar 11 16:37:50 <blueness>	scarabeus
Mar 11 16:37:50 <blueness>	ulm 
Mar 11 16:37:50 <blueness>	williamh!
Mar 11 16:37:57 <dilfridge>	hm?
Mar 11 16:38:00 <rich0>	thank you!
Mar 11 16:38:06 <dilfridge>	thank you all too :)
Mar 11 16:38:08 <blueness>	next meeting April 8th i believe
Mar 11 16:38:12 <rich0>	blueness
Mar 11 16:38:13 <rich0>	blueness
Mar 11 16:38:13 <ulm>	blueness: thanks for chairing
Mar 11 16:38:13 <rich0>	blueness
Mar 11 16:38:14 <rich0>	blueness
Mar 11 16:38:14 <rich0>	blueness
Mar 11 16:38:15 <rich0>	blueness
Mar 11 16:38:17 <rich0>	blueness
Mar 11 16:38:27 <blueness>	who chairs?
Mar 11 16:38:29 <blueness>	me again?
Mar 11 16:38:47 <ulm>	no objections ;)
Mar 11 16:38:50 <blueness>	heh
Mar 11 16:38:55 <WilliamH>	heh
Mar 11 16:38:59 <rich0>	blueness: you have May
Mar 11 16:39:03 <rich0>	err april
Mar 11 16:39:13 <rich0>	I can take May/June
Mar 11 16:39:16 <blueness>	k
Mar 11 16:39:18 <rich0>	If nobody else objects
Mar 11 16:39:21 <blueness>	works for me
Mar 11 16:39:35 <blueness>	(and now i must feed my dog who is bouncing off the walls!)