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 188AE138A3F for ; Sun, 5 Apr 2015 21:27:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F3768E094A; Sun, 5 Apr 2015 21:27:16 +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 5F31FE0943 for ; Sun, 5 Apr 2015 21:27:16 +0000 (UTC) Received: from localhost (sloan0.ut.mephi.ru [85.143.112.33]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bircoph) by smtp.gentoo.org (Postfix) with ESMTPSA id B1B313409D1 for ; Sun, 5 Apr 2015 21:27:14 +0000 (UTC) Date: Mon, 6 Apr 2015 00:27:06 +0300 From: Andrew Savchenko To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items Message-Id: <20150406002706.4aff7e4dda27a25a5c106b50@gentoo.org> In-Reply-To: <20150405195044.GA2917@linux1> References: <20150402141428.GA31638@oregano.home.lan> <201504032214.01310.dilfridge@gentoo.org> <20150404220205.GA415@linux1> <1428237147.22472.1.camel@gentoo.org> <20150405195044.GA2917@linux1> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.25; i686-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: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Mon__6_Apr_2015_00_27_06_+0300_PoTul6=8dVC49mQ+" X-Archives-Salt: 7dd2fba7-bccc-4999-861a-98316d0b3d68 X-Archives-Hash: 82460c694932a644bfd7feb738dfdf53 --Signature=_Mon__6_Apr_2015_00_27_06_+0300_PoTul6=8dVC49mQ+ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 5 Apr 2015 14:50:44 -0500 William Hubbs wrote: [...] > > I wonder if maybe we should suggest to finally move ia64/alpha/sparc to > > testing (as was done for mips, sh...) :/ > =20 > Also let's add ppc and ppc64 to this list; they were brought up in the > message starting this discussion. I personally would vote for moving all > of these arch's to exp status. >=20 > That becomes a separate action and does not answer the underlying > question that keeps coming up. >=20 > That question is, if a maintainer opens a stable request and assigns an > arch team to it, and that arch team has no activity on the stable > request for 90 days, what should the maintainer do? > > I would say that the maintainer can at their discression remove the > old stable version. Yes, that would temporarily break the stable > depgraph, but it could be argued that the old version is by definition > broken since the newer version the maintainer wants stabilized could > have fixes for bugs in the old version. Why to apply for actions such extreme as moving arch to dev/exp state or breaking its stable tree? There are more elegant solutions available. 0. Set "deadline" to 90 days for ordinary stable requests and 30 days for security-related stable requests. Numbers are may be discussed and changed, but the idea is that time constraints for response on security issues (especially critical security issues) should be tighter than for ordinary bugs. Then if time limits above are expired: 1. If developers have an access to a setup for an affected arch (e.g. can test packages on that arch), allow developers to stabilize packages themselves. 2. Otherwise allow developers to drop stable keywords from affected package and _all_ its reverse dependencies. This way a part of stable tree will be removed, but only a part. With this approach arch teams will be freed of an extra burden, while they will be still able to maintain a smaller stable tree. This is a win-win solution: a stable tree will be still kept in a maintainable size and developers will not have a long-term blockers on their stabilization requests. 3. And last but not the least: apply the rules above to all arches, not just minor teams (though probability that amd64/x86 will be slow is lower, of course). Best regards, Andrew Savchenko --Signature=_Mon__6_Apr_2015_00_27_06_+0300_PoTul6=8dVC49mQ+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVIaiqAAoJEPZTWjO6HuSNO7QP/RqgLanDL4mFnOgyVsac5SlK FBK/2fcrSYSkzShK+jabUK5EKFBObnycGvk8saeIIzXhrqoudWagV+YCm2f/e8Xr 65e6aaHCmo/L9vOZNLuNjIuc5SwPJ2kZOUh0xAMDK+AxilhcX0ALb5/cPP2RHRjy 3a14f+HEn9BkQZgzMBY4Uzt7ZZS0qZ6MztrlVg89i3ixMS65clmkPhBkQHqJxN7c MJwXPB8WBtzG+CR/YvIB/fbalfS3xk5HS8zUzGBAi5L/vYDUnMV0VNge70cISPMW MmO2axIPC5IZo7LHslx7Kc26fsJWkjiuOog0M1fsvkaJv05tZ/kn/DbnjMxEeQDl vZhb9Jpo1w/E7ll29G/v03QwwU2rgpZ96EJulcoXNxWv++2Xztz7Ksth7MzhOMWj 5H9QulLqBrPiK/rcTWjSrmOcml09Daqy+lCKLNqG0fNhxxGAJl0ZQVriRG3i26b5 w/eel2otCqVtzNyya1IwMyiwhTFsngEKjyuoiIbBnwt3TnIT/Drxph/P3pkUwXa7 x9T8Y8UxmeATAEAWcbdreNMIL0CvZRrEeGGKaEln+XvgPBv/jbJdOv1m6JEHtlnH 5Llb14yRWK/hX+7w7Dx7lqdCoBefifFHV8g6o/C9GRGmwA5HTnzxx++omrKDpJ5Q UR5ygBmgtWNUG9tmw0jR =WIZO -----END PGP SIGNATURE----- --Signature=_Mon__6_Apr_2015_00_27_06_+0300_PoTul6=8dVC49mQ+--