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 C34561381F3 for ; Tue, 21 May 2013 23:29:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 43A9EE07F1; Tue, 21 May 2013 23:29:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 44CF5E07D3 for ; Tue, 21 May 2013 23:29:00 +0000 (UTC) Received: from [192.168.178.22] (p57B4C63C.dip0.t-ipconnect.de [87.180.198.60]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tommy) by smtp.gentoo.org (Postfix) with ESMTPSA id B28B533E162 for ; Tue, 21 May 2013 23:28:58 +0000 (UTC) Message-ID: <519C0331.9040405@gentoo.org> Date: Wed, 22 May 2013 01:28:49 +0200 From: Thomas Sachau User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1 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] robo-stable bugs References: <20130519154027.37b6cdf4@marga.jer-c2.orkz.net> <5199678F.4090207@gentoo.org> <519B66BF.4090304@gentoo.org> <519B78E4.9000702@gentoo.org> <519BBDCF.1050605@gentoo.org> In-Reply-To: <519BBDCF.1050605@gentoo.org> X-Enigmail-Version: 1.6a1pre OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2ACSRIPMSRMVOKDOTFJTF" X-Archives-Salt: a1b254e6-7266-4f92-96b2-8f0e65ed4f3f X-Archives-Hash: 457ec98664ca73885073a2c80f1c8205 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ACSRIPMSRMVOKDOTFJTF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "Pawe=C5=82 Hajdan, Jr." schrieb: > On 5/21/13 6:38 AM, Thomas Sachau wrote: >> And if a maintainer is not responding within 30 days, you can ping him= >> or, without a response, try to get a different maintainer. Just assumi= ng >> that a stable request is ok without a maintainer response is really no= t >> a good idea. >=20 > Thomas, this effort is going on for over a year now (and has been > discussed on gentoo-dev). If it's only now you've noticed, maybe the sk= y > isn't falling after all. I dont remember any auto-stabilization being accepted, but maybe this happened in number 30 or 50 of some thread, where i already got bored and did not follow it any more. And how should i notice your script, when it never applies to my packages? ;-) > Note that there is a tradeoff here: I really started the stabilizations= > after I've noticed how many bugs are fixed in ~arch that still affect > stable, but the fixing version didn't get stabilized. This is the > downside of an opt-in approach, since inactive maintainers are not goin= g > to opt-in. >=20 > Finally, everyone from metadata.xml is CC-ed. There is no "trying a > different maintainer" - all of them are there since day one. "trying a different maintainer" did mean re-assigning the package, when a maintainer is gone/inactive >=20 > Please let me know if you still have concerns - ideally back them with > data and actual cases showing problems (or scenarios that can reasonabl= y > be likely) instead of just saying it _might_ lead to breakages. Anythin= g > _might_ lead to breakages, including taking no action here and allowing= > bugs to be not fixed for stable. :) Give me the needed amount of time to create such data, dont miss the motivation for such project and i may do it. ;-) Some show cases: When a maintainer wants to stable at a later point in time or another version and keeps the bug open to re-use it, he would suddenly get your suggested version stable, also he did explicitly not give his go and did not add arches. And if a maintainer does not respond for a certain amount of time, i would not take it as a sign for a package to be stable, but instead of a sign, that the package will need a new maintainer, who can then check for the best fit for a stable candidate. After all, the latest version may be the upstream development branch, while latest stable already follows upstream stable branch. So creating stable bugs with your above requirements looks ok, the point i have a problem with is still the opt-out setting. --=20 Thomas Sachau Gentoo Linux Developer ------enig2ACSRIPMSRMVOKDOTFJTF 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.20 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iJwEAQECAAYFAlGcAzcACgkQG7kqcTWJkGcljwP5AS1aNrms8KhVpJ4jcdsJ5IPc zeCQq9b7QeeQYXjyZ5us3Frk83x5i6lx48uMJ164+uh6jOeM1zSSbIBz2iLVJkyC 6Z4YFjMDMZ+crPMufeR3RQws8ZoqRPJR3cRn5HOGARKro7lnEfkg/QMRdas/WDeR c8n0SYss1voXRugrXJE= =w3II -----END PGP SIGNATURE----- ------enig2ACSRIPMSRMVOKDOTFJTF--