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 7EB47138E66 for ; Mon, 24 Feb 2014 23:55:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F2C54E0A81; Mon, 24 Feb 2014 23:55:47 +0000 (UTC) Received: from michel.telenet-ops.be (michel.telenet-ops.be [195.130.137.88]) by pigeon.gentoo.org (Postfix) with ESMTP id 47E75E09F9 for ; Mon, 24 Feb 2014 23:55:47 +0000 (UTC) Received: from localhost ([94.226.55.127]) by michel.telenet-ops.be with bizsmtp id WPvm1n00B2khLEN06Pvm12; Tue, 25 Feb 2014 00:55:46 +0100 Date: Tue, 25 Feb 2014 00:55:25 +0100 From: Tom Wijsman To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25 Message-ID: <20140225005525.615433be@gentoo.org> In-Reply-To: <530BBD0D.50808@gentoo.org> References: <201402101545.39578.dilfridge@gentoo.org> <53069A66.2090907@gentoo.org> <20140221034746.GF8819@comet.hsd1.mn.comcast.net> <530B775E.3000006@gentoo.org> <20140224195930.721c7446@gentoo.org> <530BBD0D.50808@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 761c65f3-10cd-486d-a767-c3675a27fff8 X-Archives-Hash: c03fe572a073e706d211f803435c9b4a On Mon, 24 Feb 2014 22:43:41 +0100 Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n wrote: > Tom Wijsman schrieb: > >> Thanks, I would like to phrase the question a little more > >> precisely: > >> > >> I would like to ask council to state whether the QA team has the > >> authority to mandate a policy when there is neither general > >> agreement that this policy is a good thing, nor the policy would > >> avert any kind of immediate serious problem for users. > > That can be reduced to the question whether QA is considered > > serious. >=20 > I don't think so. If the council answers this question in the > negative, QA still has its emergency powers and can enforce the > policy set by the council. > QA can also propose any new policy they consider useful to the > council, which can then hear the opposing sides and make a decision > based on that. You describe a Gentoo Developer, apart from the small difference that they have this emergency power; when it comes to it, that power is quite similar to having a Gentoo Developer revert according to policy and that deemed as OK (under the assumption of there being no QA team). > > (There is a majority that agrees as well as a serious problem to > > users in the GTK+ USE flag situation; the former can be deduced > > from the mailing list, the latter can be realized when controlling > > the USE flag among a lot of GTK+ packages. It is something that can > > be done later; on the other hand, if we categorize everything that > > way it halts progress) >=20 > The gtk flag naming problem is not serious in the sense that it will > break user systems. It depends on how you define the words; but I find it a serious issue if you have an USE flag that works one way in a set of packages and works the other way in another set of packages, it is broken in the sense that the user now has to use package.use if he has a lot of packages that have a gtk flag and needs that flag to behave. > Additionally, it has been known and discussed for a long time. If it comes up again and again on ML, upsets people in bugs, have people bring it up independently to both QA and Council; it is of much more concern than for example a thread about small bug wrangling details. > Establishing a gtk USE flag policy did not become suddenly so urgent > that next council meeting was too far in the future. The discussions, pings and mails act as a nagging reminder. > > The GLEP states that we can > > > > 1) maintain a list of current "QA Standards"; > > > > 2) ensure all developer tools are in line with the current QA > > standards; > > > > 3) and apply it as per "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." > > > > which effectively makes the "QA Standards" act as policy. >=20 > I don't think that it is necessarily the case. "QA standard" could > also mean telling developers to either use gtk USE flags in the QA > team recommended way, or ensuring through other means that users to > not encounter unexpected breakage. The GNOME team's internal policy was a recommendation; as can be seen from the current state, that doesn't ensure anything. What other means would ensure that users do not have to micro manage with package.use? > Another possible interpretation is that QA standards codify > established good practices which are largely non-controversial (it > was attempted with saying that live ebuilds should be unkeyworded or > p.mask'ed IIRC).. It also depends on who discovers the new problems, who forms the explanations, who decides how to fix the problem; ... For that, you can look at mentions like "This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action.". But then you once again need to know whether "issues" are meant as "policy violation", or as "breakage", I think we can go on for a while here... We need to remind ourselves that a GLEP is a "Gentoo Linux Enhancement Proposals" and that it is nowhere a picture perfect policy; so, yes, I hope the seriousness (and associated consequences) is clarified. GLEP 48 addresses controversy with "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.". > > As "QA Standards" under this interpretation are needed to raise > > quality; the council should clarify whether we are able to raise the > > quality level, or rather are restricted to what exists and expect > > the council to raise the quality instead (by having the council do > > that). >=20 > "raise the quality" is very subjective. This would not restrict QA > powers at all, because almost any policy can claim that as its aim. Policy formulation is a power that has a near direct effect on quality. --=20 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