From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 769F31387FD for ; Mon, 7 Apr 2014 11:37:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2B70AE0B2C; Mon, 7 Apr 2014 11:37:38 +0000 (UTC) Received: from andre.telenet-ops.be (andre.telenet-ops.be [195.130.132.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 58485E0B26 for ; Mon, 7 Apr 2014 11:37:36 +0000 (UTC) Received: from localhost ([94.226.55.127]) by andre.telenet-ops.be with bizsmtp id mzdb1n0062khLEN01zdbsc; Mon, 07 Apr 2014 13:37:35 +0200 Date: Mon, 7 Apr 2014 13:36:57 +0200 From: Tom Wijsman To: gentoo-project@lists.gentoo.org Cc: pacho@gentoo.org Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2014-04-08 Message-ID: <20140407133657.0fc9f9b8@gentoo.org> In-Reply-To: <1396819347.2061.5.camel@belkin5> References: <53342A5F.70903@gentoo.org> <201404061435.00789.dilfridge@gentoo.org> <53414CD2.4030100@gentoo.org> <53416E80.40605@gentoo.org> <534172D6.6040204@gentoo.org> <1396819347.2061.5.camel@belkin5> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 8135c509-7756-4ef4-a48d-4878125414e4 X-Archives-Hash: 5de9afefc140d57d2d5dd9c4fb918643 On Sun, 06 Apr 2014 23:22:27 +0200 Pacho Ramos wrote: > I think that one step to try to fix things like this would be to > clarify how QA decisions need to be taken. Looks like there was some > confusion related with how many QA team members were in favor and > against of hardmasking the new *udev* virtuals and, There is no confusion, because it was escalated too fast; instead of appropriately addressing the QA _team_ and waiting for response first. > then, this lead to the whole problem escalation. This is already present in GLEP 48[1]: In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council. Note however that escalating in steps still applies; talk first to the QA developer, then talk to the QA team [qa@gentoo.org], then talk to others on the gentoo-dev ML and/or then talk to the Gentoo Council. If everyone goes straight to higher instances, thus doesn't communicate; we'll have these talks happen every month, as happened twice now. > What we should try to do is to clarify how QA decisions need to be > taken. Do they need to be approved by a majority of the team? Only > some of them? I have read > https://wiki.gentoo.org/wiki/Project:Quality_Assurance but I see no > note about how QA team take actions and the "procedure" to follow and > expect. This is also already present in GLEP 48[1]: In the case of disagreement among QA members the majority of established QA members must agree with the action. Some examples of disagreements are whether the perceived problem violates the policy or whether the solution makes the situation worse. We know what to do; however, we can't do it if we're not addressed. The entire event happened at night hours in the weekend with barely any QA members awake; so, at the very least, mail us [qa@g.o] and wait 24h. [1]: https://wiki.gentoo.org/wiki/GLEP:48 -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D