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 5266B138C48 for ; Mon, 6 Apr 2015 22:06:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8ABF1E08B1; Mon, 6 Apr 2015 22:06:01 +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 E36B3E08B0 for ; Mon, 6 Apr 2015 22:06:00 +0000 (UTC) Received: from pomiot.lan (77-253-128-42.adsl.inetia.pl [77.253.128.42]) (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 C7C42340756; Mon, 6 Apr 2015 22:05:58 +0000 (UTC) Date: Tue, 7 Apr 2015 00:05:50 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: Andrew Savchenko Cc: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Re: Council meeting 2015-04-14: call for agenda items Message-ID: <20150407000550.0302b0a3@pomiot.lan> In-Reply-To: <20150407003704.208098b1575f1c862e0df625@gentoo.org> 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> 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_/mquddNHVXsxB9uI0unN5Dv/"; protocol="application/pgp-signature" X-Archives-Salt: 88c8ead1-fe48-450b-b97b-d105fffaa537 X-Archives-Hash: 17dfa964f4e33067a054d0512302cdd4 --Sig_/mquddNHVXsxB9uI0unN5Dv/ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dnia 2015-04-07, o godz. 00:37:04 Andrew Savchenko napisa=C5=82(a): > On Mon, 6 Apr 2015 09:59:22 +0200 Micha=C5=82 G=C3=B3rny wrote: > [...] > > > Hmm, that's a hard question. I tried to consider this issues from a > > > point of view of a user of such arch. If package is not used or > > > user may delete it and its deps without much harm, it doesn't affect > > > user at all. If it is used and needed, then in case of: > > >=20 > > > - one package with removed stable keyword a user have to add to > > > package.keywords only a single package, though it might be > > > difficult to locate such package, because portage deptree failure > > > events may be really obscure sometimes; > > >=20 > > > - all subtree of stable keywords is removed; then user have to > > > add all these packages to package.keywords, portage messages should > > > be clear here (but one never knows), though manual keywording of > > > hundred of packages will be irritating at best (even using "cat/*" > > > masks). So if number of affected installed packages is large, users > > > will likely move to ~arch all their setup. > > >=20 > > > So from user's perspective stable deptree broken in single point is > > > a better solution, but(!) if portage will cleanly suggest this > > > point. > > >=20 > > > Another issue to consider: what if we have one such package that > > > broke stable deptree, then after awhile another one and so on. In > > > the result stable tree will got corrupted beyond repair. > > >=20 > > > Maybe some grace period will help here? E.g. remove stable keyword > > > from a single package, wait for 30 days (or so) for reaction from a > > > team, and then dekeyword all reverse dependencies. > >=20 > > Which means developers can't commit properly for 30 days. Really > > awesome solution, thank you. Please ping QA instantly once you do it, > > you'll save us time figuring who to ban for the breakage. >=20 > 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... You are discussing something that has already been proven impossible like you're trying to make it possible via introducing more noise. > > 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. 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. > 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. 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. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/mquddNHVXsxB9uI0unN5Dv/ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVIwM+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOWXAQAINqCPXUy8rl98Spv3h9hcud sOBYX1QEh/mz6JK3mmzG8GklNZ38FpYIdmXLukjQ6G6T9nyKpTKwYvz0aibjyiSD 05tWsR1oTw515JO4VD6bB36QRZ0sMb1ZWVXDFBSSwZRvUJJQWZd9KmvzvjbiNB7X AaAvvR3FcCiUOAMgdZwQ0H54xCH22bo5FVwCZfWLXEZk9FbZ0JQNmBLkmV4MMmn/ uQG9Ht32KaW8lBcEi5mmSw/3+VZEbnzKZn1SRvSlQf/gQEa2HxcpS3SZ/Xv0vCx2 Hdk2wdGU84I8YahX/z4yTyjBasnVsTNlZjMASuimPFEksj+CLMGu83VvGPzf7Bya ldwKRV2wZxsRnYW7vawJtH3t3bc0iyaUIUAV73Qfa24fwP/BMzN34oYn/lDpcHgL Vg+ayCQl5goev4yCXb9Qz5cTqQ3Ii1hYNGkuZuSoI8LzeGI3OXFiDiayxE+BjRWy mYxvJdrCeh7Fhs6Rte7g33dWqXlhc4DnByCZ3XTkaOc8t+TTY8prqUKxYQEdcEgG lYzOWQSA8PoGBdBMtJxGvRFOIdCjoT+Fug47U11jyYBd1hZsHm2LYQtDvjqmpLTe KR5Xx58IV2e+V/7WGkCknxkjN21ofuUTfwYm3CipKb6hUK4l/EW06Qqo3WdgGsZq nKZaxCLJt+ajY52gRxPs =upgN -----END PGP SIGNATURE----- --Sig_/mquddNHVXsxB9uI0unN5Dv/--