path: root/meeting-logs/20140219.txt

2014-02-19 19:55:24	 *	TomWij opens up the door, toggles the light switch, brings the sandwiches and coffee in, puts the agenda copies on the table, wipes the whiteboard and opens the window for some fresh air.
2014-02-19 19:59:35	 *	zlogene is here
2014-02-19 20:00:28	 *	Pinkbyte is almost ready, making himself a coffee
2014-02-19 20:00:48	 *	wired here as well
2014-02-19 20:01:17	@creffett	let's get this show on the road, then
2014-02-19 20:01:43	@creffett	DrEeevil, Tommy[D], ulm, WilliamH, Zero_Chaos: ping, time for meeting
2014-02-19 20:01:55	@ulm	here
2014-02-19 20:02:01	@Tommy[D]	TomWij: you have the agenda? I want to see it too :)
2014-02-19 20:02:50	 *	creffett waits a couple more minutes in case anyone else is showing up
2014-02-19 20:02:58	@TomWij	Tommy[D]: http://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda
2014-02-19 20:04:02	@Tommy[D]	looks pretty empty :)
2014-02-19 20:04:44	@creffett	then we might not have a 2.5 hour meeting this time
2014-02-19 20:04:49	@creffett	and that's quite all right with me
2014-02-19 20:05:04	 *	creffett bangs his gavel
2014-02-19 20:05:19	@creffett	okay, let's get going, 7/10 is sufficient for a meeting
2014-02-19 20:05:48	@creffett	first up: deprecating/banning EAPIs, this is also going before the council next Tuesday but we might as well have a recommendation
2014-02-19 20:06:29	@creffett	I'm in favor of "ban 1/2, deprecate 0/3" myself
2014-02-19 20:06:38	@ulm	have all of you seen dilfridge's graphs?
2014-02-19 20:06:43	@creffett	I haven't, got a link
2014-02-19 20:06:57	@zlogene	ulm: it is ready? 
2014-02-19 20:06:57	@creffett	?
2014-02-19 20:06:58	@ulm	http://www.akhuettel.de/~huettel/plots/eapi.php
2014-02-19 20:07:37	@creffett	interesting
2014-02-19 20:07:43	@ulm	it's showing approximately exponential decay for old eapis
2014-02-19 20:07:59	@ulm	with a time constant of about 3 years
2014-02-19 20:08:08	@Pinkbyte	EAPI 5 beats EAPI 4 - yes, total win!
2014-02-19 20:08:19	@zlogene	:D
2014-02-19 20:08:21	@TomWij	On the last one EAPI 4 goes down, but then goes flat again; odd.
2014-02-19 20:08:32	@ulm	the council's deprecation of eapis 1 and 2 had no visible influence
2014-02-19 20:08:36	@Tommy[D]	creffett: you want to ban EAPI-2, also it has still thousands of ebuilds using it? sounds way too early to me
2014-02-19 20:08:56	@creffett	Tommy[D]: 2 has already been deprecated by the council
2014-02-19 20:09:05	@creffett	this just forces people to actually make the change instead of ignoring repoman
2014-02-19 20:09:09	@Tommy[D]	creffett: deprecation and baning are 2 different things
2014-02-19 20:09:15	@ulm	it should be clear what a ban means
2014-02-19 20:09:20	@Tommy[D]	creffett: you know you cannot force people on doing something?
2014-02-19 20:09:25	@TomWij	But yeah, I agree we should suggest something along the line ban 1/2 and deprecate 0/3.
2014-02-19 20:09:27	@zlogene	i think we can ban EAPI=1 anyway
2014-02-19 20:09:29	@ulm	does updating an ebuild count?
2014-02-19 20:09:29	@Pinkbyte	Tommy[D], well, it affects only new ebuilds. I think that ADDING new ebuilds with EAPI=2 is weird
2014-02-19 20:09:30	@wired	ban it, if a dev is in a rush they can speedbump to eapi 3
2014-02-19 20:10:12	@creffett	ulm: I believe updating an ebuild will trigger a ban warning
2014-02-19 20:10:16	@Tommy[D]	Pinkbyte: well, if i only read "ban 1/2", then i dont see your "for adding ebuilds" there ;)
2014-02-19 20:10:23	@Pinkbyte	Tommy[D], and upping from 2 to 3 is super easy. 4 and 5 may be tough ones, cause many changes happen
2014-02-19 20:10:23	@TomWij	Tommy[D] (and others): Banning itself is a bit ambiguous, we want to make clear what this means where we compare between an 1) in-place change (eg. DESCRIPTION), 2) rev bump and 3) new ebuild. 
2014-02-19 20:10:35	@creffett	but really, if you're updating an ebuild, it's a minute or two more to change the EAPI
2014-02-19 20:10:57	@TomWij	Unless we really want to mean that none of those three is permitted.
2014-02-19 20:10:59	@creffett	and for most cases, you don't need to actually change the ebuild, unless you're using a function which was banned in a later EAPI
2014-02-19 20:11:09	@Pinkbyte	creffett, i prefer to make repoman fatal only on adding new ebuild(does not matter - revision or version bump)
2014-02-19 20:11:11	@Tommy[D]	creffett: a ban warning is the same as deprecation warning, so what does it add?
2014-02-19 20:11:16	@ulm	creffett: so for example, if I remove a keyword from an old ebuild, then I must update the EAPI?
2014-02-19 20:11:26	@creffett	ulm: valid point
2014-02-19 20:11:28	@Pinkbyte	so, in-place edits with not changing EAPI should be possible
2014-02-19 20:11:33	@ulm	that would be just annoying
2014-02-19 20:11:37	@creffett	Pinkbyte: that's what deprecating is supposed to mean
2014-02-19 20:11:59	@ulm	we should only ban 2) and 3) in TomWij's list above
2014-02-19 20:12:08	@Tommy[D]	creffett: also, when i have EAPI=1, then bumping the EAPI may not be trivial, dont assume a minimal ebuild without defined phases ;)
2014-02-19 20:12:11	@creffett	but either a) that's been thoroughly ignored by devs, or b) people aren't touching the EAPI 1/2 stuff
2014-02-19 20:12:16	@Pinkbyte	creffett, huh? Can not we add new EAPI 2 ebuilds in tree now no matter how silly it is?
2014-02-19 20:12:43	@creffett	Pinkbyte: give me a use case where people should add an EAPI=2 ebuild instead of an EAPI=5 ebuild
2014-02-19 20:12:48	@ulm	Pinkbyte: you'll get a repoman warning
2014-02-19 20:12:50	@Pinkbyte	creffett, i think base-sysrtem are doing this quite a long time
2014-02-19 20:13:00	@Pinkbyte	ulm, warning != fatal
2014-02-19 20:13:03	@Pinkbyte	that's my point
2014-02-19 20:13:27	@Pinkbyte	now all we have in all cases(new ebuilds or just change old one) are warnings
2014-02-19 20:13:27	@Tommy[D]	Pinkbyte: maybe 2 to 3 is easy, but what about 1 to 3? 
2014-02-19 20:13:46	@creffett	Tommy[D]: then the person moves some configure stuff and some patching stuff around
2014-02-19 20:13:49	@creffett	it's not rocket science
2014-02-19 20:13:53	@wired	Tommy[D]: that's just an excuse not to update IMO, it needs to be done
2014-02-19 20:14:15	 *	ulm fears people will take the easy escape and downgrade from 1 to 0
2014-02-19 20:14:18	@Pinkbyte	Tommy[D], not so much changes too. I have done some 0->4 non-trivial bumps - that was a pain, yes
2014-02-19 20:14:35	@creffett	ulm: that's why we're also deprecating 0 (pending an estimate from toolchain on getting everything to EAPI 5)
2014-02-19 20:14:46	@wired	is it boring? yeah. do we want to get those ebuilds on the new EAPI wagon? heck yeah
2014-02-19 20:14:57	@creffett	they're going to have to make the update sooner or later, I see no reason to delay forever
2014-02-19 20:15:13	@creffett	and these _have_ been deprecated for over a year now
2014-02-19 20:15:13	@Tommy[D]	creffett: i know what to do, but i also know that such things need additional time and as you should know, if you have limited time and have the choice, then such forced additional work may be further delayed
2014-02-19 20:15:29	@creffett	so the maintainers have had adequate warning to update
2014-02-19 20:16:03	@Pinkbyte	Tommy[D], it should be done some day. Sooner is better. But, again, updating old ebuilds without touching EAPI should be possible
2014-02-19 20:16:14	@Tommy[D]	creffett: unless you want to step up to do the ebuild conversions yourself, i am against a force/ban/whatever additional
2014-02-19 20:16:27	@Pinkbyte	we do not want to force maintainer to update the whole damn EAPI for just one simple typo fix in ebuild - that would be super-silly
2014-02-19 20:17:20	@wired	a fatal error that can be overridden with --force would be fine IMO
2014-02-19 20:17:22	@Tommy[D]	neither do i want to require the maintainer to do the EAPI dance just to add a minor change with revision bump
2014-02-19 20:17:34	@ulm	BTW, I'm not sure if QA can ban EAPIs
2014-02-19 20:17:36	@ulm	that's council territory
2014-02-19 20:17:53	@creffett	ulm: it is council territory
2014-02-19 20:17:55	@Pinkbyte	wired, --force usage of repoman should be highly discouraged
2014-02-19 20:17:58	@creffett	but we can still ask them nicely
2014-02-19 20:18:06	@creffett	Tommy[D]: why not?
2014-02-19 20:18:09	@ulm	yeah, we can make a recommendation
2014-02-19 20:18:09	@Tommy[D]	wired: and thats another reason to not do it: it makes using that option more common, in the end less care about repoman warnings and finally less QA in the tree
2014-02-19 20:18:18	@wired	Pinkbyte: true, but it's a way out if you really need to commit an ebuild without bumping it
2014-02-19 20:18:20	@zlogene	ulm:but we can suggest recomendation i think
2014-02-19 20:18:25	@creffett	again: the maintainers need to make the change sooner or later
2014-02-19 20:18:26	@wired	Pinkbyte: and a way for us to track what's happening
2014-02-19 20:18:27	@TomWij	(Typing slowly:) If base-system really has some toolchain / eclass reason to keep an old EAPI around they can --force as an exception or something; we're trying to target the main thing here, they will be an exception for a while. And by the time they're the only one left, maybe they've already progressed; or we can help them with getting to EAPI 5 (as it gets more visible to non-base-system people what is
2014-02-19 20:18:27	@TomWij	stuck on lower EAPIs and why).
2014-02-19 20:18:43	@creffett	if you're taking the time to update an ebuild, you can take another minute to change the EAPI
2014-02-19 20:18:51	@Pinkbyte	wired, let's propose this as repoman fatal error with commiting straight to stable - it works only for NEW ebuilds
2014-02-19 20:19:23	@Pinkbyte	so -> want to update some things in old ebuild with old EAPI - fine. Want to commit revbump with old EAPI - go and upgrade it
2014-02-19 20:19:42	@TomWij	+1 on this being a recommendation; and yes, I think some of us try to upgrade an old EAPI ebuild every now and then.
2014-02-19 20:19:46	@Pinkbyte	s/fine/warning/ :-)
2014-02-19 20:19:47	@wired	Pinkbyte: yeah, that's what I have in mind as well
2014-02-19 20:19:49	@Tommy[D]	also keep in mind that the repoman depcrecation warning is way less then a year old and not everyone does read council logs/whatever to catch such things
2014-02-19 20:20:17	@creffett	Tommy[D]: that's not our problem.
2014-02-19 20:21:01	@creffett	also, reading over the repoman code briefly, it doesn't appear that there is a real difference between "banned" and "deprecated" besides the output
2014-02-19 20:21:05	@Tommy[D]	creffett: you argument with "it has been over a year now" and my point is "it may have been a council decision, but enough people may not have it noticed, so its imho no valid argument for banning
2014-02-19 20:22:24	@creffett	Tommy[D]: then what do you want to do?
2014-02-19 20:22:34	@Tommy[D]	creffett: also from the stats i have seen in here, all EAPI versions get reduced numbers every day/week, so it works
2014-02-19 20:22:43	@creffett	Tommy[D]: but it works slowly
2014-02-19 20:22:56	@creffett	really, really slowly
2014-02-19 20:22:57	@Tommy[D]	creffett: and an added ban wont make it faster
2014-02-19 20:23:06	@Pinkbyte	Tommy[D], not totally true
2014-02-19 20:23:09	@Tommy[D]	creffett: if you want it faster, add more manpower to the slow areas
2014-02-19 20:23:17	@creffett	how?
2014-02-19 20:23:46	@creffett	we're already working on removing old EAPIs on our own
2014-02-19 20:23:50	@Pinkbyte	Tommy[D], you want to propose QA team to force upgrading EAPIs all over the tree?
2014-02-19 20:24:03	@Pinkbyte	there would be a lot of noise about such proposal, do not you know?
2014-02-19 20:24:05	@creffett	I've been working through maintainer-needed, we've been talking to Java about migrating from EAPI 1
2014-02-19 20:24:06	@Tommy[D]	if an area is slow, it usually means not enough people in the team, so join the team, do the needed work, but dont request others to do the needed work
2014-02-19 20:24:13	@creffett	disagree
2014-02-19 20:24:22	@Tommy[D]	Pinkbyte: where did i say that?
2014-02-19 20:24:29	@creffett	it is every maintainer's responsibility to help maintain the QA of the tree, or something like that
2014-02-19 20:24:35	@zlogene	Tommy[D]: we have _too_ many slow areas 
2014-02-19 20:24:43	@zlogene	it is impossible 
2014-02-19 20:24:50	@creffett	if people want help, we can help
2014-02-19 20:24:51	@Pinkbyte	Tommy[D], that's the only way for us as QA to do the job. Other way - join to all teams.
2014-02-19 20:24:53	@creffett	I never said that we can't
2014-02-19 20:25:00	@Tommy[D]	Pinkbyte: i see no added value in a ban beside additional noice/annoyence, if you want things to go faster, join those teams with missing manpower and help them
2014-02-19 20:25:06	@Tommy[D]	nothing QA-hat related
2014-02-19 20:25:07	@creffett	but that doesn't prevent us from telling people to actually help out
2014-02-19 20:25:18	@Pinkbyte	but we need to be seven-headed octocats with 48 hours workdays to do all the job
2014-02-19 20:25:24	@Tommy[D]	zlogene: true, but a ban wont fix that
2014-02-19 20:25:25	@creffett	until we ban EAPIs, people won't CARE whether we want them to upgrade
2014-02-19 20:25:42	@ulm	I also think that a ban won't help much in removing old EAPIs
2014-02-19 20:25:54	@TomWij	Tommy[D]: Good point you raise; there are multiple ways for it to be slow; 1) the maintainer leaves it in place and doesn't care about the warning, 2) it is kept in place (slow stabilization) or 3) the package is unmaintained and/or old and just doesn't get touched. What we're doing here would only really affect (1) and make that faster; however, we're not dealing with (2) and (3) here. (Maybe the next
2014-02-19 20:25:54	@TomWij	agenda point helps with (2), and (3) could be fixable by having us pay some more attention to unmaintained/old stuff)
2014-02-19 20:26:03	@ulm	it's mostly old ebuilds sitting around, and they're just not touched
2014-02-19 20:26:06	@Pinkbyte	ok, guys, let's calm down
2014-02-19 20:26:11	@Tommy[D]	creffett: see the stats, all older EAPI versions go down, so people do respect the deprecation and do migrate
2014-02-19 20:26:21	@Pinkbyte	there is one more proposal that we all forget about
2014-02-19 20:26:22	@Tommy[D]	creffett: but you cannot force it and a ban wont help/enforce it
2014-02-19 20:26:32	@Pinkbyte	we are QA - what we should do when we see QA warning?
2014-02-19 20:26:40	@Pinkbyte	yep - we filing the damn bug
2014-02-19 20:26:49	@creffett	and it gets ignored
2014-02-19 20:26:51	@Pinkbyte	and when maintainer is slow? we fixing the damn thing
2014-02-19 20:26:59	@zlogene	Pinkbyte: i know, fix IT!
2014-02-19 20:27:01	@Pinkbyte	why this should be different?
2014-02-19 20:27:02	@zlogene	hehe
2014-02-19 20:27:51	@creffett	Tommy[D]: so you don't want anything banned or deprecated?
2014-02-19 20:29:10	@Tommy[D]	creffett: i see EAPI-1+2 deprecated and all EAPI versions being less used, so things do migrate, when a dev has the needed time, a ban wont increase this
2014-02-19 20:29:34	@creffett	all right then.
2014-02-19 20:29:35	@Pinkbyte	creffett, i rethink that and agreed with ulm said - let's gave banning decision to Council.
2014-02-19 20:29:41	@zlogene	I think we have not enough manpower, so even if we ban anything, we can't do any work more faster.
2014-02-19 20:29:49	@Tommy[D]	imho we can ban an EAPI if there is no user of it left in the tree, but otherwise i see no reason to do that
2014-02-19 20:29:58	@creffett	Pinkbyte: it's their decision, but we can still say "we, QA, would like X banned and Y deprecated"
2014-02-19 20:30:06	@TomWij	Pinkbyte: We're deciding on a recommendation here; as ulm pointed out, it's Council terrain.
2014-02-19 20:30:10	@wired	I'd like more "loud" messages, my recommendation would be to make the first commit of 1/2 eapi ebuilds fail.
2014-02-19 20:30:17	@Pinkbyte	creffett, and for now those who are bored can go and do fun with filing bugs, poking maintainers and fixing the stuff in the end
2014-02-19 20:30:35	@creffett	but right now, if those EAPIs aren't banned, there's not much point in filing the bugs
2014-02-19 20:30:37	@ulm	Tommy[D]: EAPI 1 is very close to being extinct
2014-02-19 20:30:44	@creffett	the maintainer will just say "it's not an error, go away"
2014-02-19 20:31:10	@Tommy[D]	ulm: well, if EAPI-1 is down to zero, a ban is fine by me
2014-02-19 20:31:13	@Pinkbyte	creffett, CFLAGS/LDFLAGS are also not repoman error, so?
2014-02-19 20:31:41	@creffett	Pinkbyte: apples to oranges, in this case
2014-02-19 20:31:53	@creffett	Tommy[D]: could we at least compromise on banning EAPI 1? it only has a couple hundred left in tree
2014-02-19 20:31:54	@Tommy[D]	creffett: please show us your huge amount of developers telling you "EAPI is no error, go away" ;)
2014-02-19 20:32:03	@TomWij	zlogene: Banning is just another more verbal way to say "please do upgrade, it's been around for long enough now"; the positive side is that it can get more people to upgrade, the negative side is that people that --force will become more visible. (As --force is a red light to us)
2014-02-19 20:32:24	@creffett	Tommy[D]: please show me your developers who won't do stuff if they get a repoman error because of banned EAPIs
2014-02-19 20:32:42	@TomWij	creffett: Given an hour has passed, I think we should look at how many people are for and against "recommending a ban".
2014-02-19 20:32:52	@Tommy[D]	TomWij: i dont think that it will help with any upgrade speed, imho it may even make it worse and slow it down
2014-02-19 20:32:53	@creffett	TomWij: fine with me
2014-02-19 20:32:56	@TomWij	s/an hour/an half hour/
2014-02-19 20:33:22	@creffett	all in favor of banning EAPI 1 and/or EAPI 2? (we'll nail down which to recommend if this passes)
2014-02-19 20:33:27	 *	creffett yes
2014-02-19 20:33:31	@Pinkbyte	creffett, python eclasses are deprecated and throws warnings and i see no developer who said(in bugreport, maillists have some complains about new eclasses design) - 'i will stick with my old shiny python eclass, go away with your -r1 cruft'
2014-02-19 20:33:34	@TomWij	(The arguments aren't really improving at this point anymore.)
2014-02-19 20:33:34	@wired	yeah
2014-02-19 20:33:57	@TomWij	creffett: yes
2014-02-19 20:34:14	@Tommy[D]	creffett: well, if i have little time, want to do e.g. a quick bump and get a repoman error, i likely will delay it to anytime in the future and likely to the end of my todo list
2014-02-19 20:34:15	@Pinkbyte	creffett, yes
2014-02-19 20:34:22	@ulm	yes
2014-02-19 20:34:32	@creffett	Tommy[D], zlogene: your votes, please?
2014-02-19 20:34:47	@Tommy[D]	against ban, so no
2014-02-19 20:34:55	@zlogene	yes
2014-02-19 20:35:09	@creffett	6 for, 1 against, 3 missing. Motion passes
2014-02-19 20:35:22	@creffett	all in favor of recommending EAPI 1 be banned?
2014-02-19 20:35:25	 *	creffett yes
2014-02-19 20:35:29	 *	ulm yes
2014-02-19 20:35:29	 *	Pinkbyte yes
2014-02-19 20:35:31	 *	TomWij yes
2014-02-19 20:35:46	 *	wired yes
2014-02-19 20:35:58	 *	zlogene yes
2014-02-19 20:35:58	@Tommy[D]	creffett: wrt your question above: once those couple hundred ebuilds are converted, i am ok with a ban, before i dont see any value, so no again
2014-02-19 20:35:59	@zlogene	just for straight
2014-02-19 20:36:12	@creffett	6 for, 1 against, 3 missing. motion passes.
2014-02-19 20:36:19	@creffett	all in favor of recommending EAPI 2 be banned?
2014-02-19 20:36:24	 *	ulm no
2014-02-19 20:36:25	 *	Pinkbyte abstain
2014-02-19 20:36:29	@Tommy[D]	no again
2014-02-19 20:36:30	 *	creffett yes
2014-02-19 20:36:38	 *	wired yes
2014-02-19 20:36:55	@TomWij	irker707 | [01:00:07] EAPI-stats: EAPI 1: 360 ebuilds ( 0.95 percent) +0 daily +0 weekly -10 monthly diff  
2014-02-19 20:36:55	@TomWij	irker707 | [01:00:08] EAPI-stats: EAPI 2: 3216 ebuilds ( 8.49 percent) +1 daily -14 weekly -84 monthly diff
2014-02-19 20:37:09	 *	TomWij yes
2014-02-19 20:37:27	@creffett	zlogene: your vote?
2014-02-19 20:37:29	 *	zlogene abstain 
2014-02-19 20:37:46	@creffett	3 yes, 2 no, 2 abstain, 3 missing. motion fails to pass
2014-02-19 20:37:56	@creffett	next, deprecation
2014-02-19 20:38:09	@creffett	all in favor of deprecating EAPI 0?
2014-02-19 20:38:17	 *	ulm yes
2014-02-19 20:38:18	 *	Pinkbyte yes
2014-02-19 20:38:21	 *	zlogene yes 
2014-02-19 20:38:23	@ulm	but talk to toolchain
2014-02-19 20:38:27	 *	creffett yes, but want to talk to toolchain
2014-02-19 20:38:38	@TomWij	it's just a warning afaik
2014-02-19 20:38:38	@Tommy[D]	once toolchain has an upgrade path, then yes
2014-02-19 20:38:39	@creffett	mhm
2014-02-19 20:38:40	 *	TomWij yes
2014-02-19 20:39:07	@creffett	wired: your vote?
2014-02-19 20:39:28	@wired	yes
2014-02-19 20:39:30	@wired	srry
2014-02-19 20:39:39	@creffett	7 for, 3 missing. motion carries
2014-02-19 20:39:47	@creffett	all in favor of deprecating EAPI 3?
2014-02-19 20:39:48	 *	creffett yes
2014-02-19 20:39:59	 *	zlogene yes 
2014-02-19 20:40:22	@wired	yes
2014-02-19 20:40:28	@Pinkbyte	out of curiosity - one sec - which year was EAPI 3 introduced?
2014-02-19 20:40:37	 *	ulm abstain
2014-02-19 20:40:52	@Pinkbyte	it seems that was 2010
2014-02-19 20:40:55	 *	TomWij yes
2014-02-19 20:40:56	@Pinkbyte	so, i vote - 'no'
2014-02-19 20:41:02	@ulm	Pinkbyte: https://wiki.gentoo.org/wiki/Project:PMS
2014-02-19 20:41:06	@ulm	bottom of page
2014-02-19 20:41:28	@Tommy[D]	abstain
2014-02-19 20:41:29	@Pinkbyte	ulm, thanks, discovered that myself in EAPI 3 PMS edition in your devspace ;-)
2014-02-19 20:41:47	@creffett	4 yes, 1 no, 2 abstain. motion passes.
2014-02-19 20:42:20	@creffett	next: " Revisit policy on dropping packages to unstable when stabilization takes too long "
2014-02-19 20:43:18	@Tommy[D]	what exactly is the issue/problem?
2014-02-19 20:43:23	@creffett	my opinion is that you should only be dropping stable as a last resort, and I am okay with the solution of dropping all but the stable keywords from an old version of a package (but am opposed to use of KEYWORDS="-* arch" in this context
2014-02-19 20:43:32	@TomWij	(I think the fail on banning EAPI 2 is okay if people consider the amount of ebuilds too big; of course, if it is that big it can become quite an annoyance to put a ban on it. Math shows the rate of migration is similar to that of EAPI 1, but indeed the size on its own is important as well; I voted purely on ratio there.)
2014-02-19 20:43:52	@TomWij	Zero_Chaos: Present?
2014-02-19 20:44:21	@Tommy[D]	creffett: so you now want to suggest a different policy?
2014-02-19 20:45:05	@creffett	Tommy[D]: there were concerns raised about how this ignores the standard removal policy
2014-02-19 20:45:29	@TomWij	creffett: "last resort" is kind of free for interpretation; if the maintainer cares about it, I think it is often kind of a last resort especially when a waiting time is introduced.
2014-02-19 20:45:50	@Tommy[D]	creffett: my question again: what exactly is the issue and which exact policy could be ignored with our last vote?
2014-02-19 20:45:54	@creffett	TomWij: but people were interpreting it as "if I feel like maintainers took too long, I can just drop stuff"
2014-02-19 20:45:56	@creffett	Tommy[D]: sec
2014-02-19 20:46:36	@ulm	we should always keep in mind that removing stable will break things on users' systems for these arches
2014-02-19 20:46:38	@Tommy[D]	creffett: sure about that? our vote was about maintainers, so you did replace arch teams with maintainers there?
2014-02-19 20:46:52	@creffett	Tommy[D]: er, sorry, yes, meant arch teams
2014-02-19 20:47:34	@TomWij	creffett: The policy as we had voted only allowed the maintainer to do so, did you mean "arch teams" in your quotes?
2014-02-19 20:47:40	@TomWij	creffett: Dropping the other keywords from an old ebuild version is something already done, policy doesn't disallow you to do that (and I've already done so in the past, once on gentoo-sources for instance to keep a nvidia-drivers compatible version around); so, I see it is as irrelevant wrt to forming a policy. (It is relevant to the discussion)
2014-02-19 20:47:41	@Tommy[D]	creffett: and yes, it did mean exactly that, what is the issue with dropping an old, outdated, not anymore maintained version?
2014-02-19 20:48:33	 *	creffett sighs
2014-02-19 20:48:41	@Tommy[D]	also reducing keywords adds no benefit, any arch doings its work has newer stable versions, so you wont have users there anyway, so having or dropping a keyword there does not matter
2014-02-19 20:48:41	@creffett	Zero_Chaos could explain the issue better
2014-02-19 20:49:11	@TomWij	creffett: Do we have Zero_Chaos concerns somewhere summarized? Or do you remember them well? One of them was wrt. proper masking and such, which we definitely should make policy if we continue with this; but on the other hand, I think he didn't want to see this policy at all for other concerns.
2014-02-19 20:49:27	@creffett	TomWij: I don't know
2014-02-19 20:49:42	 *	creffett has to run to class, back in 5...if someone could dig out Zero_Chaos's concerns, that would be much appreciated
2014-02-19 20:49:46	@Tommy[D]	creffett: well, he was not able to explain it to me at all, it was more a general "but it breaks something and a policy", but nothing more specific
2014-02-19 20:50:52	@TomWij	ulm: The package.mask for 30 days or so could make the progress for the user more soft, or we need to introduce something PM style to make ARCH -> ~ARCH moves more easy for the user.
2014-02-19 20:50:56	@Tommy[D]	his concerns have been something like "but it breaks stable user experience/tree" also i did not get why or how
2014-02-19 20:51:24	@TomWij	I think we really need Zero_Chaos for this discussion; so, I think we should keep this "in discussion" and schedule a mini-meeting later with Zero_Chaos present.
2014-02-19 20:51:47	@TomWij	Or give Zero_Chaos like X days to formally write down his concerns and reasons so we get a good understanding of them.
2014-02-19 20:51:48	@Tommy[D]	and his point with policy was, that our policy for removing packages in his eyes also applies to removing versions, so he claimed our policy violates the policy for removing packages
2014-02-19 20:52:03	@ulm	TomWij: why should one package mask an ebuild that is still working?
2014-02-19 20:52:21	@ulm	unless there are security issues, but that's already covered by policy
2014-02-19 20:52:25	@Pinkbyte	Tommy[D], you drop the last one "foo" ebuild, cause "foo" arch is slow. Only ~foo ebuilds are left. User, that have installed "foo"-stable version of package will get breakage on upgrade and he had to add package to keywords file 
2014-02-19 20:52:38	<--	creffett (~creffett@gentoo/developer/creffett) has quit (Read error: Operation timed out)
2014-02-19 20:52:43	@Pinkbyte	unless he has ACCEPT_KEYWORDS=~foo of course
2014-02-19 20:53:33	@Tommy[D]	Pinkbyte: well, you have any other solution except letting the package bitrot, eventually fail to even install/function just so the user thinks he has a stable system?
2014-02-19 20:54:04	@Tommy[D]	Pinkbyte: keep in mind that users on minor arches have to add entries to package.keywords for a good amount of packages anyway
2014-02-19 20:54:34	@TomWij	ulm: Well, because it is quite old and can no further be maintained; let's say sun-jdk / sun-jre-bin / sun-jce-bin didn't have security issues, then we would have still masked it at some point in time because we can no longer look after the package (but yet some people use it for some java applets in corporate companies or on bank websites).
2014-02-19 20:55:19	@Pinkbyte	Tommy[D], i know that. But to be honest, i do not see ideal solution there
2014-02-19 20:55:46	@ulm	TomWij: what's the problem with old software, given that it works and has no security issues?
2014-02-19 20:55:53	@Pinkbyte	idealistic one is understaffed but responsive arch team that CONSTANTLY drops "foo" to "~foo" on most of packages
2014-02-19 20:55:57	@Tommy[D]	Pinkbyte: imho dropping stable version/keywords is the best solution we can have without adding to much additional work on maintainers
2014-02-19 20:55:57	@Pinkbyte	for all versions
2014-02-19 20:56:07	@TomWij	Or when there's like 20 sun-* bugs and 20 oracle-* bugs; then you're simply going to say, I have time to fix the new oracle ones but the old sun ones are getting unfixable and I have no further time to look at them at well.
2014-02-19 20:56:10	@Pinkbyte	and respecting revdeps
2014-02-19 20:56:18	@TomWij	Kind of similar like the GNOME team not being able to keep GNOME 2.x around.
2014-02-19 20:56:35	@Tommy[D]	Pinkbyte: it does not matter if it is the arch team or the maintainer, dropped keywords are dropped keywords, result is the same ;)
2014-02-19 20:56:52	@TomWij	ulm: GNOME 2.x breaks over time simply because the libraries get bumped.
2014-02-19 20:57:13	@ulm	TomWij: sure, if it's broken then it's another issue
2014-02-19 20:57:17	@TomWij	New glibc, ...
2014-02-19 20:57:19	@Tommy[D]	that is likely true for all software
2014-02-19 20:57:24	@TomWij	ulm: You need to spot the breakage though.
2014-02-19 20:57:44	@Pinkbyte	Tommy[D], arch team has, well, more generic view of supported packages on their own arch
2014-02-19 20:58:23	@TomWij	I don't think a maintainer intentionally tests the oldest versions of a package on an old arch though; the maintainer doesn't even have the arch, so it rather boils down to the arch team to do that. But the arch team is undermanned ... 
2014-02-19 20:58:40	@Tommy[D]	Pinkbyte: problem is usually, that there is not enough time to do keywording, doing such generic things requires more work, so less likely to happen
2014-02-19 20:58:54	@TomWij	The user does notice it and files some bugs, but they get to stick in a backlog; they depend on the stabilization bug, that stabilization bug that is never dealt with.
2014-02-19 20:59:31	@Tommy[D]	and in the end the bug becomes WONTFIX, the ebuild removed and the result is the same
2014-02-19 20:59:49	@TomWij	Let's say hypothetically, like, GNOME 1.x was still around; how would we deal with that?
2014-02-19 20:59:50	-->	creffett (~creffett@gentoo/developer/creffett) has joined #gentoo-qa
2014-02-19 20:59:50	--	Mode #gentoo-qa [+o creffett] by ChanServ
2014-02-19 20:59:56	@Tommy[D]	just with added bad user experience
2014-02-19 20:59:59	@Pinkbyte	Well, guys, we talked about this last time with exactly the same arguments. Let's conclude - what's our options?
2014-02-19 21:00:22	@Tommy[D]	i still support the vote from last time
2014-02-19 21:00:30	@Pinkbyte	Add maintainer power to drop keywords on some arches from stable to testing after some reasonable amount of time?
2014-02-19 21:00:51	 *	creffett back
2014-02-19 21:00:57	@Pinkbyte	of course, with proper doing stuff on revdeps, etc, etc
2014-02-19 21:01:12	@creffett	I move that we postpone the discussion until we get Zero_Chaos here, since he can articulate his concerns much better than I can
2014-02-19 21:01:20	@TomWij	Pinkbyte: There are a ton of options in the stabilization threads, but it's so wide and lengthy that summarizing them is a bit hectic to do; there's been some options more explored, but those are rather the ones that were the least well received by people on the mailing list. Maybe some of the good options even drown in the bad options...
2014-02-19 21:01:23	@zlogene	creffett: glad to see you again :)
2014-02-19 21:01:32	@wired	creffett++
2014-02-19 21:02:07	@Pinkbyte	TomWij, tbh, i did not see any good options other than supported here. And no ideal, so i am a bit frustrated :'-(
2014-02-19 21:02:09	@TomWij	Similar to Tommy[D], I still support the vote from last time _under the premise_ that we update its wording; but also similar to creffett, I'd like to get Zero_Chaos input on this.
2014-02-19 21:02:24	@Tommy[D]	creffett: please ask him to write a mail, otherwise some will miss his points and then we are again in the same position as today 
2014-02-19 21:02:43	@creffett	Tommy[D]: will do
2014-02-19 21:02:58	@creffett	all right, postponed
2014-02-19 21:03:01	 *	creffett bangs the gavel
2014-02-19 21:03:47	@creffett	next: vapier stabling on experimental arches
2014-02-19 21:03:49	@creffett	do we care?
2014-02-19 21:03:55	@TomWij	(update its wording = make it clear what the conditions are, make sure no words are ambiguous or easily misinterpreted, make sure it is clear what needs to be done [= package.mask 30 days, ...] to not get a plain `rm ...`; but well, updating the wording only applies if we make the policy succeed)
2014-02-19 21:04:07	@Tommy[D]	wait for council decision for the minor arches and stable keywords
2014-02-19 21:04:11	@zlogene	creffett: it is a major problem
2014-02-19 21:04:22	@zlogene	Mike ignore all rules 
2014-02-19 21:04:36	@creffett	technically there's no rule saying you can't stable on an experimental arch
2014-02-19 21:04:42	@creffett	it's just usually considered a waste of time
2014-02-19 21:05:05	@TomWij	creffett: vapier stabling; as far as I am aware of what was going on with that, I think that was not a problem given there is no stage3 yet. This guarantees that users installing it are doing experimental stuff themselves and should expect the possibility of total breakage as part of that.
2014-02-19 21:05:19	@creffett	zlogene: do you have anything to add here?
2014-02-19 21:05:35	@Pinkbyte	creffett, but we should have some rules for this. For example - have stable only for stage building cruft
2014-02-19 21:05:43	@Tommy[D]	TomWij: i dont see any ways of misinterpretation or changed rules, but as you said, lets talk about it next time when/if it is accepted again
2014-02-19 21:05:48	@zlogene	creffett: even if we'll downgrade experemental arches, he will revert our commits again
2014-02-19 21:05:54	@Pinkbyte	TomWij, tbh, we HAVE stages for s390, that was dropped to unstable
2014-02-19 21:06:10	@zlogene	for example see dev-lang/perl ChangeLog 
2014-02-19 21:06:16	@TomWij	What I find more concerning is what happens after that; when it moves out of stable it needs a "go" from whoever needs to be involved in that, such that the stabilization has passed multiple eyes rather than just that of vapier.
2014-02-19 21:06:16	@zlogene	as i already said
2014-02-19 21:06:57	@creffett	except the council hasn't met yet, so we don't have their input on this matter...
2014-02-19 21:07:03	@creffett	dammit fosdem. :P
2014-02-19 21:07:08	@Pinkbyte	err, that question relies on previous one
2014-02-19 21:07:11	@zlogene	TomWij: : vapier does ot responsive 
2014-02-19 21:07:21	@Tommy[D]	i suggest postphone until council has decided on the minor arch keywording situation 
2014-02-19 21:07:38	@Pinkbyte	i mean, we have package-0.19 stable on s390, newer versions are not stabililzed, stabilization bug is closed, our options as maintainer?
2014-02-19 21:07:54	@TomWij	Tommy[D]: Were you present when Zero_Chaos addressed me in #gentoo-dev and #gentoo-qa? Part of it boiled down to there being a misinterpretation by people on the ML; as for the details, it had to do with `rm the.ebuild` versus following a set of proper mask&wait&remove steps.
2014-02-19 21:07:58	@creffett	I second Tommy[D]'s suggestion, I forgot that the council meeting was put off
2014-02-19 21:08:12	@creffett	TomWij: we've already postponed that discussion, please drop it
2014-02-19 21:08:23	@Pinkbyte	drop old version after fixing revdeps and hope that he would not mark new versions stable? Probably without testing as "urgent" matter as tree may be "broken" from his side?
2014-02-19 21:08:46	@Tommy[D]	TomWij: feel free to move this to pm after meeting is done, so we dont mix topic during meeting
2014-02-19 21:08:49	@TomWij	creffett: Yes, I agree with doing that next time; just noting its context, such that Tommy[D] can read up on it if wanted.
2014-02-19 21:09:02	@creffett	okay
2014-02-19 21:09:06	@Pinkbyte	so, probably we should deal minor arches question first and then - talk about vapier behaviour when we have clear decision what we SHOULD do in such cases
2014-02-19 21:09:10	@creffett	yeah
2014-02-19 21:09:27	@creffett	vapier does need to be handled somehow, but first we have to see if the council thinks he's in the wrong
2014-02-19 21:09:42	@TomWij	zlogene: What is "ot" in "vapier does ot responsive"?
2014-02-19 21:09:53	@Pinkbyte	TomWij, probably it was 'not'
2014-02-19 21:10:02	@TomWij	As in "vapier doesn't respond"?
2014-02-19 21:10:08	@creffett	TomWij: yes
2014-02-19 21:10:27	@zlogene	TomWij:  a typo 
2014-02-19 21:10:32	@creffett	if people have ideas for how to deal with unresponsive maintainers like vapier, let me know privately, but for now we'll postpone this
2014-02-19 21:10:40	@Pinkbyte	creffett, agreed. Anyway, he does this stuff on arches where he is the one in arch team, so nobody can say him 'hey, i know that arch, bro, you are not right'. Cause there are no guys who really KNOWS :-/
2014-02-19 21:10:41	@TomWij	Well, I don't think vapier sees a problem in it; so, he probably won't /care unless it forms a real problem.
2014-02-19 21:10:52	@creffett	since the agenda said that this item was waiting for a council decision which hasn't come
2014-02-19 21:11:04	 *	creffett bangs his gavel
2014-02-19 21:11:19	@creffett	next topic: multislot issue
2014-02-19 21:12:00	@creffett	the forum poll broke down (and isn't exactly a representative sample), but we've heard from dirtyepic that he's got no preference about it, and most of the forum didn't care
2014-02-19 21:12:12	@creffett	(also, I _suspect_ the one person who said it would braek things was referring to GRUB)
2014-02-19 21:12:16	@TomWij	(creffett: I think that if there's a real problem wrt vapier that actually affects people, then that should be brought forward such that we have actual material to discuss (and not just vapier as a person); but I don't see the problem on vapier here, given its experimental non-stage3 nature.)
2014-02-19 21:12:33	@ulm	creffett: yeah, 1 user using dynamic slots
2014-02-19 21:12:44	@ulm	and 24 that don't care
2014-02-19 21:12:47	@wired	creffett: seems to me this whole thing should go away to an overlay maintained by people that actually care about it
2014-02-19 21:12:51	@creffett	wired++
2014-02-19 21:13:04	@Pinkbyte	creffett, the trick is gcc ebuild
2014-02-19 21:13:06	@creffett	I move that we ask toolchain to remove the flag, either moving it to an overlay or just dropping it
2014-02-19 21:13:29	@wired	creffett++
2014-02-19 21:13:29	@Pinkbyte	which relies on toolchain eclass and dirtyepic was strongly agains maintaining two eclasses as i understand from his e-mail
2014-02-19 21:13:30	@creffett	I don't really care if they implement microslots, that's their decision, but the flag and the USE-dependent SLOT need to go
2014-02-19 21:13:59	@creffett	Pinkbyte: yeah, but I don't think it is the end of the world to have some special handling in toolchain eclass
2014-02-19 21:14:13	@creffett	heck, they probably could just remove USE=multislot from the tree and leave the eclass as-is
2014-02-19 21:14:20	@TomWij	wired++: Sounds good, let people whom are interested experiment it with overlay / PM forks and what not they deem good; but as long as it is just a hot topic, and users aren't really looking forward to this feature or approach it doesn't make much sense to add it to the Portage tree. (And I don't think it benefits us either, in terms of easier maintenance or what not)
2014-02-19 21:14:25	@creffett	but a package.use.mask isn't acceptable here either, sine the breakage is still there
2014-02-19 21:14:28	@wired	Pinkbyte: I wouldn't mind keeping eclass code in the tree, as long as the ebuilds in the tree have fixed slots
2014-02-19 21:14:41	@ulm	wired ++
2014-02-19 21:15:20	@creffett	so, formal vote: we ask toolchain to remove multislot from the tree, and further we add a policy saying that USE-dependent SLOT values are not permitted in tree
2014-02-19 21:15:22	 *	creffett yes
2014-02-19 21:15:28	 *	wired yes
2014-02-19 21:15:29	@Tommy[D]	so just ask them to drop the exposed feature as in remove the useflag in the main tree, rest could stay as it is not visible/doing harm?
2014-02-19 21:15:48	@creffett	Tommy[D]: I _think_ that is an acceptable solution
2014-02-19 21:16:11	 *	ulm yes
2014-02-19 21:16:23	 *	zlogene yes 
2014-02-19 21:16:26	@Tommy[D]	yes with clarification, that the exposed/visible part as the useflag has to go, internal parts like in the eclass coudl stay
2014-02-19 21:17:15	@creffett	TomWij, Pinkbyte: votes?
2014-02-19 21:17:23	 *	Pinkbyte yes
2014-02-19 21:18:49	 *	creffett twiddles
2014-02-19 21:19:03	 *	wired whistles
2014-02-19 21:19:03	 *	TomWij reads
2014-02-19 21:19:13	 *	TomWij yes
2014-02-19 21:19:27	@creffett	there we go
2014-02-19 21:19:36	@creffett	7 for, 3 missing. motion passes.
2014-02-19 21:19:39	 *	creffett bangs his gavel
2014-02-19 21:19:48	@wired	https://www.youtube.com/watch?v=TbEuMTOA3fo&t=3s
2014-02-19 21:19:52	@creffett	last on the agenda: "  Review GTK USE flag situation as discussed on mailing lists (continued from last month) "
2014-02-19 21:19:59	 *	creffett ducks and covers
2014-02-19 21:20:06	@creffett	the opinion on the list has been mixed
2014-02-19 21:20:14	@TomWij	We've got 40 mins for this one. \o/
2014-02-19 21:20:28	@creffett	my impression is that the GNOME people like their system, most others like the gtk2/gtk3/(gtk4?)/... solution
2014-02-19 21:20:50	@wired	creffett: yeah, that's what I thought too
2014-02-19 21:20:51	@zlogene	wired: i should save it :D
2014-02-19 21:20:57	@Pinkbyte	creffett, and hasufell has already complains on us to council, nice :-/
2014-02-19 21:20:58	@creffett	and I still think the -r200/-r300 is a horrific abuse of slots, but that's a separate issue
2014-02-19 21:21:13	@wired	well, I still need to reply to the thread
2014-02-19 21:21:56	@wired	but my opinion is there are cases where libraries need to be treated differently (like webkit-gtk)
2014-02-19 21:22:01	@creffett	I would like to recommend gtk2/gtk3 (or in this case, gtk and gtk3, to simplify everyone's workload)
2014-02-19 21:22:03	@Tommy[D]	sadly i had not enough time to read the -dev ML, so cant talk about that thread :/
2014-02-19 21:22:12	@creffett	and use a versioned GTK flag
2014-02-19 21:22:16	@wired	still, we should really push for gtk/gtk3{/gtk4,etc}
2014-02-19 21:22:39	@creffett	does anyone have input otherwise before I call a vote?
2014-02-19 21:22:41	@wired	and we really need to steer away from USE="gui"
2014-02-19 21:22:42	@TomWij	creffett: Yeah, and remembering that the RESOLVED INVALID bugs kind of are a similar situation; it seems there definitely are two camps here, and making either camp happy might dissatisfy the other camp. Now the question is what the better choice is; GNOME's view, gtk2/gtk3/... view or inconsistency? (Unless there is some intermediate / different choice that satisfies both) 
2014-02-19 21:22:45	@Pinkbyte	ulm, would it be unfair if i ask you to say other Council members that we actually care about this, no matter what hasufell said? Or am i a bit overreacting? >:-/
2014-02-19 21:22:56	@wired	that use flag reminds me of ubuntu
2014-02-19 21:22:56	@wired	:p
2014-02-19 21:23:10	@ulm	Pinkbyte: will do ;)
2014-02-19 21:23:12	@creffett	wired: heh
2014-02-19 21:23:30	@Pinkbyte	TomWij, inconsistency should be killed with fire, definitely
2014-02-19 21:23:48	@creffett	TomWij: we're going to piss one side or the other off.
2014-02-19 21:23:51	@creffett	let's pick which one
2014-02-19 21:23:52	@ulm	wired: we used to have USE=X for that
2014-02-19 21:24:00	@TomWij	Yeah, and I think wired's statement is inconsistency so I would be against this: "but my opinion is there are cases where libraries need to be treated differently (like webkit-gtk)"
2014-02-19 21:24:01	@ulm	may change with wayland, though
2014-02-19 21:24:16	@TomWij	Unless wired has some good use case for that, but then it complicates things.
2014-02-19 21:24:32	@creffett	I move that we recommend the use of versioned flags (that is, a separate flag for gtk2, gtk3, etc.); we will discuss whether gtk should = gtk2 if this passes
2014-02-19 21:24:35	@wired	ulm: that was gui under cover :P
2014-02-19 21:24:51	 *	creffett yes
2014-02-19 21:25:00	@wired	creffett: I recommend we don't do this specifically for gtk, but establish a baseline for all similar cases
2014-02-19 21:25:31	@TomWij	creffett: Wait ... do we want to "recommend" this or make it policy?
2014-02-19 21:25:34	@creffett	wired: that's vote number 3
2014-02-19 21:25:41	@creffett	TomWij: clarification, make it policy
2014-02-19 21:25:55	@ulm	creffett: what's the concrete vote? o.O
2014-02-19 21:25:56	@wired	and I would like this to be a policy that makes the tree consistent
2014-02-19 21:25:59	@creffett	one sec
2014-02-19 21:26:07	@creffett	okay, I would like to call three votes
2014-02-19 21:26:16	@wired	TomWij: well, there are corner cases that could be treated differently, but those would be exceptions
2014-02-19 21:26:19	@creffett	first, do we make it policy that GTK uses versioned USE flags (gtk2, gtk3, etc.)
2014-02-19 21:26:29	 *	TomWij yes on first.
2014-02-19 21:26:31	 *	wired yes
2014-02-19 21:26:40	@creffett	can I finish? :P
2014-02-19 21:26:57	 *	Pinkbyte yes
2014-02-19 21:27:01	@Tommy[D]	type faster :D
2014-02-19 21:27:02	@creffett	second, do we say that we migrate to gtk instead of gtk2 for the sake of simplicity
2014-02-19 21:27:12	 *	TomWij no on "can I finish?".
2014-02-19 21:27:26	 *	zlogene yes 
2014-02-19 21:27:32	@Pinkbyte	meh, let's be serious
2014-02-19 21:27:33	@creffett	(since there were a lot of complaints about how a lot of stuff uses gtk, but gtk2 is quick to kill)
2014-02-19 21:27:39	 *	Pinkbyte yes on both
2014-02-19 21:27:39	@TomWij	Pinkbyte: Yes, we should.
2014-02-19 21:27:56	@TomWij	I thought they were going one by one, but creffett wants to make it a table.
2014-02-19 21:28:05	@creffett	third, do we make this a general policy: in cases where something can link against one or more versions of a library, there should be a versioned USE flag
2014-02-19 21:28:15	@TomWij	I can't even follow what zlogene is voting on now.
2014-02-19 21:28:23	 *	ulm 1:yes 2:yes 3:no
2014-02-19 21:28:31	@TomWij	^ Let's vote again ulm's way.
2014-02-19 21:28:34	@creffett	TomWij: I just wanted to make it clear what the next votes were going to be, in case people wanted to add those as conditions)
2014-02-19 21:28:36	@ulm	too few cases for 3
2014-02-19 21:29:14	@creffett	fair
2014-02-19 21:29:16	@creffett	votes, please
2014-02-19 21:29:22	@creffett	1 yes 2 yes 3 yes
2014-02-19 21:29:30	 *	Pinkbyte 1:yes 2:yes 3:yes
2014-02-19 21:29:41	@wired	yes, yes, yes
2014-02-19 21:29:51	 *	zlogene 1,2,3: yes 
2014-02-19 21:30:13	@Tommy[D]	abstain 
2014-02-19 21:30:20	 *	TomWij 1:yes 2:no 3:no (More sane per example. / If possible, make it even more neat instead of confusing. / No, we can do this on case by case; vote on this later again.)
2014-02-19 21:30:55	@creffett	I think that's everyone
2014-02-19 21:30:56	 *	creffett tallies
2014-02-19 21:31:03	@wired	on 3: we can always discuss other cases, but I'd like the general policy to be "try to keep them versioned"
2014-02-19 21:31:17	@creffett	1: 6 for, 1 abstain, 3 absent. passes.
2014-02-19 21:31:28	@creffett	2: 5 for, 1 against, 1 abstain. passes.
2014-02-19 21:31:43	@creffett	3: 4 for, 2 against, 1 abstain. passes.
2014-02-19 21:31:51	@creffett	well, that was surprisingly painless
2014-02-19 21:31:54	@TomWij	wired: We could do another vote (4) to recommend people to keep things versioned in generic, but don't make it necessary by policy.
2014-02-19 21:32:14	@wired	policy with exceptions sounds good to me
2014-02-19 21:32:17	@creffett	I could live with making 3) be a recommendation rather than policy, and can be revisited as needed
2014-02-19 21:32:53	@ulm	+1 for making it a recommendation
2014-02-19 21:32:57	@Pinkbyte	+1
2014-02-19 21:33:06	@wired	I'd rather say "please discuss it"
2014-02-19 21:33:09	 *	TomWij yes on recommendation.
2014-02-19 21:33:17	@wired	make discussion a policy
2014-02-19 21:33:18	@wired	:p
2014-02-19 21:33:23	 *	Pinkbyte scares about this some kind of votes on votes
2014-02-19 21:33:31	@creffett	I vote that we vote on voting.
2014-02-19 21:33:36	@wired	awesome
2014-02-19 21:33:51	@ulm	we should discuss if we vote on voting :p
2014-02-19 21:33:57	@creffett	all right, let's just make this a formal vote.
2014-02-19 21:34:00	@Tommy[D]	i vote for the discussion about the votes on voting :p
2014-02-19 21:34:08	@Pinkbyte	serious people do serious business? nah, screw that :-)
2014-02-19 21:34:09	@TomWij	wired: Well, discussion is as easy as bringing it up in the agenda; otherwise we're going have to figure out now in advance if it's going to lead to inconsistency or not, etc...
2014-02-19 21:34:36	@wired	true
2014-02-19 21:34:53	@TomWij	In this GNOME case it does have inconsistency, but for other cases it might not yield inconsistency if the different approach is in use and no people go for the versioned approach.
2014-02-19 21:34:54	@wired	IMO we should keep it as a policy and work our way from there
2014-02-19 21:35:02	@wired	recommendation = do whatever you want
2014-02-19 21:35:03	@wired	:p
2014-02-19 21:35:07	@creffett	do we recommend that cases like this (can link against multiple version of a library) use versioned USE flags (and this should be discussde with the QA team)
2014-02-19 21:35:12	@wired	gnome/gtk3 situation proves this
2014-02-19 21:35:44	@creffett	(this is really hard to word in a non-awkward manner, you know)
2014-02-19 21:35:46	@creffett	anyway, vote please
2014-02-19 21:35:53	@TomWij	creffett: +1
2014-02-19 21:35:58	 *	creffett votes yes, make it a recommendation
2014-02-19 21:36:12	 *	ulm yes
2014-02-19 21:36:22	 *	wired no, I prefer a policy
2014-02-19 21:36:55	 *	Pinkbyte yes, recommendation
2014-02-19 21:37:11	 *	wired with clear wording that there can be exceptions if reasons are properly demonstrated
2014-02-19 21:37:14	@TomWij	I just don't want to see this turn out into changing an already consistent approach into another consistent approach; as you then get an inconsistent migration, just because it is policy. Ofc this won't happen in practice because nobody is crazy, but it's kind of what making this a policy could make happen.
2014-02-19 21:37:23	 *	zlogene yes, recommendation
2014-02-19 21:37:39	@creffett	Tommy[D]: your vote?
2014-02-19 21:37:40	@Tommy[D]	abstain 
2014-02-19 21:37:49	@creffett	okay
2014-02-19 21:38:00	@creffett	5 for, 1 against, 1 abstain
2014-02-19 21:38:05	@creffett	slightly better than the last vote :P
2014-02-19 21:38:06	@creffett	motion passes.
2014-02-19 21:38:15	@creffett	next up: open floor
2014-02-19 21:38:16	 *	creffett first
2014-02-19 21:38:40	@creffett	I've gotten private comments from about half of you telling me that you don't think other people are good fits for the team, should be on the team, etc.
2014-02-19 21:38:43	@creffett	I don't care :)
2014-02-19 21:39:01	@creffett	if you don't like someone on the team, you may work it out with them privately
2014-02-19 21:39:06	@creffett	you are also welcome to leave the team
2014-02-19 21:39:29	@creffett	but if you want to be on the team, you play nice in the sandbox
2014-02-19 21:39:44	@creffett	since I get tired of feeling like I'm the most mature person here when I'm pretty sure I'm one of the youngest.
2014-02-19 21:39:50	 *	creffett done
2014-02-19 21:39:55	@creffett	anyone else have anything for open floor?
2014-02-19 21:40:06	@TomWij	(wired: I would agree with this being policy for new USE flags (some new toolkit or so), but not for existing USE flags; I think there's some difference in the details here, however, if needed we can just vote on this some point in the future. I doubt even whether people would read our QA policy / recommendation when introducing such USE flags; neither do I see us run after the other cases in the tree
2014-02-19 21:40:06	@TomWij	claiming its policy to do it that way, we've got better things to do...)
2014-02-19 21:41:04	@wired	TomWij: yeah, I don't expect current packages to just switch things that are working fine because of us, but if something like the gtk situation occurs I would expect them to properly follow our policy
2014-02-19 21:42:00	 *	creffett twiddles
2014-02-19 21:42:08	@creffett	nobody have issues to bring up?
2014-02-19 21:42:29	@wired	I'm good
2014-02-19 21:42:36	 *	creffett has nothing
2014-02-19 21:42:47	 *	Tommy[D] has nothing
2014-02-19 21:43:21	@creffett	ulm, Pinkbyte, zlogene, TomWij: any issues?
2014-02-19 21:43:32	@zlogene	nothing 
2014-02-19 21:43:32	@creffett	(also, audience, you're welcome to bring stuff up right now)
2014-02-19 21:43:33	@ulm	what should be the policy if a package needs gtk, but can link against gtk2 or gtk3
2014-02-19 21:43:46	@ulm	only one use flag needed in that case?
2014-02-19 21:43:58	@creffett	ulm: uhhh
2014-02-19 21:43:58	@creffett	hmm
2014-02-19 21:44:17	@creffett	can you give an example of a package which links against either without caring?
2014-02-19 21:44:17	@TomWij	creffett: Wrt those private messages, I hope people would raise that with the respective persons or bring it out in public if it's for a good enough reason; everyone sees the good and bad in other people, but as long as it's not overly bad in general it be should be fairly well okay. And sometimes even something you might consider bad about another person might be that persons strongest point.
2014-02-19 21:44:19	@wired	ulm: it can link to either?
2014-02-19 21:44:26	@ulm	yep
2014-02-19 21:44:31	@ulm	IUSE="gtk gtk3" plus REQUIRED_USE is awful
2014-02-19 21:44:33	@wired	USE="gtk gtk3"
2014-02-19 21:44:38	@creffett	I would imagine that most packages will depend specifically on one
2014-02-19 21:44:41	@Pinkbyte	ulm, but it's the only way
2014-02-19 21:45:01	@TomWij	We've got some people that may seem AFK, but they then participate to the meeting; we've got other people that take action too fast, but that makes things happen; we've got other people that are too careful, but that's sometimes needed too; etc...
2014-02-19 21:45:01	@Pinkbyte	unless maintainer decides to do only gtk3 for example
2014-02-19 21:45:20	@creffett	ulm: I would imagine that it would make a difference which was linked against
2014-02-19 21:45:23	@creffett	ohh
2014-02-19 21:45:25	@creffett	I get it
2014-02-19 21:45:36	@creffett	REQUIRED_USE.
2014-02-19 21:45:46	@Pinkbyte	real world example - net-analyzer/nmap
2014-02-19 21:45:58	@creffett	ooh
2014-02-19 21:46:10	@ulm	but we have another policy that REQUIRED_USE should only be used if a pkg has reverse dependencies
2014-02-19 21:46:11	@Pinkbyte	can link on gtk2,gtk3,qt4 but no more than one of them(or neither)
2014-02-19 21:46:19	@creffett	wait, nmap has a graphical option?
2014-02-19 21:46:23	@creffett	huh.
2014-02-19 21:46:37	@Pinkbyte	meh, blame my stupidness
2014-02-19 21:46:41	@Pinkbyte	wireshark, of course
2014-02-19 21:46:52	@creffett	ulm: we do?
2014-02-19 21:46:59	@Pinkbyte	creffett, and yes, nmap has gui, but only GTK-2 one iirc
2014-02-19 21:47:37	@ulm	creffett: http://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags
2014-02-19 21:48:08	@creffett	ulm: I don't read that as saying "only with revdeps"
2014-02-19 21:48:37	@ulm	"In some exceptional cases, above policy would break reverse USE dependencies. To avoid this, the ebuild can specify allowed USE flag combinations with REQUIRED_USE (available in EAPI 4)."
2014-02-19 21:48:44	@creffett	also, right now, qt stuff is using ^^(qt4, qt5) with no problems
2014-02-19 21:49:14	@ulm	that would have been my next question, how does qt handle it
2014-02-19 21:49:20	@creffett	ulm: that's saying "if it breaks revdeps use REQUIRED_USE" but I don't read it as meaning "only use REQUIRED_USE with revdeps"
2014-02-19 21:49:27	@creffett	Pinkbyte: any input on this as a QT guy?
2014-02-19 21:49:38	@Pinkbyte	ulm, REQUIRED_USE is used in tree not only in case of breaking revdeps, but also when package has conflicting build-time options
2014-02-19 21:49:56	@Pinkbyte	creffett, no complains from overlay/in-tree ebuild users
2014-02-19 21:50:06	dilfridge	please dont mandate any REQUIRED_USE, it breaks --autounmask
2014-02-19 21:50:07	@creffett	^^ sufficient for me
2014-02-19 21:50:22	@creffett	dilfridge: but it's basically the only way to deal with mutually exclusive USE flags
2014-02-19 21:50:33	@ulm	Pinkbyte: it will be annoying for users if there are too many REQUIRED_USE in the tree
2014-02-19 21:50:37	@Pinkbyte	dilfridge, other options for conflicting USE-s?
2014-02-19 21:50:52	dilfridge	it's much saner to just have one useflag override another in a defined way
2014-02-19 21:50:55	dilfridge	imho
2014-02-19 21:50:55	@ulm	see the Note below in the devmanual
2014-02-19 21:51:02	@creffett	yes, I see the note
2014-02-19 21:51:05	@Tommy[D]	i also prefer to keep the amount of REQUIRED_USE as low as possible, as it raises the amount of work on users side
2014-02-19 21:51:09	@creffett	but I'm open to better ideas
2014-02-19 21:51:12	dilfridge	I would even recommend to deprecate REQUIRED_USE in a future EAPI again
2014-02-19 21:51:13	@ulm	"Note: In order to avoid forcing users to micro-manage flags too much, REQUIRED_USE should be used sparingly. Follow the normal policy whenever it is possible to do a build that will presumably suit the user's needs."
2014-02-19 21:51:17	@Pinkbyte	ulm, true. But hiding things from user applying some default when both USE are disabled/enabled is sometimes even worse
2014-02-19 21:51:46	@creffett	I mean, the other option I see is preferring latest gtk USE flag by default and printing a message saying "you picked both but only one allowed, defaulting to gtk3"
2014-02-19 21:51:55	@ulm	dilfridge: it has its use cases, but should be used sparingly
2014-02-19 21:52:01	@creffett	but the whole point of REQUIRED_USE is to get around that sort of thing
2014-02-19 21:52:02	@Tommy[D]	Pinkbyte: you can still einfo your settings to the user
2014-02-19 21:52:10	@Pinkbyte	ulm, it makes a beatiful mess in DEPEND syntax that blows my mind. When we are talking about two USE-flags - it's ok
2014-02-19 21:52:11	dilfridge	... and in a future EAPI replace it with something like "WARN_USE" combined with a message
2014-02-19 21:52:21	@Pinkbyte	when they are three, four, infinity - it's huge, massive PITA
2014-02-19 21:53:27	@ulm	getting USE flags right with REQUIRED_USE is a NP complete problem, BTW ;)
2014-02-19 21:53:33	@creffett	I personally am okay with the use of REQUIRED_USE to indicate conflicting flags
2014-02-19 21:54:09	@Pinkbyte	ulm, we can use REQUIRED_USE with USE-enabled default
2014-02-19 21:54:15	@Tommy[D]	ulm: if you say it needs gtk, the only thing on userside is choosing, i would suggest to select the upstream preferred by default and adding a useflag for the other one to choose as alternative
2014-02-19 21:54:35	@Pinkbyte	ulm, so, things are not THAT bad
2014-02-19 21:55:03	@Pinkbyte	but some badness still happens, yes. user doing USE="gtk gtk3" in make.conf - and screwed
2014-02-19 21:55:17	@creffett	do we need a decision on this now, or are we okay with putting it off until later?
2014-02-19 21:55:32	@ulm	creffett: I don't need a decision
2014-02-19 21:55:40	@creffett	all right
2014-02-19 21:55:46	@ulm	just wnated to make you aware that this problem exists
2014-02-19 21:55:52	@ulm	*wanted
2014-02-19 21:56:09	@creffett	mhm, I'm aware, but I think this gets at a bigger issue of REQUIRED_USE in general
2014-02-19 21:56:16	@creffett	and I don't want to open that one up right now ;)
2014-02-19 21:56:23	@Pinkbyte	creffett, let's clarify is any change are going to happen from GNOME team. And if they asks - let's speak about this with all pros and cons.
2014-02-19 21:56:48	@creffett	Pinkbyte: we've made a policy, so yes, we expect them to follow it
2014-02-19 21:57:34	 *	creffett will handle the meeting notes and announcements tonight
2014-02-19 21:57:42	@creffett	all in favor of closing the meeting?
2014-02-19 21:58:47	@creffett	glad you all agree
2014-02-19 21:58:47	@wired	++
2014-02-19 21:58:49	 *	creffett bangs the gavel
2014-02-19 21:58:49	@Tommy[D]	another vote :D
2014-02-19 21:58:51	@creffett	bye
2014-02-19 21:58:52	@creffett	:P
2014-02-19 21:58:53	@Tommy[D]	yes :)
2014-02-19 22:00:01	@zlogene	good night to all :)
2014-02-19 22:00:09	@TomWij	Well, we already had the vote last time; and since it is 22:00 now, the meeting is closed. :D
2014-02-19 22:00:36	 *	TomWij mumbles "right on time!".
2014-02-19 22:01:17	@Pinkbyte	TomWij, cheater! :-). Anyway, thanks guys, it was interesting(as usual).
2014-02-19 22:01:57	@zlogene	wow, 01.07. Time go in bed :p
2014-02-19 22:01:58	@Pinkbyte	creffett, as you are still here, KDE meeting will be tomorrow?
2014-02-19 22:02:23	@creffett	Pinkbyte: yes
2014-02-19 22:02:31	@creffett	I may be a little late to it, though...should warn the team
2014-02-19 22:02:59	@zlogene	creffett: you are busy man :) 
2014-02-19 22:03:09	@ulm	hm, gtk3 isn't even a global USE flag
2014-02-19 22:03:39	@ulm	used by 27 packages
2014-02-19 22:03:39	@Pinkbyte	ok, maybe i will be as a guest. I look like wandering from meeting to meeting, when i need to sit and appoint the damn Qt one :-(
2014-02-19 22:04:48	 *	TomWij wonders if Zero_Chaos is doing another awesome presentation.
2014-02-19 22:14:02	@creffett	so, my policy changes are "use=multislot dies" "changes to gtk flags" and "general recommendations about versioned flags"
2014-02-19 22:14:04	@creffett	did I miss anything?
2014-02-19 22:15:43	@creffett	and "we recommend eapi 1 banned, 0/3 deprecated"
2014-02-19 22:17:02	@ulm	that's what I remember, too
2014-02-19 22:18:17	@TomWij	Yeah, four agenda items; one delayed, the 3 other you covered; nothing in the open floor afaik, that should be it.