From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 059A2139694 for ; Tue, 25 Jul 2017 20:17:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B3362E0E59; Tue, 25 Jul 2017 20:17:08 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 55903E0B4B for ; Tue, 25 Jul 2017 20:17:08 +0000 (UTC) Received: from [46.246.44.10] (anon-44-10.vpn.ipredator.se [46.246.44.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zlg) by smtp.gentoo.org (Postfix) with ESMTPSA id C4EA53416AD for ; Tue, 25 Jul 2017 20:17:05 +0000 (UTC) Subject: Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts? To: gentoo-dev@lists.gentoo.org References: <20170724222223.6d359e47@sf> <10267d25-547b-cbe1-7fdd-40200e7bae4b@gentoo.org> From: Daniel Campbell Message-ID: <6ab7e1c7-e967-a82f-c309-c62524b91168@gentoo.org> Date: Tue, 25 Jul 2017 13:16:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 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 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FM7I2ANdO4RTaRFuQC22t9DKd7eR3MB7W" X-Archives-Salt: 66444d61-231b-4f83-9dcc-79c305f19bd2 X-Archives-Hash: d713497f8ea808cfa9a907f75b3c65ca This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FM7I2ANdO4RTaRFuQC22t9DKd7eR3MB7W Content-Type: multipart/mixed; boundary="6JcrCfR4VIxqMmoStUb2oxMqSaKS7n0cT"; protected-headers="v1" From: Daniel Campbell To: gentoo-dev@lists.gentoo.org Message-ID: <6ab7e1c7-e967-a82f-c309-c62524b91168@gentoo.org> Subject: Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts? References: <20170724222223.6d359e47@sf> <10267d25-547b-cbe1-7fdd-40200e7bae4b@gentoo.org> In-Reply-To: --6JcrCfR4VIxqMmoStUb2oxMqSaKS7n0cT Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/25/2017 06:22 AM, Rich Freeman wrote: > On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka wrote: >> >> The 30 day waiting period is useful for smoking out major upstream bug= s, >> but can't replace stabilisation integration testing. For example, >> package foobar may build fine in ~arch but fails in stable because it >> needs a newer libbaz. >> >=20 > I think this is a good reason why everything should be at least > build-tested on a stable tree before getting stabilized. Now, that > might not be on each arch if it is truly arch-independent (and if > arches keep the dependencies reasonably in sync). >=20 > This might be a situation where a compromise could exist. Have some > kind of flag (in metadata, or maybe the ebuild) that indicates that > the maintainer believes the package is low-risk to stabilize purely on > a build test. Then after 30 days in testing a tinderbox could > build-test the package and stabilize it automatically. >=20 > If the package is considered at-risk then it goes through manual > testing, either by the maintainer or an arch team. >=20 > This will also encourage the teams doing testing to actually do more > testing on the packages that would benefit from it. >=20 > We wouldn't set hard criteria but leave it up to maintainer > discretion, with a guideline being that past performance is probably a > good predictor of future results. >=20 This reads like a practical use of both developer time and machine time. Build testing at a minimum, imo, is necessary if the word "stable" is going to mean anything for us. So +1. Since there are bound to be fewer manually tested packages than automatic "it builds, ship it" packages, I think it would make a bit more sense to add a "manually test this please" tag to metadata.xml, rather than expect auto-stabilizers to have additional tags, which will outnumber the manual packages and inflate the size of the tree (albeit slightly). Since maintainers also manage their packages in various ways, could we extend this to a general element? Maintainers can specify how they'd prefer bugs or commits to be done, and an additional element to indicate hand-testing. This would solve two problems instead of just one: indicate a package is ready for auto-stabilization, and give a single, canonical location for a maintainer to put maintenance policy. Just my 2=C2=A2, ~zlg --=20 Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 --6JcrCfR4VIxqMmoStUb2oxMqSaKS7n0cT-- --FM7I2ANdO4RTaRFuQC22t9DKd7eR3MB7W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgIn+0tMDW9PQWDLnASQOlFA54XAFAll3pzQACgkQASQOlFA5 4XDvdw/+PhplENyEtaZ6+j1ijAhK/b9biHA/9oDqVh6u0o8o9y8nLIXJed5lQCYv ew705cIu32laR9FSJzF3Qr1SkIDnsvEqZPCVrwp93XkZ++AaMhOFOG9k+6sXFYtX jRqfxu9uzPr4hZNPrS05vXcPvMRblMsbFXdfkQ2IXKCX7acW/i4tkSkcidz7f7XR Upp+UlzL8ampkZ/6OKqNNIZ/w0rbWp/xiczTFhA52/57DFM1+s3BB/04bWysjlA3 esM+FHW5EISFHl3CScQeAGMiR/ISzYPoeMhQD4UqT4KE+9ch18JjIkIppmVx3JtK +EhpsB3Takxz/bE5i1Ld5hjkIMZuFDNrN0c8LPj/vIDZ6ZsJdRpkxMnupS60SVsr 43CDf+9IQ4Xez53YzHNFp2uz/AbEK6HhUhJyDRwiRa3YmfcMPWEeECisajChuLvq b3uKW6mW2Ifc7HMlLGsJaonImeofC6rVO2w2QRYBDbYj3yUk74ITAoFARTGnll4R CmJ96LHP1dUewh9O9Y2XKnGb+5iSRj8hLL0QoVn1LDmsc97qXOxcmBzYuGpgl/tu VYsP4gMeh5ccyc8G7YN7N6yO1l0ZEq66jbeIdDgb13AXN6w1zhkq/gISDFpjVsth natjGvgvRTJmMSG1lJDmJtUTb9WYcdCrbRTDwK6FaG6KaM6Fz9o= =OVVn -----END PGP SIGNATURE----- --FM7I2ANdO4RTaRFuQC22t9DKd7eR3MB7W--