Import QA team meeting logs.

https://dev.gentoo.org/~tomwij/files/qa/meetings/gentoo-qa-team-meeting-log-20140219.txt
https://dev.gentoo.org/~tomwij/files/qa/meetings/gentoo-qa-team-meeting-log-20140319.txt
https://dev.gentoo.org/~tomwij/files/qa/meetings/gentoo-qa-team-meeting-log-20140326.txt
https://dev.gentoo.org/~tomwij/files/qa/meetings/gentoo-qa-team-meeting-log-20140416.txt
https://dev.gentoo.org/~tomwij/files/qa/meetings/gentoo-qa-team-meeting-log-20140423.txt
https://dev.gentoo.org/~pinkbyte/files/qa/meetings/gentoo-qa-team-meeting-log-20141203.txt
https://dev.gentoo.org/~pinkbyte/files/qa/meetings/gentoo-qa-team-meeting-log-20150218.txt

7 files changed, 3201 insertions, 0 deletions

diff --git a/meeting-logs/20140219.txt b/meeting-logs/20140219.txt
new file mode 100644
index 0000000..ed8d3b2
--- /dev/null
+++ b/meeting-logs/20140219.txt
@@ -0,0 +1,628 @@
+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.
diff --git a/meeting-logs/20140319.txt b/meeting-logs/20140319.txt
new file mode 100644
index 0000000..1679b88
--- /dev/null
+++ b/meeting-logs/20140319.txt
@@ -0,0 +1,144 @@
+2014-03-19 20:04:29	@wired	ohai?
+2014-03-19 20:06:11	 *	Pinkbyte stares on creffett
+2014-03-19 20:06:38	@Tommy[D]	[01:03:00] <creffett> I can't make tomorrow's meeting at all (or if I can, I will be rather late), I have an exam at the time
+2014-03-19 20:07:21	 *	zlogene is here
+2014-03-19 20:07:47	@Pinkbyte	ok
+2014-03-19 20:07:52	 *	Pinkbyte stares on TomWij
+2014-03-19 20:07:59	@zlogene	but busy with stydyin too
+2014-03-19 20:08:00	@Pinkbyte	Deputy Lead, your word?
+2014-03-19 20:08:17	 *	TomWij is here.
+2014-03-19 20:08:55	@TomWij	https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda
+2014-03-19 20:08:58	@TomWij	!herd qa
+2014-03-19 20:09:00	willikins	TomWij: (qa) (Gentoo Quality Assurance) is not a herd. For a semi complete listing of people on that team visit http://www.gentoo.org/proj/en/qa
+2014-03-19 20:09:09	@TomWij	Right, this thing again; moment... :D
+2014-03-19 20:09:27	@Tommy[D]	!expn qa
+2014-03-19 20:09:29	willikins	Tommy[D]: qa = (private)
+2014-03-19 20:09:31	@zlogene	TomWij: qa is private anyway :D 
+2014-03-19 20:09:34	@Pinkbyte	)))
+2014-03-19 20:10:09	@TomWij	creffett, patrick, Pinkbyte, TomWij, Tommy[D], ulm, WilliamH, wired, Zero_Chaos, zlogene: Everybody here?
+2014-03-19 20:10:18	 *	wired o/
+2014-03-19 20:10:22	 *	zlogene is here
+2014-03-19 20:10:34	@TomWij	bonsaikitten: Here?
+2014-03-19 20:10:35	@Pinkbyte	\o/
+2014-03-19 20:11:54	@TomWij	If I see correctly Chris, Patrick, Ulrich, William and Rick are absent at this point.
+2014-03-19 20:12:21	@TomWij	Anyone wants to do the meeting; if not, I guess I'll take it on my plate (though I'm certainly not used to it).
+2014-03-19 20:13:33	@zlogene	4 of 10
+2014-03-19 20:13:35	@zlogene	hmm
+2014-03-19 20:14:10	@Pinkbyte	no quorum at all, i am for reassigning meeting time
+2014-03-19 20:14:31	 *	WilliamH is here late
+2014-03-19 20:14:36	@wired	yeah the stats are not good today, are people out to watch Champions League or sth? :p
+2014-03-19 20:14:54	@zlogene	I am too, as for me i am busy right now 
+2014-03-19 20:14:55	@WilliamH	I'm fine with reassigning meeting time too.
+2014-03-19 20:14:56	@TomWij	6 of 10; 6 here, 4 absent; yeah, maybe we can just discuss the first agenda point.
+2014-03-19 20:15:01	@TomWij	"Rotating meeting times/other ways to get everyone to be able to make a meeting"
+2014-03-19 20:15:03	@Tommy[D]	maybe the rest is watching Chris? :D
+2014-03-19 20:15:37	@zlogene	!seen creffett 
+2014-03-19 20:15:37	willikins	zlogene: creffett was last seen 16 hours, 37 minutes and 56 seconds ago, joining #gentoo-dev
+2014-03-19 20:15:46	@Tommy[D]	i see no point in chaning the meeting time to a different time where less people can make it
+2014-03-19 20:15:56	@WilliamH	I thought I saw him say he has an exam or something
+2014-03-19 20:16:03	@Tommy[D]	zlogene: he wrote around 19 hours ago, that he cannot make it
+2014-03-19 20:16:40	@Pinkbyte	well, current time is not ideal for me, but i doubt that we could choose better one that fits everybody
+2014-03-19 20:16:47	@TomWij	Rick and Patrick consistently can't make it, afaik; and with the time shift, it's a problem for Chris too. So, maybe we should set up a whenisgood to figure out better times?
+2014-03-19 20:16:59	@WilliamH	Right, I think we are spread pretty far across time zones?
+2014-03-19 20:17:18	@Tommy[D]	TomWij: we did already have a setup there and this was afaik the best time to get most people on board
+2014-03-19 20:17:50	@Tommy[D]	you cant get everyone together, if some are in europe, someone in china and somone in the west of the us
+2014-03-19 20:18:16	@TomWij	Yeah, in China it's 03:18 now or so.
+2014-03-19 20:18:19	@wired	perhaps we can alternate our meeting times
+2014-03-19 20:18:29	@zlogene	!time Pinkbyte 
+2014-03-19 20:18:30	willikins	zlogene: Europe - Moscow - Wed Mar 19 23:18 MSK
+2014-03-19 20:18:40	@WilliamH	!time williamh
+2014-03-19 20:18:41	willikins	WilliamH: America - Chicago - Wed Mar 19 14:18 CDT
+2014-03-19 20:18:53	@Tommy[D]	wired: other times mean even less people can make it there, so even higher chance we dont even get half of the team to the meeting
+2014-03-19 20:18:54	@zlogene	!time Zlogene 
+2014-03-19 20:18:54	willikins	I don't know where zlogene is, (s)he should use !time set <Continent>/<City> to let me know
+2014-03-19 20:19:04	@zlogene	!time zlogene 
+2014-03-19 20:19:04	willikins	I don't know where zlogene is, (s)he should use !time set <Continent>/<City> to let me know
+2014-03-19 20:19:12	@TomWij	wired: Yes, something like two meetings in the same day or in the same week might work.
+2014-03-19 20:19:12	@zlogene	lolwhat? 
+2014-03-19 20:20:09	@wired	and we can always let missing people vote over mail the next day for important issues if we are not enough present
+2014-03-19 20:20:17	@zlogene	in short, i live in Europe/Moscow and curent time is not ok for me 
+2014-03-19 20:20:25	@Tommy[D]	TomWij: how do you want to organize that? especially, since the first group is then expected to vote without the comments from the second one
+2014-03-19 20:20:25	@wired	killed that sentence \o/
+2014-03-19 20:20:52	@wired	we can make a second attempt to find a good time using that website
+2014-03-19 20:21:06	@wired	just in case people have different schedules now
+2014-03-19 20:21:46	@WilliamH	wired: I'm not sure anyone's schedules are going to be that different, I think we are just spread too far across timezones...
+2014-03-19 20:21:47	@TomWij	Tommy[D]: Voting over mail might be an option.
+2014-03-19 20:21:56	@Tommy[D]	wired: unless someone moved his home, i would not expect it :)
+2014-03-19 20:22:32	@wired	well, my schedule is even lighter these days
+2014-03-19 20:22:50	@TomWij	Like, have the two meetings; then after that the motions are spread by mail and everyone mails their response within 24h or so.
+2014-03-19 20:22:57	@wired	for one, although I had a flexible schedule to begin with
+2014-03-19 20:22:57	@Tommy[D]	TomWij: we could have a majority meeting, get the log to the alias and allow the rest to vote, if needed, via mail
+2014-03-19 20:23:11	@wired	Tommy[D]: that's what I was thinking as well
+2014-03-19 20:23:14	@wired	for important stuff anyway
+2014-03-19 20:24:10	@Pinkbyte	Tommy[D], yeah, at least more coverage for voting is good. Quorum is sufficient, but, hell, missing guys should also have opportunity at least to vote
+2014-03-19 20:24:10	@zlogene	!rime Europe/Moscow 
+2014-03-19 20:24:17	@zlogene	!time Europe/Moscow 
+2014-03-19 20:24:17	willikins	zlogene: Europe - Moscow - Wed Mar 19 23:24 MSK
+2014-03-19 20:24:30	@zlogene	!botsnack 
+2014-03-19 20:24:30	@TomWij	Hmm, anyone knows how to pull IRC statistics; could see when people talk here often and deduce activity from that.
+2014-03-19 20:24:30	willikins	zlogene: schweet!
+2014-03-19 20:24:43	@wired	TomWij: I have stats for gentoo-dev
+2014-03-19 20:24:53	@Pinkbyte	zlogene, if you want to set time in willikins, you are doing it wrong ;-)
+2014-03-19 20:25:04	@Pinkbyte	i mean, timezone, of course )
+2014-03-19 20:25:16	@wired	http://pages.linuxized.com/stats/gentoo-dev.html
+2014-03-19 20:25:27	@TomWij	wired: Ah, feel free to share; but, I'm thinking along the line of just grepping the individuals and chart their time presence.
+2014-03-19 20:25:27	@Tommy[D]	TomWij: i would be carefull about such stats, i might shortly write a comment/line via IRC, but that should not imply i have an hour or two for a meeting ;)
+2014-03-19 20:26:01	@wired	1664 days xD
+2014-03-19 20:27:05	@Pinkbyte	"Poor bonsaikitten, nobody likes him/her. He/She was attacked 5 times." - i lol'd
+2014-03-19 20:27:26	@TomWij	Tommy[D]: Yeah, needs to be aggregated rather than boolean.
+2014-03-19 20:27:49	@zlogene	Pinkbyte: he reset my timezone again and again :( 
+2014-03-19 20:28:41	@wired	so, lets keep the current meeting time for now and discuss it again over mail?
+2014-03-19 20:29:06	@Pinkbyte	fine by me
+2014-03-19 20:29:28	@Tommy[D]	fine with me
+2014-03-19 20:29:51	@Tommy[D]	zlogene: sure you simply did not set your timezone details with the bot? :)
+2014-03-19 20:31:47	@TomWij	wired: Yes, discussing it on mail gives some room to think this through; the options that I see come up afaik: 1) Another whenisgood to see if schedules have changed. 2) Multiple meetings, though that can be an organization problem (different motions, ...). 3) Alternating time meetings, though a meeting with less persons can be a quorum problem. 4) Keep things the way they are, expect absent people to mail
+2014-03-19 20:31:47	@TomWij	their opinion / comment / votes; though, this is less fair if they do want to actively talk.
+2014-03-19 20:32:22	@wired	I don't like having two meetings, sounds weird.
+2014-03-19 20:32:48	@wired	but lets continue this discussion over mail, we need to talk with all members of the team
+2014-03-19 20:33:53	@zlogene	!time set  Europe/Moscow 
+2014-03-19 20:33:53	willikins	Ok, I'll remember that zlogene is on the Europe/Moscow time zone
+2014-03-19 20:34:08	@zlogene	Pinkbyte: thanks for note 
+2014-03-19 20:34:39	@TomWij	I count 4 of 6 that vote we discuss this over mail, let's do that then; then we just close this meeting and I guess we can organize another meeting in one or two weeks?
+2014-03-19 20:35:17	@TomWij	Probably want to do the actual planning on when to do that meeting in a week or so after we've got feedback and/or an idea on mail.
+2014-03-19 20:36:06	@wired	oh, we were discussing about dropping this meeting as well? I'm in, just didn't realize it
+2014-03-19 20:36:45	@TomWij	Looking at the other agenda items, there doesn't seem to be anything that important; we need to follow up on the GTK flag issue and Zero_Chaos stable dropping policy feedback, such that we have data on that by next meeting.
+2014-03-19 20:37:34	@wired	I recommend we tentantively set the next meeting date to next week's Wednesday and try to figure out if we want to change it over email the next few days
+2014-03-19 20:37:35	@TomWij	wired: Someone mentioned it early, given the count is low; 6 people are here (with zlogene studying), ...
+2014-03-19 20:38:06	@Tommy[D]	so raise a mail about meeting time and remind Rick about his feedback, i would also suggest to set him a limit like beginning of next meeting for his feedback, so he cannot dely the policy forever
+2014-03-19 20:38:19	@wired	++
+2014-03-19 20:38:52	@TomWij	++
+2014-03-19 20:38:59	@zlogene	+
+2014-03-19 20:39:02	@WilliamH	TomWij: I'm still working on the email for the gtk issue, I'll have it ready for the team to look over before next week.
+2014-03-19 20:39:51	@WilliamH	TomWij: I got your email and the one from creffett; I am going to come up with an email that puts ideas from both of them together.
+2014-03-19 20:40:31	@TomWij	WilliamH: Are you still here? If I remember correctly, were you the person that planned to send a mail regarding the GTK flag issue; how far are we on that? I also remember the GNOME team writing something up, EvaSDK in particular; haven't seen it yet, but I suppose that's intended to be in response of that mail. 
+2014-03-19 20:40:47	@TomWij	Didn't look at the screen while typing that. :D
+2014-03-19 20:41:07	@TomWij	Okay, sounds good; thank you in advance.
+2014-03-19 20:41:24	@WilliamH	TomWij: No problem.
+2014-03-19 20:42:45	@Tommy[D]	TomWij: so will you write the mail about meeting time and the reminder for Rick?
+2014-03-19 20:42:55	@TomWij	Let's close the meeting then; I'll send up a mail based on Tommy's statement, when we meet again depends on whether the mail will cause a change. 
+2014-03-19 20:43:20	@wired	cheers
+2014-03-19 20:44:24	@Tommy[D]	so meeting closed and good evening/whatever it currently is in your timezone :)
+2014-03-19 20:45:06	@wired	2145 here ;p
+2014-03-19 20:45:14	@WilliamH	14:45 here ;-)
+2014-03-19 20:45:21	@TomWij	20:45
+2014-03-19 20:45:28	@zlogene	23.51 
+2014-03-19 20:46:02	@zlogene	ehehe
+2014-03-19 20:46:40	@Tommy[D]	zlogene: you win/loose (choose as you wish), you have the highest number :D
+2014-03-19 20:47:12	@Tommy[D]	!time
+2014-03-19 20:47:12	willikins	Tommy[D]: Europe - Berlin - Wed Mar 19 20:47 CET
+2014-03-19 20:47:21	@Tommy[D]	ah, good, still works :)
+2014-03-19 20:47:59	@zlogene	Tommy[D]: Pinkbyte live in the same timezone with me :D 
+2014-03-19 20:48:28	@Tommy[D]	zlogene: so sadly you have to share your price with him :)
+2014-03-19 20:48:51	@TomWij	The two Tom(my)'s are in the same time zone. ^^
+2014-03-19 20:50:29	@Tommy[D]	TomWij: so you will never have a price for yourself alone either :p
+2014-03-19 20:51:50	@wired	!time
+2014-03-19 20:51:51	willikins	wired: Europe - Athens - Wed Mar 19 21:51 EET
+2014-03-19 20:52:08	@zlogene	!time 
+2014-03-19 20:52:08	willikins	zlogene: Europe - Moscow - Wed Mar 19 23:52 MSK
+2014-03-19 20:52:28	@wired	well I'm a bit to the north atm, but OK
+2014-03-19 20:52:33	@wired	same timezone :p
+2014-03-19 21:25:07	@ulm	sorry I've missed the meeting
+2014-03-19 21:29:26	@zlogene	ulm: don't worry, we could not make meeting
+2014-03-19 21:30:25	@ulm	yeah, because of other slackers like me :/
+2014-03-19 21:30:29	@TomWij	Mail sent.
+2014-03-19 22:53:13	@creffett	ulm: don't worry, I missed it too :P
diff --git a/meeting-logs/20140326.txt b/meeting-logs/20140326.txt
new file mode 100644
index 0000000..c17620a
--- /dev/null
+++ b/meeting-logs/20140326.txt
@@ -0,0 +1,411 @@
+2014-03-26 19:49:57	 *	zlogene is here, already 
+2014-03-26 19:53:11	 *	zlogene take chocolate ice cream with cherry and waiting for meeting start
+2014-03-26 19:53:29	 *	TomWij just ate chocolate and goes for a drink.
+2014-03-26 19:59:40	 *	Zero_Chaos is here
+2014-03-26 20:00:27	@creffett|irssi	k, showtime.
+2014-03-26 20:00:38	 *	ulm here
+2014-03-26 20:00:40	@WilliamH	ok you should get the email
+2014-03-26 20:00:45	@WilliamH	qa team...
+2014-03-26 20:00:57	 *	WilliamH is here
+2014-03-26 20:00:59	 *	TomWij is here
+2014-03-26 20:01:22	 *	Tommy[D] didnt miss his own reminder
+2014-03-26 20:01:32	@creffett|irssi	wired, Pinkbyte, bonsaikitten: you all here?
+2014-03-26 20:01:45	 *	Pinkbyte here
+2014-03-26 20:02:18	@creffett|irssi	close enough.
+2014-03-26 20:02:36	@creffett|irssi	first question: do we want to do rotating meeting times? I know this time doesn't work for everyone
+2014-03-26 20:02:36	@TomWij	(Agenda @ https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda)
+2014-03-26 20:03:11	@Zero_Chaos	creffett|irssi: wednesday are almost always bad for me, especially in the middle of the work day. so I have to vote for rotating meetings.
+2014-03-26 20:03:33	@creffett|irssi	Zero_Chaos: I agree, especially when this summer comes and I actually have a job to keep
+2014-03-26 20:04:14	@creffett|irssi	so how will we want to handle that is the real question--do we want to go for discussion-only during meetings and voting some other way? vote during meetings and if you can't make it too bad? what?
+2014-03-26 20:04:27	@creffett|irssi	(also, I will fire up a whenisgood so we can find another good time)
+2014-03-26 20:04:41	@Pinkbyte	creffett, what about shifting meeting time to saturday or sunday?
+2014-03-26 20:04:41	@Tommy[D]	i disagree, we already checked, when most people have time and even then, see last week, we have problems get enough people together
+2014-03-26 20:04:45	@TomWij	I wouldn't mind if they were rotating, giving everyone a fair chance to attend; though, the only concern I have here is when times get picked where not a sufficient quorum can attend.
+2014-03-26 20:04:54	@Tommy[D]	other times will make it even harder to even get half of qa together
+2014-03-26 20:05:19	@creffett|irssi	Tommy[D]: then what would you prefer we do with the handful of people who can't/rarely can make the current time
+2014-03-26 20:05:27	 *	WilliamH agrees with Tommy[D] 
+2014-03-26 20:05:32	@zlogene	what about make meeting on Saturday/Sunday
+2014-03-26 20:05:35	@zlogene	?
+2014-03-26 20:06:02	@Tommy[D]	creffett|irssi: pretty simple: normal meetings/votes like now and we dont get a majority, let the rest vote via mail within e.g. 48 hours after announcing open vote on the alias
+2014-03-26 20:06:06	 *	WilliamH isn't opposed to a weekend meeting...
+2014-03-26 20:06:17	@ulm	I'm against meeting on weekends too
+2014-03-26 20:06:27	 *	TomWij isn't opposed to a weekend meeting either.
+2014-03-26 20:06:35	@Tommy[D]	weenends is pretty bad, i often cant say when/if i have time then
+2014-03-26 20:07:27	@Zero_Chaos	honestly I have more freetime if we shift this +5-6 hours
+2014-03-26 20:07:28	@creffett|irssi	the issue here is that we pretty effectively span the globe
+2014-03-26 20:07:32	@Tommy[D]	in addition i like it to have sometimes a day for myself without any meetings/work ;)
+2014-03-26 20:07:34	@creffett|irssi	no matter when we pick, someone suffers
+2014-03-26 20:07:34	@Zero_Chaos	but then everyone else is alseep
+2014-03-26 20:08:14	@zlogene	so, i agree with pinkbyte about weekend 
+2014-03-26 20:08:18	@Tommy[D]	creffett|irssi: so the best we can get is like we do now: get the majority together, let the rest vote in addition, if needed for a majority vote
+2014-03-26 20:08:44	@Tommy[D]	we cannot make it right for everyone and shifting times make it very likely we would not even get half of qa team together
+2014-03-26 20:09:27	@creffett|irssi	yeah.
+2014-03-26 20:09:28	@TomWij	creffett|irssi: We could 1) vote right now on making it rotating or not, 2) do a doodle to pick the preferred day of the week and 3) do another whenisgood to see if there is perhaps a better hour than 1900 UTC due to changed schedules.
+2014-03-26 20:09:42	@Tommy[D]	Zero_Chaos: nothing against you personally, but seems like you got the worst timezone together with Patrick 
+2014-03-26 20:09:56	@Pinkbyte	Tommy[D], yep, seems the better decision. And 48h timeframe for voting can be extended a bit. Let's see, we have meeting at wednesday. Let's say, that majority should be there and other should vote till next Monday
+2014-03-26 20:09:57	@creffett|irssi	Tommy[D]: I'm in Zero_Chaos's timezone :P
+2014-03-26 20:10:05	@Zero_Chaos	Tommy[D]: I'm actually the same timezone as creffett|irssi, just I have a job :-P
+2014-03-26 20:10:11	@creffett|irssi	^^
+2014-03-26 20:10:45	@zlogene	!time zlogene
+2014-03-26 20:10:45	willikins	zlogene: Europe - Moscow - Wed Mar 26 23:11 MSK
+2014-03-26 20:11:09	@creffett|irssi	I would like to try another whenisgood just to check if the DST shift (for those affected by it) has opened up a better time
+2014-03-26 20:11:38	@Tommy[D]	Zero_Chaos: even then, if we take you 2 out, we still have 6 out of 10, who can make it, any other time will have even lower numbers and we need 6 to get a majority vote....
+2014-03-26 20:12:04	@creffett|irssi	and for the future, I think our best bet will unfortunately be to have people send in their opinions beforehand if they can't make it, and conduct email votes if we don't have a majority
+2014-03-26 20:12:12	@Zero_Chaos	Tommy[D]: I agree, but it is kinda shitty to plan every meeting to miss 40% of the team.
+2014-03-26 20:12:26	@Zero_Chaos	creffett|irssi: I think possibly voting by list is a good idea.
+2014-03-26 20:12:38	@Tommy[D]	Zero_Chaos: its not good, but still better to plan with 60% missing
+2014-03-26 20:12:59	@Tommy[D]	*still better then to plan with 60% missing
+2014-03-26 20:13:05	@Zero_Chaos	Tommy[D]: rotating meeting times to always catch at least 6 but miss different people wouldn't hurt.
+2014-03-26 20:13:09	@Zero_Chaos	if possible anyway
+2014-03-26 20:13:39	@creffett|irssi	I'll look into that too, if there's a different time which has >=6 on whenisgood then we can consider rotating to that occasionally
+2014-03-26 20:13:48	@Tommy[D]	Zero_Chaos: thats the point: if possible, keep in mind that current schedule was the best matching time for all and we have problems getting a majority at the best time....
+2014-03-26 20:14:28	@creffett|irssi	Tommy[D]: let's see how the whenisgood turns out
+2014-03-26 20:14:35	@Zero_Chaos	accepted
+2014-03-26 20:14:42	@creffett|irssi	next topic.
+2014-03-26 20:14:46	@WilliamH	creffett|irssi: sounds reasonable to me.
+2014-03-26 20:14:57	@creffett|irssi	vapier stabilizing on experimentals: do we care? what do we want to do, if we do care?
+2014-03-26 20:15:04	@Tommy[D]	creffett|irssi: i suggest you create it, send a mail after meeting and we can discuss via mail once its done
+2014-03-26 20:15:15	@Zero_Chaos	creffett|irssi: please provide background
+2014-03-26 20:15:15	@creffett|irssi	Tommy[D]: I was planning on that
+2014-03-26 20:15:23	@creffett|irssi	WilliamH: I think this was yours
+2014-03-26 20:15:26	@creffett|irssi	(the vapier thing)
+2014-03-26 20:15:29	@TomWij	+1 on whenisgood
+2014-03-26 20:15:29	@Tommy[D]	any update from council wrt those arches?
+2014-03-26 20:15:37	@WilliamH	creffett|irssi: Well, if the archs have exp in their profiles we don't have to care.
+2014-03-26 20:15:56	@Zero_Chaos	oh experimental arches?
+2014-03-26 20:15:59	@Zero_Chaos	+1 for don't care
+2014-03-26 20:16:28	@WilliamH	That's the point of the status in profiles.desc
+2014-03-26 20:16:34	@Zero_Chaos	very much so
+2014-03-26 20:16:41	 *	WilliamH isn't sure about dev status
+2014-03-26 20:16:47	@Zero_Chaos	if you are using an experimental profile you get to keep the pieces.
+2014-03-26 20:17:01	@zlogene	what should we do if vapier still stabilize for this? 
+2014-03-26 20:17:09	@Zero_Chaos	and if it ever moves up to a stable profile, less work if they were already following a stabilization policy (of some kind)
+2014-03-26 20:17:11	@zlogene	revert, or no?
+2014-03-26 20:17:17	@WilliamH	zlogene: nothing if the profiles are in the right status
+2014-03-26 20:17:20	@creffett|irssi	zlogene: I'm still unclear if it even matters to us
+2014-03-26 20:17:26	@Pinkbyte	zlogene, as said - if the whole arch profiles are 'exp' - just do not care
+2014-03-26 20:17:34	@zlogene	okay 
+2014-03-26 20:17:39	@Pinkbyte	if repoman -d does not throw warnings - forget about this
+2014-03-26 20:17:48	@TomWij	+1 for don't care; I think I've said earlier that the lack of stage3 makes it experimental to users anyway, and when it gets out of experimental we expect the arch team to properly make sure it is stable.
+2014-03-26 20:18:12	@Pinkbyte	TomWij, the culprit is that some of those arches are not exp, they are dev
+2014-03-26 20:18:13	@Zero_Chaos	sounds like TomWij summed up the majority favor
+2014-03-26 20:18:16	@zlogene	+1 for don't care then 
+2014-03-26 20:18:22	@Zero_Chaos	Pinkbyte: dev we care.
+2014-03-26 20:18:26	@Pinkbyte	i mean arch profiles of course
+2014-03-26 20:18:29	@Zero_Chaos	I think we have to care on dev
+2014-03-26 20:18:33	@creffett|irssi	then what do we do about dev?
+2014-03-26 20:18:44	@Zero_Chaos	creffett|irssi: what specifically was done?
+2014-03-26 20:18:52	@TomWij	Pinkbyte: Some of which arches, did vapier stabilize something like that on dev?
+2014-03-26 20:18:54	@creffett|irssi	Zero_Chaos: ask WilliamH, this was his issue
+2014-03-26 20:19:09	@Zero_Chaos	WilliamH: can you please provide some background on this? I am unfamiliar.
+2014-03-26 20:19:14	@Pinkbyte	TomWij, sh is still in dev, right?
+2014-03-26 20:19:21	@Pinkbyte	and s390
+2014-03-26 20:19:26	@WilliamH	Zero_Chaos: council declared some archis to be unstable then vapier continued stabilizing packages..
+2014-03-26 20:19:34	@zlogene	Pinkbyte: yes 
+2014-03-26 20:20:14	@WilliamH	s390, sh and  (I can't find the other one right now)...
+2014-03-26 20:20:16	@Pinkbyte	to be 'unstable only' if i understand right
+2014-03-26 20:20:21	@Pinkbyte	WilliamH, m68k
+2014-03-26 20:20:22	@Zero_Chaos	WilliamH: the profiles have ACCEPT_KEYWORDS="~arch" right?
+2014-03-26 20:20:29	@Pinkbyte	Zero_Chaos, yep
+2014-03-26 20:20:42	@TomWij	Pinkbyte: Right, I perceived this issue to be about exp only; and the other part, as said above, handled by Council.
+2014-03-26 20:20:54	@ulm	Zero_Chaos: is it enough to have ~arch?
+2014-03-26 20:20:55	@WilliamH	Zero_Chaos: vapier's point was we shouldn't do that but bump the profiles to exp status in profiles.desc
+2014-03-26 20:21:03	@zlogene	Zero_Chaos: ACCEPT_KEYWIRDS="arch ~arch"
+2014-03-26 20:21:06	@ulm	Zero_Chaos: for repoman -d not to complain?
+2014-03-26 20:21:08	@zlogene	*KEYWORDS
+2014-03-26 20:21:10	@Zero_Chaos	then in my head it's masturbation. If you are stabilizing on an arch which lists ACCEPT_KEYWORDS="~arch" then the users will always get ~arch anyway so who cares?
+2014-03-26 20:21:41	@Pinkbyte	Zero_Chaos, well, vapier keeps some machines with overrided ACCEPT_KEYWORDS
+2014-03-26 20:21:56	@Zero_Chaos	ulm: the council said those arches were not stable, so in my head, it's enough that the profiles list ~arch and that we don't wait on them to stabilize.
+2014-03-26 20:22:01	@Pinkbyte	Zero_Chaos, ACCEPT_KEYWORDS="-~s390 s390"
+2014-03-26 20:22:14	@Pinkbyte	that's how he do things :-)
+2014-03-26 20:22:15	@WilliamH	I tend to agree that the status of theprofile should be switched instead of fooling with accept_keywords.
+2014-03-26 20:22:15	@Zero_Chaos	Pinkbyte: that is his choice, and it doesn't affect anyone else in any way.
+2014-03-26 20:22:41	@TomWij	Pinkbyte: If he's still doing it on dev profiles after 20130917 council decision (per https://bugs.gentoo.org/show_bug.cgi?id=304133#c21) then I think we can enforce the policy here; but, I'm in doubt whether this is to be considered part of this agenda item.
+2014-03-26 20:22:50	@Pinkbyte	WilliamH, then - let's do this
+2014-03-26 20:22:52	@Zero_Chaos	WilliamH: making the profile exp instead of dev or stable means that there will be much more inadvertant breakage which we can avoid.
+2014-03-26 20:23:21	@Tommy[D]	Who about moving those testing-only arches per council decision to exp profile status or, if preferred, ask council for such decision?
+2014-03-26 20:23:25	@Tommy[D]	*how about
+2014-03-26 20:23:27	@Pinkbyte	Zero_Chaos, we are talking about arches, that basically have only vapier in arch team
+2014-03-26 20:23:32	@Pinkbyte	so, it depends...
+2014-03-26 20:23:45	@Zero_Chaos	Pinkbyte: we are here to fight for the users, not to battle vapier for fun.
+2014-03-26 20:23:55	@Zero_Chaos	Pinkbyte: I don't care what vapier does if it doesn't affect the users.
+2014-03-26 20:23:59	@creffett|irssi	so the choices as I see them are "do nothing" "mark exp ourselves" "punt to council"
+2014-03-26 20:24:01	@WilliamH	Zero_Chaos: it also ties in with being able to remove old versions.
+2014-03-26 20:24:03	@creffett|irssi	did I miss anything?
+2014-03-26 20:24:30	dilfridge	about the arches
+2014-03-26 20:24:33	@Zero_Chaos	WilliamH: we don't have to respect his stable keywords since council said those arches do not have stable keywords. so again, who cares.
+2014-03-26 20:24:36	 *	WilliamH votes punt to council
+2014-03-26 20:24:36	@zlogene	i'm interested why vapier still stabilize it
+2014-03-26 20:24:47	@creffett|irssi	dilfridge: go ahead
+2014-03-26 20:24:49	dilfridge	we had a council decision that all these arches should go exp (suggested by vapier)
+2014-03-26 20:24:56	@Zero_Chaos	punting to council is worthless, they haven't enforced anything for years and won't
+2014-03-26 20:24:58	@zlogene	make it sense ? If profile have arch ~arch? 
+2014-03-26 20:24:58	@Pinkbyte	Zero_Chaos, it's a question of support. If only vapier cares about them, then we can not enforce decision that he does not like
+2014-03-26 20:24:59	@Tommy[D]	creffett|irssi: additionally would be "force testing keywords, drop stable keywords again"
+2014-03-26 20:25:06	@Zero_Chaos	we either make a choice ourselves or stop pretending we care.
+2014-03-26 20:25:06	dilfridge	nah, 
+2014-03-26 20:25:26	dilfridge	the agreement was "all these arches become exp profiles, and noone cares about the stable or not keywords"
+2014-03-26 20:25:27	@TomWij	creffett|irssi: It depends on what we consider to be the agenda item: If it's just 'experimental' as listed on the wiki, the choices are limited; if we include 'dev' in that, additional choices come in.
+2014-03-26 20:25:33	@Pinkbyte	zlogene, as i said - he maintains his own machines with some like of 'stable' branch
+2014-03-26 20:25:34	@WilliamH	wait hold on a second all
+2014-03-26 20:25:38	@ulm	dilfridge: right
+2014-03-26 20:25:43	@creffett|irssi	Zero_Chaos: what, and you think they'll listen to us? out of the existing decisions we've made, which have actually been listened to?
+2014-03-26 20:25:49	@ulm	so we should simply mark them as exp
+2014-03-26 20:26:00	@Zero_Chaos	creffett|irssi: nut up man. they can't throw us all out ;-)
+2014-03-26 20:26:18	@WilliamH	dilfridge: ok, we had a council decision that the arch's should go exp... we just flip that switch and don't care otherwise...
+2014-03-26 20:26:27	@Tommy[D]	dilfridge: have a summay link containing that agreement?
+2014-03-26 20:26:45	@Zero_Chaos	again, things are black and white to me. If the profiles are correct and he isn't affecting the users he can stabilize whatever he wants. I'm here to protect users not battle for good form.
+2014-03-26 20:26:47	dilfridge	vapier uses the stable keywords for e.g. stage building, and imho as long as they are not annoucned anywhere and the profiles default to ACCEPT_KEYWORDS="arch ~arch", who cares
+2014-03-26 20:27:02	@Zero_Chaos	dilfridge: ++
+2014-03-26 20:27:11	@WilliamH	bump the profiles to exp and we're done with this item. ;-)
+2014-03-26 20:27:14	@Zero_Chaos	this doesn't affect us. this doesn't affect users. I say vote.
+2014-03-26 20:27:25	dilfridge	Tommy[D]: I think that's one of the summaries that donnie still has to make
+2014-03-26 20:27:26	@Pinkbyte	Zero_Chaos, the key point ' if the profiles are correct'. They are marked 'dev' right now, but it does not reflect the reality.
+2014-03-26 20:27:33	@Pinkbyte	let's vote
+2014-03-26 20:27:37	@Zero_Chaos	Pinkbyte: dev is fine with me.
+2014-03-26 20:27:38	@creffett|irssi	dilfridge: to clarify, the profiles _should_ be marked exp?
+2014-03-26 20:27:45	dilfridge	will be marked exp
+2014-03-26 20:27:47	@WilliamH	There's nothing to vote on since council made the decision.
+2014-03-26 20:27:54	@Zero_Chaos	creffett|irssi: let's try a vote and see where it lands....
+2014-03-26 20:27:55	dilfridge	exactly.
+2014-03-26 20:27:56	@Tommy[D]	i vote for setting those profiles to exp, allowing everyone to drop stable keywords, let vapier do his keywording and noone gets repoman warnings
+2014-03-26 20:28:19	@Zero_Chaos	Tommy[D]: are there repoman warnings now?
+2014-03-26 20:28:33	dilfridge	I'm still busy with bumping the whole profile tree to eapi=5, otherwise I'd possbly have done it in the meantime
+2014-03-26 20:28:34	@Tommy[D]	Zero_Chaos: should be for dev profiles with repoman -d
+2014-03-26 20:28:49	@Zero_Chaos	Tommy[D]: I know how to scan thanks, I said, "Are there warnings now"?
+2014-03-26 20:28:49	@zlogene	Tommy[D]: heh, even we'll drop stable keywords vapier will revert us 
+2014-03-26 20:28:53	@WilliamH	all the council already made the decision on this ;-)
+2014-03-26 20:29:05	@creffett|irssi	I vote EDONTCARE, the profiles are set to be marked exp so nothing to do.
+2014-03-26 20:29:15	@Zero_Chaos	creffett|irssi: who is marking them exp?
+2014-03-26 20:29:22	@Zero_Chaos	creffett|irssi: and on what authority?
+2014-03-26 20:29:24	dilfridge	in case of doubt me 
+2014-03-26 20:29:34	dilfridge	on council decision authority
+2014-03-26 20:29:35	@creffett|irssi	Zero_Chaos: sounded like dilfridge either is planninng on it or knows who will be, and on council authority
+2014-03-26 20:29:38	@WilliamH	Zero_Chaos: the authority of council
+2014-03-26 20:29:40	@TomWij	creffett|irssi: +1 For the original 'experimental' agenda item, my vote is "don't care"; for the 'dev' discussion as above, my vote is "enforce what council decided or let council enforce it if they wish to do so" (which boils down to "don't care" unless council wants us to enforce).
+2014-03-26 20:29:48	@WilliamH	Zero_Chaos: as already said
+2014-03-26 20:29:48	@ulm	dilfridge: please do
+2014-03-26 20:29:53	@Tommy[D]	zlogene: i mean, if we remove an old version (last stable version on that arch), we dont have to wait for that arch and he is free to stable a newer version
+2014-03-26 20:29:57	@Pinkbyte	TomWij, +1
+2014-03-26 20:30:03	dilfridge	soon... (we have dpg meeting next week... argh...)
+2014-03-26 20:30:09	@Zero_Chaos	if the council already said that is what's happening then I'd like to raise creffett|irssi's EDONTCARE with a EWHYAREWEEVENTALKINGABOUTTHIS
+2014-03-26 20:30:22	dilfridge	hehe
+2014-03-26 20:30:26	@ulm	dilfridge: it's just profiles.desc?
+2014-03-26 20:30:29	dilfridge	yes
+2014-03-26 20:30:41	@Pinkbyte	Zero_Chaos, as Tommy[D] said - those 'stable' things on sh/s390/m68k slows closing bugs dramatically
+2014-03-26 20:30:44	@Pinkbyte	even security ones
+2014-03-26 20:30:53	@Zero_Chaos	dilfridge: is there a way to make repoman scan experimental profiles?
+2014-03-26 20:30:56	dilfridge	yes
+2014-03-26 20:30:57	@ulm	dilfridge: m68k s390 sh?
+2014-03-26 20:31:00	@creffett|irssi	Zero_Chaos: repoman -e iirc
+2014-03-26 20:31:05	@Zero_Chaos	then yeah, this is super closed for me.
+2014-03-26 20:31:07	dilfridge	ulm: yes but better check
+2014-03-26 20:31:13	@creffett|irssi	okay, glad we all agree.
+2014-03-26 20:31:15	@creffett|irssi	next topic.
+2014-03-26 20:31:40	@Zero_Chaos	dilfridge: thanks for the input.
+2014-03-26 20:31:41	@creffett|irssi	Zero_Chaos: you're on, issues with dropping-last-stable policy and what you want us to do
+2014-03-26 20:32:03	 *	ulm reading council log
+2014-03-26 20:32:06	@Zero_Chaos	I sent a short mail in response to TommyD, but I can summarize here
+2014-03-26 20:32:23	@zlogene	Zero_Chaos: please do it 
+2014-03-26 20:32:36	@Zero_Chaos	Dropping a keyword from a package, stable or otherwise, will NOT prevent any issues since the user will still have the package installed.
+2014-03-26 20:32:38	@Tommy[D]	based on the input from the mail, i suggest the following addition: "if there is no urgency (like security bugs), the developer should follow the policy for removing a package when removing the last stable version or stable keyword from a package"
+2014-03-26 20:32:52	@Zero_Chaos	Moreover, the user gets no warning of the issue and still reports bugs, etc.
+2014-03-26 20:32:56	@TomWij	(For reference, https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Dropping_Stable_KEYWORDs)
+2014-03-26 20:33:24	@Zero_Chaos	So I say, follow the package removal policies (since we are removing the package for a given arch) and use the normal masking practice.
+2014-03-26 20:33:43	@Zero_Chaos	simply removing keywords *will* cause more issues, not make them go away
+2014-03-26 20:34:04	@creffett|irssi	concern: masking drops visibility even lower than dropping to ~
+2014-03-26 20:34:16	@Zero_Chaos	masking properly, listing a bug, it might get fixed, or it might get keyword removed, either way, it will stop us from getting bug reports, etc, and the users won't be caught be surprise.
+2014-03-26 20:34:59	@Tommy[D]	creffett|irssi: masking will show a warning to users including the mask message, so he has additional 30 days to react / adjust himself to the situation, so that sounds fine with me
+2014-03-26 20:35:03	@ulm	m68k/s390/sh dropped to exp
+2014-03-26 20:35:12	@Zero_Chaos	creffett|irssi: if a user of a stable system has foobar-1.2 installed and we remove stable keywords from it, the result is invisible if we do not mask it.
+2014-03-26 20:36:00	@Zero_Chaos	creffett|irssi: and since this would only happen in the case of extreme situations like security bugs etc, I think the mask will be needed either way.
+2014-03-26 20:36:02	@ulm	dilfridge: we really should have timely council summaries
+2014-03-26 20:36:04	@TomWij	creffett|irssi: Maybe we need package.stable.mask; though, I think the goal was removal of the ebuild, so package.mask may just work as well and therefore the increased drop in visibility a mask brings is not of concern.
+2014-03-26 20:36:05	@WilliamH	If we are going to mask, I would say s/0/60/ for when the policy can start happening.
+2014-03-26 20:36:14	@creffett|irssi	Zero_Chaos: good enough for me
+2014-03-26 20:36:16	@WilliamH	s/90/60/
+2014-03-26 20:36:47	@WilliamH	hrm maybe package.stable.mask...
+2014-03-26 20:36:53	@Tommy[D]	WilliamH: i see no point for that, but no real feelings against it either
+2014-03-26 20:36:54	@Zero_Chaos	TomWij: I believe package.mask is better, since some users run mixed systems
+2014-03-26 20:37:05	@creffett|irssi	Zero_Chaos: did you like Tommy[D]'s suggested wording, or do you have a different preferred way to amend the policy
+2014-03-26 20:37:07	@Pinkbyte	WilliamH, no-no-no, please do not
+2014-03-26 20:37:11	@Pinkbyte	package.mask
+2014-03-26 20:37:52	 *	WilliamH reads again
+2014-03-26 20:37:59	@Zero_Chaos	creffett|irssi: I don't like his wording, even if there is urgency an entry in package.mask doesn't take much time.
+2014-03-26 20:38:02	@Pinkbyte	not package.stable.mask
+2014-03-26 20:38:49	@creffett|irssi	Zero_Chaos: then please suggest a wording to vote on
+2014-03-26 20:38:53	@TomWij	Zero_Chaos: So, if I understand it right, your suggestion is like replacing "The maintainer may drop ..." by something (we can decide on exact wording) like "The maintainer may mask (to inform the user) and then after 30 days drop ..."?
+2014-03-26 20:38:54	@Zero_Chaos	Tommy[D]: can you give an example for something so critical you must remove keywords now instead of adding a package.mask? the effect is the same imho.
+2014-03-26 20:38:59	@Tommy[D]	Zero_Chaos: i dont mind a package.mask entry, but for security reasons i would prefer removing that version as fast as possible, especially since it has been around for at least 90 days
+2014-03-26 20:39:31	@Zero_Chaos	Tommy[D]: masked is masked though, and you can already remove all other keywords once those arches have newer versions stabilized.
+2014-03-26 20:39:46	@Tommy[D]	Zero_Chaos: i dont talk about removing stable keyword in this context, but removing an outdated version, which is last stable version for an unresponsive arch
+2014-03-26 20:39:48	@TomWij	Pinkbyte: Yeah, no need for package.stable.mask until there is a real need for that; package.mask suffices after thinking it through.
+2014-03-26 20:39:51	@Zero_Chaos	creffett|irssi: one more min to discuss with Tommy[D] 
+2014-03-26 20:39:53	@creffett|irssi	Tommy[D]: security team has no issue with masking before removal when absolutely necessary
+2014-03-26 20:39:56	@creffett|irssi	Zero_Chaos: certainly
+2014-03-26 20:40:04	@Pinkbyte	Tommy[D], some core packages i(and base-system) prefer to see masked, rather then removed immediately
+2014-03-26 20:40:22	@Zero_Chaos	Tommy[D]: certainly if the vulnerable version only has keywords for one arch, and it's masked on that arch, the user is protected enough?
+2014-03-26 20:40:33	@Pinkbyte	Zero_Chaos, definitely
+2014-03-26 20:40:36	@Zero_Chaos	Tommy[D]: removing the ebuild won't help the user any further, will it?
+2014-03-26 20:40:45	@Pinkbyte	if user unmasks package, than - he knows what he is doing
+2014-03-26 20:40:59	@Pinkbyte	and he reads mask message
+2014-03-26 20:41:01	@Zero_Chaos	"the developer should follow the policy for removing a package  when removing the last stable version or stable keyword from a package"
+2014-03-26 20:41:09	@Zero_Chaos	creffett|irssi: ^^
+2014-03-26 20:41:11	@Tommy[D]	What is the point in keeping a vulnerable package around? Removal wont affect those, that have it installed and for those installing newly, they should not even think about installing a vulnerable version
+2014-03-26 20:41:12	@TomWij	Tommy[D]: I think security migration is faster dealt with by the user if they get a mask message explaining the reason (or pointing to a GLSA) than when it is masked by missing keyword.
+2014-03-26 20:41:40	@Zero_Chaos	Tommy[D]: removing a package affects dep calculation with things like dynamic deps, it's a critical issue honestly.
+2014-03-26 20:41:42	@WilliamH	Hmm,
+2014-03-26 20:42:00	@Tommy[D]	TomWij: as i said: i dont mind an additional mask entry, but see no reason to keep an outdated and vulnerable version around
+2014-03-26 20:42:01	@TomWij	Zero_Chaos: That's vague to me, if that's taken literal it would mean a lastrite message; can we avoid like-the-package-removal constructs?
+2014-03-26 20:42:01	@Pinkbyte	Tommy[D], look at glibc. Old versions are preserved for some exotic software that breaks with newer glibc(yeah, that shit happens, blame code monkeys that wrote proprietary software)
+2014-03-26 20:42:10	@WilliamH	Wouldn't developers be touching profiles/<arch>/package.mask in this case though?
+2014-03-26 20:42:16	@Zero_Chaos	WilliamH: yes
+2014-03-26 20:42:21	@Zero_Chaos	WilliamH: and I see no issue with that.
+2014-03-26 20:42:24	@Pinkbyte	Tommy[D], and base-system guys are strongly against removing glibc ebuilds
+2014-03-26 20:42:37	@WilliamH	current policy doesn't allow that; you have to get an arch team member to do it iirc.
+2014-03-26 20:42:40	@Zero_Chaos	TomWij: agreed, I think we can safely drop that part...
+2014-03-26 20:42:59	@creffett|irssi	WilliamH: but at this point the arch team has been unresponsive
+2014-03-26 20:43:04	@Zero_Chaos	WilliamH: our policy is above arch team policy, they will like our improvements.
+2014-03-26 20:43:08	@Tommy[D]	Pinkbyte: any existing glibc ebuild has a security issue?
+2014-03-26 20:43:08	@zlogene	Pinkbyte: and against bash removing too
+2014-03-26 20:43:09	@creffett|irssi	which is why we're dropping last stable in the first place.
+2014-03-26 20:43:15	@creffett|irssi	Tommy[D]: several, actually
+2014-03-26 20:43:26	@Pinkbyte	Tommy[D], all <2.17 - yes
+2014-03-26 20:44:00	@Zero_Chaos	"The developer should follow the policy for removing a package, except for last rites emails,  when removing the last stable version or stable keyword from a package."
+2014-03-26 20:44:01	@Tommy[D]	for masking: masking in base profile(s) should be enough, any need to do it in specific arch profiles?
+2014-03-26 20:44:07	@TomWij	Zero_Chaos: Think you missed it, but I asked earlier whether you meant something like "The maintainer may mask (to inform the user) and then after 30 days drop ..." (instead of "The maintainer may drop ..."), does that miss anything?
+2014-03-26 20:44:55	@Zero_Chaos	TomWij: I was trying to not be so wordy, the official removal policy includes a bit more like closing bugzie entries, etc.
+2014-03-26 20:45:29	@Zero_Chaos	Tommy[D]: depends if we determine multiple arches slacker at different times. I see no reason why we would so profiles/package.mask should be enough.
+2014-03-26 20:45:40	@TomWij	Zero_Chaos: Hmm, okay, without last rites that seems to make sense; I think the reader is smart enough to s/package/ebuild/ for the rest of it.
+2014-03-26 20:45:52	@WilliamH	Tommy[D]: let me think about that...
+2014-03-26 20:45:54	@Zero_Chaos	TomWij: I sure hope so :-)
+2014-03-26 20:45:57	@TomWij	Zero_Chaos: So, if I understand correctly; to fit it in with the current policy, that would be added as a sentence to the end?
+2014-03-26 20:46:04	@Zero_Chaos	TomWij: yes
+2014-03-26 20:46:17	@Zero_Chaos	creffett|irssi: "The developer should follow the policy for removing a package, except for last rites emails,  when removing the last stable version or stable keyword from a package."
+2014-03-26 20:46:26	@creffett|irssi	all right.
+2014-03-26 20:46:32	@Zero_Chaos	creffett|irssi: I believe we can vote on adding this wording to the end and removing the contest on the page.
+2014-03-26 20:46:36	@creffett|irssi	yes
+2014-03-26 20:46:39	@Tommy[D]	looks ok to me as an addition
+2014-03-26 20:46:44	@Zero_Chaos	Tommy[D]: yessir.
+2014-03-26 20:46:48	@creffett|irssi	@all: please vote on Zero_Chaos's amendment
+2014-03-26 20:46:49	 *	creffett|irssi yes
+2014-03-26 20:46:52	@TomWij	(That goes behind the original "The maintainer may drop stable keyword or last stable version, if arch team does not respond within 90 days; if it breaks the dependency tree, then the maintainer has to work with maintainers of depending packages before dropping keyword/last stable version.")
+2014-03-26 20:46:52	 *	Zero_Chaos is obviously in favor
+2014-03-26 20:47:14	@TomWij	+1 on Zero_Chaos amendment.
+2014-03-26 20:47:17	 *	Pinkbyte votes 'yes'
+2014-03-26 20:47:17	 *	ulm yes
+2014-03-26 20:47:23	 *	zlogene yes 
+2014-03-26 20:47:23	 *	WilliamH yes
+2014-03-26 20:47:47	@Zero_Chaos	woohoo. thanks for the patience guys, I've been very underwater.
+2014-03-26 20:48:02	@creffett|irssi	Zero_Chaos: amend the page at your convenience
+2014-03-26 20:48:09	@Zero_Chaos	creffett|irssi: immediately your highness
+2014-03-26 20:48:23	@creffett|irssi	next item on the agenda is the gtk email; WilliamH just sent out a draft email, any feedback on that?
+2014-03-26 20:48:49	@Tommy[D]	didnt read it yet, i suggest we discuss that mail via mail
+2014-03-26 20:48:59	@Tommy[D]	(if there is discussion needed)
+2014-03-26 20:49:10	 *	creffett|irssi shrugs
+2014-03-26 20:49:15	@creffett|irssi	any objections to mail discussion?
+2014-03-26 20:49:35	@WilliamH	creffett|irssi: I was a little confused on your last point, I think I got it right though.
+2014-03-26 20:49:37	@Zero_Chaos	not I
+2014-03-26 20:49:41	@zlogene	no
+2014-03-26 20:49:57	@WilliamH	no objections here either.
+2014-03-26 20:50:17	@creffett|irssi	good enough for me
+2014-03-26 20:50:20	@TomWij	No objections to do discussion on mail, too long to stall meeting.
+2014-03-26 20:50:34	@Pinkbyte	creffett|irssi, fine by me. I have read email and see no problems with it. It describes the whole problem and our actions pretty well
+2014-03-26 20:50:56	@ulm	e-mail draft looks good to me
+2014-03-26 20:50:58	@creffett|irssi	next up: getting other people to help out
+2014-03-26 20:51:01	 *	zlogene reads now 
+2014-03-26 20:51:17	@creffett|irssi	the general idea here is a) we're not doing so well in the PR department and b) there are a lot of small issues that could be tackled
+2014-03-26 20:51:43	@Zero_Chaos	creffett|irssi: page updated.
+2014-03-26 20:51:57	@creffett|irssi	(fixing maintainer-needed bugs, fixing bitrotting bugs that never got a patch applied, hunting some of the existing QA issues like ignored CFLAGS, etc.)
+2014-03-26 20:52:17	@Tommy[D]	for a): unless you want to pay some PR agency, probably not much we can do about it :)
+2014-03-26 20:52:46	@creffett|irssi	Tommy[D]: well, we could try to stop making decisions that piss off a quarter of the dev community each
+2014-03-26 20:52:50	@TomWij	creffett|irssi: Well, I think that overall this boils down to needing more manpower in Gentoo.
+2014-03-26 20:52:59	@creffett|irssi	but then we're doing less useful stuff
+2014-03-26 20:53:03	@Pinkbyte	and about maintainer-needed... well, they are 'maintainer needed' - everybody can touch them. If nobody did - what we can do? :-)
+2014-03-26 20:53:19	@Tommy[D]	the only idea for the small things: a page within QA wiki listing the things any dev could do and maybe seperated, what a user could do to help
+2014-03-26 20:53:35	@Pinkbyte	creffett|irssi, the problem is that we do not have easy problems
+2014-03-26 20:53:38	@creffett|irssi	Pinkbyte: yes, but nobody does.
+2014-03-26 20:53:39	@TomWij	So, (b) is non-QA, unless we, as QA team, want to work on getting more contributors, perhaps QA contributors.
+2014-03-26 20:53:42	@creffett|irssi	Pinkbyte: indeed.
+2014-03-26 20:53:47	@WilliamH	creffett|irssi: about pissing people off, I don't think we are going to win that battle...
+2014-03-26 20:53:52	@Pinkbyte	and serious problems when solved usually hurt somebody
+2014-03-26 20:53:54	@creffett|irssi	TomWij: QA contributors would be nice
+2014-03-26 20:53:57	@Tommy[D]	creffett|irssi: well, still better then to piss 3 quarter of the dev community :D
+2014-03-26 20:54:07	@TomWij	But given a lot of developers are overworked, I don't see us convincing them; it's already a surprise we have ~10 people in the QA team.
+2014-03-26 20:54:09	@WilliamH	creffett|irssi: no matter what we do someone is going to be upset.
+2014-03-26 20:54:15	@creffett|irssi	WilliamH: correct!
+2014-03-26 20:54:39	@TomWij	Hmm ... is it possible to crowd source QA efforts?
+2014-03-26 20:54:56	@TomWij	Like not to Gentoo Developers, but extend it to users.
+2014-03-26 20:54:58	@creffett|irssi	TomWij: entirely possible, get a few trusted users to bug hunt
+2014-03-26 20:55:36	@creffett|irssi	anyway, not expecting results this meeting, just want to get people thinking
+2014-03-26 20:55:38	@Tommy[D]	as i said: only option i see is some page listing the simple and open work seperated for devs and users and announcing that page, so that anyone with some free time and willing can open that page and fix some of those things
+2014-03-26 20:55:49	@TomWij	The last few bug days (and to small extent bug cleaners project) don't reveal much interest; outside of that, we've got some regulars doing things here and there.
+2014-03-26 20:56:11	@Zero_Chaos	I apologize, I have a flight to catch. I also have no ideas how to get us better PR or more help, so see you all later ;-)
+2014-03-26 20:56:18	@creffett|irssi	Zero_Chaos: see ya
+2014-03-26 20:56:25	@Tommy[D]	see you zero
+2014-03-26 20:57:08	@creffett|irssi	actually, I have to run in a few too, so one thing I had to bring up: Pinkbyte, since you were running the multislot issue, would you mind filing bugs against toolchain to give them a friendly reminder?
+2014-03-26 20:57:08	@Pinkbyte	Zero_Chaos, ciao
+2014-03-26 20:57:10	 *	antarus mutters something abuot more automation
+2014-03-26 20:57:10	antarus	;p
+2014-03-26 20:57:33	@WilliamH	antarus: heh
+2014-03-26 20:57:43	ssuominen	TomWij: system wide use of lto is not supported yet in sense that the toolchain maintainers know it to be broken and not ready for gentoo-x86
+2014-03-26 20:57:53	@Tommy[D]	antarus: do it :p
+2014-03-26 20:58:05	@Pinkbyte	creffett|irssi, sure. There quite a few of them, i will dig the entire tree, maybe i missed some of them and file apropriate bugs
+2014-03-26 20:58:26	@TomWij	creffett|irssi: ^ Tinderbox was also on the agenda; not sure how, but it was skipped; unless we decided out of the meeting to not meet about that, I think it boils down to needing the hardware to do it (and someone to get it automated)?
+2014-03-26 20:58:33	ssuominen	TomWij: lto in compiler is just fine but the rest of portage (ie. packages) are not :/
+2014-03-26 20:58:37	@creffett|irssi	Pinkbyte: just need three--glibc, gcc, and binutils(?) iirc
+2014-03-26 20:58:40	@creffett|irssi	TomWij: whoops
+2014-03-26 20:58:54	@creffett|irssi	that one boils down to "no hardware"
+2014-03-26 20:59:00	antarus	Tommy[D]: less is more!
+2014-03-26 20:59:11	@creffett|irssi	so unless someone plans to give us hardware in the near future, CANTFIX
+2014-03-26 20:59:26	@Pinkbyte	creffett|irssi, well, maybe i can
+2014-03-26 20:59:27	@Pinkbyte	)))
+2014-03-26 20:59:32	ssuominen	TomWij: plus the user has other flags that simply generate invalid code (like -ftree-vectorize for sys-libs/zlib, just to name one example)
+2014-03-26 20:59:33	antarus	I have 12 cores and 32GB of ram
+2014-03-26 20:59:36	antarus	thats about it
+2014-03-26 20:59:45	ssuominen	TomWij: -fweb breaks x264, at least
+2014-03-26 20:59:59	ssuominen	TomWij: just treat him as -O3 user :PP
+2014-03-26 21:00:00	@TomWij	Better PR can boils down to 1) make sure we take everyone into consideration and 2) making clear we revisit our choices if needed.
+2014-03-26 21:00:16	@TomWij	It's not like if we say "tomorrow the tree is pink" that it'll be pink tomorrow. :D
+2014-03-26 21:00:17	@Pinkbyte	but it would be VM, 4 cores, 16Gb of RAM
+2014-03-26 21:00:31	@creffett|irssi	Pinkbyte: if you want to look into it, feel free :P
+2014-03-26 21:01:01	@Pinkbyte	creffett|irssi, well, i can donate resources(that's not the problem). Setting up tinderbox is a different issue
+2014-03-26 21:01:04	antarus	if you can design your workloads for the cloud
+2014-03-26 21:01:10	@Pinkbyte	even with flameeyes scripts...
+2014-03-26 21:01:10	antarus	we have space at rackspace
+2014-03-26 21:01:19	antarus	but we pay by the hour
+2014-03-26 21:01:26	antarus	and running a big vm 24/7 will eat the budget
+2014-03-26 21:01:39	 *	creffett|irssi out
+2014-03-26 21:01:44	antarus	so you have to do stuff like 'turn vm on, start job, write output to storage, turn vm off'
+2014-03-26 21:01:47	antarus	so you are not paying for idle hours
+2014-03-26 21:01:52	@wired	hey :p
+2014-03-26 21:02:14	@Tommy[D]	wired: that was the last word of the meeting :p
+2014-03-26 21:02:29	@wired	heheh
+2014-03-26 21:02:35	@wired	meh, sorry
+2014-03-26 21:02:55	@WilliamH	wired: lol
+2014-03-26 21:03:09	@zlogene	wired, too late:p but hi there :p
+2014-03-26 21:03:24	@TomWij	Did someone want to open floor something?
+2014-03-26 21:03:26	@Tommy[D]	so summary for the "get more people to work": no fixed content to decide on, feel free to add content via mail on the alias
+2014-03-26 21:04:11	@Tommy[D]	summary for the "QA tinderbox": we need the hardware, a concept to use it and someone doing the work for it, so until we got those donated, nothing to vote/discuss on
+2014-03-26 21:04:27	antarus	I think you have a fairly annoying catch-22 there
+2014-03-26 21:05:06	@Tommy[D]	no openfloor content from me
+2014-03-26 21:05:07	@TomWij	Tommy[D]: "get more people to work" I think making things more accessible (a list of all QA work users can help with, and not just autorepoman) is one way to do it; the other I agree.
+2014-03-26 21:05:36	@Pinkbyte	Tommy[D], as i said - i can give resources
+2014-03-26 21:05:54	@Pinkbyte	but about other things - no idea
+2014-03-26 21:06:16	@Tommy[D]	TomWij: as i said: we could look into creating a page listing possible work specific groups (devs/users) can do, beside that we currently dont have anything specific
+2014-03-26 21:07:09	@TomWij	Tommy[D]: Yeah, even for ourselves I think it can help; for example, I have a search that does something like:
+2014-03-26 21:07:12	@TomWij	Resolution: --- Keywords: (contains none of the words) Tracker Assignee: qa@gentoo.org Severity: QA CC: qa@gentoo.org
+2014-03-26 21:07:39	@TomWij	(The Keywords is wrong, it checks for QA.)
+2014-03-26 21:08:22	@Tommy[D]	Pinkbyte: i suggest you write that via mail to the alias, so we have a starting point for our further discussion/planning
+2014-03-26 21:08:31	@TomWij	The idea being that {assignee,cc}:qa@gentoo.org alone doesn't suffice; there's like a lot where severities get said to QA or something QA is put in another field or so (eg. QAcanfix).
+2014-03-26 21:09:23	 *	TomWij gets scared thinking about the amount of QA bugs that have none of these bug parameters indicate that it is a QA bug.
+2014-03-26 21:10:41	@Tommy[D]	dont think too much about it, just gets you less/grey hair quicker :)
+2014-03-26 21:10:58	@TomWij	Does someone know when the first QA team was formed?
+2014-03-26 21:10:59	@Tommy[D]	as there is no new input, i suggest, we close the meeting for today
+2014-03-26 21:11:33	@TomWij	Tommy[D]: +1
+2014-03-26 21:11:47	@TomWij	Just for fun, I'm even thinking there might even still be QA bugs lingering around from before that time.
+2014-03-26 21:12:13	@Pinkbyte	TomWij, try not to thing about unreported QA bugs too ;-)
+2014-03-26 21:13:00	@Tommy[D]	so i assume meeting closed, have a good evening everyone
+2014-03-26 21:13:15	 *	TomWij feels that his hair changes color.
+2014-03-26 21:13:32	@TomWij	good evening
+2014-03-26 21:22:34	@creffett|irssi	TomWij: at the rate we're going, I will be gray-haired by the time my term is up
diff --git a/meeting-logs/20140416.txt b/meeting-logs/20140416.txt
new file mode 100644
index 0000000..5b84035
--- /dev/null
+++ b/meeting-logs/20140416.txt
@@ -0,0 +1,621 @@
+2014-04-16 19:34:46	 *	WilliamH is here just hanging around
+2014-04-16 19:38:15	 *	zlogene around 
+2014-04-16 19:43:41	@zlogene	!away Pinkbyte
+2014-04-16 19:43:42	willikins	zlogene: pinkbyte:  Limited development activity till June 1, 2014. Available via e-mail, feel free to contact on urgent stuff or fix things yourself. But do not break anything ;-) @ 2014/04/05 15:04Z
+2014-04-16 19:52:55	@WilliamH	fire alarm going off, I'll be back asap
+2014-04-16 20:02:52	@creffett|irssi	all right, it's 1800, let's get going
+2014-04-16 20:03:39	@creffett|irssi	DrEeevil, Pinkbyte, TomWij, Tommy[D], ulm, WilliamH, wired, Zero_Chaos, zlogene: meeting time
+2014-04-16 20:03:46	 *	TomWij here
+2014-04-16 20:03:58	@Zero_Chaos	oh dear god
+2014-04-16 20:04:00	 *	ulm here
+2014-04-16 20:04:05	@Zero_Chaos	two meetings in a row, YES
+2014-04-16 20:04:07	 *	Zero_Chaos here
+2014-04-16 20:05:33	@zlogene	as usual 
+2014-04-16 20:05:48	@creffett|irssi	that's 5, would be nice to get one more at least
+2014-04-16 20:05:58	@wired	I'm here as well 
+2014-04-16 20:06:24	@creffett|irssi	excellent, that's enough to get started, and I expect that WilliamH will join us once he's done dealing with whatever's on fire
+2014-04-16 20:06:40	 *	WilliamH is back, false alarm
+2014-04-16 20:07:18	@Zero_Chaos	WilliamH: always preferred.
+2014-04-16 20:07:23	@Zero_Chaos	well... not always
+2014-04-16 20:07:25	@Zero_Chaos	:-)
+2014-04-16 20:07:30	@WilliamH	he
+2014-04-16 20:07:32	@WilliamH	heh
+2014-04-16 20:07:59	@creffett|irssi	first on the agenda: after discussion with antarus, we're going to be backing off a little on the "enforcement" of policies and leaving that to comrel
+2014-04-16 20:08:14	@creffett|irssi	the general idea is that if someone's breaking policy, we ask them nicely, and if they refuse, we pass it to comrel
+2014-04-16 20:08:59	@wired	1900 utc should be in 50 m btw
+2014-04-16 20:09:02	@Zero_Chaos	creffett|irssi: can you please explicitly state historical samples of why? don't need specifics of each incident, but I'd like to know which incidents specifically.
+2014-04-16 20:09:14	@zlogene	it seems we have really long list of topics, no?
+2014-04-16 20:09:18	@Zero_Chaos	zlogene: yes
+2014-04-16 20:09:21	@TomWij	zlogene: Most are short.
+2014-04-16 20:09:25	@WilliamH	wired: the meeting is at 1800
+2014-04-16 20:09:33	@TomWij	And we can skip whatever's not important if we go over time.
+2014-04-16 20:09:41	@wired	the mail said 1900
+2014-04-16 20:09:48	@wired	no worries on my side 
+2014-04-16 20:10:05	@creffett|irssi	we don't need to be reaching in and changing things when someone's ignoring policy, unless it is presently causing breakage (and by breakage I'm talking "unbootable user system" or "unusable portage tree")
+2014-04-16 20:10:18	@creffett|irssi	wired: I forgot to check our agreed-upon time before sending the email, it was my bad
+2014-04-16 20:11:01	@Zero_Chaos	creffett|irssi: I'm not trying to be difficult but I'd like to know if this is specifically incited by the udev virtuals being masked.
+2014-04-16 20:11:34	@creffett|irssi	Zero_Chaos: that was the impetus for this, yes, but it's been something I've been thinking over for a while
+2014-04-16 20:11:56	@Zero_Chaos	creffett|irssi: there is no arguement, I just need to understand the resolutions which come out of my actions.
+2014-04-16 20:12:01	@Zero_Chaos	creffett|irssi: please continue.
+2014-04-16 20:12:02	@creffett|irssi	Zero_Chaos: okay
+2014-04-16 20:12:39	@creffett|irssi	basically, the problem I'm addressing here is twofold: inconsistent handling of when someone is ignoring policy, and accusations of us being quick to flash the QA badge without cause
+2014-04-16 20:13:19	@Tommy[D]	creffett: so if someone violates a qa policy, you want us to basicly ask "please dont" and next step "comrel, your case"?
+2014-04-16 20:13:33	@Zero_Chaos	or a tree policy in general.
+2014-04-16 20:13:35	@TomWij	creffett|irssi: So; policy violations => ComRel, user visible breakage => QA. And the gray area goes through discussion with proper step-by-step escalation?
+2014-04-16 20:14:04	@creffett|irssi	Tommy[D]: basically, yes, because when they are willfully ignoring tree policy, it's then comrel's problem
+2014-04-16 20:14:14	@wired	I thought the original idea was to only touch the tree when breakage is involved, otherwise try to talk with the devs first 
+2014-04-16 20:14:23	@creffett|irssi	wired: that is the idea
+2014-04-16 20:14:46	@creffett|irssi	we're just expanding a bit on that
+2014-04-16 20:14:59	@WilliamH	wired: I think the problem is some people's definition of what breakage is is very arbitrary
+2014-04-16 20:15:11	@creffett|irssi	the first step should always be to politely message the dev in question and let them know about the issue
+2014-04-16 20:15:20	@wired	so nothing needs to change, we only need to be more specific on how to handle devs who don't want to listen to us
+2014-04-16 20:15:25	@creffett|irssi	wired: affirmative
+2014-04-16 20:15:34	@Zero_Chaos	creffett|irssi: just to further clarify, impending breakage due to policy violation is comrel's problem, current breakage is under the jurisdiction of QA?
+2014-04-16 20:16:00	@wired	I'd say that this is not our job, comrel sounds good to me in those cases 
+2014-04-16 20:16:01	@creffett|irssi	Zero_Chaos: current breakage that is actually user-visible
+2014-04-16 20:16:18	mgorny	i'd say it would be good if QA action would result in less visible breakage than there was before the action
+2014-04-16 20:16:22	@WilliamH	Zero_Chaos: What I'm getting is willful ignoring of tree policy after we contact the dev is under the jurisdiction of comrel.
+2014-04-16 20:16:28	@Zero_Chaos	creffett|irssi: so QA is not to intervene on incipient breakage. understood.
+2014-04-16 20:16:58	@creffett|irssi	Zero_Chaos: there will be judgment calls here, but someone using a USE flag against some policy or other isn't a reason for us to jump in
+2014-04-16 20:17:09	@Zero_Chaos	WilliamH: the concern is that we are creating a policy that literally binds our hands to prevent breakage until the damage is done.
+2014-04-16 20:17:44	@Zero_Chaos	creffett|irssi: stabilizing something that gets pulled into the system set with known breakage is not to be blocked until AFTER it's been done. I fully understand the policy.
+2014-04-16 20:18:03	@Zero_Chaos	creffett|irssi: I fully disagree with the policy mind you, but I understand it.
+2014-04-16 20:18:12	@creffett|irssi	I appreciate your candor
+2014-04-16 20:18:37	@WilliamH	creffett|irssi: I don't quite get it.  Here's what I'm thinking, tell me if I'm right.
+2014-04-16 20:18:46	@Zero_Chaos	creffett|irssi: well that is the example most fresh in my head. open stabilization bug for items in the system set, pulling in new undiscussed virtuals with circular deps.
+2014-04-16 20:18:55	@Zero_Chaos	creffett|irssi: I prevented user visible breakage and that was wrong.
+2014-04-16 20:18:58	@Zero_Chaos	I follow
+2014-04-16 20:19:02	@WilliamH	creffett|irssi: 1. dev violates policy. 2. we advise him that he is in violation. 3. he says ok, but I'm not fixing it. 4. comrel.
+2014-04-16 20:19:26	@creffett|irssi	WilliamH: correct
+2014-04-16 20:19:29	@wired	assuming the violation does not visibly break the tree 
+2014-04-16 20:20:10	@WilliamH	I think the problem is, how do we define what breaks the tree?
+2014-04-16 20:20:14	@ulm	glep 48 says that we can take action if devs don't cooperate
+2014-04-16 20:20:19	@TomWij	also assuming advise would mean you properly discuss and escalate it in steps.
+2014-04-16 20:20:44	@creffett|irssi	ulm: yes, we can, but I would like that to be limited to when things actually break.
+2014-04-16 20:20:44	@TomWij	(There's a difference between one QA dev stepping to ComRel and the QA team stepping to ComRel)
+2014-04-16 20:20:54	@ulm	creffett|irssi: sure
+2014-04-16 20:21:19	@creffett|irssi	Zero_Chaos: which was your main issue with the new udev virtuals, the "undiscussed" part or the "circular deps" part?
+2014-04-16 20:21:36	@Zero_Chaos	I am greatly concerned that we are *requiring* ourselves to wait for the breakage to be "user visible". Although again, in my case you could say the breakage was user visible since it would have broken releng for ~arch.
+2014-04-16 20:21:57	@Zero_Chaos	creffett|irssi: my main issue is the attempt to bind our hands to not act when we see impending failure.
+2014-04-16 20:22:04	@WilliamH	creffett|irssi: he told me at the time that his main issue was the undiscussed part.
+2014-04-16 20:22:08	mgorny	Zero_Chaos: did you confirm that it would, or are you assuming that it would?
+2014-04-16 20:22:16	@creffett|irssi	mgorny: enough.
+2014-04-16 20:22:18	@Zero_Chaos	creffett|irssi: as of this moment my actions still meet the new policy. There was user visible breakage in ~arch, I acted accordingly.
+2014-04-16 20:22:32	@creffett|irssi	Zero_Chaos: I am still not clear on what the breakage was
+2014-04-16 20:22:43	@TomWij	Zero_Chaos: I'm also concerned with breakage-by-default type of actions happening these days (VS working-by-default).
+2014-04-16 20:22:55	@Zero_Chaos	creffett|irssi: circular deps between udev and the new virtuals would make it impossible to bootstrap.
+2014-04-16 20:23:08	@Zero_Chaos	TomWij: agreed.
+2014-04-16 20:23:24	@creffett|irssi	Zero_Chaos: then that is almost certainly issue that we would want to act on.
+2014-04-16 20:23:38	@creffett|irssi	but it came off to me as you masking because it was not discussed prior to introductin
+2014-04-16 20:23:42	@creffett|irssi	*introduction
+2014-04-16 20:23:45	@Zero_Chaos	creffett|irssi: as I said, even by the new standards my actions followed policy.
+2014-04-16 20:23:51	@WilliamH	It came off that way to me too.
+2014-04-16 20:24:02	@creffett|irssi	and that is explicitly what I am trying to deal with with the new policy
+2014-04-16 20:24:40	@Zero_Chaos	creffett|irssi: yes, I understand, but what you are saying is that we need to wait for user visible breakage before we can act. This is in no way an improvement, it's the opposite.
+2014-04-16 20:24:51	@WilliamH	I think it was even stated on the ml that the masking was done to force discussion.
+2014-04-16 20:25:07	@creffett|irssi	Zero_Chaos: ~arch breakage is still breakage
+2014-04-16 20:25:15	@Zero_Chaos	WilliamH: by the time that post hit the mailing list some of the fixes had been made.
+2014-04-16 20:25:30	@creffett|irssi	so unless you are able to read minds, every issue is going to have to hit the tree in some way before we act
+2014-04-16 20:25:53	@WilliamH	creffett|irssi: ~arch breakage is breakage, but ~arch users are supposed to understand that they may get breakage from time to time.
+2014-04-16 20:26:08	@Zero_Chaos	creffett|irssi: right, but by that standard everything in the tree affects users so this policy may as well require oxygen nearby the QA member before he is allowed to act.
+2014-04-16 20:26:18	@TomWij	creffett|irssi: Yep, the lack of discussion is a ComRel matter; it's of concern when people want to raise something after they introduce and stabilize it (as it can break due to unawareness, assumptions, lack of thoughts, ...), but it's not our terrain if you think about the scope of QA and ComRel.
+2014-04-16 20:26:24	@Zero_Chaos	creffett|irssi: so we are making a pointless policy here.
+2014-04-16 20:26:37	@Zero_Chaos	"QA isn't allowed to mask things not in the tree"
+2014-04-16 20:27:05	@TomWij	Zero_Chaos: Reiterating it; I've not seen something new here, just learning from what happened and what could happen.
+2014-04-16 20:27:06	@creffett|irssi	Zero_Chaos: disagree, there are a lot of policies that are nice-to-follow but won't break peoples' systems
+2014-04-16 20:27:37	@creffett|irssi	so let me try giving an example to see if I can make clear what I'm imagining
+2014-04-16 20:27:43	@Zero_Chaos	creffett|irssi: I suppose I'm still lacking an example then.
+2014-04-16 20:27:48	@creffett|irssi	I introduce an eclass without discussing it on the ML
+2014-04-16 20:28:04	@Zero_Chaos	creffett|irssi: if that eclass is in use that's user visible breakage.
+2014-04-16 20:28:07	@creffett|irssi	someone from QA masks packages that are using it because it wasn't discussed -> bad.
+2014-04-16 20:28:12	@wired	I tend to consider testing as current, not as a playground, I would prefer to avoid breakage of possible
+2014-04-16 20:28:33	@creffett|irssi	someone from QA masks packages using it because it runs rm -rf / in pkg_postinst -> okay \
+2014-04-16 20:28:52	@creffett|irssi	Zero_Chaos: it is not breakage, because nothing is broken; someone just ignored part of the policy, and we should talk to them about it
+2014-04-16 20:28:58	@Zero_Chaos	creffett|irssi: sorry but how is a new undiscussed eclass IN USE not user visible breakage?
+2014-04-16 20:29:06	@WilliamH	wired: the reason for that is slow stabilizations.
+2014-04-16 20:29:11	@Zero_Chaos	creffett|irssi: how do we know the eclass works? it wasn't reviewed at all, by anyone.
+2014-04-16 20:29:35	@Zero_Chaos	creffett|irssi: you want us to pour over every single thing looking for bugs before we are allowed to follow policy?
+2014-04-16 20:29:43	@creffett|irssi	no
+2014-04-16 20:29:55	@creffett|irssi	but if it is not actively hurting somebody, then there is no reason to take immediate action
+2014-04-16 20:30:01	@Zero_Chaos	creffett|irssi: try reading /usr/portage/eclass/python* "real quick" to make sure there is no breakage.
+2014-04-16 20:30:22	@Zero_Chaos	creffett|irssi: so again, you are specifically saying we must wait for users to be harmed by the policy breakage, is that correct?
+2014-04-16 20:30:42	@creffett|irssi	no, I'm saying there needs to be something wrong, not that the users need to be harmed
+2014-04-16 20:30:42	@Zero_Chaos	creffett|irssi: because that isn't "Quality Assurance" that's "Custodial Engineering"
+2014-04-16 20:31:00	@TomWij	creffett|irssi: I think bug #435094 (comment #11) is an example of how we can address things.
+2014-04-16 20:31:01	willikins	TomWij: https://bugs.gentoo.org/435094 "Optional multilib USE flag could cause problems, devs and users could be unaware (was: Force multilib USE flag only on core packages)"; Gentoo Linux, Eclasses and Profiles; RESO, FIXE; mattst88:toolchain
+2014-04-16 20:31:01	@Zero_Chaos	creffett|irssi: fixing something BEFORE it affects users is QA, cleaning up after is janitorial.
+2014-04-16 20:31:10	@creffett|irssi	I would like to assume basic competence on the part of the developer base
+2014-04-16 20:31:32	@Zero_Chaos	creffett|irssi: I'd like to assume I can get any girl I like and I'll be 6 feet tall someday.
+2014-04-16 20:31:52	@Zero_Chaos	creffett|irssi: people make mistakes, honest mistakes, it happens.
+2014-04-16 20:31:56	@wired	I think what creffet is trying to say is that there are qa violations that don't have significant impact to users and we can delay actions on those cases 
+2014-04-16 20:32:26	@TomWij	Zero_Chaos: Even better is if you can prevent it from existing; as that is true QA, but of course often hard to do.
+2014-04-16 20:32:26	@Zero_Chaos	wired: and what I'm saying is that very specifically we wouldn't be the Quality ASSURANCE team in that case.
+2014-04-16 20:33:07	@wired	well it is not always easy to enforce policy in a large group of developers 
+2014-04-16 20:33:09	@Zero_Chaos	TomWij: I agree, but to specficially bind QA from preventing problems before they occur is moving the assumption of perfection from us to the developer community.
+2014-04-16 20:33:46	@Zero_Chaos	creffett|irssi: no matter what we do, some assumptions must be made about the developers at large, and QA itself.  First we assume niether side has no malice, and both sides make mistakes.
+2014-04-16 20:33:57	@creffett|irssi	Zero_Chaos: I am not disagreeing with that
+2014-04-16 20:34:27	@Zero_Chaos	creffett|irssi: now all that is left is do we want to assume it's more likely QA will make mistakes, or the developers will make mistakes? Further we need to see what the negative impact of those mistakes are.
+2014-04-16 20:34:44	@creffett|irssi	right now? QA's making the mistakes.
+2014-04-16 20:34:53	@Zero_Chaos	creffett|irssi: if a dev screws up, people can lose everything. if QA screws up, a perfectly good package isn't in use for a few days while we discuss.
+2014-04-16 20:35:20	@Zero_Chaos	creffett|irssi: I'd rather have QA have the power to prevent breakage, and admit sometimes they are wrong, rather than wait for breakage to be assured and damage the users.
+2014-04-16 20:35:45	@Zero_Chaos	creffett|irssi: I realize everyone wants to be in charge, but sadly, we are harming our users, here and now.
+2014-04-16 20:35:55	@TomWij	A mask is just a mask.
+2014-04-16 20:36:00	@Zero_Chaos	exactly
+2014-04-16 20:36:18	@Zero_Chaos	worst case, we masked something improperly, remove the mask, users didn't get a change for a few days
+2014-04-16 20:36:22	@Zero_Chaos	no harm, no foul.
+2014-04-16 20:36:25	@TomWij	It sits there between Gentoo and the users; it even allows the developers to continue their work, although in a way that the users won't get their updates.
+2014-04-16 20:36:39	@TomWij	It's perceived as a weapon by some; however, it isn't. It's just a temporary measure.
+2014-04-16 20:37:05	@Zero_Chaos	if there is malice in a QA mask that's an entirely different matter, what we are dicussing here is trying to help the users before injury vs digging them out of the hole we let them fall in.
+2014-04-16 20:38:08	@wired	I need to relocate, I'll be back in 10m
+2014-04-16 20:38:09	 *	antarus lurks
+2014-04-16 20:38:14	@Zero_Chaos	I don't see how we expect the QA team to Assure Quality if we are not allowed to attempt to prevent breakage.
+2014-04-16 20:38:18	@creffett|irssi	antarus: oh, hi there.
+2014-04-16 20:38:23	@creffett|irssi	antarus: any input on the discussion so far?
+2014-04-16 20:38:26	@Zero_Chaos	WORST CASE, we mask something, remove it, no big deal.
+2014-04-16 20:38:34	@TomWij	creffett|irssi: This all then boils down to "what is perceived as breakage?" and the whole way the GLEP addresses that.
+2014-04-16 20:38:40	@Zero_Chaos	vs an undiscussed change that causes massive breakage.
+2014-04-16 20:38:59	@creffett|irssi	TomWij: the glep does not address it sufficiently, thus the problem.
+2014-04-16 20:39:01	 *	Tommy[D] will be back in some minutes
+2014-04-16 20:39:07	@Zero_Chaos	TomWij: this really boils down to people understanding a mask isn't a weapon.
+2014-04-16 20:39:15	@creffett|irssi	Zero_Chaos: but most undiscussed changes will _not_ cause breakages
+2014-04-16 20:39:21	@creffett|irssi	and there can be discussed changes which do
+2014-04-16 20:39:38	@TomWij	Iotw "Ukraine and Russia are starting a war. Do you want to mask? [Y/N]"
+2014-04-16 20:39:43	@creffett|irssi	your assumption seems to be something down the lines of "if it's not discussed, it's going to break things"
+2014-04-16 20:39:48	@Zero_Chaos	creffett|irssi: I agree with you 100%, BUT 100% of masks won't cause breakage. So masking something is much safer than not if there is a question.
+2014-04-16 20:40:16	@Zero_Chaos	creffett|irssi: no, I'm saying there is a ZERO percent chance of a QA mask hurting the users, and a slim chance not masking something will.
+2014-04-16 20:40:30	 *	creffett|irssi sighs
+2014-04-16 20:40:48	@creffett|irssi	fine, we will remain as-is, and revisit this later if the issue comes up again
+2014-04-16 20:40:54	@Zero_Chaos	creffett|irssi: we cannot possibly hurt the users by masking something we feel breaks policy, et al.  The reverse cannot be said.
+2014-04-16 20:41:22	antarus	creffett|irssi: I think generally I expect masks to be backed up by some sort of policy
+2014-04-16 20:41:28	@Zero_Chaos	creffett|irssi: honestly, comrel needs to be there when the devs cannot discuss like people (it happens to us all) or when there is direct and obvious malice.
+2014-04-16 20:41:36	antarus	I don't think actual user breakage is necessary
+2014-04-16 20:41:37	@Zero_Chaos	creffett|irssi: past that, it's not their job.
+2014-04-16 20:41:40	@TomWij	(Answer: If you don't mask, they'll have their resolution and/or fight, hard to tell which; if you mask, they perceive it as a weapon and you get world war until we understand a world war isn't the most efficient way to become powerful and/or solve problems.)
+2014-04-16 20:41:51	antarus	creffett|irssi: if you want comrel to mask for policy violations (rather than user breakages)
+2014-04-16 20:41:55	antarus	I'm happy to discuss
+2014-04-16 20:41:57	@creffett|irssi	I suggest we adjourn until 1850, since wired and Tommy[D] are both out, and I need to run to my next class anyway
+2014-04-16 20:42:14	@Zero_Chaos	heh
+2014-04-16 20:42:18	 *	WilliamH agrees with antarus, if we qa mask something we should cite the policy that  we are using in the mask message.
+2014-04-16 20:42:51	@Zero_Chaos	antarus: 
+2014-04-16 20:42:52	@Zero_Chaos	@creffett|irssi> first on the agenda: after discussion with antarus, we're going to be backing off a little on the "enforcement" of policies and leaving that to comrel
+2014-04-16 20:42:56	@Zero_Chaos	14:09 <@creffett|irssi> the general idea is that if someone's breaking policy, we ask them nicely, and if they refuse, we pass it to comrel
+2014-04-16 20:43:04	@Zero_Chaos	antarus: to catch you up, that was the start of this discussion.
+2014-04-16 20:43:30	@Zero_Chaos	antarus: I am against this, as we have policies to prevent breakage, ignoring them isn't a matter for comrel, it's a matter for Quality Assurance, imho.
+2014-04-16 20:44:06	@Zero_Chaos	antarus: comrel is for personal inability to discuss something technically (like how for instance Samuli and I both got a bit heated) or direct malice.
+2014-04-16 20:44:23	@Zero_Chaos	antarus: unless I'm missing something, technical policy enforcement is our charter, not comrels.
+2014-04-16 20:44:26	@zlogene	oops i have a hard problem, should be back ASAP, (but not sure right now).On line anyway.
+2014-04-16 20:44:38	@Zero_Chaos	zlogene: I think we are on break for a few anyway.
+2014-04-16 20:45:03	antarus	Zero_Chaos: well the aforementioned eclass policy could be construed as a policy issue (but not a user-affecting issue)
+2014-04-16 20:45:10	@WilliamH	Zero_Chaos: what about willful violation of policy?
+2014-04-16 20:45:12	antarus	so who owns that one?
+2014-04-16 20:45:23	@TomWij	WilliamH: Willful / repeated is ComRel.
+2014-04-16 20:45:31	@Zero_Chaos	antarus: eclasses are technical issues not personal, QA does.
+2014-04-16 20:45:38	@Zero_Chaos	antarus: that's not even blurry to me.
+2014-04-16 20:46:04	@Zero_Chaos	WilliamH: willful violation of policy is both, QA corrects things technically and comrel deals with the malice since we lack the power to do so.
+2014-04-16 20:46:06	antarus	to speak bluntly
+2014-04-16 20:46:11	@Zero_Chaos	antarus: please :-)
+2014-04-16 20:46:34	@WilliamH	Zero_Chaos: but if the eclass  doesn't break things there is no breakage.
+2014-04-16 20:46:47	antarus	I don't mind if qa members mask things if they communicate clearly what they did, why they did it, and what the remediation is, and they cite the relevant policies
+2014-04-16 20:46:50	@WilliamH	Zero_Chaos: so that the dev didn't discuss it isn't our issue really.
+2014-04-16 20:46:56	antarus	becuase you are in essence utilizing your authority over other people
+2014-04-16 20:47:03	antarus	and it needs to be clear to them why
+2014-04-16 20:47:57	@Zero_Chaos	WilliamH: sorry that's not how that works. If a new "whatever" is introduced and there is supposed to be policy requiring discussion then to not discuss it is violating policy and has the potential to affect users. we are here to PREVENT breakage not to pour over undiscussed code looking for mistakes before we can act.
+2014-04-16 20:48:16	antarus	(I will avoid making the qa-as-cops comparison)
+2014-04-16 20:48:23	antarus	but I think there are similarities there
+2014-04-16 20:48:36	@Zero_Chaos	WilliamH: again, if QA masks something the worst case is we are wrong and the users get is in a few days. If we don't mask something and it turns out to break, much worse things can happen.
+2014-04-16 20:48:58	@Zero_Chaos	WilliamH: I'm going to introduce a new kernel-builder.eclass soon, and move all kernel sources to using it.
+2014-04-16 20:49:15	@Zero_Chaos	WilliamH: when I do that without any discussion, do you think ANYONE will let that stand until breakage is reported?
+2014-04-16 20:49:37	@TomWij	antarus: And ComRel is Committee P?
+2014-04-16 20:49:41	@TomWij	(:P)
+2014-04-16 20:50:00	dilfridge	nope, just shady conspiracy :D
+2014-04-16 20:50:23	 *	wired back
+2014-04-16 20:50:33	@Zero_Chaos	antarus: expecting either side to be perfect is irrational, but when QA messes up, no one is really "hurt". In my opinion anyway.
+2014-04-16 20:50:49	antarus	TomWij: not getting it
+2014-04-16 20:51:01	antarus	Zero_Chaos: being wrongfully arrested is a crime
+2014-04-16 20:51:06	@Zero_Chaos	antarus: take my most recent example. barring the rampant asshattery (on both sides), the changes were discussed, the bugs were fixed, and the mask was removed inside of a day.
+2014-04-16 20:51:12	@Zero_Chaos	antarus: not in my country buddy.
+2014-04-16 20:52:00	@TomWij	(Not a joke, just further comparing; because as they say here, the police is your friend)
+2014-04-16 20:52:01	@Zero_Chaos	antarus: now if there were no QA mask, ~arch was broken with circular deps, and there was an open stable bug which means that stable would have been affected shortly. I see a lot of harm there.
+2014-04-16 20:52:24	@TomWij	antarus: A mask is hardly an arrest though.
+2014-04-16 20:52:57	antarus	TomWij: legally, the police are not your friends
+2014-04-16 20:52:58	@Zero_Chaos	a mask isn't "OMG you are a terrible person and must die!" it's more like "whoa, hold on, let's look at this"
+2014-04-16 20:53:07	antarus	but I digress ;)
+2014-04-16 20:53:13	@Zero_Chaos	removing things from the tree is "DIE DIE DIE"
+2014-04-16 20:53:28	@Zero_Chaos	a mask is just a "this needs review/discussion/majorfix/etc"
+2014-04-16 20:53:55	antarus	TomWij: I use them here as they are both 'uses of authority'
+2014-04-16 20:54:00	@Zero_Chaos	we need to either assume both parties are acting without malice or we need to involve comrel like they should be involved when there is malice.
+2014-04-16 20:54:14	@Zero_Chaos	masks aren't a punishment.
+2014-04-16 20:54:29	@Zero_Chaos	I've masked my own packages before, I didn't take any offense :-)
+2014-04-16 20:56:16	antarus	as I said, in the past things were not...on the level?
+2014-04-16 20:56:46	@Zero_Chaos	antarus: go back to speaking bluntly, clarity is important here.
+2014-04-16 20:57:29	@ulm	do I see it right, we are at one hour and haven't finished with any agenda topic yet? ;)
+2014-04-16 20:57:43	@wired	yup
+2014-04-16 20:57:45	antarus	hehe
+2014-04-16 20:57:52	@wired	you could say the meeting starts now
+2014-04-16 20:57:53	@creffett|irssi	let's get going
+2014-04-16 20:57:54	@ulm	well, roll call is done ;)
+2014-04-16 20:58:11	@creffett|irssi	someone got the agenda up? what's next? /me mobile right now, so a pain to switch back and forth
+2014-04-16 20:58:17	antarus	Zero_Chaos: so using the samuli as an example
+2014-04-16 20:58:24	@TomWij	Masks are like "It is fine for the Portage tree where ~200 devs can test if it's not broken, but it needs at least a bit of peer review before releasing this (possible / actual) breakage to OVER 9000 users". 
+2014-04-16 20:58:27	antarus	it looked as though you tackled him to the ground
+2014-04-16 20:58:33	antarus	and then beat him repeatedly
+2014-04-16 20:58:38	@ulm	creffett|irssi: GTK flags is next, I think
+2014-04-16 20:58:39	antarus	and then masked his package ;p
+2014-04-16 20:58:55	@Zero_Chaos	creffett|irssi: we hadn't really finished with the first topic yet... or had we?
+2014-04-16 20:58:59	@creffett|irssi	okay, I think that one gets pushed back since we just send the mail
+2014-04-16 20:59:09	@creffett|irssi	Zero_Chaos: I said that we'll just stay as-is and revisit if we have further issues
+2014-04-16 20:59:10	@TomWij	(https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda)
+2014-04-16 20:59:25	@Zero_Chaos	antarus: moving to pm to avoid disrupting the meeting
+2014-04-16 20:59:39	@wired	15m => 1h, yeah, nailed that first topic :p
+2014-04-16 21:00:01	antarus	sure
+2014-04-16 21:00:20	@TomWij	creffett|irssi: Yes, let's keep things as-is; several of us have a different view of this, both you and me have thought about ways to steer it when it happens, it'll happen different (and hopefully better) next time.
+2014-04-16 21:00:51	@wired	* Where are the GNOME and QA team at with the GTK flag issue? [~ 5 min] (Mail was sent, either defer agenda item or ask leio or eva [were working on something])
+2014-04-16 21:01:27	@TomWij	I know that weeks before the mail, Eva was working on reviewing all the gtk* packages in the tree; not sure what the progress on that is, other than that I guess we'll await response to the mail?
+2014-04-16 21:01:37	 *	WilliamH hasn't heard a word from the gnome guys
+2014-04-16 21:01:56	@TomWij	We could ask; but given the mail went out late, that might be too early.
+2014-04-16 21:01:59	leio	We have heard absolutely nothing from the QA people, so eva deferred finishing the work until useful stuff is done, like getting gnome 3.12 to the tree.
+2014-04-16 21:02:01	@WilliamH	I guess my question is, how long do we wait?
+2014-04-16 21:02:02	@creffett|irssi	we'll push that one back
+2014-04-16 21:02:15	@TomWij	leio: Did you receive the mail WilliamH has sent out?
+2014-04-16 21:02:17	leio	QA people haven't even contacted us, at all, sans that possible mail you are talking about now.
+2014-04-16 21:02:27	@creffett|irssi	leio: we sent a mail a few days ago
+2014-04-16 21:02:37	@WilliamH	leio: you didn't get the mail to gnome@g.o that was sent a few days ago?
+2014-04-16 21:02:39	@creffett|irssi	check your spam folder :)
+2014-04-16 21:03:01	leio	I was busy with work and just got back from abroad, so no, I haven't seen that yet
+2014-04-16 21:03:16	@WilliamH	leio: it was sent a few days back.
+2014-04-16 21:03:25	leio	https://docs.google.com/spreadsheet/ccc?key=0Aj3aOd1GtLyadHpVTUVnYk1IT200empIcVMzdmlkQVE#gid=0 was eva's working sheet
+2014-04-16 21:03:40	 *	WilliamH looks for the date
+2014-04-16 21:03:43	@TomWij	(Date: Sat, 12 Apr 2014 21:49:43 -0500 From: William Hubbs <williamh@gentoo.org> To: gnome@gentoo.org Cc: qa@gentoo.org Subject: gtk use flag situation)
+2014-04-16 21:03:46	@creffett|irssi	leio: we don't need a response, but could you verify that you got the mail?
+2014-04-16 21:04:03	leio	ok, but I need to find my mouse :)
+2014-04-16 21:04:10	@creffett|irssi	leio: sounds good
+2014-04-16 21:04:20	@wired	mouse? you still use that thing? xD
+2014-04-16 21:04:27	@WilliamH	heh
+2014-04-16 21:04:48	leio	I haven't found a good brain to computer interface yet, that would be open source
+2014-04-16 21:04:55	leio	that would be more effective than keyboard and mouse
+2014-04-16 21:05:14	@zlogene	wired: now about pc :P 
+2014-04-16 21:05:22	 *	WilliamH thinks brain-computer interfaces are sort of scary... well not them specifically, but the implications...
+2014-04-16 21:05:23	@zlogene	*how
+2014-04-16 21:05:37	@creffett|irssi	while we wait, next topic: dynamic-deps, revbumps, etc.
+2014-04-16 21:05:37	@WilliamH	if/when that tech falls into the wrong hands
+2014-04-16 21:05:42	@wired	* Rely on dynamic dependencies (has binpkg and subslot problems), revision bumps (causes some unnecessary rebuilds) or keep status quo when changing dependencies in an existing ebuild? [~ 10 min]
+2014-04-16 21:05:46	@creffett|irssi	wired++
+2014-04-16 21:06:03	@zlogene	wired: what you will do there without mouse? :p
+2014-04-16 21:06:06	@creffett|irssi	so basically, we need to produce a recommendation for this (or no change)
+2014-04-16 21:06:18	@TomWij	(leio: Thank you for the link.)
+2014-04-16 21:06:31	@creffett|irssi	since right now, if you revbump after changing deps, it breaks binpkgs but dynamic-deps for normal packages handles things fine
+2014-04-16 21:06:34	@creffett|irssi	er
+2014-04-16 21:06:36	@wired	zlogene: mouse exists for games and design apps, but lets leave that for another time :P
+2014-04-16 21:06:38	@creffett|irssi	if you _don't_ revbump
+2014-04-16 21:07:03	@creffett|irssi	opinions? thoughts? edontcare?
+2014-04-16 21:07:11	@Zero_Chaos	creffett|irssi: honestly this topic is above QA. PMS doesn't specifiy how things should be handled.
+2014-04-16 21:07:12	@ulm	dynamic dependencies are a hack and not always working
+2014-04-16 21:07:32	@ulm	e.g. they aren't working if the ebuild has been removed
+2014-04-16 21:07:43	@Zero_Chaos	dynamic deps are indeed a hack and cause all kinds of issues but the flip side is rebuilding libreoffice daily.
+2014-04-16 21:07:46	@ulm	and they are portage specific
+2014-04-16 21:07:48	@WilliamH	Well, if we force a revbump for this, we are adding another stable req to arch teams too just for changing deps.
+2014-04-16 21:07:56	@creffett|irssi	so what do we do? punt it to PMS?
+2014-04-16 21:08:07	@TomWij	Zero_Chaos: The PMS does say dependencies should be merged before certain moments; and thus, by PMS dynamic deps shouldn't even be possible. 
+2014-04-16 21:08:14	@ulm	creffett|irssi: we cannot
+2014-04-16 21:08:30	@creffett|irssi	ulm: why not?
+2014-04-16 21:08:45	@ulm	that would mean to keep metadata of removed ebuilds indefinitely
+2014-04-16 21:08:58	@ulm	otherwise it's not guaranteed to work
+2014-04-16 21:08:59	@Zero_Chaos	TomWij: you are saying that dynamic deps specifically violates pms?
+2014-04-16 21:09:14	@creffett|irssi	ulm: I meant "can we punt this question to the PMS team"
+2014-04-16 21:09:18	@TomWij	So, we need to decide on either the PMS (rev bump) or Portage (dyn deps) approach and correct the other; that is, unless we keep the status quo.
+2014-04-16 21:09:29	@Zero_Chaos	creffett|irssi: fyi this is a VERY long standing issue, I wouldn't expect resolution, just direction of travel.
+2014-04-16 21:09:49	leio	latest e-mail from WilliamH that I see is from 5th April, and only gentoo-commits of him after that. But I found it from spam...
+2014-04-16 21:10:19	@Zero_Chaos	TomWij: I'm okay with either one, leaning towards extending the hack of dynamic deps to binpkgs and PMS
+2014-04-16 21:10:28	@ulm	I'd say always revbump if necessary
+2014-04-16 21:10:29	@creffett|irssi	Zero_Chaos: we can't solve long-standing issues in one meeting? /me removes "cure cancer" from the agenda
+2014-04-16 21:10:56	@TomWij	Zero_Chaos: http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-750008.1 "Build dependencies (DEPEND). These must be installed and usable before any of the ebuild src_* phase functions is executed. [...] Runtime dependencies (RDEPEND). These must be installed and usable before the results of an ebuild merging are treated as usable. [...] Post dependencies (PDEPEND). These must be installed at some point before
+2014-04-16 21:10:56	@TomWij	the package manager finishes the batch of installs."
+2014-04-16 21:11:04	@ulm	maybe introduce an exception that the new revision can go straight to stable if only dependencies are changed
+2014-04-16 21:11:20	dilfridge	that does not solve the issue of libreoffice rebuilds
+2014-04-16 21:11:29	@creffett|irssi	^^ beat me to it
+2014-04-16 21:11:34	@Zero_Chaos	ulm: that's going to piss off a lot of people for "unnessesary rebuilds"
+2014-04-16 21:12:09	@ulm	well, there's libreoffice-bin for them :p
+2014-04-16 21:12:16	@Zero_Chaos	honestly, and I've been on this issue since I became a dev, I think we need to keep the ugly hack of dynamic deps and correct binpkgs and PMS to define it better.
+2014-04-16 21:12:39	@Zero_Chaos	it's too much to rebuild for every little thing but portage needs to know the deps properly, it's critical.
+2014-04-16 21:13:06	wired_	sorry
+2014-04-16 21:13:10	wired_	my vps died
+2014-04-16 21:13:34	@TomWij	You can bend that RDEPEND definition in the PMS by claiming that usable in "results of an ebuild merging are treated as usable" to be usable after you've changed the dependencies; but well, that's quite a loophole. :D
+2014-04-16 21:13:45	@creffett|irssi	so, for now, how abot we push this to portage/PMS teams?
+2014-04-16 21:13:47	wired_	I've missed everything on the last topic
+2014-04-16 21:14:12	@Zero_Chaos	creffett|irssi: I agree with that, however, it should be noted that the portage team is understaffed for this kind of thing.
+2014-04-16 21:14:14	@WilliamH	wired_: the topic is dynamic deps.
+2014-04-16 21:14:26	@TomWij	creffett|irssi: +1 Push this off to both teams.
+2014-04-16 21:14:34	wired_	yeah, I dropped right after I pasted the topic
+2014-04-16 21:14:43	@creffett|irssi	Zero_Chaos: the portage team has somewhere ~20 contributors, I owuld not call them understaffed
+2014-04-16 21:15:11	@Tommy[D]	numbers are not everything ;)
+2014-04-16 21:15:22	@Zero_Chaos	creffett|irssi: then you clearly don't discuss issues of this magnitude with them, because they have told me they do not have the man power to work this due to skill, and the one who could do it refuses.
+2014-04-16 21:15:37	@TomWij	wired_: https://gist.github.com/TomWij/06c4882e8074f6ad2f5f
+2014-04-16 21:15:41	@ulm	creffett|irssi: I predict that neither of the teams will have a solution
+2014-04-16 21:15:57	@Zero_Chaos	creffett|irssi: the only one would could fix this is few_ and he said if he touches dynamic-deps code at all it will only be to remove it.
+2014-04-16 21:15:58	dilfridge	we'd need something like a revbump that only triggers update of metadata
+2014-04-16 21:15:59	wired_	TomWij, thanks
+2014-04-16 21:16:04	@ulm	come up with one and we'll adopt it
+2014-04-16 21:16:06	@creffett|irssi	ulm: then we stay at staus quo
+2014-04-16 21:16:21	 *	antarus is on few_'s side on this one, ftr ;)
+2014-04-16 21:16:24	@ulm	dilfridge: yeah, but how?
+2014-04-16 21:16:27	@Zero_Chaos	dilfridge: same problem as dynamic deps, once the ebuild is gone the information is gone.
+2014-04-16 21:16:38	@creffett|irssi	the alternative of "revbump on all dep changes" is, to be blunt, stupid.
+2014-04-16 21:16:43	dilfridge	i.e. introduce one more version level -r0-s1 (yes I know ugly)
+2014-04-16 21:16:56	@ulm	sub-revisions ;) like sub-slots
+2014-04-16 21:16:59	@creffett|irssi	dilfridge: could have it stored in the ebuild itself
+2014-04-16 21:17:11	@creffett|irssi	METADATA_VERSION="0"
+2014-04-16 21:17:21	dilfridge	but then portage has to read the file
+2014-04-16 21:17:26	@TomWij	dilfridge, creffett|irssi: Sounds like overengineering to me somehow.
+2014-04-16 21:17:33	@Zero_Chaos	creffett|irssi: then devs would need to bump it by hand
+2014-04-16 21:17:43	@creffett|irssi	I'm just spitballing right now
+2014-04-16 21:17:54	@creffett|irssi	so my ideas should be taken with a grain of salt
+2014-04-16 21:17:56	@TomWij	Do we need dependency information in /var/db/pkg?
+2014-04-16 21:18:06	dilfridge	yes.
+2014-04-16 21:18:07	@ulm	TomWij: yes
+2014-04-16 21:18:10	@Zero_Chaos	TomWij: YES
+2014-04-16 21:18:11	@Zero_Chaos	:-)
+2014-04-16 21:18:35	dilfridge	because if a package is removed otherwise things would really go down hard.
+2014-04-16 21:18:35	@TomWij	I guess ... for the subslot information? Or are there other reasons?
+2014-04-16 21:18:56	@ulm	TomWij: it reflects the state of installed packages
+2014-04-16 21:18:56	@Zero_Chaos	TomWij: when ebuilds are removed the only information we have left are in /var/db/pkg
+2014-04-16 21:18:58	dilfridge	(removed from portage)
+2014-04-16 21:19:06	@ulm	including their dependencies
+2014-04-16 21:19:15	@TomWij	dilfridge: But for what do you need to know the dependencies of a package?
+2014-04-16 21:19:17	@Zero_Chaos	TomWij: that's the problem with all of this. when ebuilds are removed
+2014-04-16 21:19:31	@Zero_Chaos	TomWij: if we never removed ebuilds, dynamic deps would be near perfect actually.
+2014-04-16 21:19:32	@ulm	TomWij: for depcleaning, for example
+2014-04-16 21:19:56	@TomWij	Hmm, right; it can't just pick another version from the Portage tree.
+2014-04-16 21:20:15	 *	dilfridge back later
+2014-04-16 21:20:20	@Zero_Chaos	dilfridge: peace
+2014-04-16 21:21:15	@TomWij	ulm: Before a depclean a full world upgrade should be done; and thus, that would ensure you don't have packages with no dependencies...
+2014-04-16 21:21:40	@creffett|irssi	for now, can we agree on pushing this to PMS/portage teams?
+2014-04-16 21:21:44	@TomWij	creffett|irssi: Yes.
+2014-04-16 21:21:46	@Zero_Chaos	yes
+2014-04-16 21:21:49	wired_	yeah
+2014-04-16 21:22:02	@WilliamH	yes
+2014-04-16 21:22:02	@creffett|irssi	good enough for me
+2014-04-16 21:22:09	@creffett|irssi	next topic: QA bugs
+2014-04-16 21:22:12	 *	TomWij still awaits an actual example for why dependencies are needed in /var/db/pkg, feel free to /query or mail me later.
+2014-04-16 21:22:44	@Tommy[D]	by "pushing to PMS/portage team" you mean asking them for their input? or should they decide what to do?
+2014-04-16 21:22:44	@creffett|irssi	the first one--nothing to do there, that's just Pinkbyte following up on our decision a couple months ago re: USE=multislot
+2014-04-16 21:22:53	@creffett|irssi	Tommy[D]: their decision
+2014-04-16 21:23:35	@Tommy[D]	ok with me
+2014-04-16 21:23:37	@creffett|irssi	second bug, re: readme.gentoo.eclass: anyone have input on that?
+2014-04-16 21:24:03	 *	WilliamH doesn't think we can do much there, that eclass isn't part of policy...
+2014-04-16 21:24:29	@ulm	any dev can help with that bug
+2014-04-16 21:24:34	@WilliamH	Right.
+2014-04-16 21:24:42	@ulm	e.g. file bugs for packages
+2014-04-16 21:24:44	@TomWij	WilliamH: Yeah, I think it's somewhat less important than EAPI migration, "respecting *FLAGS" bugs, ...; it's nice to have, but it isn't really covered by policy / a big need / ...
+2014-04-16 21:24:55	@ulm	so it's not a exclusive qa task
+2014-04-16 21:24:56	@TomWij	... but indeed, anyone can still help with it.
+2014-04-16 21:25:06	@creffett|irssi	agreed, we can add it to the list of stuff anyone can help with vaguely QA-related
+2014-04-16 21:25:50	@TomWij	creffett|irssi: And then I've put "..." for input on whether there were other bugs we should look into; because sometimes I see bugs pass on the alias, eg. pax-mark but I wonder if someone looks into them.
+2014-04-16 21:26:16	@creffett|irssi	TomWij: they've been there for a while; whether they're our problem or not is something we can discuss later
+2014-04-16 21:26:22	@TomWij	(Sometimes it's hard to tell what the QA involvement is and whether QA should be involved)
+2014-04-16 21:26:44	@TomWij	Yeah, okay, let's move on them; just wanted to make sure we're not losing our view on open bugs, ... :)
+2014-04-16 21:26:49	@TomWij	then*
+2014-04-16 21:28:01	@creffett|irssi	kk
+2014-04-16 21:28:43	@creffett|irssi	next: handling internal disagreements
+2014-04-16 21:29:18	@Zero_Chaos	"I"ll kill you all!!!!"
+2014-04-16 21:29:36	@creffett|irssi	sounds about right.
+2014-04-16 21:29:42	@TomWij	creffett|irssi: That agenda item is based on rich0's mails to us.
+2014-04-16 21:29:43	@WilliamH	lol
+2014-04-16 21:29:49	@creffett|irssi	TomWij: I know
+2014-04-16 21:30:07	@Zero_Chaos	I think it's important that we clarify that the team is allowed to act individually. Some people seem to think we need to vote on EVERY SINGLE LITTLE THING and that's just not useful.
+2014-04-16 21:30:23	@creffett|irssi	my suggestion: even if you don't agree with a QA member's action, back them publicly, discuss privately
+2014-04-16 21:30:40	wired_	or don't say anything publicly
+2014-04-16 21:30:40	@Zero_Chaos	I think using best judgement as when to ask others, and discussion when needed.
+2014-04-16 21:30:43	@Zero_Chaos	creffett|irssi: great idea
+2014-04-16 21:30:53	@creffett|irssi	and if there is an issue, we discuss, we vote, and then we make a change if needed--but we only change after discussion
+2014-04-16 21:31:01	wired_	you don't have to agree, just don't make a big deal of it in public
+2014-04-16 21:31:06	@TomWij	wired_++, don't even back them
+2014-04-16 21:31:08	@creffett|irssi	wired_: works for me
+2014-04-16 21:31:17	@creffett|irssi	but don't disagree in public is the end goal
+2014-04-16 21:31:28	@TomWij	creffett|irssi: What is considered public? :D
+2014-04-16 21:31:59	@ulm	any public medium
+2014-04-16 21:32:00	@TomWij	I mean, when the discussion is in #gentoo-qa; we have no #gentoo-qa-private.
+2014-04-16 21:32:07	@ulm	mailing lists, irc etc.
+2014-04-16 21:32:08	@TomWij	Or should we then move to the mail alias?
+2014-04-16 21:32:40	@TomWij	Though the mail alias is slow.
+2014-04-16 21:33:08	@ulm	TomWij: not sure
+2014-04-16 21:33:19	@Zero_Chaos	TomWij: the mail alias is slow, but it actually gets the whole team, unlike irc.
+2014-04-16 21:33:20	@ulm	reading long irc backlogs is slow, too
+2014-04-16 21:33:50	@creffett|irssi	I'd suggest the alias for this
+2014-04-16 21:34:10	@TomWij	Zero_Chaos, ulm: Good points, thanks.
+2014-04-16 21:34:50	 *	WilliamH is concerned still about the definition of "breakage", is that something we should discuss somewhere else?
+2014-04-16 21:35:04	@creffett|irssi	WilliamH: I think we need a whole meeting for that argument.
+2014-04-16 21:35:06	@Zero_Chaos	creffett|irssi: so official policy to not pull support of team members in public without consensus?
+2014-04-16 21:35:25	 *	Zero_Chaos fractures WilliamH's arm
+2014-04-16 21:35:25	@creffett|irssi	Zero_Chaos: yes, and I acknowledge that I wasn't following that policy recently
+2014-04-16 21:35:28	@creffett|irssi	and I'm sorry for that
+2014-04-16 21:35:36	@Zero_Chaos	WilliamH: don't worry, it's not broken.
+2014-04-16 21:35:51	@WilliamH	Zero_Chaos: heh
+2014-04-16 21:36:05	@Zero_Chaos	creffett|irssi: some recent events were not handled in a cohesive manner. I look forward to all of us acting more like a team.
+2014-04-16 21:36:24	@Zero_Chaos	creffett|irssi: i think this policy will help that. we can't all be countermanding each other in public.
+2014-04-16 21:36:37	@creffett|irssi	mhm
+2014-04-16 21:37:02	@TomWij	WilliamH: Would need you to make a full list of the user visible effects, categorize them in different categories and then mark them as not at all breakage, almost not at all breakage, might be breakage, somewhat breakage, half broken, ...
+2014-04-16 21:37:34	@creffett|irssi	so, for an official policy: if a QA member takes an action other team members disagree with, it should be discussed privately within the team, and reverted only by team vote. Team members who disagree with the action should not discuss this until the vote is taken.
+2014-04-16 21:37:40	@creffett|irssi	how's that sound?
+2014-04-16 21:38:02	@ulm	not discuss this *in public*
+2014-04-16 21:38:09	@creffett|irssi	right.
+2014-04-16 21:38:52	@wired	++
+2014-04-16 21:38:53	@creffett|irssi	further additions/comments?
+2014-04-16 21:39:04	@creffett|irssi	if not, I'd like to call a vote
+2014-04-16 21:39:25	@Zero_Chaos	creffett|irssi: I believe the only part of this which is new is the "don't discuss in public". team vote isn't needed for lead/deputy action, so do not wish to tie hands with "only after vote"
+2014-04-16 21:39:33	@TomWij	creffett|irssi: And leads can still override that? (but are accountable / responsible themselves when doing so)
+2014-04-16 21:39:35	@WilliamH	Can any team member call another member's action up for a vote?
+2014-04-16 21:39:53	@Zero_Chaos	creffett|irssi: specifically in the recent challenge to action, WilliamH and I agreed to talk to a lead/deputy instead of voting.
+2014-04-16 21:40:01	@Zero_Chaos	WilliamH: YES
+2014-04-16 21:40:02	@TomWij	Not in general, as a form of power; but rather, to prevent abuse.
+2014-04-16 21:40:07	@creffett|irssi	WilliamH: yes
+2014-04-16 21:40:12	@creffett|irssi	TomWij: clarify
+2014-04-16 21:40:12	@Zero_Chaos	WilliamH: I'm 100% for that.
+2014-04-16 21:40:22	@Zero_Chaos	WilliamH: but as for anything else, if possible discuss first.
+2014-04-16 21:40:24	@TomWij	creffett|irssi: Clarify what you want me to clarify?
+2014-04-16 21:40:37	@creffett|irssi	TomWij: I want you to clarify the things I want you to clarify. Clearly.
+2014-04-16 21:40:52	@creffett|irssi	TomWij: what actions by leads would be exempt from this rule?
+2014-04-16 21:41:10	@wired	IMO the lead/deputy has the power to overrule any action without vote if they deem it a serious mistake
+2014-04-16 21:41:20	@Zero_Chaos	creffett|irssi: ALL.
+2014-04-16 21:41:21	@wired	but they would be responsible for that action
+2014-04-16 21:41:37	@creffett|irssi	does the rest of the team feel that way?
+2014-04-16 21:41:41	@Zero_Chaos	creffett|irssi: power structure is member, vote of members, deputy overrule, lead overrule.
+2014-04-16 21:42:16	@ulm	the lead cannot overrule a team vote
+2014-04-16 21:42:22	@wired	well, no, lead is lead, but team > lead IMO, if you have 8/10 saying A and lead says B
+2014-04-16 21:42:25	@wired	it's A, bot B
+2014-04-16 21:42:34	@wired	not*
+2014-04-16 21:42:35	@TomWij	creffett|irssi: Ah, "override" here means: QA dev does an action widely breaking a @system package but claims it to fix breakage as a form of abuse, QA lead reverts and takes the accountability / responsibility on him.
+2014-04-16 21:42:41	@Zero_Chaos	okay, so "member, deputy, lead, team vote"?
+2014-04-16 21:42:59	@Zero_Chaos	that seems fair to me ^^
+2014-04-16 21:43:40	@TomWij	creffett|irssi: I was NOT saying "this is a rule affecting the team but not leads", but saying "if someone acts under this rule, can leads undo it without a vote if really necessary?".
+2014-04-16 21:43:49	 *	WilliamH agrees with wired
+2014-04-16 21:44:02	@wired	I feel we are nitpicking this too much
+2014-04-16 21:44:09	@wired	too much politics :p
+2014-04-16 21:44:37	@creffett|irssi	so...someone give me a wording we can all agree on
+2014-04-16 21:44:38	@WilliamH	The deputy then the lead are the highest authority on the team.
+2014-04-16 21:45:03	@TomWij	wired, Zero_Chaos: Yes, "member, deputy, lead, team vote"; I'm talking about the action by the member, not about the vote of the team.
+2014-04-16 21:45:04	@WilliamH	so they have the authority to override any actions.
+2014-04-16 21:45:26	@ulm	it's outlined in glep 48
+2014-04-16 21:45:44	@WilliamH	and remember the lead is approved by the council.
+2014-04-16 21:45:45	@Zero_Chaos	A team member may act on their own.  Any action by a member may be overruled by the deputy or lead without a vote if needed, however, the highest authority in the team will be a team vote.
+2014-04-16 21:45:47	@ulm	if there's disagreement amongst members, a team vote is needed
+2014-04-16 21:45:53	@Zero_Chaos	something like this ^^?
+2014-04-16 21:46:03	@ulm	that includes disagreements between a member and the lead
+2014-04-16 21:46:55	@TomWij	Zero_Chaos: Where did the discuss in private go? :D
+2014-04-16 21:47:55	@WilliamH	ulm: ok, so if I do something and creffett removes me from the team for it, can the rest of the team force him to reinstate me?
+2014-04-16 21:48:30	@creffett|irssi	that one I will object to; removing people from the team is the one power that is explicitly given to the team lead
+2014-04-16 21:48:37	@ulm	WilliamH: can the lead actually remove members from the team?
+2014-04-16 21:48:42	@Zero_Chaos	A QA team member may act on their own. If there is any dispute of a QA member's action, it should be in private. Any action by a member may be overruled by the deputy or lead without a vote if needed, however, the highest authority in the team will be a team vote.
+2014-04-16 21:48:46	@Zero_Chaos	better?
+2014-04-16 21:49:15	@Zero_Chaos	creffett|irssi: where do you see that power assigned to you?
+2014-04-16 21:49:18	@creffett|irssi	wait, no it isn't
+2014-04-16 21:49:19	@WilliamH	ulm: I think so?
+2014-04-16 21:49:19	@creffett|irssi	adding people is
+2014-04-16 21:49:24	@Zero_Chaos	creffett|irssi: bingo
+2014-04-16 21:49:25	@creffett|irssi	oh well
+2014-04-16 21:49:27	@TomWij	Zero_Chaos: Isn't this in metastructure?
+2014-04-16 21:49:36	@Zero_Chaos	TomWij: show me, I've never seen it
+2014-04-16 21:49:52	@WilliamH	flameeyes sure did ;-)
+2014-04-16 21:49:55	@Zero_Chaos	anyway, shall we add this to our wiki page? :
+2014-04-16 21:49:57	@Zero_Chaos	A QA team member may act on their own. If there is any dispute of a QA member's action, it should be in private. Any action by a member may be overruled by the deputy or lead  without a vote if needed, however, the highest authority in the team will be a team vote.
+2014-04-16 21:50:01	@Zero_Chaos	^^ ?
+2014-04-16 21:50:05	@wired	QA team members may act on their own. All internal disagreements on said actions must be handled privately between QA members. The Lead/Deputy may revert any action if they believe it was a mistake, but they will be held responsible for that change. All disagreements are to be settled by team votes.
+2014-04-16 21:50:05	@wired	or something
+2014-04-16 21:50:29	@TomWij	Zero_Chaos: It neither says something about voting. :-$
+2014-04-16 21:50:37	@ulm	wired: that sounds good
+2014-04-16 21:50:41	@creffett|irssi	+1
+2014-04-16 21:50:46	@Zero_Chaos	wait one
+2014-04-16 21:50:52	 *	creffett|irssi waits
+2014-04-16 21:51:04	@Zero_Chaos	"All disagreements are to be settled by team votes" is a requirement
+2014-04-16 21:51:08	@Zero_Chaos	not an option
+2014-04-16 21:51:11	@Zero_Chaos	it needs to be an option
+2014-04-16 21:51:23	@Zero_Chaos	If the lead acts we don't have to vote still
+2014-04-16 21:51:25	@TomWij	Again, where did the discussion in private go?
+2014-04-16 21:51:35	@TomWij	Ah
+2014-04-16 21:51:40	 *	TomWij reads *again*.
+2014-04-16 21:51:40	@Zero_Chaos	TomWij: you are skipping lines dude ;-)
+2014-04-16 21:52:22	@Zero_Chaos	"If the Lead/Deputy action is disputed a team vote will be used to settle the disagreement."
+2014-04-16 21:52:26	@Zero_Chaos	is that okay?
+2014-04-16 21:52:35	@Tommy[D]	Zero_Chaos: if the lead acts and everyone does agree, there is no disagreement anymore, so no need to vote, but if there is still some disagreement, there should be a vote
+2014-04-16 21:52:45	@Zero_Chaos	QA team members may act on their own. All internal disagreements on said actions must be handled privately between QA members. The Lead/Deputy may revert any action if they believe  it was a mistake, but they will be held responsible for that change. If the Lead/Deputy action is disputed a team vote will be used to settle the disagreement.
+2014-04-16 21:53:03	wired_	meh
+2014-04-16 21:53:21	@Zero_Chaos	Tommy[D]: "All disagreements" means that once there is a disagreement it must be voted upon.
+2014-04-16 21:53:29	@Tommy[D]	Zero_Chaos: now you are missing the vote for team member disagreements ;)
+2014-04-16 21:53:40	wired_	something is srly wrong with this thing today. haven't read anything after my last message
+2014-04-16 21:54:09	@TomWij	wired_: Don't worry, we're forming the statement we'll vote on; I think Zero_Chaos will very soon post another revision of it.
+2014-04-16 21:54:13	@Tommy[D]	the last suggestion from wired looks good to me
+2014-04-16 21:54:30	@WilliamH	Zero_Chaos: I don't quite read it that way. The statement with "all disagreements" just refers to not discussing them in public.
+2014-04-16 21:54:36	@Zero_Chaos	QA team members may act on their own. All internal disagreements on said actions must be handled privately between QA members. The Lead/Deputy may revert any action if they believe  it was a mistake, but they will be held responsible for that change. Any action which is disputed can be settled by a team vote.
+2014-04-16 21:55:08	@Zero_Chaos	WilliamH: the line in question read: "All disagreements are to be settled by team votes" that means if there is a disagreement it MUST be voted on.
+2014-04-16 21:55:14	@creffett|irssi	One addition: "by a team vote, and the result of that vote will be the final decision"
+2014-04-16 21:55:18	wired_	well, it should be
+2014-04-16 21:55:26	@creffett|irssi	just to make it clear that a team vote trumps all
+2014-04-16 21:55:36	wired_	if there's a disagreement, I want it settled
+2014-04-16 21:55:40	wired_	not floating around
+2014-04-16 21:56:06	@Zero_Chaos	QA team members may act on their own. All internal disagreements on said actions must be handled privately between QA members. The Lead/Deputy may revert any action if they believe  it was a mistake, but they will be held responsible for that change. Any action which is disputed can be settled by a team vote, and the result of that vote will be the final decision.
+2014-04-16 21:56:11	@Zero_Chaos	^^ vote?
+2014-04-16 21:56:23	@TomWij	Wait.
+2014-04-16 21:56:30	@Zero_Chaos	waiting :-)
+2014-04-16 21:56:38	@TomWij	How about non-internal disagreements?
+2014-04-16 21:56:49	@WilliamH	TomWij: separate issue.
+2014-04-16 21:56:57	@Zero_Chaos	those are obviously not required to be in private :-)
+2014-04-16 21:57:03	@WilliamH	TomWij: not relevant for this vote.
+2014-04-16 21:57:13	@TomWij	Okay.
+2014-04-16 21:57:20	@Zero_Chaos	this is our policy for us
+2014-04-16 21:57:28	@TomWij	+1 on Zero_Chaos last statement.
+2014-04-16 21:57:32	@Zero_Chaos	there is already an escalation policy for people outside QA disputing QA actions.
+2014-04-16 21:57:35	@Zero_Chaos	so vote
+2014-04-16 21:57:43	@creffett|irssi	+1 from me
+2014-04-16 21:57:47	@Zero_Chaos	+1
+2014-04-16 21:57:59	@ulm	+1
+2014-04-16 21:58:07	@Tommy[D]	+1
+2014-04-16 21:58:15	 *	WilliamH yes
+2014-04-16 21:58:40	@Zero_Chaos	that's 6, and poor wired is probably still having connection issues.
+2014-04-16 21:58:51	@wired	+1, but can be settled sounds vague
+2014-04-16 21:59:00	@creffett|irssi	7, good enough for me
+2014-04-16 21:59:20	@Zero_Chaos	wired: it really isn't, it means you *can* vote but you are not required to.
+2014-04-16 21:59:31	@Zero_Chaos	creffett|irssi: may i add this to the wiki then?
+2014-04-16 21:59:36	@creffett|irssi	since we've been going two hours, I suggest that we handle one minor issue, then meet again next Wednesday
+2014-04-16 21:59:39	@creffett|irssi	Zero_Chaos: go for it
+2014-04-16 21:59:46	@wired	I want to settle all issues, so can't is vague for me
+2014-04-16 21:59:54	@wired	I don't want to leave conflicts around
+2014-04-16 22:00:26	@creffett|irssi	wired: it will be settled in some capacity, and I don't expect that people who have disputes will let them go until they've been completely settled :)
+2014-04-16 22:00:29	@TomWij	* Where and how will we document what QA processes for both current and future Gentoo Developers and QA members? (Per Council meeting: "the council notes that QA is looking into documenting their process"). [~ 5 min]
+2014-04-16 22:00:30	@TomWij	* Are there unclarities wrt what "QA team" and similar things mean in GLEP 48? An individual or the whole team? With agreement or not? Do we need to suggest a change to Council? [~ 10 min]
+2014-04-16 22:00:30	@TomWij	* Move QA policies to the devmanual? [~ 5 min]
+2014-04-16 22:00:30	@TomWij	* What will we do about the missing QA meeting logs and summaries? [~ 5 min]
+2014-04-16 22:00:33	@TomWij	^ Take your pick. :D
+2014-04-16 22:00:37	@Tommy[D]	if you want a vote, request it and you get it, but if someone wants to leave the discussion without vote, that should be ok too
+2014-04-16 22:00:46	@Zero_Chaos	wired: then it would be voted on, or abandoned (and there is no more conflict)
+2014-04-16 22:00:47	@creffett|irssi	I'm up for the last one
+2014-04-16 22:01:08	@wired	creffett|irssi: yeah, thats what I'm hoping for. TBH, this policy is a bit redundant, the only important thing stated here is that we should avoid conflicts in the open so we don't look bad
+2014-04-16 22:01:11	@creffett|irssi	can I get volunteers to find, summarize, and email out/add to wiki the results of both this meeting and the last meeting?
+2014-04-16 22:02:30	@creffett|irssi	last meeting wasn't too bad, the only major change iirc was clarifying the drop-last-stable policy
+2014-04-16 22:02:34	@creffett|irssi	don't all volunteer at once.
+2014-04-16 22:03:20	@Zero_Chaos	creffett|irssi: way to kill a meeting dude
+2014-04-16 22:03:23	@Zero_Chaos	:-)
+2014-04-16 22:03:31	@TomWij	creffett|irssi: You're going to have to pick people. :D
+2014-04-16 22:03:32	@WilliamH	lol
+2014-04-16 22:03:39	@Zero_Chaos	fine, I'll do this meeting
+2014-04-16 22:03:46	@creffett|irssi	Zero_Chaos: thank you
+2014-04-16 22:03:49	@Zero_Chaos	someone else volunteer, not like I want to do this either.
+2014-04-16 22:03:58	@creffett|irssi	WilliamH: congratulations, you get to take care of last meeting's summary
+2014-04-16 22:04:13	 *	WilliamH doesn't have a backlog
+2014-04-16 22:04:31	@Zero_Chaos	WilliamH: that was an expensive lol, I hope it was heartfelt and enjoyable.
+2014-04-16 22:04:43	@creffett|irssi	who does have a log of last meeting?
+2014-04-16 22:04:51	@Zero_Chaos	not I
+2014-04-16 22:04:57	wired_	I probably have one
+2014-04-16 22:05:01	@Zero_Chaos	that's why i volunteer for this week :-)
+2014-04-16 22:05:08	wired_	lemme check
+2014-04-16 22:05:45	@TomWij	WilliamH: Now you do: https://gist.github.com/TomWij/9d033e0fbb5ce4e43568
+2014-04-16 22:05:47	@Tommy[D]	you are talking about the meeting on the 26th of march?
+2014-04-16 22:05:51	@Zero_Chaos	creffett|irssi: where in the hell do I add this policy for us on the wiki, I can't pick a place in the wiki that makes sense.
+2014-04-16 22:05:55	@creffett|irssi	Tommy[D]: yes
+2014-04-16 22:06:02	@creffett|irssi	Zero_Chaos: policy page, under team policies
+2014-04-16 22:06:11	@wired	TomWij beat me to it :)
+2014-04-16 22:06:41	@TomWij	Yeah, had it still open.
+2014-04-16 22:06:48	@creffett|irssi	WilliamH: okay, there's your backlog. summarize :)
+2014-04-16 22:07:18	@creffett|irssi	anyway, meet next week, same time same place?
+2014-04-16 22:07:20	@TomWij	Here is a automatically generated summary: {"sentences":["Zero_Chaos: I agree, especially when this summer comes and I actually have a job to keep.","creffett|irssi: who is marking them exp?. creffett|irssi: and on what authority?. in case of doubt me .","creffett|irssi: ^^.","creffett|irssi: I was a little confused on your last point, I think I got it right though.","I apologize, I have a flight to
+2014-04-16 22:07:20	@TomWij	catch."]}
+2014-04-16 22:07:41	@wired	lol
+2014-04-16 22:07:54	@creffett|irssi	that...didn't work at all
+2014-04-16 22:08:03	@TomWij	(Produced with https://github.com/MojoJolo/textteaser)
+2014-04-16 22:08:25	@TomWij	Works quite good on news articles and scientific papers; but yeah, not on meetings.
+2014-04-16 22:08:34	@creffett|irssi	okay, no objections to same time same place
+2014-04-16 22:08:38	 *	creffett|irssi bangs the gavel
+2014-04-16 22:08:39	@Tommy[D]	next week, same time should work, would be nice to have a reminder at least some hours before it (in irc+mail) in case i forgot it 
+2014-04-16 22:08:43	@creffett|irssi	Tommy[D]: will do
+2014-04-16 22:08:47	@Zero_Chaos	https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Action_Policy_and_Internal_Dispute_Resolution <-- anyone have an issue with the heading name?
+2014-04-16 22:08:56	@wired	thanks, c ya guys
+2014-04-16 22:08:59	@Zero_Chaos	thanks all
+2014-04-16 22:09:05	@creffett|irssi	Zero_Chaos: lgtm
+2014-04-16 22:09:30	@Zero_Chaos	creffett|irssi: I always try to figure out what sex act that is for at least 10 seconds before I remember what it means.
+2014-04-16 22:11:51	@TomWij	So, from a quick look the next meeting is about documenting QA processes further (council's statement), are there unclarities in GLEP (raised on project ML, I'll find that mail back by next week) and moving QA policies (and perhaps ComRel's dev handbook) to devmanual as well as about anything that comes up by then.
+2014-04-16 22:12:15	@TomWij	None of them urgent.
+2014-04-16 22:12:51	@WilliamH	TomWij: Yeah, there was a discussion a while back about putting all of our policies in one place, but I don't know what happened to it.
+2014-04-16 22:13:18	@TomWij	WilliamH: It was put at the bottom of https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Current_projects I figured out today.
+2014-04-16 22:17:14	@Zero_Chaos	creffett|irssi: we just do meeting summaries right? we don't preserve the entire meeting log? we probably should have the whole log available to be able to show the summary is correct....
+2014-04-16 22:19:10	@TomWij	Zero_Chaos: We should have the logs online; wired for example did for the first, the second is yet to be filled in.
+2014-04-16 22:20:07	@Zero_Chaos	TomWij: roger that
+2014-04-16 22:24:49	@TomWij	(It's just opinion; but under the thought that we're forming policies that affect all developers, and because of that how they were formed should be available to those interested in them. Otherwise you get the behind closed door effect; or misconceptions, when someone really doesn't understand how we came to a decision, for what reason [background, reasoning, etc...])
+2014-04-16 22:33:00	@Zero_Chaos	TomWij: agreed, I didn't see the other logs and was concerned for exactly those reasons.
diff --git a/meeting-logs/20140423.txt b/meeting-logs/20140423.txt
new file mode 100644
index 0000000..74e7912
--- /dev/null
+++ b/meeting-logs/20140423.txt
@@ -0,0 +1,289 @@
+2014-04-23 18:33:15	 *	zlogene is here 
+2014-04-23 18:33:15	 *	TomWij is here
+2014-04-23 18:33:15	 *	creffett|irssi here
+2014-04-23 18:33:15	@creffett|irssi	showtime
+2014-04-23 18:33:15	 *	Tommy[D]_ hides
+2014-04-23 18:33:15	 *	ulm is here
+2014-04-23 18:33:15	@creffett|irssi	DrEeevil, Pinkbyte, WilliamH, wired, Zero_Chaos: ping
+2014-04-23 18:33:15	@wired	here
+2014-04-23 18:33:15	@wired	from mobile xD
+2014-04-23 18:33:15	@creffett|irssi	6...a bit light, let's wait a couple minutes in case anyone else shows up
+2014-04-23 18:33:15	@creffett|irssi	eh, oh well
+2014-04-23 18:33:15	@creffett|irssi	let's get started
+2014-04-23 18:33:15	@creffett|irssi	topic 1: hacked pkgconfig files
+2014-04-23 18:33:15	@creffett|irssi	thoughts on the matter?
+2014-04-23 18:33:15	@wired	per case, I could think of justified cases 
+2014-04-23 18:33:15	@Tommy[D]_	uh, that matter is pretty old
+2014-04-23 18:33:15	@ulm	isn't this just part of the larger picture that our patches should be sent upstream
+2014-04-23 18:33:15	@TomWij	Upstream where possible, otherwise create one in FILESDIR; I don't think the problem is that bad or complex to justify an eclass, afaik.
+2014-04-23 18:33:15	@creffett|irssi	you tell me
+2014-04-23 18:33:15	@wired	ulm++
+2014-04-23 18:33:15	@ulm	and yes, it doesn't justify an eclass
+2014-04-23 18:33:15	@creffett|irssi	ulm: and what about cases where upstream won't take our changes?
+2014-04-23 18:33:15	@TomWij	And banning, as suggested, kind of keeps the breakage around; I'd rather see us work towards creating (and upstreaming) pkgconfig files.
+2014-04-23 18:33:15	@Tommy[D]_	wired: what justified cases do you have in mind?
+2014-04-23 18:33:15	@creffett|irssi	so...status quo? "We encourge all developers to upstream any changes made to pkgconfig files, just as with any other local changes"
+2014-04-23 18:33:15	@wired	I don't have a specific example in mind atm, I was thinking that patches should be sent upstream and if they don't accept them but they make our life easier, we can keep em
+2014-04-23 18:33:15	@creffett|irssi	I do not like banning pkgconfig edits, since I can imagine cases where it would help (and cases where upstream hates us or something and so would just ignore the patches)
+2014-04-23 18:33:15	@ulm	creffett|irssi: something like that, yes
+2014-04-23 18:33:15	@wired	+1
+2014-04-23 18:33:15	@zlogene	дпеь
+2014-04-23 18:33:15	@zlogene	errr
+2014-04-23 18:33:15	@Tommy[D]_	wired: in which case are gentoo-only *.pc files usefull anyway? If those are not upstream, no other package should use it anyway, so only gentoo-specific or -modified packages would use them
+2014-04-23 18:33:15	@zlogene	lgtm
+2014-04-23 18:33:15	@TomWij	+1
+2014-04-23 18:33:15	@creffett|irssi	Tommy[D]_: thoughts on my suggested opinion?
+2014-04-23 18:33:15	@Tommy[D]_	creffett|irssi: is this only about modified pkgconfig files or also about creation of those?
+2014-04-23 18:33:15	@wired	tommy as I said before, I don't have specific examples in mind
+2014-04-23 18:33:15	@creffett|irssi	Tommy[D]_: if you make one, it should be upstreamed too, so that case falls under these rules
+2014-04-23 18:33:15	@creffett|irssi	thanks for pointing that out
+2014-04-23 18:33:15	@Tommy[D]_	do we have some way to make clear, that a pkgconfig file has been created or modified for gentoo so noone does depend on them?
+2014-04-23 18:33:15	@creffett|irssi	I don't know, but I'm not sure why someone would take our pkgconfig files instead of upstream's, or not check them carefully if we make one ourselves because upstream doesn't provide one
+2014-04-23 18:33:15	@Tommy[D]_	as written in that discussion, if someone with a gentoo system depends on a lib and does see a pkgconfig file installed, he may depend on it, results in failures on all other distros
+2014-04-23 18:33:15	@TomWij	Tommy[D]_: I'd think they should depend on it and even upstream it, having other upstreams push the one upstream to create a pkgconfig file.
+2014-04-23 18:33:15	@Tommy[D]_	maybe some short ewarn line about "pkgconfig file is custom/gentoo-only" if it does not get upstream and continues to exist in gentoo?
+2014-04-23 18:33:15	@creffett|irssi	Tommy[D]_: that's...kind of stupid, to not verify whether something actually provides a pkgconfig file upstream
+2014-04-23 18:33:15	@creffett|irssi	doubt people would see, notice, or care
+2014-04-23 18:33:15	@creffett|irssi	uh, can we suggest putting comments in locally created/modified pkgconfig files? (I assume those support comments, at least)
+2014-04-23 18:33:15	@Tommy[D]_	creffett|irssi: uhm, no, i dont call it stupid, i expect gentoo to install upstream content, so without any hint or notice i expect the installed content to be from upstream
+2014-04-23 18:33:15	@TomWij	Tommy[D]_: You often would look for it after packages have been installed; so, instead of the ewarn, you might as well look into the FILESDIR or patches tarball.
+2014-04-23 18:33:15	@creffett|irssi	Tommy[D]_: the issue is that I really think it's excessive to warn for every custom/patched Gentoo file
+2014-04-23 18:33:15	@Tommy[D]_	creffett|irssi: i dont talk about warning for every file, but something like pkgconfig files, which dont exist in this form upstream/for other distros is imho an important detail
+2014-04-23 18:33:15	@TomWij	A comment could work theoretically; but in practice, I don't see this consistently be done. Unless we grep FILESDIR and check those that don't have a comment yet. Furthermore, even with comments in them; would other maintainers read the pkgconfig contents of other packages when considering to use it?
+2014-04-23 18:33:15	@creffett|irssi	well, an ewarn is frankly useless; most ewarns/elogs/etc. are ignored, and the person would need to be (re)installing it when making their new package dep on the pkgconfig file to actually see it
+2014-04-23 18:33:15	@Tommy[D]_	it is afaik the only way to even get a message out
+2014-04-23 18:33:15	@creffett|irssi	I don't see why we're obligated to get a message out
+2014-04-23 18:33:15	@creffett|irssi	also, while we're arguing, could I get a volunteer to take notes on the meeting?
+2014-04-23 18:33:15	@TomWij	creffett|irssi: Already making a summary here.
+2014-04-23 18:33:15	@Tommy[D]_	hm, would initially also be a hassle to change, but suggest some gentoo-*.pc naming for those pkgconfig files, which cannot be upstreamed?
+2014-04-23 18:33:15	@creffett|irssi	TomWij: thank you
+2014-04-23 18:33:15	@creffett|irssi	Tommy[D]_: I don't know a ton about .pc files, would naming them that way cause any problems?
+2014-04-23 18:33:15	@Tommy[D]_	if it is done consistantly, one would have to do the pkgconfig calls with this gentoo prefix, which should make it pretty obvious, that it is gentoo-only
+2014-04-23 18:33:24	@Tommy[D]_	but it was just a quick idea to avoid the issues mentioned in that discussion from 2 years ago
+2014-04-23 18:33:41	@creffett|irssi	yes, but then this requires more work to make sure that everything calls it with the gentoo- prefix
+2014-04-23 18:34:10	@Tommy[D]_	well, if gentoo creates it, only gentoo could use it, so we control everything calling it, no?
+2014-04-23 18:34:13	@TomWij	Tommy[D]_: I like the naming idea, should work out well in terms of visibility; only one wonder, what do you do once it eventually does arrive upstream, how do you migrate away from the gentoo- prefix version?
+2014-04-23 18:34:56	@TomWij	Hmm, maybe... Break it locally and test whether rev deps still configure?
+2014-04-23 18:35:11	--	Mode #gentoo-qa [+nt]
+2014-04-23 18:35:11	--	Channel created on Sun, 26 Nov 2006 07:42:47
+2014-04-23 18:35:23	@creffett|irssi	Tommy[D]_: yes, I guess so
+2014-04-23 18:35:23	@Tommy[D]_	TomWij: either include it for some time after upstream added a pkgconfig file (transition period) or bump/stable matching versions at the same time
+2014-04-23 18:35:39	@creffett|irssi	how much work would it be to migrate everything to using gentoo-*.pc files?
+2014-04-23 18:35:41	@TomWij	Yeah, multiple options; should work out.
+2014-04-23 18:36:39	@Tommy[D]_	How about encourage upstreaming pkgconfig files now and adding a topic on -dev ML about the gentoo-prefix for those, which are not accepted?
+2014-04-23 18:36:49	@creffett|irssi	+1
+2014-04-23 18:36:56	@TomWij	+1
+2014-04-23 18:37:03	@ulm	+1
+2014-04-23 18:37:03	@wired	+1
+2014-04-23 18:37:07	@zlogene	++
+2014-04-23 18:37:49	@creffett|irssi	okay, sold.
+2014-04-23 18:38:11	@creffett|irssi	next topic: "Are there unclarities wrt what "QA team" and similar things mean in GLEP 48? An individual or the whole team? With agreement or not?"
+2014-04-23 18:38:41	@creffett|irssi	did we cover this sufficiently last time, or is there more to go over?
+2014-04-23 18:40:51	@Tommy[D]_	can you write for clarity, what in your view was covered last time?
+2014-04-23 18:41:29	@creffett|irssi	if I had a summary, I would remember what we covered
+2014-04-23 18:41:36	@creffett|irssi	(in other words: I am blanking right now)
+2014-04-23 18:41:55	@zlogene	creffett|irssi, http://article.gmane.org/gmane.linux.gentoo.project/3509
+2014-04-23 18:42:42	@TomWij	What we have voted on last time should help, that is the order in which we elevate a disagreement; I think that going forward, we can assume that in case of disagreement "QA team" means a vote by the entire team unless otherwise noted or implied by another GLEP 48 compliant policy we have formed.
+2014-04-23 18:42:51	@creffett|irssi	we agreed on the order of action for undoing (dev does action, deputy/lead may revert action unilaterally but take the consequences, team vote overrides that)
+2014-04-23 18:42:54	@creffett|irssi	yes
+2014-04-23 18:43:05	@TomWij	The idea with this agenda item is that the GLEP 48 should be sufficiently clear to most people; and if not, we'd need to suggest a change to the Council.
+2014-04-23 18:43:14	@wired	I'm happy with that 
+2014-04-23 18:43:43	 *	creffett|irssi running to next class, please discuss if we need to clearly indicate any parts of the GLEP which are "any team member" vs "team must agree"
+2014-04-23 18:44:21	@Tommy[D]_	so "QA team" is every member unless there is a disagreement, if the lead takes over, he takes over the term, if we vote, the voters become "QA team"?
+2014-04-23 18:45:31	@ulm	fine with me
+2014-04-23 18:45:39	@zlogene	fine
+2014-04-23 18:45:39	@wired	++
+2014-04-23 18:46:18	@ulm	might still be wise to follow a four-eyes principle for matters that could be controversial
+2014-04-23 18:46:41	@TomWij	Tommy[D]_: So; that means that in case of disagreement, we go further with the statement (the escalation order [member, deputy, lead, team vote]) we've agreed on last week.
+2014-04-23 18:47:04	@Tommy[D]_	TomWij: that is my suggestion
+2014-04-23 18:47:17	@wired	ulm I would consider this best practice whenever possible
+2014-04-23 18:47:26	@TomWij	Ah, I see now; yes.
+2014-04-23 18:47:54	@TomWij	+1 then
+2014-04-23 18:47:56	@Pinkbyte	Hi guys, i am late, sorry
+2014-04-23 18:48:33	@zlogene	hello
+2014-04-23 18:49:13	@Tommy[D]_	Pinkbyte: you just missed one topic, so your opinion on the clarification of the term "QA team"?
+2014-04-23 18:49:54	 *	Pinkbyte looking at backlog of bouncer
+2014-04-23 18:50:10	@Pinkbyte	+1 from me too
+2014-04-23 18:51:01	@TomWij	Pinkbyte: Feel free to vote on "Encourage upstreaming pkgconfig files now and add a topic on -dev ML about prefixing pkgconfig files with gentoo- (eg. gentoo-${PN}.pn), which are not accepted."
+2014-04-23 18:52:15	@Pinkbyte	to be honestly, i think that downstream pkgconfig files should be banned at all
+2014-04-23 18:52:32	@Pinkbyte	i mean, if they are added by downstream
+2014-04-23 18:53:21	@Pinkbyte	modification is a different point, but adding non-existant pkgconfig file will confuse software developers that use Gentoo. Not sure about prefixing stuff though
+2014-04-23 18:54:43	 *	creffett|irssi back
+2014-04-23 18:54:48	@creffett|irssi	hello Pinkbyte 
+2014-04-23 18:54:57	@Tommy[D]_	thats why i suggested a gentoo-prefix for those, which are not accepted by upstream, so software developers dont get confused
+2014-04-23 18:55:55	@creffett|irssi	ulm, Tommy[D]_, etc.: concur, with recommendation that issues which the developer expects to be controversial should always be discussed with a couple other developers before action
+2014-04-23 18:56:11	@creffett|irssi	(so strongly recommend the four-eyes principle, basically)
+2014-04-23 18:56:13	@Pinkbyte	Yeah, so, my conclusion: allow adding only prefixed pkgconfig files and trivial modification(like libdir fixes or other such stuff) for non-prefixed ones
+2014-04-23 18:57:31	@creffett|irssi	Pinkbyte: well, let's start with recommending upstreaming and starting an RFC on prefixing
+2014-04-23 18:57:34	@creffett|irssi	since that's going to break stuff
+2014-04-23 18:58:26	@TomWij	Currently I've listed Pinkbyte's vote on the first one as abstain, as he wants a different / more strong vote; do we want to revise the statement and/or votes, or stay with our decision and look into the situation at a future meeting?
+2014-04-23 18:59:13	 *	creffett|irssi stands by "proceed as discussed, RFC for prefixing"
+2014-04-23 18:59:17	@TomWij	But yeah, the prefixing needs some docs; might as well create a general doc on pkgconfig while we're at it.
+2014-04-23 18:59:20	@creffett|irssi	since I expect stuff to break
+2014-04-23 18:59:22	 *	TomWij agrees with creffett.
+2014-04-23 19:00:42	@wired	me 2
+2014-04-23 19:01:38	@Tommy[D]_	Pinkbyte: are you ok with an RFC on the -dev ML first? If it gets accepted, we can then make the prefix a policy (keep in mind, it was a quick idea from me, did not check all consequences yet)
+2014-04-23 19:02:34	@Pinkbyte	Tommy[D]_, sure, sounds good
+2014-04-23 19:02:50	@Pinkbyte	we need wider discussion with a lot of bikeshedding ;-)
+2014-04-23 19:03:55	@creffett|irssi	k, next topic
+2014-04-23 19:04:01	@creffett|irssi	"Move QA policies to the devmanual"
+2014-04-23 19:04:05	@creffett|irssi	input?
+2014-04-23 19:04:05	@TomWij	And for creffett I've listed the second vote as agreeing with the motion (duo to "concur"), do we want to add his recommendation? "issues which the developer expects to be controversial should always be discussed with a couple other developers before action"?
+2014-04-23 19:04:20	@wired	I like the devmanual idea
+2014-04-23 19:05:39	@Pinkbyte	Me too. It will help new developers, who may lost finding documentation in dozen different places
+2014-04-23 19:05:59	@ulm	can we even distinguish between "qa policy" and "general policy"?
+2014-04-23 19:06:20	@TomWij	I like the devmanual idea; more generic, I like all non-specific (!= GNOME / KDE specific details) information for developers to be in one convenient place.
+2014-04-23 19:07:08	@Pinkbyte	ulm, i think not. All "general policies" are usually established for QA sake
+2014-04-23 19:07:28	@creffett|irssi	well, QA team internal policy stays on the wiki
+2014-04-23 19:07:30	@creffett|irssi	of course
+2014-04-23 19:07:51	@TomWij	Yes, internal should still be separate.
+2014-04-23 19:07:54	@ulm	sure
+2014-04-23 19:08:02	@zlogene	just to clarify, what sort of policy want we move? 
+2014-04-23 19:08:08	@creffett|irssi	and I think that specific stuff should stay on the wiki (such as the gtk situation), whereas more general policy (say, on versioning USE flags) would go to devmanual
+2014-04-23 19:08:47	@wired	++
+2014-04-23 19:08:55	@Tommy[D]_	how to distinguish, what should stay in qa wiki and what should go into devmanual? Also, if things go into devmanual, should it get a seperate chapter for "qa rules to follow"?
+2014-04-23 19:09:04	@TomWij	"Move general recommendations, guidelines and policies for Gentoo Developers to the devmanual"
+2014-04-23 19:09:48	@TomWij	Tommy[D]_: Just categorize it where it fits, I think we'll want to avoid a dry list of QA rules to follow.
+2014-04-23 19:09:49	@ulm	Tommy[D]_: things should go to the section of the devmanual that is relevant
+2014-04-23 19:10:02	@wired	actually, all policies should be in the devmanual, except from internal qa team policies 
+2014-04-23 19:10:39	@creffett|irssi	wired: yes, but some of the decisions are specific enough to not really belong in devmanual
+2014-04-23 19:10:55	@creffett|irssi	so, any objections to moving stuff to devmanual? /me in favor of moving some stuff
+2014-04-23 19:11:00	@wired	well, even the gtk thing is important enough 
+2014-04-23 19:11:31	@TomWij	Wait, to avoid confusion: Are we suggesting the statement we're forming to be an internal QA policy or affect anyone?
+2014-04-23 19:11:31	@wired	I would want devs adding new gtk ebuilds to be aware of that policy 
+2014-04-23 19:11:56	@TomWij	(Iotw, is our goal to move the policies we make to the devmanual or do we want all non-specific pollicies to go to the devmanual?)
+2014-04-23 19:13:00	@creffett|irssi	TomWij: well, both I guess, but the question before us is "should QA team move" not "should everybody move"
+2014-04-23 19:13:10	@zlogene	creffett|irssi, +1, it will useful for new developers 
+2014-04-23 19:13:11	@wired	one place for everything for the developer is my thought 
+2014-04-23 19:13:47	@Tommy[D]_	So question is "Should qa team move everything except internal policies to devmanual?"?
+2014-04-23 19:14:20	@wired	++
+2014-04-23 19:14:25	@ulm	I think devmanual maintainers will also have a say ;)
+2014-04-23 19:14:37	@creffett|irssi	ulm: we administratively own devmanual, if nothing else
+2014-04-23 19:14:38	@creffett|irssi	:P
+2014-04-23 19:15:13	@Pinkbyte	creffett|irssi, that's where evil laughing should be heard
+2014-04-23 19:15:15	@Pinkbyte	:-D
+2014-04-23 19:15:31	@creffett|irssi	we will MAKE THEM follow our demands! muahahaha.
+2014-04-23 19:15:32	@creffett|irssi	no.
+2014-04-23 19:15:33	@wired	lol
+2014-04-23 19:15:48	@creffett|irssi	that said, I don't think hwoarang will have too many issues with us moving stuff
+2014-04-23 19:16:10	@wired	I'll take care of him
+2014-04-23 19:16:16	@wired	harhar
+2014-04-23 19:16:19	@creffett|irssi	so, votes for "QA team to move everything except internal policies to devmanual"?
+2014-04-23 19:16:28	@wired	+1
+2014-04-23 19:16:31	 *	creffett|irssi yes, though the more specific policies will take work to move to devmanual
+2014-04-23 19:16:34	@zlogene	+1
+2014-04-23 19:16:34	@ulm	+1
+2014-04-23 19:16:38	@Tommy[D]_	yes
+2014-04-23 19:16:49	@Pinkbyte	+1 from me
+2014-04-23 19:16:56	@TomWij	Well, you (creffett and ulm) both are members; hwoarang has already stated something along the lines that he doesn't mind if it is formed and reviewed policy, hwoarang also is busy these days, the history of our changes can be tracked and reviewed as well, I don't think this forms a problem. And if it does, we'll hear about it...
+2014-04-23 19:17:06	@creffett|irssi	TomWij: vote?
+2014-04-23 19:17:15	@TomWij	creffett|irssi: I'm not so sure what "everything" means.
+2014-04-23 19:17:30	@creffett|irssi	anything on the policies page that is not marked "QA team policy"
+2014-04-23 19:17:38	@TomWij	eg. I don't want to force GNOME team policies to go there.
+2014-04-23 19:17:50	@TomWij	If it's limited to our non-internal QA made policies; then:
+2014-04-23 19:17:53	@TomWij	+1 from me
+2014-04-23 19:18:01	@creffett|irssi	kk, passes
+2014-04-23 19:18:46	@creffett|irssi	can I get a couple volunteers to start prepping changes for devmanual? (you can push yourself, though I'd suggest the first couple changes go through github pull requests just to make sure they're formatted right and stuff)
+2014-04-23 19:19:56	@wired	I volunteer, God help
+2014-04-23 19:19:59	@wired	me
+2014-04-23 19:20:03	@wired	he he
+2014-04-23 19:20:20	@wired	we should discuss the proper places by email first though 
+2014-04-23 19:20:33	@ulm	creffett|irssi: should be filed as bugs, not pull requests
+2014-04-23 19:21:05	@creffett|irssi	ulm: why not? we have github for a reason
+2014-04-23 19:21:20	 *	ulm won't use non-free software for gentoo development
+2014-04-23 19:21:36	@Tommy[D]_	sorry, plan to get a recruit on board, takes enough time for now 
+2014-04-23 19:22:11	@TomWij	I don't care where, as long as we know about the place and it is tracked; eg. pull requests are one way, but if you do it through bugs then mention the bug number in the commit message. Also point out when and where we decided on a certain policy in the commit message or bug.
+2014-04-23 19:22:34	@creffett|irssi	ulm: okay then
+2014-04-23 19:22:35	@TomWij	(s/or bug/or bug or pull request/)
+2014-04-23 19:22:44	@creffett|irssi	ulm: you're welcome to use bugzie, then
+2014-04-23 19:23:06	@creffett|irssi	wired: thank you for volunteering
+2014-04-23 19:23:59	@TomWij	ulm: Is devmanual.gentoo.org mirrored elsewhere than GitHub?
+2014-04-23 19:24:08	@ulm	creffett|irssi: I won't object others using github, but if you want me to volunteer then don't make github a requirement :p
+2014-04-23 19:24:41	@ulm	TomWij: it's hosted on git.overlays.gentoo.org
+2014-04-23 19:24:42	 *	TomWij isn't sure if devmanual.gentoo.org on GitHub is a mirror af a Gentoo repository or whether it is the only place.
+2014-04-23 19:25:03	@creffett|irssi	ulm: it's not a requirement, just a suggestion
+2014-04-23 19:25:09	@creffett|irssi	TomWij: it's a mirror of a gentoo repo
+2014-04-23 19:25:14	@creffett|irssi	devmanual.git
+2014-04-23 19:25:14	@ulm	http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=summary
+2014-04-23 19:25:21	@creffett|irssi	any dev may push to it iirc
+2014-04-23 19:25:29	@wired	hopefully others will volunteer as well?? xD
+2014-04-23 19:25:41	@creffett|irssi	wired: you may also enlist non-QA devs as your minions
+2014-04-23 19:25:43	@ulm	wired: sure, I do
+2014-04-23 19:26:06	@TomWij	Thanks, I've used pull requests in the past; but reasonably, we're working with a team here that needs to review it and everyone needs to get a mail from it so we might opt to solely do this on Bugzilla instead of either.
+2014-04-23 19:26:11	@wired	++
+2014-04-23 19:27:45	@creffett|irssi	all right, you all may sort that out
+2014-04-23 19:27:54	@creffett|irssi	last topic: documenting QA policy/workflow
+2014-04-23 19:28:01	@creffett|irssi	we've covered some of that today
+2014-04-23 19:28:10	@creffett|irssi	what else do we do that's not really documented?
+2014-04-23 19:29:06	@TomWij	creffett|irssi: We could document how developers can approach and await the QA team.
+2014-04-23 19:30:13	@creffett|irssi	okay
+2014-04-23 19:30:14	@TomWij	eg. Do they file a bug? Do they mail us? Is both fine? When they've mailed, what kind of answer should they wait for (single member, team vote, next meeting summary, ...)? What things can and can't QA be contacted for?
+2014-04-23 19:30:38	@zlogene	first part *where?*
+2014-04-23 19:31:35	@creffett|irssi	well, item 1: they need to tell us what they want, and do so clearly
+2014-04-23 19:31:55	@creffett|irssi	there have been a lot of bugs where QA gets CC'd and nobody says exactly what they want us to decide on
+2014-04-23 19:32:06	@Pinkbyte	Filing a bug seems a best bet IMO. Easier to keep track of things.]
+2014-04-23 19:32:10	@Pinkbyte	creffett|irssi, ++
+2014-04-23 19:32:23	@TomWij	On the Gentoo Wiki, one or two visible links ("How to raise an issue for the QA team?" and "What kind of issues can I bring to the QA team?")
+2014-04-23 19:32:29	@creffett|irssi	to get on the meeting agenda, they just need to email us/ping us and say "Here is the situation, please decide if this is good or bad"
+2014-04-23 19:32:36	@creffett|irssi	or something like that
+2014-04-23 19:32:37	@TomWij	(Or perhaps throw these questions into a FAQ)
+2014-04-23 19:32:52	@creffett|irssi	what kind of issues, now that's a different story
+2014-04-23 19:32:56	@creffett|irssi	"does this violate policy"
+2014-04-23 19:33:04	@creffett|irssi	"should there be a policy against this"
+2014-04-23 19:33:41	@creffett|irssi	what I would like to try to avoid is the more blatant examples of people trying to use the QA hammer against someone else
+2014-04-23 19:33:47	@creffett|irssi	so...more input, please
+2014-04-23 19:35:06	@TomWij	creffett|irssi: The last question (wrt kind of issues) we need to clarify we don't want ComRel matters (existing policy breakage) and that we don't want matters that should be discussed in public first (otherwise we need to make it public under our name), etc...
+2014-04-23 19:35:14	@Tommy[D]_	well, hard to list everything not to bring to qa, so just decide on it case by case?
+2014-04-23 19:35:32	@creffett|irssi	yes
+2014-04-23 19:35:52	@creffett|irssi	but it would still be helpful to suggest stuff we do want and stuff we don't want
+2014-04-23 19:36:49	@Tommy[D]_	"dont bring comrel issues to qa" sounds like "dont bring kde bump requests to qa" ... to obvious to me
+2014-04-23 19:37:00	@Pinkbyte	Tommy[D]_, but needed
+2014-04-23 19:37:08	@Pinkbyte	i made such mistake... well... today :-)
+2014-04-23 19:37:26	@TomWij	Tommy[D]_: Not mention it like that in the literal way; but for the less obvious cases, like how we were CCed today.
+2014-04-23 19:37:39	@Pinkbyte	i am sure, other devs(read non qa team members) can do this too
+2014-04-23 19:37:54	@Pinkbyte	s/can/could/
+2014-04-23 19:38:03	@Pinkbyte	and we do not want this
+2014-04-23 19:38:04	@TomWij	So, more like "if it a lack of communication or breaks existing policy, consider ComRel instead"; less like "we don't take ComRel issues".
+2014-04-23 19:38:31	@creffett|irssi	yes
+2014-04-23 19:38:39	@Tommy[D]_	well, for the first, comrel will say "then communicate" :)
+2014-04-23 19:38:55	antarus	"now kiss"
+2014-04-23 19:39:30	@TomWij	Right; more like "consider communicating with the community or people involved first, then escalate to ComRel when really necessary", might even drop everything after the comma. 
+2014-04-23 19:39:31	@Tommy[D]_	antarus: you dont have to write your private activities in public :)
+2014-04-23 19:40:33	@TomWij	Or we just add "...; if not, then kiss." there as a side joke. :D
+2014-04-23 19:40:38	@Pinkbyte	antarus, is this your suggestion as a ComRel lead? :-)
+2014-04-23 19:40:47	antarus	no
+2014-04-23 19:42:54	@Tommy[D]_	the question is, how to divide? if to people/groups argue about a technical detail, the techical part may well be qa area while personal attacks may become comrel area
+2014-04-23 19:43:03	@Tommy[D]_	*two people/groups
+2014-04-23 19:43:12	antarus	I really haven't posted my manifesto
+2014-04-23 19:43:15	antarus	so sorry about that
+2014-04-23 19:43:21	@TomWij	creffett|irssi: So, moving towards a statement; I think we can work towards creating one or two Wiki pages (perhaps a FAQ if it fits that format better). Those would then contain how to reach QA (a bug with clear information), as well as examples of what to (and what not to) contact QA with.
+2014-04-23 19:44:01	@TomWij	As for whether the pages are in the right place and what on them is right or wrong, we can still work that out outside the meeting (or when there are disagreements, sort it out further at a future meeting).
+2014-04-23 19:44:43	@Tommy[D]_	fine with me
+2014-04-23 19:45:16	@TomWij	Tommy[D]_: At that point there has been a discussion; which works out better than receiving a mail from someone who doesn't want to discuss, as a result we don't know the viewpoints the community would have on the matter at hand.
+2014-04-23 19:46:06	@creffett|irssi	TomWij: ++, let's go FAQ
+2014-04-23 19:46:26	@creffett|irssi	there's space for one on the main QA page already, we can start there
+2014-04-23 19:48:18	@TomWij	Pinkbyte, Tommy[D]_ wired, ulm, zlogene: Your vote on the statement of two messages sent in response to creffett|irssi above? Or do you want to propose an alternative statement? More discussion?
+2014-04-23 19:49:02	@wired	I like it
+2014-04-23 19:49:18	@Pinkbyte	+1 from me
+2014-04-23 19:49:20	@zlogene	fine for me 
+2014-04-23 19:49:32	@Tommy[D]_	TomWij: i already responded to your "moving towards a statement" part
+2014-04-23 19:49:32	@ulm	fine with me too
+2014-04-23 19:49:56	@TomWij	Tommy[D]_: Heh, sorry; I figured out I'm missing out on myself instead of you. :D
+2014-04-23 19:50:31	@TomWij	7 for, 0 against, 0 abstain, 3 absent. Motion passed.
+2014-04-23 19:50:35	@creffett|irssi	okay
+2014-04-23 19:50:39	@creffett|irssi	anything else for today?
+2014-04-23 19:50:51	@wired	just short of 2h
+2014-04-23 19:50:56	@wired	nice
+2014-04-23 19:51:23	@creffett|irssi	mhm
+2014-04-23 19:51:37	@creffett|irssi	speak now or forever hold your peace
+2014-04-23 19:51:45	@creffett|irssi	...until next meeting, at least
+2014-04-23 19:52:19	@zlogene	Pinkbyte, what sutation with your suggestion for tinderbox?
+2014-04-23 19:52:23	@Tommy[D]_	nothing else from me for now
+2014-04-23 19:52:50	@Pinkbyte	zlogene, nothing changes - only can gave hardware resources for it
+2014-04-23 19:53:07	@zlogene	okay
+2014-04-23 19:53:46	@TomWij	Meeting summary available at https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_April_23.2C_2014
+2014-04-23 19:54:08	@creffett|irssi	TomWij++
+2014-04-23 19:54:12	 *	creffett|irssi bangs the gavel
+2014-04-23 19:54:18	@creffett|irssi	meeting adjourned, thank you all for coming
+2014-04-23 19:54:31	@wired	woot
+2014-04-23 19:54:33	@wired	thanks
\ No newline at end of file
diff --git a/meeting-logs/20141203.txt b/meeting-logs/20141203.txt
new file mode 100644
index 0000000..463d60e
--- /dev/null
+++ b/meeting-logs/20141203.txt
@@ -0,0 +1,487 @@
+Timestamps are in UTC+3
+
+[22:05:53] <zlogene>	ok, first meeting after months 
+[22:06:13] <Pinkbyte>	creffett, i can do it, start recording log right now just in case...
+[22:06:18] <creffett>	Pinkbyte: okay
+[22:06:46] *	zlogene writes logs too
+[22:06:51] <zlogene>	fyi 
+[22:06:59] <creffett>	so, let's start with elections
+[22:07:17] <creffett>	if you want to run, please email the alias saying as much and with a short statement of why people should vote for you
+[22:07:41] <creffett>	we'll leave that open until next tuesday, at which point I'd like to do a helios vote, same as what we did last year
+[22:07:45] <creffett>	any objections?
+[22:07:56] *	zlogene is ok 
+[22:08:02] <mgorny>	no objections, move forward ;P
+[22:08:05] <ulm>	ok
+[22:08:17] <Tommy[D]>	ok
+[22:08:26] <Pinkbyte>	creffett, everything is clear, ok
+[22:08:35] <wired>	+1
+[22:08:45] <creffett>	that said, I strongly suggest people step up to run, it would be very sad if QA were without a lead
+[22:09:18] *	wired doesn't have enough time for this, unfortunately
+[22:09:42] <zlogene>	creffett, do you plan to continue your leadership, btw?
+[22:09:47] <creffett>	zlogene: I do not
+[22:10:11] <Pinkbyte>	That would be sad, i think you are doing very well
+[22:10:18] <ulm>	+1
+[22:10:31] <creffett>	I disagree with you, but that's a discussion we can have outside of meeting time
+[22:10:40] <creffett>	back to the agenda: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Inquiry
+[22:10:56] <creffett>	TomWij isn't here to talk about it, unfortunately
+[22:11:11] <creffett>	agenda says to review it. Do we have any input? do we like it? do we care?
+[22:11:22] <Pinkbyte>	creffett, my opinion after quick look - this should be posted officially as is, no major changes required
+[22:11:41] <ulm>	IMHO doesn't make sense to discuss without TomWij
+[22:11:50] <Pinkbyte>	and yes, we care. Clearly said what is QA area of responsibility is a good point
+[22:11:54] <ulm>	and it's already online ;)
+[22:11:58] <creffett>	well, according to the Wiki page, TomWij isn't part of the team, so...
+[22:12:04] <creffett>	that's a bit of an issue
+[22:12:12] <zlogene>	in general it looks good to me 
+[22:12:27] <creffett>	personally I'm happy with it in general, but would like to rewrite it to be more concise
+[22:13:06] <Pinkbyte>	creffett, o_O. How it's possibly? I saw him in our project page with a 'Deputy lead' in description. Probably something breaks :-/
+[22:13:31] <zlogene>	Pinkbyte, his account has been deleted it seems 
+[22:13:36] <creffett>	Pinkbyte: he removed himself from pretty much all of his projects a couple weeks ago
+[22:13:39] <creffett>	!away TomWij
+[22:13:40] <willikins>	creffett: tomwij:  I am taking a break from Gentoo. I don't think I'm ready to retire, but I think I need a break to decide. Still present to talk if you can catch me... @ 2014/09/10 12:28Z
+[22:13:45] <ulm>	Pinkbyte: https://wiki.gentoo.org/index.php?title=Project%3AQuality_Assurance&action=historysubmit&diff=165052&oldid=157850
+[22:13:45] <creffett>	^^ there we go
+[22:14:25] <creffett>	so let's put this off until next meeting, I will rewrite it a little to make it more understandable
+[22:14:32] <ulm>	and he was doing well, too
+[22:14:35] <ulm>	IMHO
+[22:14:45] <Pinkbyte>	That's sad too. We have some disagreement with him in a past, but he did a good job. Hope he will come back
+[22:15:22] <creffett>	yeah, well, it is what it is
+[22:15:43] <creffett>	any other input on the Inquiry article for now?
+[22:15:57] <zlogene>	no 
+[22:16:34] <Pinkbyte>	creffett, no, as i said - i think it's good to go right now, but if you want to reword it to be more clearer - i do not mind
+[22:16:39] <creffett>	Pinkbyte: okay
+[22:16:53] <creffett>	next topic, then
+[22:16:59] <creffett>	 Review the games team policies: games group, forcing /usr/games when upstream does not use it, games.eclass (points 3-5 in mgorny's reply of last Council agenda, deferred by Council to be discussed by QA). 
+[22:17:06] <creffett>	mgorny: talk to us
+[22:17:08] <mgorny>	yay, finally
+[22:17:29] <mgorny>	so pretty much council said we don't have to use games.eclass but specific policies should be discussed by qa
+[22:17:42] <mgorny>	games team had no input except that i'm stupid
+[22:17:46] <creffett>	as expected
+[22:17:55] <creffett>	mgorny: what specifically do you want us to vote on?
+[22:17:55] <ulm>	kill it with fire
+[22:18:01] <ulm>	the eclass, that it
+[22:18:03] <ulm>	*is
+[22:18:03] <mgorny>	i think we should decide on some goals to get things consistent
+[22:18:11] <zlogene>	as usual...
+[22:18:13] <mgorny>	1) install stuff as upstream wants (preferably to /usr)
+[22:18:28] <creffett>	mgorny: does games.eclass provide any utility other than forcing /usr/games and the games group?
+[22:18:34] <mgorny>	2) remove games group as currently defined, open access to games
+[22:18:45] *	ulm notes that the FHS has /usr/games, /usr/share/games, and /var/games
+[22:19:05] <mgorny>	creffett: i think there's one function to do wrappers and one unpacker
+[22:19:07] <ulm>	with binaries directly in /usr/games, not /usr/games/bin
+[22:19:13] <Pinkbyte>	creffett, i wrote some games ebuilds using games.eclass. And - basically no. Only plenty of functions to force such behaviour
+[22:19:17] <mgorny>	but the wrappers are probably /usr/games-related
+[22:19:18] <creffett>	k
+[22:19:22] <mgorny>	and the unpacker is in unpacker.eclass too
+[22:19:35] <creffett>	okay then
+[22:19:45] <Pinkbyte>	ulm, yeah, some FHS compatibility is one thing that stops me to say 'god damn, just go with games like with any other normal application in Gentoo!"
+[22:20:11] <creffett>	so stop forcing weird install locations, kill games group, eventually kill games.eclass (and make it non-mandatory for now)?
+[22:20:25] <mgorny>	it's non-mandatory already but some developers are confused
+[22:20:40] <mgorny>	and some people (games team?) tell others to use it
+[22:20:41] <creffett>	games team says otherwise ;)
+[22:21:09] <creffett>	anyone have comments on these before we vote?
+[22:21:10] <mgorny>	which brings up to things like gnome wasting time converting their ebuild to games.eclass
+[22:21:22] <mgorny>	because someone told them to
+[22:21:24] <ulm>	mgorny: so usual rules, install to /usr
+[22:21:27] <ulm>	and /opt if it's a binary pkg?
+[22:21:38] <mgorny>	yes, if you believe so
+[22:21:53] <mgorny>	though i think /opt is more like /opt/company/fancything
+[22:22:02] <mgorny>	when it can't work with /usr layout
+[22:22:54] <Pinkbyte>	mgorny, in Gentoo i often see that /opt is used for binary-only stuff
+[22:23:08] <mgorny>	i know
+[22:23:19] <mgorny>	but that's another topic, so let's not bother ourselves with it
+[22:23:24] <ulm>	actually, do we have a policy on this?
+[22:23:29] <mgorny>	maybe i'll write a GLEP for simple filesystem layout at some point
+[22:23:42] <mgorny>	i'm sure people will be very happy to see it
+[22:23:51] <creffett>	ulm: I'm not certain, I know that's unofficial policy for a long time at least
+[22:24:21] <mgorny>	another common choice is /usr/lib/whatever
+[22:24:25] <mgorny>	i think FHS allows both
+[22:24:33] <mgorny>	(firefox, opera, chromium)
+[22:24:49] <mgorny>	oh wait, you said binary-only, then opera ;P
+[22:24:50] <ulm>	creffett: we do: "Binary-only applications must not be installed outside of /opt."
+[22:24:56] <ulm>	http://devmanual.gentoo.org/general-concepts/filesystem/index.html
+[22:24:59] <creffett>	ulm: okay, that works
+[22:25:23] <creffett>	any further discussion on the games topics, or are we ready to vote?
+[22:25:31] <wired>	I feel games is way too broad a category of packages for one team to enforce things like install location. as long as the package is not doing something stupid, I do not see any reason to enforce stuff on it just because it's a game.
+[22:25:38] <ulm>	anyway, we can simply say that games should follow our normal rules
+[22:25:59] <creffett>	yeah
+[22:26:41] <Pinkbyte>	ulm, +1 from me
+[22:26:45] <creffett>	vote 1: games team should stop forcing install locations to /usr/games/bin and other odd locations.
+[22:27:02] <Pinkbyte>	i am for it
+[22:27:03] <Tommy[D]>	isnt clear to me
+[22:27:03] *	ulm yes
+[22:27:04] *	creffett yes
+[22:27:14] <creffett>	Tommy[D]: would "follow upstream" be better?
+[22:27:22] *	zlogene yes 
+[22:27:25] *	mgorny yes
+[22:27:38] <Tommy[D]>	e.g. is that for all packages, for those with group=games and maintainer or only those with games as maintainer?
+[22:27:39] <ulm>	creffett: "follow upstream and gentoo policies"
+[22:27:39] <wired>	yes
+[22:27:42] <Pinkbyte>	creffett, follow upstream, unless it breaks gentoo rules. I mean - if upstream forces installing to /usr/local - screw it
+[22:27:45] <creffett>	okay
+[22:28:11] <creffett>	Tommy[D]: the gist of these all is going to be "games team isn't special and should follow the rules the rest of Gentoo follows"
+[22:28:17] <ulm>	Pinkbyte's wording is better than mine
+[22:28:26] <creffett>	okay
+[22:28:44] <mgorny>	does that request them to change the eclass?
+[22:28:49] <creffett>	mgorny: we're getting there ;)
+[22:28:59] <Tommy[D]>	creffett: my point is, that imho games team should be allowed to create whatever policy they want for the packages they actually maintain, but others maintaining games themselves should not be forced to follow it
+[22:29:05] <wired>	I don't mind if some dev feels that a game belongs to a different folder (because of size), we just shouldn't force everyone to do it
+[22:29:36] <mgorny>	size is rather a poor argument for /usr/games
+[22:29:43] <mgorny>	esp. that games data goes into /usr/share/games
+[22:30:07] <creffett>	Tommy[D]: I don't agree, games team should follow the same rules as everyone else
+[22:30:43] <Tommy[D]>	creffett: games team uses games eclass, kde uses kde eclass, gnome uses gnome eclass.... ;)
+[22:31:07] <creffett>	Tommy[D]: and gnome and KDE all install to standard locations (given that kdeprefix died a long time ago)
+[22:31:16] <mgorny>	and we dropped /usr/X11R6 too
+[22:32:04] <ulm>	another relic from the 1980s :)
+[22:32:18] <creffett>	heh.
+[22:32:22] <mgorny>	next meeting we will discuss sbin :>
+[22:32:23] *	mgorny hides
+[22:32:30] <creffett>	next vote: kill games group
+[22:32:34] *	creffett yes
+[22:32:51] *	zlogene yes 
+[22:32:53] <Tommy[D]>	well, if the vote includes a forced change for packages actively maintained by games team, if it only prevents the games team to force their rules onto others, i am fine with it
+[22:33:00] <mgorny>	kill games group as used to manage access to running games*
+[22:33:08] <creffett>	mgorny: what else is it used for?
+[22:33:12] <ulm>	eh, what about usage of the games group by upstream packages?
+[22:33:24] <mgorny>	some upstream were using it to share scores... but we broke that by redefining games
+[22:33:25] <ulm>	like setgid for accessing score files?
+[22:33:29] <creffett>	ah
+[22:33:33] <creffett>	I forgot about that
+[22:33:38] <mgorny>	we will probably need to sed it to another group
+[22:33:51] <mgorny>	or request people to remove their users from games
+[22:34:12] <creffett>	what would you suggest? kill games group entirely, or just stop it from being used to restrict game access?
+[22:34:25] <ulm>	the latter
+[22:34:30] <creffett>	okay
+[22:34:38] *	creffett is okay with that
+[22:34:42] <ulm>	follow usage as it is in other distros
+[22:35:55] <creffett>	anyone else planning to vote?
+[22:36:14] *	mgorny yes
+[22:36:30] <ulm>	what is the vote? "kill games group"?
+[22:36:36] *	Pinkbyte yes
+[22:36:49] <creffett>	okay, try this again
+[22:37:08] <creffett>	vote to stop games group from being used to restrict access to games, it should only be used to follow usage upstream/in other distros
+[22:37:15] <creffett>	ulm: is that acceptable wording?
+[22:37:19] <ulm>	yes
+[22:37:24] *	zlogene yes 
+[22:37:24] *	ulm votes yes
+[22:37:42] *	creffett yes
+[22:37:54] *	mgorny yes
+[22:38:06] *	Pinkbyte yes
+[22:38:32] <creffett>	wired, Tommy[D]
+[22:38:43] <wired>	yes
+[22:38:55] <Tommy[D]>	i abstain
+[22:39:00] <creffett>	okay, passes
+[22:39:25] <creffett>	games.eclass: do we want to completely deprecate it, or just vote to confirm that it isn't required
+[22:39:46] <mgorny>	let's try deprecating. we already voted out all its features :)
+[22:39:54] <creffett>	k
+[22:40:00] *	WilliamH is here sorry folks
+[22:40:02] <creffett>	vote to deprecate games.eclass
+[22:40:08] *	mgorny yes
+[22:40:12] *	zlogene yes 
+[22:40:15] *	WilliamH yes
+[22:40:15] *	creffett yes
+[22:40:20] *	ulm yes
+[22:40:31] *	Tommy[D] abstain
+[22:40:35] *	Pinkbyte abstain
+[22:40:59] <wired>	abstain
+[22:41:23] <creffett>	passes
+[22:41:26] <Pinkbyte>	i'd prefer to make it non-required for generic games ebuild. When it loses most of features - it will be dropped as is, no need to force that on QA level
+[22:41:44] *	creffett out, can I get a volunteer to run the rest of the meeting?
+[22:41:48] <ulm>	well, deprecated != removal
+[22:41:52] <mgorny>	Pinkbyte: right now games.eclass has configurable dirs
+[22:42:03] <mgorny>	i'm sure some people will try to workaround our decisions
+[22:42:21] <Pinkbyte>	creffett, sure, i will takeover ;-)
+[22:42:31] <creffett>	Pinkbyte: okay then, thank you
+[22:42:52] <mgorny>	good luck, creffett
+[22:42:53] <WilliamH>	Did I miss the vote on tinfo?
+[22:42:56] <Pinkbyte>	mgorny, no doubt, i know how behave some of current Games team members
+[22:42:57] <zlogene>	so, forward to the next item? 
+[22:42:59] <mgorny>	WilliamH: not yet
+[22:43:00] <creffett>	WilliamH: not yet
+[22:43:01] <zlogene>	WilliamH, no 
+[22:43:05] <mgorny>	so far killed games
+[22:43:25] <Tommy[D]>	mgorny: but i liked some games :p
+[22:44:05] <mgorny>	Pinkbyte: run that meeting!
+[22:44:10] *	mgorny is hungry
+[22:44:16] <Pinkbyte>	mgorny, ok then
+[22:44:44] <Pinkbyte>	next topic: repoman checks for missing slot/subslot operators
+[22:44:47] <Tommy[D]>	anyway, 10 members, 5 votes, so it did not pass?
+[22:44:53] <Pinkbyte>	mgorny, your word :-)
+[22:45:22] <mgorny>	i have mixed feeling about it these days
+[22:45:35] <mgorny>	but the idea was that repoman is supposed to warn you when you do RDEP+DEP on dev-libs/openssl
+[22:45:39] <ulm>	Tommy[D]: generally only members being present in a meeting are counted
+[22:45:46] <mgorny>	and that could match both openssl:0 and openssl:0.9.8 (which has no headers, just libs)
+[22:46:14] <Pinkbyte>	mgorny, one note. Is that checks would be for RDEPEND only or on DEPEND too?
+[22:46:25] <mgorny>	so you're required to either do openssl:0, openssl:* explicitly or openssl:=
+[22:46:28] <ulm>	mgorny: has this been tested in a real world scenario?
+[22:46:38] <ulm>	the repoman check, I mean
+[22:46:39] <mgorny>	Pinkbyte: i think ulm has bikeshed it to the point of common subset of RDEP+DEP
+[22:46:47] <Tommy[D]>	ulm: in previous meetings the idea was to get more then half of the members into the meeting to be able to get a vote accepted, so that is not clear to me
+[22:46:49] <mgorny>	ulm: i was running it for a while ;P
+[22:46:49] <Pinkbyte>	let's have some example: boost have subslots. And some app uses ONLY boost headers. Should we force some slot operator here?
+[22:47:15] <mgorny>	Pinkbyte: if you can really take any slot, you can do :*
+[22:47:39] <mgorny>	right now slot-less dep on slotted package is treated as semi-undefined behavior
+[22:48:05] <Pinkbyte>	mgorny, boost have no slots, only subslots. Does that matter?
+[22:48:17] <mgorny>	that's the second part :)
+[22:48:18] <Pinkbyte>	ahhh, that's what i want to hear
+[22:48:24] <mgorny>	first part is just slots in general
+[22:48:36] <mgorny>	i don't remember who requested subslots anymore
+[22:48:51] <mgorny>	but the second part is the same for subslots
+[22:49:06] <mgorny>	i.e. dev-libs/libfoo on subslotted package bad
+[22:49:09] <ulm>	what's the rationale for the subslot check?
+[22:49:18] <mgorny>	either :0, :0=, :=, :* to force it
+[22:49:35] <mgorny>	i.e. to force a specific subslot behavior or to silence the check
+[22:49:43] <mgorny>	ulm: finding missing subslot uses, i think
+[22:50:30] <mgorny>	but i'm not really convinced by that, so i put that as second item
+[22:51:03] <Tommy[D]>	what happens, if a package with only :0 starts to add more slots?
+[22:51:18] <ulm>	mgorny: it has the potential for false positives, I think
+[22:51:47] <mgorny>	ulm: yes, it does
+[22:52:13] <mgorny>	it pretty much requires us to use :* or likes to confirm stuff
+[22:52:25] <mgorny>	Tommy[D]: with first check? repoman starts issuing warnings about missing slots
+[22:52:25] <Pinkbyte>	so, let's reiterate. Repoman check for slots is needed for packages, that had no slots, but when they are added - it will ease migration if old ebuilds, depending on that now-slotted package, that will have category/foo:0 instead of category/foo dependency
+[22:53:43] <Tommy[D]>	mgorny: so maintainer has to request all depending packages to be fixed before adding new slot?
+[22:53:58] <mgorny>	or when developers are missing the fact that package is slotted, like they do a lot now
+[22:54:09] <mgorny>	Tommy[D]: basically he has to do all the fixing right now
+[22:54:20] <mgorny>	we just don't have any checks to help him
+[22:57:07] <Pinkbyte>	Tommy[D], well, if it would be warning and not error, i do not think that this is problem. And of course, if old behaviour would not be broken until all things would be fixed
+[22:57:23] <mgorny>	and if it proves to bring too many false positives, we can always revert it
+[22:57:37] <Tommy[D]>	Pinkbyte: well, if there can be false positives, it cannot be an error ever
+[22:58:58] <mgorny>	'false positive' depends on how undefined behavior of lack of slot op is defined
+[22:59:01] <ulm>	I'd say let's try it for slots
+[22:59:15] <mgorny>	so let's get it into 3 votes
+[22:59:16] <ulm>	but not for subslots, at least not immediately
+[22:59:22] <mgorny>	1. warning for missing slots
+[22:59:29] <mgorny>	2. warning for missing subslots
+[22:59:54] <mgorny>	3. recommending :* over no slot for packages that really support all slots and trigger the warning
+[22:59:56] <ulm>	s/slots/slot operators/ ?
+[23:00:11] <mgorny>	it can be either a slot spec or slot op
+[23:00:14] <Tommy[D]>	so the exact suggestion is, that if repoman detects at least 2 versions of the dependency with different slots, that it then issues a warning, if no explicit slot is defined for the dependency?
+[23:00:15] <mgorny>	i.e. :0 or := or :*
+[23:00:26] <mgorny>	Tommy[D]: yes
+[23:00:58] <mgorny>	(or :0/0 or :0=)
+[23:01:31] <mgorny>	Tommy[D]: i can show you the patch if you want
+[23:02:21] <Pinkbyte>	can we make this check works only for new revision/version?
+[23:02:31] <Tommy[D]>	mgorny: thanks, but i am tired and have pretty limited time for now, so probably would not get to checking it :/
+[23:03:01] <mgorny>	Pinkbyte: i don't think we have a sane way of figuring that out
+[23:03:18] <mgorny>	plus, the point is to warn about package deps that used not to be slotted
+[23:03:26] <mgorny>	this requires retroactive fixes
+[23:05:06] <mgorny>	did others leave already? :P
+[23:05:25] *	WilliamH is still here, just reading what's going on...
+[23:05:26] <Tommy[D]>	maybe already sleeping :)
+[23:05:48] <ulm>	so, are we going to vote on it, or what?
+[23:05:57] <Tommy[D]>	i follow the suggestion of ulm: try it for slots only for now
+[23:06:26] <Pinkbyte>	ok, guys, let's reiterate. Vote 1: should we enable missing slot operator check in repoman?
+[23:06:49] <mgorny>	sounds right
+[23:06:54] *	ulm yes
+[23:06:55] *	zlogene yes 
+[23:06:58] *	mgorny yes
+[23:06:59] <Tommy[D]>	yes
+[23:07:21] *	Pinkbyte yes
+[23:07:38] *	WilliamH abstain
+[23:08:13] <Pinkbyte>	wired, your voice?
+[23:08:28] <wired>	abstain
+[23:09:18] <Pinkbyte>	so, 5 for, 2 abstain, others do not vote? Motion failed, i'd say
+[23:09:41] <mgorny>	err, what?
+[23:09:42] <ulm>	7 members present
+[23:09:48] <mgorny>	5 out of 7 is failed/
+[23:09:54] <ulm>	so 5 is a majority
+[23:10:05] <Pinkbyte>	oh, stupid me, counted from total members
+[23:10:10] <zlogene>	passed
+[23:10:14] <ulm>	(given that we follow usual rules)
+[23:10:17] <Pinkbyte>	it's probably too late and my brain is sleeping already
+[23:10:35] <Pinkbyte>	it's passed of course, no doubt for that, if i would count it correctly :-)
+[23:11:03] <Pinkbyte>	so, Vote 2:  should we enable missing sub-slot operator check in repoman?
+[23:11:09] *	ulm no
+[23:11:11] *	Pinkbyte abstain
+[23:11:20] <ulm>	not for now
+[23:11:37] *	zlogene abstain 
+[23:11:42] <Tommy[D]>	no (not for now)
+[23:11:44] *	mgorny nope
+[23:11:53] *	WilliamH no
+[23:12:49] <Pinkbyte>	wired, ?
+[23:14:51] <Pinkbyte>	ok, i figured out that wired's voice did not change situation much in our case. Clear 'no' is said for this check for now, let's move on
+[23:15:00] <Pinkbyte>	no offense, wired
+[23:15:27] <Pinkbyte>	next thing: Making global-scope 'use*', 'has_version' and 'best_version' fatal in EAPI 6
+[23:15:51] <ulm>	such usage was never allowed
+[23:16:03] <Pinkbyte>	yeah, devmanual said about that pretty clear
+[23:16:04] <mgorny>	yet vapier did it
+[23:16:14] <ulm>	can't we fix remaining usage in tree, and make it fatal everywhere?
+[23:16:15] <mgorny>	so this is about making it fatal in EAPI 6
+[23:16:39] <mgorny>	i don't mind extending it to all EAPIs
+[23:16:43] <ulm>	it's not related to EAPI 6
+[23:16:51] <WilliamH>	one question about this, is this a repoman check? I don't see how a function can know if it was called in global scope.
+[23:18:28] <mgorny>	no, portage change
+[23:18:33] <Pinkbyte>	WilliamH, i suppose it would be portage and not repoman check
+[23:18:35] <mgorny>	the global call will cause 'die'
+[23:18:37] <Pinkbyte>	ahh, i was right :-)
+[23:19:17] <ulm>	mgorny: one has to make sure that it doesn't die when uninstalling a package
+[23:19:43] <mgorny>	ulm: then EAPI 6 ;)
+[23:19:49] <Pinkbyte>	retroactive changes are bad, BUT, we will do retroactive change to set up behaviour that was intended by standart and devmanual...
+[23:20:04] <Pinkbyte>	ulm, hm, i forgot about this case, thanks for catching this up
+[23:20:11] <ulm>	mgorny: so it _does_ die on uninstall?
+[23:20:36] <mgorny>	ulm: not sure
+[23:20:37] <wired>	Pinkbyte: no problem, I'm at work so 'abstain' is my default answer if not here
+[23:20:48] <mgorny>	i don't think portage actaulyly reevals globals on uninstall
+[23:20:48] <Pinkbyte>	ulm, it would be hard to check, i think, so probably would be better to not alter behaviour for already installed ebuilds
+[23:21:26] <ulm>	mgorny: it should source the environment file from the VDB but not the ebuild (?)
+[23:22:06] <mgorny>	yes, i think so
+[23:22:12] <WilliamH>	I think it is going to be hard to check inside a function whether it was called from global scope or not.
+[23:22:30] <mgorny>	WilliamH: it's already implemented
+[23:22:37] <mgorny>	and enabled for Arfrever's EAPIs
+[23:22:48] <mgorny>	pretty much we can check whether we're in a phase
+[23:23:12] <WilliamH>	mgorny: Oh ok.
+[23:23:26] <ulm>	can we shelve this till next meeting please? I don't have enough input to be ready for a vote
+[23:23:59] <WilliamH>	That's fine with me.
+[23:24:17] <mgorny>	if you feel like it
+[23:24:34] <mgorny>	next item important
+[23:24:35] <Pinkbyte>	guys, should we? I think if we vote for that change in EAPI 6 it would not hurt anyone. Setting this for all previous EAPIs is another thing...
+[23:24:49] <ulm>	or that
+[23:25:10] <ulm>	but it won't go into pms
+[23:25:29] <mgorny>	it already is in pMS :)
+[23:25:33] <ulm>	or rather, it is in pms already, for all eapis :)
+[23:25:48] <Pinkbyte>	ulm, huh? i thought it is already for all EAPIs, but we just do not do such check in reality
+[23:25:58] <ulm>	Pinkbyte: exactly
+[23:28:14] <Pinkbyte>	So, will talk about current EAPIs when we will have clear understanding about all possibly consequences Vote: Making global-scope 'use*', 'has_version' and 'best_version' fatal since EAPI 6
+[23:30:02] *	Pinkbyte yes
+[23:30:04] *	mgorny yes
+[23:30:12] *	ulm yes
+[23:30:29] *	Tommy[D] yes
+[23:31:08] *	WilliamH yes
+[23:31:20] *	uDH ушел (Ping timeout: 256 seconds)
+[23:31:35] *	zlogene yes 
+[23:32:18] <Pinkbyte>	6 'yes', motion passed
+[23:32:37] <Pinkbyte>	Next topic: Use of <maintainer/> and <herd/> elements in metadata.xml
+[23:32:48] <mgorny>	yay
+[23:32:54] <mgorny>	so my newest idea
+[23:32:59] *	WilliamH thinks <herd> should just be switched to <maintainer>
+[23:33:01] <Pinkbyte>	a bit ambiguous topic as it recorded
+[23:33:03] <mgorny>	1. replace <herd> with <maintainer>/<email>
+[23:33:12] <mgorny>	2. possibly add maintainer type="foo"
+[23:33:33] <Tommy[D]>	i am leaving now, i really need to get some sleep
+[23:33:50] <mgorny>	the goal is to make bug assignment simpler
+[23:34:10] <mgorny>	we keep maintainer/email useful for bug assignment, add extra information without changing the spec
+[23:34:12] <ulm>	I must leave soon, too
+[23:34:29] <WilliamH>	mgorny: right now, you 1) assign to first maintainer, 2) cc everyone else.
+[23:34:31] <zlogene>	herd != maintainer IMO 
+[23:34:52] <zlogene>	why should we do so then
+[23:34:57] <WilliamH>	zlogene: technically, you are right, a herd is a group of packages...
+[23:35:04] <Pinkbyte>	zlogene, basically it is. i mean, herd acts like alias for group of maintainters in terms of bug wrangling
+[23:35:15] <ulm>	is this topic even a qa issue?
+[23:35:20] <Pinkbyte>	but we should differ herd and herd maintainers of course
+[23:35:28] <ulm>	it's something for the -dev ml
+[23:35:29] <WilliamH>	herds are dead
+[23:35:50] <zlogene>	ulm, the same question here 
+[23:35:55] <Pinkbyte>	WilliamH, lack of cooperation != dead
+[23:36:04] <Pinkbyte>	WilliamH, yes, there is really dead herds
+[23:36:13] <WilliamH>	Pinkbyte: relevence == dead
+[23:36:27] <WilliamH>	Pinkbyte:  the herd concept is pretty useless
+[23:36:30] <mgorny>	we can leave herds, just change the tags used to assign bugs
+[23:36:34] <zlogene>	Pinkbyte, there are, i'd even said :D 
+[23:37:02] <mgorny>	i.e. <herd>foo</herd> -> <maintainer type="herd"><email>foo-bugs@gentoo.org</></>
+[23:37:27] <Pinkbyte>	WilliamH, it works for quite a long time as i know. Do you propose to drop the whole idea of collective maintainership?
+[23:38:17] <WilliamH>	Pinkbyte: this is part of the problem. Herds are NOT people, they are groups of packages.
+[23:38:34] <WilliamH>	Pinkbyte: people maintain herds, they are not in herds.
+[23:38:45] <Pinkbyte>	WilliamH, but herd maintainers ARE a group of people. So mgorny change seems reasonable in this case
+[23:39:27] <Pinkbyte>	for me it's quite simple. Project maintains some complicated stuff. That stuff are present as one or multiple group of packages(herds). Herds are maintained by respective maintainers
+[23:39:42] <Pinkbyte>	first problem - herds without a project
+[23:39:44] <WilliamH>	Pinkbyte: but why not just have aliases for the herds e.g. <maintainer><name>group name</name><elail>foo@gentoo.org</email></maintainer>
+[23:40:03] <WilliamH>	Pinkbyte: it is just another maintainer.
+[23:40:06] <ulm>	http://www.gentoo.org/proj/en/council/meeting-logs/20141111-summary.txt
+[23:40:19] <ulm>	council has shelved this in the last meeting
+[23:40:36] <ulm>	so does it make sense if we decide something here now?
+[23:41:09] <mgorny>	we could give a recommendation to the council
+[23:41:31] <zlogene>	ulm, yes it does, for the future references 
+[23:42:27] <Pinkbyte>	mgorny, i like your idea about 'type' attribute in maintainer field, but i think we can go just by converting herds to apropriate maintainer tags without additional attribute
+[23:42:45] *	WilliamH agrees with Pinkbyte 
+[23:42:45] <Pinkbyte>	anyway, i saw some packages that has <maintainer>media-video@gentoo.org</maintainer> and no herd at all
+[23:42:49] <mgorny>	there were concerns that we lose information
+[23:43:05] <WilliamH>	mgorny: what information? I don't see any information loss.
+[23:43:18] <mgorny>	but basically, i'm all for having some other structure mapping e-mail addresses to herds
+[23:43:50] <ulm>	we need to distinguish single maintainers from projects
+[23:44:07] <mrueg>	how about media-video@projects.gentoo.org ?
+[23:44:09] <ulm>	or whatever will substitute herds
+[23:44:17] <WilliamH>	ulm: does that really matter though?
+[23:44:31] <WilliamH>	ulm: you can do that in the <name> tag of a maintainer
+[23:44:51] <Pinkbyte>	WilliamH, good catch!
+[23:45:26] <ulm>	WilliamH: how to you prevent projects from using the name tag?
+[23:45:40] <ulm>	s/to/do/
+[23:46:12] <WilliamH>	ulm: you don't. <maintainer><name>foo project</name><email>foo@gentoo.org</email></maintainer>
+[23:46:44] <ulm>	the dtd says that names are only for individuals, though
+[23:47:09] <ulm>	but it has to be changed anyway
+[23:47:38] <Pinkbyte>	ulm, could you raise mgorny's idea on next Council meeting? If yes, i think we can skip voting on this entirely, until they spoke their word
+[23:47:55] <ulm>	yeah, can do
+[23:48:24] <WilliamH>	sounds good to me
+[23:48:35] <Pinkbyte>	good. Next one: ncurses[tinfo] flag used to change library ABI, bug #487844
+[23:48:38] <willikins>	Pinkbyte: https://bugs.gentoo.org/487844 "sys-libs/ncurses: USE=tinfo changes library ABI"; Gentoo Linux, Applications; RESO, WONT; mgorny:base-system
+[23:48:52] <Pinkbyte>	i suppose, that's here because of WilliamH
+[23:49:42] <Pinkbyte>	my personal opinion - vapier said all things right in the bug. Extra revdep-rebuild ewarn is not needed in this case
+[23:49:43] <ulm>	I don't see any breakage there, unless users switch from -tinfo to +tinfo and then back to -tinfo
+[23:50:04] <mgorny>	this doesn't go alongwith our work on subslots
+[23:50:09] <Pinkbyte>	ulm, in the latter case - there would be preserved rebuild warning
+[23:50:17] <mgorny>	we want to know ABI breakages before upgrading
+[23:50:24] <ulm>	it's certainly not ideal, but we don't have use dependency operators
+[23:50:30] *	WilliamH is against dropping the use flag
+[23:50:40] <mgorny>	not allow people to play with them because base-sysetm can't handle deciding
+[23:50:53] <mgorny>	i'm for making it use.masked or use.forced
+[23:51:02] <WilliamH>	There is no  prohibition against using a use flag that way
+[23:51:05] <mgorny>	or droppping entirely, and doing the switch via revbump with subslot change
+[23:52:16] <WilliamH>	I posted a patch on the bug that could be used to provide a warning to the user if we really want to do that.
+[23:52:45] <WilliamH>	We can't force dropping or masking of the use flag.
+[23:53:06] <WilliamH>	But there is a way as shown in that patch to test whether it was turned off.
+[23:53:44] <ulm>	one could also say that the real issue is with reverse dependencies, that are sniffing if there's a tinfo lib and automagically depend on it
+[23:54:04] <Pinkbyte>	mgorny, we can not go on subslot logic in all times of ABI problems happened. revdep-rebuild is supported solution, so i do not see serious QA issue here(yet)
+[23:54:11] *	zlogene is out, because has no sleep for 2 days 
+[23:54:12] <mgorny>	ulm: that's how upstream wants it
+[23:54:16] <mgorny>	tinfo is basically the future way
+[23:54:27] <mgorny>	normal distros just switch and fix the deps
+[23:54:33] <Pinkbyte>	mgorny, but too many breakages happens for now
+[23:54:42] <mgorny>	only gentoo makes a lot of noise and doesn't do real work
+[23:55:35] <Pinkbyte>	mgorny, you can go in usual way - fix all bugs about USE="tinfo" enabled libncurses consumers and then say - 'hey guys, nobody uses ncurses without libtinfo, let's move on!!!'
+[23:55:41] <ulm>	well, add WilliamH's patch then, and warn if the users switches from USE=tinfo to USE=-tinfo
+[23:55:48] <Pinkbyte>	mgorny, if you are really THAT care
+[23:55:49] <ulm>	that certainly won't harm
+[23:57:51] <WilliamH>	I can do it if you want after we are done
+[23:57:55] <WilliamH>	ulm: ^^
+[23:58:03] <WilliamH>	I can add the patch.
+[23:58:37] <ulm>	has vapier commented on it?
+[23:58:42] <WilliamH>	no
+[23:59:15] <ulm>	WilliamH: hm, you could emit the warning in pkg_preinst
+[23:59:25] <WilliamH>	I would need to know the exact revdep-rebuild command users should use though.
+[23:59:27] <ulm>	would get rid of the environment saving
+[00:00:04] <WilliamH>	ulm: Hmm, what would the test look like if I did that?
+[00:00:15] <mgorny>	pkg_pretend maybe/
+[00:00:31] <WilliamH>	has_version [tinfo] && ! use tinfo
+[00:01:04] <ulm>	WilliamH: I think so
+[00:01:36] <ulm>	and revdep-rebuild --library=/path/to/libtinfo.so
+[00:03:11] <WilliamH>	ulm: I guess that path would end up being ${EROOT}usr/lib/libtinfo.so
+[00:03:58] <Pinkbyte>	WilliamH, yep
+[00:03:59] <ulm>	or $(get_libdir) instead of lib
+[00:04:09] <WilliamH>	ulm: right.
+[00:04:12] <Pinkbyte>	ah, nice catch too
+[00:04:33] <Pinkbyte>	errr, nope
+[00:04:39] <WilliamH>	I'll update the bug first.
+[00:04:44] <ulm>	no?
+[00:04:44] <Pinkbyte>	i have it in /lib64/libncurses.so.5
+[00:04:56] <Pinkbyte>	so i suppose no /usr thingie for libtinfo too
+[00:05:03] <Pinkbyte>	but it should be checked, of course
+[00:05:58] <ulm>	Matched Files:          /usr/lib64/libtinfo.so; /usr/lib32/libtinfo.so; /usr/lib/libtinfo.so
+[00:06:02] <ulm>	says e-file
+[00:06:41] <ulm>	and it makes sense because terminfo stuff is in /usr/share
+[00:06:49] <Pinkbyte>	ulm, portagefilelist.de agrees too
+[00:07:10] <Pinkbyte>	so, i was wrong
+[00:07:12] <ulm>	that's the same as e-file, I think
+[00:09:25] <ulm>	sorry, but I must leave now
+[00:09:27] <Pinkbyte>	ok, guys. I have a bit tired too, so can we skip last part of agenda - status checks about GTK use flag issue, missing QA meetings summary and other stuff. I know that this is important, but as i see - not much of us are left in channel
+[00:09:33] <Pinkbyte>	?
+[00:09:48] <ulm>	yeah, please postpone
+[00:10:14] <Pinkbyte>	WilliamH, ^^ ok with that?
+[00:10:42] <Pinkbyte>	mgorny, wired, ^^
+[00:10:47] <mgorny>	sure
+[00:10:53] <WilliamH>	That's fine.
+[00:11:01] <wired>	sure
+[00:11:08] <WilliamH>	So for now should I just update the bug?
+[00:12:20] <Pinkbyte>	WilliamH, path that you are supposed(${EROOT}usr/lib/libtinfo.so) is correct. Add warning about needed revdep-rebuild for library in that path
+[00:12:30] <Pinkbyte>	i think that's all that we can do now
+[00:12:56] <WilliamH>	Pinkbyte: ok
+[00:14:17] <Pinkbyte>	All right guys, meeting is over. Thanks to everyone
+[00:14:37] <WilliamH>	ulm: I think there is a concern about using preinst to emit the warning...
+[00:14:40] <Pinkbyte>	Will try to post meeting log and summaries tomorrow. If i do not, just poke me with friendly reminder
diff --git a/meeting-logs/20150218.txt b/meeting-logs/20150218.txt
new file mode 100644
index 0000000..2f14690
--- /dev/null
+++ b/meeting-logs/20150218.txt
@@ -0,0 +1,621 @@
+Timestamps are in UTC+3
+
+[22:04:05] <Pinkbyte>	Let's start then, maybe others will join us later
+[22:04:16] <zlogene>	WilliamH, ^
+[22:04:32] <zlogene>	I saw he around
+[22:04:49] <Pinkbyte>	First of all - the simpliest thing. Give mrueg a warm welcome as our fellow team member. And kudos to zlogene as Deputy Lead
+[22:04:56] *	WilliamH is here
+[22:05:02] *	wired here
+[22:05:18] <ulm>	mrueg: welcome :)
+[22:05:30] <WilliamH>	mrueg: Welcome aboard. :-)
+[22:05:44] <mrueg>	thanks :-)
+[22:06:19] *	mgorny kicked mrueg from #gentoo-qa (welcome)
+[22:06:36] <mgorny>	oh wait, is that a wrong practice? :D
+[22:06:40] <Pinkbyte>	meh
+[22:06:54] <Pinkbyte>	well, it's usual for generic newcomers, so... not sure :-)
+[22:06:54] <WilliamH>	heh
+[22:07:01] <wired>	too late :P
+[22:07:11] <mgorny>	he's a dev long enough to have autorejoin
+[22:07:13] *	mrueg (~mrueg@gentoo/developer/mrueg) joined #gentoo-qa
+[22:07:48] <Zero_Chaos>	mrueg: welcome
+[22:08:11] <mrueg>	:)
+[22:09:23] <Pinkbyte>	so, i will take care about our logs, but it would be nice to have a backup. zlogene, could you please enable logging in your client too, just in case?
+[22:09:45] <zlogene>	Pinkbyte, sure
+[22:12:21] <Pinkbyte>	So, let's begin our business
+[22:12:43] <Pinkbyte>	games policies... again. Or should i say - at last? :-)
+[22:13:24] <Pinkbyte>	bug #537580...
+[22:13:27] <willikins>	Pinkbyte: https://bugs.gentoo.org/537580 "Allow packages to install files in games directories without chgrp games"; Gentoo Linux, Games; CONF; ulm:qa
+[22:13:54] <ulm>	I've outlined the problems and proposed a solution in comment #0
+[22:14:16] <Pinkbyte>	i do not want to be rude, but i am kinda tired about hasufell's nagging, who are not willing to put any reasonable amount of real work in this issue, but continues saying that all proposed stuff are useless
+[22:14:49] <mgorny>	i like ulm's solution
+[22:15:00] <ulm>	basically, devs still cannot install any games in FHS locations, because games.eclass sets the dirs' permissions to 750
+[22:15:01] <mgorny>	Pinkbyte: hasufell is a true troll, we could ban him and he wouldn't care much
+[22:15:09] <mgorny>	as in, he does that on purpose
+[22:15:23] <mgorny>	but it's comrel, not qa business :)
+[22:15:52] <zlogene>	i'd vote for ulm's solution
+[22:15:54] <ulm>	so my first suggestion would be to change all top-level games dirs to root:root and 755 (i.e. the default)
+[22:16:02] <Pinkbyte>	mgorny, true. I am just saying about my personal attitude. Now, technically...
+[22:16:11] <ulm>	patch for games.eclass is attached to the bug
+[22:16:16] <Pinkbyte>	ulm, let me clarify - do you propose to change games.eclass?
+[22:16:18] <mgorny>	ulm: that is equal to /usr/bin and others, correct?
+[22:16:39] <Pinkbyte>	ulm, sorry, did not see your attachment in bug, ignore last question
+[22:16:43] <ulm>	Pinkbyte: yes, just the part that restricts the dirs listed in comment #0
+[22:17:13] <ulm>	e.g. /usr/games and /var/games should be world readable
+[22:17:30] <Pinkbyte>	ulm, no objections from me
+[22:17:36] *	WilliamH is reading
+[22:17:41] <ulm>	any more restrictive permissions can be applied to files or subdirs
+[22:18:18] <ulm>	second part is a new group for shared scores/bones/states
+[22:18:45] <ulm>	the "games" group cannot be used for that, unfortunately
+[22:18:54] <ulm>	so we would need a new name
+[22:19:16] <ulm>	like "scores"
+[22:19:36] <Pinkbyte>	ulm, 'gamescores'(or scores) seems more valid for me, rather than proposed name 'gamers' in maillist
+[22:19:51] <mgorny>	i'd go for scores
+[22:19:54] <mgorny>	simple and efficient
+[22:19:56] <ulm>	or "spiele", "jeux", "juegos", "ludi", "gry"
+[22:19:59] <mrueg>	gamescores
+[22:20:18] <mgorny>	Pinkbyte, mrueg: this makes me think about 'cores'
+[22:20:26] <ulm>	mrueg: yeah, but it's too long
+[22:20:45] <mrueg>	or maybe game-stats
+[22:20:49] <ulm>	shouldn't be more than 8 chars otherwise some programs cannot display it
+[22:20:58] <mrueg>	gamestat ;)
+[22:21:00] <ulm>	and no hyphen ;)
+[22:21:15] <zlogene>	gscores? ;D
+[22:21:19] <Pinkbyte>	ulm, lol, a bit off-topic: your last sentence reminds me about some russian user, that was really curious about why locale defined in make.conf as LINGUAS and not LANGS for example :-)
+[22:22:03] *	WilliamH isunsure what the games group is supposed to be used for
+[22:22:22] <zlogene>	Pinkbyte, lingua latina non ... you know
+[22:22:26] <ulm>	WilliamH: games would be setgid "scores" (or whatever its name will be)
+[22:22:41] <ulm>	so they can access shared score files on the system
+[22:23:03] <WilliamH>	ulm: My question though was, why not setgid games?
+[22:23:09] <Pinkbyte>	WilliamH, 'games' can not be thrown away because of backward compatibility. And can not be utilized by regular users because of security bug #125902
+[22:23:13] <willikins>	Pinkbyte: https://bugs.gentoo.org/125902 "games-roguelike/nethack: local privilege escalation and insecure savegame creation (CVE-2006-1390)"; Gentoo Security, Vulnerabilities; IN_P; taviso:security
+[22:23:48] <ulm>	WilliamH: many gentoo users will be in the games group, so there will be a security issue if we have setgid binaries at the same time
+[22:23:59] <mgorny>	WilliamH: long story short, because that group needs to be empty ;)
+[22:24:01] <Pinkbyte>	WilliamH, if regular user can overwrite score files in default configuration by another app, not related to reading/writing them(like text editor) it creates some nasty security holes
+[22:24:32] <WilliamH>	So users shouldn't have been put in the games group to begin with.
+[22:24:54] <ulm>	WilliamH: right, but too late to change that now
+[22:24:56] <Pinkbyte>	WilliamH, yes, but we can not say them - go away from games group until we throw away games.eclass entirely
+[22:25:13] <Pinkbyte>	WilliamH, it will not happen in any near future, it will require some work to do
+[22:25:39] <WilliamH>	Pinkbyte: ok, thanks. :-)
+[22:25:51] <Pinkbyte>	and that bitrotting security issue pains me from the time i join Gentoo Security, i am glad that it was brought to our attention(at last!)
+[22:26:03] <ulm>	so, gscores, gamestat, or should I go to the -dev ml for bikeshedding?
+[22:26:06] <ulm>	or launch a forums poll? :)
+[22:26:36] <WilliamH>	gamestat ++
+[22:26:37] <Zero_Chaos>	whatever you want man, I think this is not so important we need a vote
+[22:26:40] <Zero_Chaos>	gamestat, fine
+[22:26:42] <Pinkbyte>	ulm, i like 'gamestat'
+[22:27:00] <ulm>	ok, gamestat it will be
+[22:27:17] <ulm>	can we have a vote on the whole proposal
+[22:27:19] <ulm>	?
+[22:27:45] <ulm>	as outlined in bug 537580 comment #0
+[22:27:47] <willikins>	https://bugs.gentoo.org/537580#c0 "Allow packages to install files in games directories without chgrp games"; Gentoo Linux, Games; CONF; ulm:qa
+[22:27:51] <ulm>	(first two items)
+[22:28:16] <Pinkbyte>	Let's clarify: "Create separate group: 'gamestat' and set score files to it, /usr/games and /var/games should be world-readable"
+[22:28:32] <ulm>	well, all dirs listed in the bug
+[22:28:57] <ulm>	/usr/games /usr/games/bin /usr/games/lib* /usr/share/games /var/games /etc/games /opt
+[22:29:32] <ulm>	 /opt was already fixed, though
+[22:30:50] <ulm>	and these dirs' permissions and owner should just be left alone
+[22:30:56] <ulm>	root:root and 755
+[22:31:21] <ulm>	like /usr/bin and all others
+[22:31:32] *	WilliamH yes
+[22:31:36] *	Pinkbyte yes
+[22:31:38] *	mgorny yes
+[22:31:39] *	ulm yes
+[22:31:53] *	zlogene yes 
+[22:31:56] <Zero_Chaos>	yes
+[22:32:35] <Pinkbyte>	mrueg, ?
+[22:32:42] <mrueg>	yes.
+[22:32:59] <ulm>	thank you :)
+[22:33:08] <Pinkbyte>	motion passed
+[22:33:25] *	wired yes
+[22:33:50] <Pinkbyte>	...unanimously
+[22:33:51] <Pinkbyte>	:-)
+[22:34:18] <Pinkbyte>	so, next question... "Developers ignoring (not updating) eclass/ChangeLog file"
+[22:34:46] <zlogene>	Pinkbyte, what do you mean by this item ?
+[22:34:46] *	WilliamH doesn't have a strong opinion since once we go to git it will be irrelivent.
+[22:34:51] <mgorny>	we should get a consistent policy here
+[22:34:51] <Pinkbyte>	Who brought this up?
+[22:34:56] *	mgorny did
+[22:35:04] <mgorny>	long story short, some devs update eclass/ChangeLog, some don't
+[22:35:08] <Zero_Chaos>	Changelogs should be updated
+[22:35:11] <Pinkbyte>	zlogene, i am just reading what is in our agenda, not all of those items are brought there by me
+[22:35:13] <mrueg>	repoman should work on profiles/ and eclass/
+[22:35:13] <mgorny>	the result is you can't read the file reliably
+[22:35:23] <mrueg>	right now it doesn't
+[22:35:44] <zlogene>	mrueg, repoman is for qa checks
+[22:35:46] <Pinkbyte>	mrueg, the problem is that not every directory in profiles/ has ChangeLog
+[22:36:01] <zlogene>	echangelog can deal with profiles and eclass
+[22:36:04] <mgorny>	Pinkbyte: that's not really a problem, it's a bit irritating
+[22:36:09] <Pinkbyte>	some deep arch profiles have only top level ChangeLog(and it's fine if it is consistent)
+[22:36:20] <ulm>	as long as we have a ChangeLog in eclass it should be updated
+[22:36:30] <mrueg>	zlogene: repoman ci -m "Foo" calls echangelog, except for eclass or profile.
+[22:36:31] <Pinkbyte>	mgorny, i mean that this is problem for a automatic tool to check, such as repoman
+[22:36:49] <mgorny>	the problem is that it's not devs forgetting, i think
+[22:36:54] <zlogene>	mrueg, i know
+[22:37:01] <mgorny>	they openly refuse to update the ChangeLog
+[22:37:24] <mgorny>	so we should decide if refusing this is a reason for QA action
+[22:37:26] <WilliamH>	mgorny: Yes, there is some of that going on too.
+[22:37:35] <mgorny>	or we should just drop the ChangeLog since it confuses people
+[22:37:39] <WilliamH>	mgorny: But I've also seen situations where
+[22:37:52] <mrueg>	well don't we try to enforce the usage of repoman to commit stuff to the tree?
+[22:37:53] <WilliamH>	mgorny: repoman ci -m 'msg' doesn't work.
+[22:38:28] <WilliamH>	mgorny: I can't figure out when it doesn't work.
+[22:38:42] <Zero_Chaos>	for all I care we can drop the Changelog files entirely and rely on cvs log for eclasses, but it should be consistent
+[22:38:57] <Pinkbyte>	mgorny, well, before we will have git we should preserve as much ChangeLogs as possible
+[22:39:31] *	WilliamH agrees with Zero_Chaos  about consistency
+[22:39:51] <mrueg>	bug #390651
+[22:39:53] <willikins>	mrueg: https://bugs.gentoo.org/390651 "repoman: support commit in non-package directories like eclasses and profiles"; Portage Development, Repoman; CONF; zmedico:dev-portage
+[22:39:58] <Pinkbyte>	we could rely on CVS commit messages, but they are not for end-users as i would said. 'git log' is a more user-friendly
+[22:40:21] <Zero_Chaos>	Pinkbyte: git log and cvs log are effectively the same thing. you just have to |less on your own for cvs
+[22:40:50] <wired>	this changelog problem has been around forever, I don't see it going away until we switch to git
+[22:40:55] <mgorny>	i'd suggest two possible decisions:
+[22:41:04] <zlogene>	mgorny, phrase "we will have a git" correlates to HL3 release
+[22:41:26] <mgorny>	a. we declare that if a particular subtree or a parent tree has a ChangeLog, developer must update it when committing to it
+[22:41:37] <Pinkbyte>	zlogene, be more optimistic. At least mgorny do a real work for this, writing nice kind-of-migration software
+[22:41:49] <mgorny>	b. we drop eclass/ChangeLog and possible others ChangeLogs used inconsistently
+[22:41:59] <ulm>	I believe that a. is existing policy already
+[22:42:12] <Pinkbyte>	mgorny, "a" plan is fine by me
+[22:42:20] <Pinkbyte>	ulm, not sure
+[22:42:24] <WilliamH>	"a" allows "b" even.
+[22:42:39] <WilliamH>	Because if the changelog is gone you don't have to worry about it.
+[22:43:00] <zlogene>	maybe developers confused since they don't know what changelog they should update?
+[22:43:02] <mgorny>	ulm: if it is, then we should confirm it
+[22:43:13] <Pinkbyte>	ulm, i was wrong - http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html
+[22:43:15] <zlogene>	in subprofiles case
+[22:43:16] <mgorny>	zlogene: no, i'm talking about eclass/, there's only one ;P
+[22:43:21] <Pinkbyte>	"Note: If a ChangeLog file is not present in your current working directory, then you should write a ChangeLog entry in the parent's directory ChangeLog file. "
+[22:43:24] <zlogene>	ah
+[22:43:43] <Pinkbyte>	so, it IS a policy, from devmanual
+[22:44:50] <Pinkbyte>	and i do not think that we need to change it in current situation. It's in pure "a" variant, suggested by mgorny
+[22:45:28] *	mgorny prepares a gentoo-dev@ mail then :)
+[22:45:47] <ulm>	we could confirm the policy again
+[22:46:09] <Zero_Chaos>	I say we officially confirm the policy
+[22:46:12] <mrueg>	maybe ping portage-devs to add support to repoman for these profiles?
+[22:46:25] <mrueg>	s/profiles/Changelog generation/
+[22:46:35] <mgorny>	mrueg: not sure if you can do that reliably
+[22:46:50] <mgorny>	it would have to somehow distinguish between 'update parent changelog' and 'create new changelog here'
+[22:46:56] <WilliamH>	mrueg: I'm not sure how much work we should ask the portage devs to do, because
+[22:47:10] <WilliamH>	mrueg: once we change to git, the ChangeLog files will be gone
+[22:47:27] <Pinkbyte>	mgorny, dol-sen is quite responsive and not so busy as zmedico(which is responsive too). And that's not so hard work to do
+[22:47:29] <mrueg>	mgorny: well at least for eclass it should be easy?
+[22:47:47] <WilliamH>	mrueg: per council decision
+[22:47:48] <mgorny>	yes
+[22:48:01] <Pinkbyte>	WilliamH, if we will pospone fixing this until git migration is done it will be there -> not good
+[22:48:48] <WilliamH>	Pinkbyte: I'm just saying that any fix we do should be a fix that won't break again once the git migration happens.
+[22:49:07] <WilliamH>	Pinkbyte: and the ChangeLog disappears
+[22:49:08] <Pinkbyte>	WilliamH, repoman does not write to changelog in git repos, IIRC
+[22:49:11] <mgorny>	can we vote on confirming this policy then? if we remove all the ChangeLogs with git, the rule would still be fine
+[22:49:15] <Zero_Chaos>	git migration will change things, it is what it is.
+[22:49:27] <mrueg>	ack mgorny
+[22:49:34] <Zero_Chaos>	ack mgorny
+[22:49:42] *	ulm votes yes for confirming the policy
+[22:49:57] *	WilliamH yes
+[22:49:58] <Pinkbyte>	And yes, let's not mix things up. We are with cvs now - so, let's keep things clear and tidy NOW
+[22:49:58] <mrueg>	(which means vote yes)
+[22:49:59] <Zero_Chaos>	yes
+[22:50:04] *	Pinkbyte yes
+[22:50:12] *	zlogene yes
+[22:50:21] *	mgorny yes
+[22:50:27] <Zero_Chaos>	so we all seem to agree, what do we do about violators? revert their changes?
+[22:50:49] <Zero_Chaos>	publicly insult their mothers?
+[22:50:54] <ulm>	that would be an overreaction :)
+[22:50:59] <ulm>	both :)
+[22:51:20] <Zero_Chaos>	flaming bags of dog poop on their porch?
+[22:51:24] <Pinkbyte>	Zero_Chaos, send apropriate message in gentoo-dev, blaming author and asking to update changelog itself
+[22:51:38] <Zero_Chaos>	we can't have a policy we don't enforce, so we need to have a policy for enforcement.
+[22:51:49] <Zero_Chaos>	I'm fine with emailing the dev directly and cc gentoo-dev
+[22:51:50] <Pinkbyte>	Zero_Chaos, you are really inventor these days, are not you? :-)
+[22:51:54] <Zero_Chaos>	but not all devs read gentoo-dev alone
+[22:52:03] *	WilliamH agrees with Pinkbyte 
+[22:52:16] <WilliamH>	That would be a response to a msg on gentoo-commits probably
+[22:52:21] <zlogene>	Zero_Chaos, do we have any other method?
+[22:52:24] <Pinkbyte>	Zero_Chaos, sure, direct mails WITH CC-ing gentoo-dev@ is fine too
+[22:52:28] <zlogene>	g-dev only
+[22:52:37] <mrueg>	+ CC qa@
+[22:52:47] <zlogene>	yeah
+[22:52:52] <Zero_Chaos>	zlogene: if we don't email the dev directly, they might not see it. I'm a few thousand behind on gentoo-dev
+[22:52:52] <mgorny>	i'd say gentoo-dev + 24h timeout
+[22:52:58] <mgorny>	if developer doesn't update the ChangeLog, we revert
+[22:53:26] <Pinkbyte>	WilliamH, i am not receiving all mail from gentoo-commits and it's not trivial to receive a specific e-mail from mailman archive too, so, it depends...
+[22:53:26] <mgorny>	and a regular QA action on repeated offenses
+[22:53:30] <WilliamH>	g-dev alone isn't good enough though because g-dev is not  mandatory for devs.
+[22:53:38] <mrueg>	mgorny: we need a lcvs-qa-revert tool ;p
+[22:53:45] <ulm>	mgorny: revert because of missing changelog entry? what if it's an important fix?
+[22:54:05] <Zero_Chaos>	I think email warnings and we don't bind our hands if we have a repeat offender
+[22:54:20] <WilliamH>	Yeah, we would have to use common sense; we can't just revert depending on the fix.
+[22:54:38] <mgorny>	maybe
+[22:54:38] <zlogene>	ulm, i'd say write a message before rever (directly to dev maybe)
+[22:54:45] <zlogene>	*revert
+[22:55:00] <mgorny>	but not reverting means the ChangeLog will again be inconsistent
+[22:55:03] <Pinkbyte>	ulm, agreed, retroactively add ChangeLog entry is better than losing a critical fix. But it should not be a usual practice like 'ah, those guys will update changelog themselves"
+[22:55:08] <wired>	wait. revert changes because of changelog?
+[22:55:29] <zlogene>	may be we should make a template for it?
+[22:55:38] <Zero_Chaos>	I don't think we need to officially state we will revert changes. i think we can leave ourselves free to act as appropriate
+[22:55:44] <mrueg>	mgorny: if we revert it, we need to fix the changelog anyway right?
+[22:55:49] <wired>	please don't, it may be a policy violation, but the commit may be more important than the policy violation.
+[22:55:59] <Pinkbyte>	wired, ++
+[22:56:02] <mrueg>	aka echangelog "Foo"; echangelog "Revert foo"
+[22:56:08] *	WilliamH is against specifying how we will react
+[22:56:32] <WilliamH>	That should be a case by case kind of thing.
+[22:56:41] <mgorny>	mrueg: well, if you revert something that wasn't there, you don't say you did :)
+[22:56:50] <wired>	the only real solution is to enforce this server side. until then, we have to point fingers and accept that some people will not follow rules unless they are enforced
+[22:57:43] <Pinkbyte>	wired, and again - ++ from my side
+[22:58:14] <Pinkbyte>	apropriate git hooks will screw such retarded behaviour and force dev's commits to be nice and shiny
+[22:58:22] <wired>	^^
+[22:58:23] <mrueg>	mgorny: so you even don't echangelog "Revert foo"?
+[22:58:23] <Pinkbyte>	**devs'
+[22:58:25] <WilliamH>	Folks, you cannot just blindly revert an update because of a ChangeLog entry missing.
+[22:58:43] <mgorny>	mrueg: yes
+[22:58:44] <Zero_Chaos>	we cannot blindly revert fixes, period.
+[22:58:47] <ulm>	WilliamH: ++
+[22:58:57] <wired>	and we're spending way too much time on this, it's not an important policy altogether
+[22:58:58] <mgorny>	how about reverting unreviewed eclass changes?
+[22:59:10] <Zero_Chaos>	so let's vote that we email the developer, cc -dev, and deal with anyone who refuses as appropriate
+[22:59:22] <WilliamH>	mgorny: again, no.
+[22:59:24] <Pinkbyte>	so, let's recap: "Remind all about our policy on ChangeLog files"
+[22:59:26] <ulm>	mgorny: not all eclasses require a review
+[22:59:38] <ulm>	e.g. toolchain.eclass doesn't
+[22:59:40] <Pinkbyte>	mgorny, i am understanding where this goes. That's ANOTHER issue
+[22:59:49] <Pinkbyte>	ulm, hm. Why?
+[23:00:00] <ulm>	Pinkbyte: the devmanual says so
+[23:00:13] <wired>	mgorny: that's a different issue altogether, I'd like to see us use a review tool and enforce at least one peer review, starting with eclasses, but that's something for another day :P
+[23:00:15] <ulm>	and explicitly mentions toolchain as example
+[23:00:52] *	WilliamH is with Pinkbyte  remind everyone about our policy
+[23:01:14] <Pinkbyte>	ulm, you were right, again
+[23:01:21] <WilliamH>	Then handle violaters on a case by case basis
+[23:01:28] <Pinkbyte>	"It is not usually necessary to email the gentoo-dev list before making changes to a non-general eclass which you maintain. Use common sense here."
+[23:01:29] <WilliamH>	just like any other violation
+[23:01:39] <Pinkbyte>	!herd toolchain
+[23:01:41] <willikins>	Pinkbyte: (toolchain) halcy0n, kumba, lu_zero, rhill, vapier
+[23:02:11] <Pinkbyte>	vapier is there, so it's his right to do so and accept all consequences of breakages
+[23:02:50] <mgorny>	but while at it, do we consider it ok to revert if the commit actually causes breakage, and request fixing it first?
+[23:03:21] <Pinkbyte>	mgorny, yes, but WITH notifying those who break it about breakage
+[23:03:22] <wired>	I would revert if the commit wrecked havoc
+[23:03:49] <wired>	and ping the proper people to fix it
+[23:04:00] <Pinkbyte>	mgorny, even after reverting, does not matter. Our own policy requires that for serious breakages - to send notice to the actual maintainer that things was bad and WE fixed it
+[23:04:02] <wired>	we really need a review tool ^_^
+[23:04:50] <ulm>	should go without saying that the maintainer will be notified
+[23:05:33] <Pinkbyte>	ulm, by sending notice i mean e-mail, that does not require it's ACK
+[23:05:40] <Pinkbyte>	just a reminder
+[23:05:50] <Pinkbyte>	that things reverted on purpose
+[23:06:08] <mgorny>	ok, i guess we can move forward with the agenda
+[23:07:04] <Pinkbyte>	yep, we voted for the initial agenda proposal, motion passed
+[23:07:19] <Pinkbyte>	"Missing QA meetings summaries"
+[23:07:38] <Pinkbyte>	Not sure what i personally can  do here. Probably nothing, unless somebody has missing logs
+[23:09:00] <Zero_Chaos>	which ones are missing?
+[23:09:37] *	zlogene has no logs 
+[23:09:44] *	WilliamH has no logs
+[23:10:26] <Pinkbyte>	Zero_Chaos, oh, stupid me, i thought that logs are missing too!
+[23:10:36] <Zero_Chaos>	I also have no logs
+[23:10:41] <Pinkbyte>	so, we just need to provide a convinient summary for them
+[23:10:45] <ulm>	we can ask robbat2
+[23:10:55] <ulm>	willikins is logging IIRC
+[23:11:01] <Pinkbyte>	no need - we have all meeting logs on our wiki page
+[23:11:29] <Pinkbyte>	just lacks some summaries for March 19, 2014 and March 26, 2014 meetings
+[23:11:51] <Pinkbyte>	i will take care of that and post apropriate summaries
+[23:11:58] <Zero_Chaos>	Pinkbyte: thanks
+[23:13:31] <Pinkbyte>	"GTK use flag" status check
+[23:13:55] <Pinkbyte>	Who wants to discuss this? Your word.
+[23:14:03] <floppym>	If anyone ever needs logs, feel free to ask me for any channel I am in.
+[23:14:12] <floppym>	quassel logs everything.
+[23:15:19] <zlogene>	gtk use flags? again?
+[23:15:50] <mrueg>	Pinkbyte: has the status changed?
+[23:16:00] <WilliamH>	heh, I sent an email to the gnome team sometime back but we never got an answer.
+[23:16:01] <mrueg>	if not: unchanged. ;)
+[23:16:29] <WilliamH>	So I would say the status is unchanged.
+[23:16:49] <ulm>	so how do we proceed?
+[23:17:01] <Zero_Chaos>	kill everyone in the gnome team!
+[23:17:02] <ulm>	we cannot wait for the gnome team forever
+[23:17:23] <Zero_Chaos>	that or just do it, assuming someone cares enough to do the work
+[23:17:23] <ulm>	Zero_Chaos: you have crative suggestions today :)
+[23:17:28] <ulm>	*creative
+[23:17:40] <zlogene>	Zero_Chaos, do you have a pistol for this purpose?
+[23:17:41] <Zero_Chaos>	ulm: I'm working on something I find enjoyable, it helps my mood a lot.
+[23:17:47] <Zero_Chaos>	zlogene: several
+[23:17:52] *	WilliamH doesn't know enough about the build system, or gtk in general to comment.
+[23:18:01] <Pinkbyte>	well, i remember WilliamH's e-mail. I propose to send it again. And then - if no answer will be till the next meeting - move that to Council. There is nothing we can do when we are ignored
+[23:18:04] <WilliamH>	e.g. does upstream support gtk slotting?
+[23:18:36] <Pinkbyte>	WilliamH, not really matters in case of regular apps, that usually build with only ONE of GTK versions, but can not be built with both
+[23:18:48] <Pinkbyte>	i mean - simultaneously build with both
+[23:19:04] <creffett>	ahh, my favorite QA issue.
+[23:19:05] *	creffett here
+[23:19:11] <Pinkbyte>	creffett, o/
+[23:19:34] <zlogene>	creffett, \o
+[23:19:41] *	WilliamH would have to go back and dig up the email.
+[23:19:55] <Zero_Chaos>	creffett: \o/
+[23:20:43] <creffett>	WilliamH: does it matter? they've been asked several times and ignored the requests
+[23:21:32] <WilliamH>	creffett: good point.
+[23:22:14] <mgorny>	is this crusade worth fighting?
+[23:22:22] <Pinkbyte>	ulm, are you ok with moving that up to Council?
+[23:22:30] <Zero_Chaos>	if none of us is willing to make the commits, then we should drop this
+[23:22:34] <Pinkbyte>	mgorny, consistency and following policies? Yeah, why not ;-)
+[23:22:37] <Zero_Chaos>	that's the only way it will ever get done
+[23:22:41] <ulm>	Pinkbyte: fine with me
+[23:23:50] <Pinkbyte>	Zero_Chaos, i can dig with this, if i will have strong backup on my shoulders. Saying "I am QA team lead and we decided this should be THAT way" is not enough here
+[23:24:17] <Zero_Chaos>	Pinkbyte: it really is. You will only ever have the power you assume. If you assume you are weak, then you are.
+[23:25:04] <WilliamH>	Pinkbyte: qa has a lot of tree-wide authority. It is up to us to figure out how to use it.
+[23:26:10] <WilliamH>	Pinkbyte: the only way someone can override qa is by going to the council.
+[23:26:29] <Pinkbyte>	No doubt it is. But ulm already agrees to bring that to Council, so we would not blamed to over-use our powers. In any case, this is consistency issue, and it is serious. But nothing is broken badly on users systems
+[23:26:44] <Zero_Chaos>	We have no authority if we choose not to exercise authority.  We have authority to do this, if we choose to.
+[23:27:10] <Zero_Chaos>	but again, this will never happen if we don't do the work
+[23:27:55] <WilliamH>	It is a consistency issue that I personally think we should follow through on.
+[23:28:04] <ulm>	Pinkbyte: alternatively to forwarding this to the council, you could post the qa decision on gtk and gtk3 flags to the -dev ml
+[23:28:09] <Zero_Chaos>	is that a volunteer I hear?
+[23:28:13] <WilliamH>	I"m not really ina position where I can do the commits personally since I don't use a gui
+[23:28:45] <ulm>	Pinkbyte: assuming that we have a decision. do we?
+[23:28:51] <WilliamH>	ulm: that will end up in endless arguments again
+[23:29:17] <Pinkbyte>	WilliamH, we have answer from eva@, but it's only about 'keeping us in touch' with changes he planned to do
+[23:29:22] <Pinkbyte>	ulm, yes
+[23:29:25] <WilliamH>	ulm: I thought we did have a decision... but I don't remember now.
+[23:29:29] <ulm>	WilliamH: if it's a policy it has to be made public
+[23:29:42] <ulm>	makes no sense, otherwise
+[23:30:32] <ulm>	we had a discussion with the conclusion that we want gtk=GTK2 and gtk3=GTK3
+[23:30:45] <ulm>	but I don't remember if we had a formal vote on it
+[23:31:22] <Pinkbyte>	ulm, https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#GTK_flag_situation
+[23:31:23] <Pinkbyte>	we do
+[23:32:10] <WilliamH>	The email I sent was to ask the gnome team for more information about why they are doing things differently, but they never answered.
+[23:32:51] <ulm>	heh, that was a full year ago
+[23:33:17] <Pinkbyte>	WilliamH, as i said eva@ is answered, but his anwer does not contain any information about the problem itself and the concrete things to fix that
+[23:34:36] <WilliamH>	ulm: So basically we made the decision and tried to dialog with the gnome team but they gave us nothing.
+[23:34:42] <leio>	He went on and did actual QA work. Found that many related USE flags are completely wrongly used, and from there I am amazed the QA team is doing some stuff like that, when there are much bigger fish to fry than decide that USE flags are for declaring external dependencies instead of FEATURES.
+[23:35:12] <leio>	The half-done work was linked to you from a spreadsheet by me, I have not heard of anything since on what to do about all those.
+[23:35:14] <creffett>	leio: everyone has their idea of what QA should be doing
+[23:35:31] <creffett>	and none of those ideas agree with any other person's idea
+[23:35:42] <leio>	well, considering half of those USE=gtk's shouldn't be a USE=gtk at all...
+[23:36:16] <leio>	anyways, I realized this is a meeting,
+[23:36:17] *	leio shuts up
+[23:36:40] <mgorny>	don't worry, it's boring anyway :P
+[23:36:57] <WilliamH>	leio: Should they be hard deps instead of use=gtk?
+[23:37:15] <Pinkbyte>	leio, you are free to attend the meeting and say your opinion about problem, do not worry about that
+[23:37:47] <Pinkbyte>	leio, and beeing in GNOME team makes your opinion even more valuable :-)
+[23:37:48] <leio>	I do not have the time to read through the meeting log right now. Need to fix problems in the xorg/gtk/wayland/gles2 area.
+[23:38:28] <leio>	But you are welcome to engage the GNOME team in the #gentoo-desktop channel. We hate e-mail.
+[23:41:06] <Pinkbyte>	So, who will be in charge of  that conversation with GNOME team? I am all for making it as clear as it's possible, without enforcing rules, that are not apropriate because of some stupid misunderstanding
+[23:43:19] <Pinkbyte>	guys?
+[23:44:02] <Pinkbyte>	WilliamH, ^^
+[23:45:00] <ulm>	I don't know, but if we had a valid policy, then I would just fix my few packages with IUSE=gtk
+[23:45:28] <ulm>	but I've postponed it because I feel that things are still in a pending state
+[23:46:01] <Pinkbyte>	ok, seems nobody wants to do this. I will take care about talking to GNOME team myself then.
+[23:46:04] <WilliamH>	ulm: I thought we had a valid policy...
+[23:46:06] <Pinkbyte>	and yes, we HAVE policy
+[23:46:11] <Pinkbyte>	but nobody enforces it
+[23:46:11] <ulm>	so e.g. emacs neither follows gnome nor qa policy
+[23:46:37] <ulm>	ok, so I will change flag usage there
+[23:47:52] <wired>	gotta run
+[23:48:01] <wired>	l8r :)
+[23:48:08] <WilliamH>	Pinkbyte: I don't know that I'm really qualified to do much since I don't use gnome myself.
+[23:48:36] <Pinkbyte>	WilliamH, sure, no problem. You are not the only QA team member :-/
+[23:49:09] <Pinkbyte>	So, postponed until beeing discussed with GNOME team. "Status check: Followup on decisions of past QA and Council meeting"
+[23:49:18] <Pinkbyte>	not sure what's this about
+[23:50:25] <Pinkbyte>	!expn qa
+[23:50:26] <willikins>	Pinkbyte: qa = creffett,patrick,pinkbyte,tommy,ulm,williamh,wired,zerochaos,zlogene,mgorny,mrueg,
+[23:50:39] *	mgorny has no clue
+[23:50:40] <Pinkbyte>	Guys, can we have some attention here, please? We are close to end the meeting
+[23:50:57] *	WilliamH isn't sure either
+[23:51:01] <Zero_Chaos>	I'm still here, just not sure I have anything to contribute
+[23:51:30] <ulm>	not sure, who has put this topic on the agenda? :)
+[23:51:31] *	zlogene too 
+[23:52:18] <Pinkbyte>	ulm, you!
+[23:52:24] <ulm>	oops https://wiki.gentoo.org/index.php?title=Project%3AQuality_Assurance%2FMeeting_Agenda&action=historysubmit&diff=256210&oldid=167544
+[23:52:39] <ulm>	yeah, copied from previous meeting's agenda
+[23:52:44] <Pinkbyte>	logs does not lie, muahahaha :-P
+[23:53:17] <ulm>	well, next topic please :)
+[23:53:21] <Pinkbyte>	ok then
+[23:53:43] <Pinkbyte>	"open bugs with QA involvement"
+[23:53:53] <ulm>	https://bugs.gentoo.org/buglist.cgi?email2=qa%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=2670328&query_format=advanced&resolution=---
+[23:53:58] <ulm>	210 open bugs
+[23:54:05] <Zero_Chaos>	lol, ouch
+[23:54:50] <Pinkbyte>	well, i do not think we should discuss all of them now :-)
+[23:55:03] <Pinkbyte>	we have life, you know
+[23:55:46] <mgorny>	who? ;o
+[23:55:53] <Pinkbyte>	anything concrete about open bugs?
+[23:55:57] <dilfridge>	life?
+[23:56:17] <ulm>	mgorny: can I close bug 539982?
+[23:56:22] <willikins>	ulm: https://bugs.gentoo.org/539982 "Unused licenses: CC-BY-ND-2.5, DSL, ECL-2.0, ODbL-1.0, intel-psb, mongrel, newton, urbanterror-4.1-maps"; Gentoo Linux, Unspecified; CONF; mgorny:licenses
+[23:56:33] <mgorny>	sure, your choice
+[23:56:38] <ulm>	k
+[23:56:56] <hedge256>	Damn I forgot all about the meeting :(
+[23:57:33] <WilliamH>	Zero_Chaos: can I close bug 537996?
+[23:57:36] <willikins>	WilliamH: https://bugs.gentoo.org/537996 ">=sys-apps/openrc-0.13 netmount script cannot properly mount nfs shares"; Gentoo Hosted Projects, OpenRC; CONF; zerochaos:openrc
+[23:57:49] <Zero_Chaos>	WilliamH: not until it works, no
+[23:58:01] <Zero_Chaos>	WilliamH: but you could ask the team to vote on it.
+[23:58:04] <Pinkbyte>	Zero_Chaos, what's the problem there?
+[23:58:13] <WilliamH>	Zero_Chaos: it does according to qa, and a new release was spun with "use" in the dependencies as requested.
+[23:58:17] <Zero_Chaos>	Pinkbyte: /etc/init.d/netmount cannot start nfs mounts
+[23:58:33] <Zero_Chaos>	Pinkbyte: you have to start another service first, but openrc currently lacks the ability to do it right.
+[23:58:41] <Pinkbyte>	Zero_Chaos, i clearly states how it should be done, did not i?
+[23:58:48] <WilliamH>	Pinkbyte: it is a config issue. he wants it to start them without having to type rc-update add nfsclient default
+[23:59:06] <Pinkbyte>	WilliamH, i remember that i answered clearly on that bug, did not i?
+[23:59:14] <Zero_Chaos>	netmount is also not in the default runlevle
+[23:59:22] <WilliamH>	Pinkbyte: Yes, you did, and I followed your suggestion.
+[23:59:35] <Pinkbyte>	Zero_Chaos, and it is correct not beeing in default runlevel
+[23:59:38] <WilliamH>	Zero_Chaos: that's on you; you removed it.
+[23:59:59] <Zero_Chaos>	WilliamH: your init script is missing deps. that's not my fault.
+[00:00:14] <Zero_Chaos>	WilliamH: you know how I feel about this, why constantly ask if I reconsidered?
+[00:00:15] <Pinkbyte>	Zero_Chaos, not everybody uses NFS. And who did - they can follow proper procedure to configure it, including adding nfsclient to runlevel
+[00:00:28] <Zero_Chaos>	WilliamH: I though we agreed to add 'want' or similar to openrc?
+[00:00:49] <WilliamH>	Zero_Chaos: there is a separate bug for that, like I already told you.
+[00:00:54] <Pinkbyte>	Zero_Chaos, it can not be the 'need dep', only 'use' and it's already done. But this does not fix your situation, unless you will reconsider some configuration things
+[00:01:30] <Zero_Chaos>	Pinkbyte: /etc/init.d/netmount cannot possibly mount nfs shares without taking addition actions. that's a bug.
+[00:01:45] <WilliamH>	Zero_Chaos: but that isn't a blocker for this issue. Like I said, netmount is in the default runlevel for all  installs unless you remove it.
+[00:01:46] <Pinkbyte>	Zero_Chaos, why?
+[00:02:06] <Zero_Chaos>	Pinkbyte: that's like saying "sure my ebuild works, you just have to emerge something else first.
+[00:02:09] <Pinkbyte>	Zero_Chaos, netmount can not mount AFS/CEPH/whateverFS too(for example)?
+[00:02:19] <Pinkbyte>	should it be other bug too?
+[00:02:26] <Zero_Chaos>	Pinkbyte: I don't see how hilighting additional bugs makes mine invalid....
+[00:02:45] <Pinkbyte>	should netmount depends hardly on EVERY initscript of every net-based file system?
+[00:03:00] <WilliamH>	Pinkbyte: that is unreasonable.
+[00:03:04] <Zero_Chaos>	Pinkbyte: no, that's why WilliamH and I agreed to have 'want' added to openrc
+[00:03:13] <Zero_Chaos>	Pinkbyte: so it can use things which are there, but not fail if they are not.
+[00:03:20] <Pinkbyte>	Zero_Chaos, ok, that's another issue you want it
+[00:03:26] <Pinkbyte>	that depends on that one
+[00:03:42] <Zero_Chaos>	Pinkbyte: yes, the bug for fixing nfs would dep on the bug for "want"
+[00:03:57] <WilliamH>	Pinkbyte: It works right now if users follow the instructions covered in the newsitem.
+[00:04:12] <Pinkbyte>	simple as that - document current behaviour with workarounds, set proper depends on bug and remove QA from there
+[00:04:13] <Zero_Chaos>	Pinkbyte: I do not dispute that
+[00:04:15] <WilliamH>	Pinkbyte: The newsitem was very clear about what you need to do.
+[00:04:40] <Zero_Chaos>	WilliamH: I agree with pinkbyte, set my bug to dep the one on adding 'want' and drop qa from my bug is fine.
+[00:04:59] <Pinkbyte>	So, everything for workaround is set up. We do not need QA involvement in there, no breakages that users are unaware from are happening
+[00:05:10] <Zero_Chaos>	I accept
+[00:05:32] <WilliamH>	Pinkbyte: I vote close zero's bug because if you do what you are told in the newsitem things work. then,
+[00:05:41] <WilliamH>	Pinkbyte: let me finish.
+[00:06:05] <Zero_Chaos>	WilliamH: if you want my bug closed against my wishes, I believe it will need to go to a vote.
+[00:06:34] <WilliamH>	Pinkbyte: bug 406021 is a separate feature I have agreed to work on, but not having it isn't a bug if you folow the docs.
+[00:06:36] <willikins>	WilliamH: https://bugs.gentoo.org/406021 "sys-apps/openrc -"want" soft-dependency"; Gentoo Hosted Projects, OpenRC; CONF; polynomial-c:openrc
+[00:06:47] <Zero_Chaos>	WilliamH: documenting a bug doesn't make it a feature.
+[00:07:11] <Pinkbyte>	WilliamH, why you need that bug to be closed right now? It's example behaviour that you can see improved after realizing "want" feature
+[00:07:16] <WilliamH>	Zero_Chaos: it isn't a bug. Like I said it works fine in the default setup. you removed netmount; that is on you.
+[00:07:26] <Zero_Chaos>	WilliamH: you are missing a dep, it's a bug.
+[00:07:48] <WilliamH>	Zero_Chaos: no sir
+[00:08:19] <WilliamH>	Zero_Chaos: we don't have depends in localmount or netmount for all of the things they need to mount file systems.
+[00:08:24] <Zero_Chaos>	WilliamH: we both know how the other feels, if we still have enough of the team let's just vote, shall we?
+[00:08:57] <mgorny>	vote: deprecate openrc, use systemd which is free of such issues
+[00:09:02] <Pinkbyte>	Guys! Currently it's a workarounded bug. It is workarounded because of lacking features in OpenRC. It's workarounded nicely, so it would not hurt anyone, if they follow workarounds properly
+[00:09:06] <WilliamH>	But this brings up an interesting question... Even if we do vote, OpenRC is an independent upstream... Does the vote matter?
+[00:09:47] <Zero_Chaos>	Pinkbyte: he wants to close the bug because he doesn't feel it's a bug, I want it open because a missing dep is a bug.  So this elevates back up to qa
+[00:10:01] <Zero_Chaos>	WilliamH: the vote is about a gentoo bug, so yes, it matters.
+[00:10:07] <Pinkbyte>	Ok, then, let's vote
+[00:10:19] <Zero_Chaos>	may we each explain briefly the issue?
+[00:10:40] <Pinkbyte>	WilliamH, if you want that patch realizing 'want' was Gentoo-specific - that would be a problem. If no - no, it would not
+[00:10:58] <WilliamH>	Well, I do plan to work on want.
+[00:11:12] <Pinkbyte>	WilliamH, so...
+[00:11:14] <WilliamH>	But, the bug I sited from zero isn't really a bug because
+[00:11:16] <Zero_Chaos>	WilliamH: as is standard in legal proceeding, I brought the charges, may I explain my issue, you defend, and we vote?
+[00:11:39] <WilliamH>	there is procedure in place to handle it.
+[00:12:02] <WilliamH>	and president (sp) for openrc behaving that way.
+[00:12:05] <Zero_Chaos>	WilliamH: you are dragging your feet on the vote, we don't have all day. let's just get to this.
+[00:12:08] <Pinkbyte>	Guys, the all discussion here is summarized by that picture - https://geekwhisperin.files.wordpress.com/2009/09/bug-vs-feature.jpg?w=1200
+[00:12:16] <Pinkbyte>	but if you want - fine, let's vote
+[00:12:32] <WilliamH>	wait
+[00:12:38] <WilliamH>	the picture does me no good. ;-)
+[00:12:43] <Zero_Chaos>	Pinkbyte: who explains (briefly) first? I think this merits explaination
+[00:13:01] <Zero_Chaos>	WilliamH: it was a lame picture anyway, picture of a bug, then a bug in a suit marked "feature"
+[00:13:19] <ulm>	I use nfs but this issue never hit me
+[00:13:21] <WilliamH>	Here's where I'm at on it.
+[00:13:27] <ulm>	maybe because I'm using autofs?
+[00:13:37] <WilliamH>	ulm: maybe...
+[00:13:59] <WilliamH>	ulm: basically, nfsclient has "before netmount" in the dependencies.
+[00:14:20] <WilliamH>	ulm: nfsmount did in the past handle the mounting as well, but now it doesn't, so it was renamed nfsclient.
+[00:14:46] <WilliamH>	ulm: netmount for a while was a noop... zero's bug has all of the history
+[00:15:09] <Zero_Chaos>	can we please just each say a short explaination and vote? I have 10 minutes before my next meeting....
+[00:15:18] <WilliamH>	ulm: zero removed netmount from his default runlevel because he didn't want it running.
+[00:15:20] <Zero_Chaos>	please, let's do this or drop it and stop wasting everyone's time
+[00:15:38] <WilliamH>	Zero_Chaos: do we really need a vote on this?
+[00:15:56] <WilliamH>	Zero_Chaos: I agreed to work on "want", and the other bug is resolved per qa instructions and a newsitem.
+[00:16:15] <Zero_Chaos>	WilliamH: I do not want my bug closed until it's fixed. So yes, if you want to close it without fixing it, we need a vote.
+[00:16:25] <Zero_Chaos>	WilliamH: win, and you get to close the bug
+[00:16:34] <Zero_Chaos>	but for the love of god, we need to do this or drop it
+[00:16:47] <Zero_Chaos>	I only had an hour and a half for this meeting
+[00:16:59] <WilliamH>	Zero_Chaos: I agreed that want is a feature I'll look into. But, as things currently stand, if you follow the instructions in thenewsitem things work.
+[00:17:33] <Zero_Chaos>	WilliamH: I refuse to argue with you on this any further. agree to a vote or drop it. now.
+[00:17:46] <Zero_Chaos>	I lack the time for this
+[00:18:17] <WilliamH>	Zero_Chaos: fine, vote, but if I lose I will go straight to council.
+[00:18:27] <ulm>	Pinkbyte: what is the motion?
+[00:18:31] <Pinkbyte>	WilliamH, it's your right
+[00:18:37] <Zero_Chaos>	WilliamH: as is your right
+[00:18:44] <Zero_Chaos>	Pinkbyte: who explains their side first?
+[00:19:05] <Pinkbyte>	ulm, "Bug #537996 - should it be closed as fixed?"
+[00:19:08] <willikins>	Pinkbyte: https://bugs.gentoo.org/537996 ">=sys-apps/openrc-0.13 netmount script cannot properly mount nfs shares"; Gentoo Hosted Projects, OpenRC; CONF; zerochaos:openrc
+[00:19:24] <Zero_Chaos>	can we please give a brief description before the vote?
+[00:19:26] <Zero_Chaos>	it's a long bug
+[00:19:43] <ulm>	< 100 chars please :p
+[00:20:41] <Zero_Chaos>	I'll be quick.  nfs is supposed to be mounted by netmount, but netmount cannot do it without a helper which is not in the dep list.
+[00:21:35] <Pinkbyte>	helper can not be added as 'need' dependency(because nfs-utils should be added to RDEPEND list of openrc too), and 'use' dependency makes no sense too
+[00:21:56] <Pinkbyte>	however, most of OTHER filesystem, unlike nfs is as 'use' dependencies in netmount script already
+[00:21:57] <Zero_Chaos>	right, so WilliamH and I agreed that openrc needed 'want' which would resolve this issue when implemented
+[00:22:13] <Pinkbyte>	so it's a question - is all of them refers to this bug, or NFS is a special case?
+[00:22:53] <WilliamH>	May I state my side?
+[00:23:00] <Pinkbyte>	WilliamH, sure
+[00:23:01] <Zero_Chaos>	WilliamH: please do
+[00:24:26] <WilliamH>	OpenRC, by default, puts netmount in the default runlevel. nfsmount has "before netmount" and netmount now has "use nfsmount" in their dependencies. The newsitem I released with the new openrc tells you to add both to your runlevels.
+[00:24:49] <WilliamH>	If you do that, things start as they should.
+[00:24:52] <WilliamH>	and netmount works.
+[00:25:52] <WilliamH>	I have agreed to look into adding the "want" dependency as an enhancement, but that is separate from this issue.
+[00:26:26] <WilliamH>	I'm done.
+[00:26:27] <ulm>	WilliamH: I thought nfsmount was deprecated?
+[00:26:50] <ulm>	you mean "use nfsclient"?
+[00:26:56] <WilliamH>	ulm: nfsmount is nfsclient now. again, you add nfsclient to your runlevel as stated in the newsitem.
+[00:27:02] <WilliamH>	hang on.
+[00:27:10] <WilliamH>	How can I link to the newsitem here?
+[00:27:14] <Zero_Chaos>	this is a lot more than 100 char at this point
+[00:27:29] <Zero_Chaos>	and I'm out of time
+[00:27:30] <ulm>	WilliamH: above you said 'netmount now has "use nfsmount" in their dependencies'
+[00:27:48] <WilliamH>	It is 2015-02-02-nfs-service-changes
+[00:27:49] <ulm>	should read "use nfsclient", I guess?
+[00:27:51] <Zero_Chaos>	Pinkbyte: please count that I vote against closing my bug until it is fixed, but I agree to making to dep the 'want' but and removing QA.
+[00:28:00] <Pinkbyte>	Zero_Chaos, sure
+[00:28:35] <WilliamH>	ulm: that use was put there because pinkbyte requested it.
+[00:29:10] <ulm>	now you've managed to completely confuse me
+[00:29:15] <Pinkbyte>	ulm, it's the closest currently available dependency measure
+[00:29:41] <Pinkbyte>	ulm, problem is - 'use FOO' would not start foo, unless service foo is added into the same runlevel
+[00:29:54] <ulm>	on my system here I see "need nfsclient netmount" in nfsmount
+[00:30:00] <Pinkbyte>	'need FOO' would do the trick, but it's hard dependency, not soft
+[00:30:04] <ulm>	openrc-0.13.9
+[00:30:20] <Pinkbyte>	ulm, look at nfsclient
+[00:30:26] <WilliamH>	ulm: the nfsmount script was re-added by robbat2 to catch people who didn't follow the news item.
+[00:30:31] <ulm>	and netmount has "use nfsclient"
+[00:31:05] <Pinkbyte>	ulm, i am sorry, netmount of course.
+[00:31:07] <Pinkbyte>	yeah
+[00:31:08] <Zero_Chaos>	Pinkbyte: the real solution to my issue is add 'want' support to openrc, and then "want nfsclient" when nfs mount are in fstab.  the patch is written, WilliamH agreed to add want support when he has time, so my bug tracks the issue.
+[00:31:15] <WilliamH>	ulm: that change too netmount was requested by Pinkbyte
+[00:31:19] <Zero_Chaos>	Pinkbyte: we agree on everything except the fact that it's a bug.
+[00:32:13] <WilliamH>	Pinkbyte: imo this is all happening because Zero_Chaos  removed netmount from his default runlevel.
+[00:33:01] <Pinkbyte>	WilliamH, non-default setup is not always a bug itself, sometimes it reveals bugs
+[00:33:28] <WilliamH>	Pinkbyte: the news item specifically tells you to make sure netmount and nfsclient are in the same runlevel.
+[00:33:54] <Pinkbyte>	WilliamH, true
+[00:33:58] <WilliamH>	How do I link to it here?
+[00:34:11] <Zero_Chaos>	WilliamH: they are, niether is in any run level at all :-)
+[00:34:44] <WilliamH>	Zero_Chaos: then you aren't following instructions. :p
+[00:34:57] <Pinkbyte>	http://cgit.gentooexperimental.org/proj/gentoo-news.git/plain/2015/2015-02-02-nfs-service-changes/2015-02-02-nfs-service-changes.en.txt?id=b60e047f2588e275c1ddae4fd66d221ca33adda3
+[00:35:08] <WilliamH>	I need a link to the newsitem in this channel so everyone can see it.
+[00:35:22] <Zero_Chaos>	I do not contend the news item is wrong
+[00:35:25] <WilliamH>	ok
+[00:35:27] <Zero_Chaos>	I contend the init script is wrong
+[00:35:49] <WilliamH>	Zero_Chaos: then what you are asking for is the want feature, wich has a separate bug.
+[00:36:08] <WilliamH>	Zero_Chaos: so we don't need two bugs open.
+[00:36:56] <Pinkbyte>	How about that solution - rename bug to "nfsclient dependendency should be 'want'", depend that bug on other one, about the feature itself and lower it's priority to enhancement
+[00:36:57] <WilliamH>	Zero_Chaos: the want feature is bug 406021
+[00:37:00] <willikins>	WilliamH: https://bugs.gentoo.org/406021 "sys-apps/openrc -"want" soft-dependency"; Gentoo Hosted Projects, OpenRC; CONF; polynomial-c:openrc
+[00:37:05] <Pinkbyte>	so you could track all things up properly
+[00:37:16] <Pinkbyte>	and remove qa@ from it, of course
+[00:37:51] <Zero_Chaos>	Pinkbyte: I would accept that as well. I would accept almost anything that keeps my issue properly tracked
+[00:38:20] <WilliamH>	Zero_Chaos: I don't see why we need a dupe bug which is basically what yours is.
+[00:38:38] <WilliamH>	Zero_Chaos: I think if I dupe it it will move you to the other bug...
+[00:39:04] <Pinkbyte>	WilliamH, your bug is about feature itself. Zero_Chaos's bug is about which script should utilize this feature after it would be implemented
+[00:39:04] <WilliamH>	Zero_Chaos: Can I test that and reopen it if it doesn't?
+[00:39:36] <ulm>	guys, we're approaching 3 hours meeting time ...
+[00:39:49] <Zero_Chaos>	WilliamH: this is not a dupe, it is a missing dep in your init script which cannot be solved without a feature enhancement
+[00:40:22] <Pinkbyte>	WilliamH, let's recap - you will code nice and shiny 'want' feature. But you will need to remember which initscript will have benefits from it
+[00:40:29] <Pinkbyte>	or dig into closed bugs for that
+[00:41:04] <Pinkbyte>	or wait until new bug would be opened for exactly the same issue with netmount/nfsclient
+[00:41:38] <Zero_Chaos>	right
+[00:41:41] <WilliamH>	Pinkbyte: ok... do that for now...
+[00:43:14] <Zero_Chaos>	WilliamH: you want to close my bug, add the want feature, and for me to reopen my bug and as for "want nfsclient" (which is exactly my bug now)? that makes no sense.
+[00:43:34] <Zero_Chaos>	I think this issue makes sense to all, let's vote so we can end this pain.
+[00:43:42] <WilliamH>	Zero_Chaos: no, I just agreed with him to drop the priority on yours etc.
+[00:44:49] <Zero_Chaos>	WilliamH: I am fine with making my bug an "enhancement" and marking the want bug as a depend.  If that meets your approval, please proceed.
+[00:44:59] <Zero_Chaos>	WilliamH: just don't close my bug.
+[00:45:28] <WilliamH>	Zero_Chaos: ok
+[00:45:42] <Pinkbyte>	I am really glad that we finally make some consensus here. Thanks for you both
+[00:46:26] <Pinkbyte>	So, i propose we will end our meeting now, cause, as ulm is mentioned - we hit 3 hours barrier and it's not really good
+[00:46:53] <WilliamH>	go for it ;-)
+[00:47:00] <Pinkbyte>	But honestly - there is 00:46 am now on my clock and i need to be at work at 08:00 am, so... i just want to go to bed :-P
+[00:47:10] <mrueg>	Pinkbyte: just one last question
+[00:47:32] <mrueg>	is there an invite-only gentoo qa channel?
+[00:47:46] <mrueg>	I haven't found any information on that.
+[00:47:54] <Pinkbyte>	mrueg, nope. And i do not think we need to have that channel
+[00:47:57] <mrueg>	Tommy[D] told me that qa@g.o is used for that
+[00:48:01] <ulm>	there is #gentoo-qa-private
+[00:48:09] <mrueg>	heh.
+[00:48:12] <Pinkbyte>	ulm, o_O
+[00:48:19] <ulm>	but no idea who uses it
+[00:48:38] <Pinkbyte>	so, it's non-official
+[00:49:32] <ulm>	founded by creffett, as it looks like
+[00:49:43] <mrueg>	creffett|irssi: ^
+[00:49:51] <ulm>	and most qa members are listed
+[00:50:05] <Pinkbyte>	yep. And i am(along with almost all team members) lucky to be in access list of it
+[00:50:21] <ulm>	but I don't see mrueg there
+[00:51:09] <Pinkbyte>	ulm, yep, the other place that i forgot to send a request to add him to. Because i did not even know about it :-)
+[00:51:42] <mrueg>	Pinkbyte: should we document adding new qa members somewhere in the wiki?
+[00:52:22] <Pinkbyte>	mrueg, maybe. You can draft an article as a member, who went through all that pain :-)
+[00:52:37] <ulm>	Pinkbyte: only creffett has +f there
+[00:52:38] <mrueg>	Pinkbyte: okay will do ;)