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 6CC23138C48 for ; Mon, 6 Apr 2015 22:25:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 02215E08C4; Mon, 6 Apr 2015 22:25:31 +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 72518E08B1 for ; Mon, 6 Apr 2015 22:25:30 +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 F395A340817 for ; Mon, 6 Apr 2015 22:25:28 +0000 (UTC) Date: Tue, 7 Apr 2015 01:25:22 +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: <20150407012522.f863b4812f5e7c7d610b020b@gentoo.org> In-Reply-To: <20150407000550.0302b0a3@pomiot.lan> References: <20150402141428.GA31638@oregano.home.lan> <201504032214.01310.dilfridge@gentoo.org> <20150404220205.GA415@linux1> <1428237147.22472.1.camel@gentoo.org> <20150405195044.GA2917@linux1> <20150406002706.4aff7e4dda27a25a5c106b50@gentoo.org> <20150406023841.46e7491f7c76925908446de5@gentoo.org> <20150406095922.19036ce2@pomiot.lan> <20150407003704.208098b1575f1c862e0df625@gentoo.org> <20150407000550.0302b0a3@pomiot.lan> 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=_Tue__7_Apr_2015_01_25_22_+0300_x=P00FXtwnlTA.O=" X-Archives-Salt: a37b959a-3d0f-4036-80de-70148490d1a6 X-Archives-Hash: 4290efcb146a5891cd1d6874d3935efa --Signature=_Tue__7_Apr_2015_01_25_22_+0300_x=P00FXtwnlTA.O= Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, 7 Apr 2015 00:05:50 +0200 Micha=C5=82 G=C3=B3rny wrote: [...] > > I sad nowhere I'm going to do it. We are discussing opportunities > > to fix current sore situation. Threatening people with bans just > > for their thoughts reminds me of George Orwell's Thought Police... >=20 > You are discussing something that has already been proven impossible > like you're trying to make it possible via introducing more noise. >=20 > > > Let me remind you: once you break dependency tree on *ANY* stable > > > architecture, repoman won't let you commit. Travis turns red. All pull > > > requests are marked as broken. > >=20 > > Repoman, travis and other QA tools can be fixed if policy changes. > > That's not a problem. Right now we have an all-green travis, but > > outdated, broken and likely insecure packages it tree marked as > > stable. That is the problem we're trying to discuss here. >=20 > How can they be fixed? By making them ignore dependency breakages? What > is the use of QA tools if you disable the most important QA check just > to push your some really stupid idea through. >=20 > > And as I see this problem has no good solution, so one less painful > > for users should be chosen. If this will require a QA policy > > update, then it should be done. >=20 > And thanks to this 'less painful' solution people lately had a real > hard time due to app-eselect/ move. Sure, it looks good on a first > glance but then you get into the fine details and everything falls > apart. Of course, some people simply don't care about the fine details > at all. I'm not claiming that my proposal is perfect or even good enough; please propose something better, but consider all side-effects carefully: you'll see that broken stable deptree is not a worse possible scenario. My main point is that things should not be left as they are right now. Best regards, Andrew Savchenko --Signature=_Tue__7_Apr_2015_01_25_22_+0300_x=P00FXtwnlTA.O= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVIwfSAAoJEPZTWjO6HuSNJ/0P/0DVfnN/dkZdrXTxiWhAOwQ0 AcEO+McHCiTmKkHaIK34MyxkVdL8nByfoOQaKx8lN3MKoGyKdMHOoXF+9M5NxMav hqZSSHtE1B6WXU3FMlOoGAYkASyd5JrMekjXGOuoMB5ny5oRSMcUOs8rAghj0BfB 6AVY0V6LgF3gFiyd4RkylExUuqw2zZ94QXZjE4pxyVU8U3fxfy+3ejnfRBh1s8P+ qFfa58EJF2d5U+A/iG1udXr5HvhnohjEGrmbx6MUgMsphAxIFmHG9bvglSN1Kvsy eU7ldEVvlHUAAYwrWpCWzubATBcv3uh7x6Ybn+kCAgUdpFcdYHgUoI4nYRfNjTwb UoSauSglghqKCj2dkEQxRXeTrvcWYPWJvRL0ipkCA4Lx/miy8iV6l8WFP6JM9pAV CZECnvYF4PDRb6ug05VI6NguRoKFpLCQm0Z5LfoDRGjlt5R1rVsXJGNfIeJpbVwe bGuM8zv1xrvGeD5mVyb1Dr4Xkco3i8fOnoti3Yw7BQ2hQ2xFgFi4v1AaL7ynXEWt xz7DbtVlsNh12q10by8Hj/vauDmEI9H0DBHdXuGcz4FCsZSyvunIbyz0KkaIn2Z1 zFM0wcNVoqHWlhRQDzG8bMYIG6Op/Gi2wIFkSNAdHDmetXlGrX6P0oobWYm+gIHy BzPZ+dCRrzGXznEvfa6g =7Od0 -----END PGP SIGNATURE----- --Signature=_Tue__7_Apr_2015_01_25_22_+0300_x=P00FXtwnlTA.O=--