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 75126138247 for ; Wed, 15 Jan 2014 11:40:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 61F89E0B42; Wed, 15 Jan 2014 11:40:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5F1E7E0B0C for ; Wed, 15 Jan 2014 11:40:27 +0000 (UTC) Received: from [91.220.220.251] (pinkbyte.micronet-rostov.ru [91.220.220.251]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pinkbyte) by smtp.gentoo.org (Postfix) with ESMTPSA id 3ACE933F46D for ; Wed, 15 Jan 2014 11:40:25 +0000 (UTC) Message-ID: <52D673A4.2080508@gentoo.org> Date: Wed, 15 Jan 2014 15:40:20 +0400 From: Sergey Popov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131113 Thunderbird/17.0.9 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy References: <20140114213719.GA2684@laptop.home> <20140115004928.1fae6bf9@TOMWIJ-GENTOO> In-Reply-To: <20140115004928.1fae6bf9@TOMWIJ-GENTOO> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K3r8PmN1hTpl7I3uAVEGcQs8Cl6glKhfK" X-Archives-Salt: 0fd62086-7e7b-4b74-9267-f5ee51e34346 X-Archives-Hash: 847951752368c05873d57c5ba1f39bb3 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --K3r8PmN1hTpl7I3uAVEGcQs8Cl6glKhfK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 15.01.2014 03:49, Tom Wijsman =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Tue, 14 Jan 2014 15:37:19 -0600 > William Hubbs wrote: >=20 >> Thoughts? >=20 > In this situation, I see three opposite ends of choices: >=20 > 1. "We do nothing"; which means that as a side effect either less > often a version would be picked for stabilization or stabilizations > will just take longer due to a longer queue. The question here is > whether the queue is actually growing; to get a quick idea, we could > compare the amount of bugs we have now compared to those of last time= =2E >=20 > Advantage: We keep the same policy and quality of stabilization. >=20 > Disadvantage: Stable runs further behind. Waiting time. Frustration. >=20 > Resources: We need to find more people for the arch teams. >=20 > 2. "We crowd source it"; which means we tackle the 'low manpower' > problem itself, we invite at a larger scale feedback for packages in > one or another way. This ranges from a simple reminder when merging a= > non-stable package to report back whether it is working, to a more > large scale new website effort where this can be done much more > organized; but that's a whole discussion on its own. >=20 > Advantage: Power to the community. Need for arch teams decreases. >=20 > Disadvantage: Stabilization quality could drop. Enough feedback? >=20 > Resources: We need to patch up and/or write enough to pull > attention from the user that there aid is needed. >=20 > 3. "We make stable mean less"; which means that we accept the 'low > manpower' problem, this would as a consequence thus mean that because= > we cannot put in enough effort to deem everything stable anymore. The= > word 'stable' would thus mean less, instead of 'thoroughly tested by > a separate person' it becomes 'tested by the same maintainer'. >=20 > Advantage: Gentoo becomes slightly more bleeding edge. >=20 > Disadvantage: Problematic for important packages were stabilization=20 > is really needed; 'stability' of some user application > has a much smaller meaning than on a library shared > between multiple applications of the user. >=20 > Resources: Less resources used, though it might yield more bugs. >=20 > Of course this is not meant to limit other choices, there might be > others and I hope people bring them forward; as a closing word it feels= > hard to decide here, especially since it can have quite an effect on > the distribution. As put above neither option seems convincing, neither= > option seems like it is without risk; does anyone have a different view= ? >=20 > Unless we only do a small version of those options, like changing a > minor detail instead of pushing it through at once; which could be a > more safe step forward. Which smaller options do we have here? >=20 > If at all, maybe experiment something on one arch to start with? >=20 As i said earlier for similar proposals - the one option that i see here to make all things going better - to recruit more people in arch teams/arch testers. Other options lead us to nowhere, when stable will be eliminated or transformed into fake. --=20 Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead --K3r8PmN1hTpl7I3uAVEGcQs8Cl6glKhfK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS1nOlAAoJECo/aRed9267Hs8H/A30G6/g/cz6HWora7N7nejf gHGNnXlTkBwJT+IxUxuppMIsnNOYNRqih8SrVYT0viWPIPgnpLqG2M7xfMrYNams r3nkobTE2Oou1u3oNn7BaOAFF7SlmKGIl2o/5IeMWFmUSB3o2MiEAH2HwCu1V0mr xqPI8YE7nD1Weq/Jy79/ojUAVOGB6k+ERFGyNo/thSJhta3Gukzu16zT6QYYueWm 3NDG0KKx8vTuFILQNPUte9z/jAMNn5pmgngyXA+jy0dTUWfhrTjOSrKCD3AUjCRk Kz0R714DRXtQlvKhGLbDoubZKXSXdoi2GITN73/VJ5g8vqPEjsy/1gbJI/KxCP8= =SSGW -----END PGP SIGNATURE----- --K3r8PmN1hTpl7I3uAVEGcQs8Cl6glKhfK--