path: root/meeting-logs/20140416.txt

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.