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 04F6B138247 for ; Tue, 14 Jan 2014 23:50:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8170AE09EA; Tue, 14 Jan 2014 23:50:26 +0000 (UTC) Received: from jacques.telenet-ops.be (jacques.telenet-ops.be [195.130.132.50]) by pigeon.gentoo.org (Postfix) with ESMTP id 5136EE09D5 for ; Tue, 14 Jan 2014 23:50:25 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by jacques.telenet-ops.be with bizsmtp id DzqQ1n00d2khLEN0JzqQmD; Wed, 15 Jan 2014 00:50:24 +0100 Date: Wed, 15 Jan 2014 00:49:28 +0100 From: Tom Wijsman To: williamh@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: revisiting our stabilization policy Message-ID: <20140115004928.1fae6bf9@TOMWIJ-GENTOO> In-Reply-To: <20140114213719.GA2684@laptop.home> References: <20140114213719.GA2684@laptop.home> 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 Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/DyuIit._xoVa5LXykKzqgOb"; protocol="application/pgp-signature" X-Archives-Salt: 0be30d72-e1af-4930-9fea-6a7247bd4430 X-Archives-Hash: 263f3e4dcde6466cb21c377ae8f76186 --Sig_/DyuIit._xoVa5LXykKzqgOb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 14 Jan 2014 15:37:19 -0600 William Hubbs wrote: > Thoughts? In this situation, I see three opposite ends of choices: 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. Advantage: We keep the same policy and quality of stabilization. Disadvantage: Stable runs further behind. Waiting time. Frustration. Resources: We need to find more people for the arch teams. 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. Advantage: Power to the community. Need for arch teams decreases. Disadvantage: Stabilization quality could drop. Enough feedback? Resources: We need to patch up and/or write enough to pull attention from the user that there aid is needed. 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'. Advantage: Gentoo becomes slightly more bleeding edge. 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. Resources: Less resources used, though it might yield more bugs. 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? 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? If at all, maybe experiment something on one arch to start with? --=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 --Sig_/DyuIit._xoVa5LXykKzqgOb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS1c0IAAoJEJWyH81tNOV91YkIAMZDPVYm7j7TEFIVYjv1wPLj hdBBPKkguqfQebZrwTkHP+xfs/kbWkY4oaLLTX2nwSZ79xDBNrbtPBFdXaqyHngw g9m4G4xugKeZnhqFKwSqIGY2ykDnVT1lsdeeq3a0REej7Fp4SoshoYeN2+IDiqzi 8SyFmioCqolRF8ugUx8zF06mHNiftK13VX2T445xq4iNXppUAsk9GaVhT21UArzc LdJQJjhhDmO+pS4DUKpNC9TDH8XIoe3YnLde7K2exYR4/1H2cn0GKmC84TWyAaWE e/8F7+9vBS2V83aAOKDvBd9VvY4x46fNtsB40yNoNgPa5Wb47W99AxU8AMfAoxY= =fJQX -----END PGP SIGNATURE----- --Sig_/DyuIit._xoVa5LXykKzqgOb--