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 878C01389F5 for ; Sat, 4 Apr 2015 17:11:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0601FE0A45; Sat, 4 Apr 2015 17:10:37 +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 67685E0A44 for ; Sat, 4 Apr 2015 17:10:31 +0000 (UTC) Received: from pomiot (77-255-17-177.adsl.inetia.pl [77.255.17.177]) (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 2BF5B340992; Sat, 4 Apr 2015 17:10:27 +0000 (UTC) Date: Sat, 4 Apr 2015 17:44:01 +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: <20150404174401.627878c9@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_/NRPcpcBwXsS_+W27Jpd.OZH"; protocol="application/pgp-signature" X-Archives-Salt: a517182e-49e0-4e86-b5e1-747f47f1f9ff X-Archives-Hash: 593d45c09bedb31f52f25651fe0bb7f3 --Sig_/NRPcpcBwXsS_+W27Jpd.OZH 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_/NRPcpcBwXsS_+W27Jpd.OZH Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVIAbBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOVxkQAIxkFvR+0IsYMBXmZyZxHXCr EoExv7VzmMFr7sXm0PV6Upx9ZuOphb5feOrD1O8DET1AJygmKax+LoD+PTbdgWWo ZV8v/paYHdubrUKB4q0D7Bj+zms+MemmB2grFyGpXXERwzph0hFTeyHf2LW0ueOR Qu/WFb2JjAt+gtbVxPPkHwu1NaWTr6FJ3UKllOlQlY3CIHK+ZZGffGpJSL/9CBhg 8GxT4fq0kjIc7RV2qin6La5nljFCfNtNgV+X0OVCOw4KQCX5yc89pNO5tB8DKvFA RbY9BvzqijXscPslx86unqlOu5L8Qyj3VQla8wtqzyz3pFly60h0JVQFAPbaaA3Y I4lJiIEfaPVHnjriLCl7TPsc+/sEhXM0jW/WchKo1e8Ro8Ar397W4M0OtWgwTw2S P/Gl/bZWhv1Q82vaggfdqJ4NdqutugkWPwR1/8B258Enkdf5QSc4TceWTGm9RG6W K0R74rR8UbP5LvzOFi2wfBsj0v0tCLwBZCHBV0S/KHymD080GteVN6QzBgA8Bu3z IozT6ixdxmBler2fLaOaUvYdWSTtreMjj4+WQCfQzNtRJXQMZUPVs9c4uLvyf7OO S9mtuWNJNGlz2VeAOGe0n2Ux4+3Ol+qfKZluIeXO4tkOM1+GlUg+6wzkdwihfSKV f7RYPEgo/NVi/cVMly7g =9jc6 -----END PGP SIGNATURE----- --Sig_/NRPcpcBwXsS_+W27Jpd.OZH--