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 2BB321389F5 for ; Sat, 4 Apr 2015 15:48:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E44B5E08AD; Sat, 4 Apr 2015 15:48:55 +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 625DFE08AC for ; Sat, 4 Apr 2015 15:48:55 +0000 (UTC) Received: from pomiot (ip-5-172-247-195.free.aero2.net.pl [5.172.247.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 9B6BC34098F; Sat, 4 Apr 2015 15:48:48 +0000 (UTC) Date: Sat, 4 Apr 2015 17:48:29 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: Rich Freeman Cc: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items Message-ID: <20150404174829.133969d9@pomiot> In-Reply-To: References: <20150402141428.GA31638@oregano.home.lan> <201504032214.01310.dilfridge@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-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; micalg=pgp-sha512; boundary="Sig_/4x8zSuyQkBopXHJ.82NmiWA"; protocol="application/pgp-signature" X-Archives-Salt: 94fe500f-1657-4c59-aff5-b64fda2e0f20 X-Archives-Hash: 710286fd934193c175c5333fd66117ef --Sig_/4x8zSuyQkBopXHJ.82NmiWA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dnia 2015-04-04, o godz. 11:13:54 Rich Freeman napisa=C5=82(a): > On Sat, Apr 4, 2015 at 10:31 AM, Michael Palimaka = wrote: > > On 04/04/15 07:13, Andreas K. Huettel wrote: > >> Am Freitag, 3. April 2015, 22:01:32 schrieb Rich Freeman: > >> > >>> For reference, the policy we came up with last time for ia64 and alph= a only was: > >> > >>> "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a > >>> pending STABLEREQ, for 90 days with archs CCed and otherwise ready > >>> to be stabilized, the maintainer can remove older stable versions of > >>> the package at their discretion. A package is considered ready to be > >>> stabilized if it has been in the tree for 30 days, and has no known > >>> major flaws on arches that upstream considers supported." > >> > >> If we're bringing this up again, we should maybe also clarify it. My u= nderstanding at the time was that the removal of older stable versions may = leave the deptree of the arch in question in a broken state, however bad th= at is. There seem to be different interpretations though. > > > > I am against breaking the deptree for any arch that has a stable > > profile. It's reasonable to expect devs to dekeyword revdeps to ensure > > the deptree is consistent. > > If the state of the arch really is that bad, its profiles should be > > switched to dev or exp to reflect reality. > > >=20 > Tend to agree, but be careful what you ask for. Which would the arch > team REALLY prefer after ignoring a bug for 90 days? The stable > depgraph is broken and they have to hurry and stabilize one package to > fix it, OR the stable depgraph is fine, but suddenly 300 packages no > longer have stable keywords at all. Fixing the latter would be a > royal PITA without git. Getting rid of stable on those 300 packages > is also a lot of work for the package maintainer without some kind of > tool to automate this. What Gentoo developers would really prefer is being able to commit to packages without using --force just because someone screwed up the dependency tree. If you don't care about stable working on some arch, don't mark the arch profiles stable. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/4x8zSuyQkBopXHJ.82NmiWA Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVIAfNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOo+0QAJCAjx1+H3xvNHjrFk+67Dc6 GKsqOF0Sp6PioQIMnDIPrt5970XnwJhMSC86vStfylSP1D87OM3Vds8WYUz+xj4W JuplyNua1HD7sFrh24ePMA+fdK8zhFPXdQVQf5xwXfrqIgdoCVH1rFp8AgkfJzdL ElfVlFd1gktXsCW85r8Nr9/HCSmuI2+0YT17nC9LEy+S166h1W3kNxYGKiAFu+MO oAprt3MvA8KadHq0U6xi78CSsCqGYSXYvJyOm2sseJKs30AuuULpFpCBkhsW5GnI +OdRjVD5kr+5geNtP3bbtUV7akeof3FuaGBz0NVpnXe9e2P6OtZuBT1LpksbffH6 6t9zFdiNKVCng0c+0/2p4i/ZS/eAvzf13H1ARXQv5iISfOwWLNaOBQq1Phpf/ZNv EMnOYaZ1fHrwt9YDcTfiQGbvZ8pS8KgKQvdy0Lru2x7ATSG/63ePbMw51vCUokdg cImOXlI1G+1TOgXZ/bhMLUO/GgCJ+WUhgFt9pB+nRMaVzTc0gMyPSSk0qqt4GRbx vIgP+oeepSVrJ83HXpPQKRaj8qN0SNWAdckL3w5hm5A/p3TTGpND+ftQ9ivbHkUv rxipaGJOG9+tmeIJeBzZSSezC936JkZpw8Fxu9SfAukXp1dFmwxvXIMOLfmuerCn t7gEdV/8S03UlGFH6UGf =i+2C -----END PGP SIGNATURE----- --Sig_/4x8zSuyQkBopXHJ.82NmiWA--