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 3F78D138A1C for ; Mon, 6 Apr 2015 08:05:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AD028E0982; Mon, 6 Apr 2015 08:05:30 +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 1EBD9E0942 for ; Mon, 6 Apr 2015 08:05:30 +0000 (UTC) Received: from pomiot.lan (ip-5-172-247-243.free.aero2.net.pl [5.172.247.243]) (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 0B315340B11; Mon, 6 Apr 2015 08:05:16 +0000 (UTC) Date: Mon, 6 Apr 2015 09:59:22 +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: <20150406095922.19036ce2@pomiot.lan> In-Reply-To: <20150406023841.46e7491f7c76925908446de5@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> 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_/KPwnbT0sA9ixW3ytlIayj40"; protocol="application/pgp-signature" X-Archives-Salt: 3e7902ee-84b3-47de-85ca-25249acc5160 X-Archives-Hash: 3873b9e3ea40ec3f496a46ff27885737 --Sig_/KPwnbT0sA9ixW3ytlIayj40 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dnia 2015-04-06, o godz. 02:38:41 Andrew Savchenko napisa=C5=82(a): > On Sun, 5 Apr 2015 18:54:10 -0400 Rich Freeman wrote: > > On Sun, Apr 5, 2015 at 5:27 PM, Andrew Savchenko w= rote: > > > > > > 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). > > > > >=20 > > This was some of what I was getting at. My question still stands that > > I'm not sure arch teams REALLY want 300 packages to have their stable > > keywords removed instead of just having one package break the > > depgraph. >=20 > 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. 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. 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. Long story short, we end up with a lot of extra work. And so far, nobody but me and Patrick basically cared about dependency graph not being broken. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/KPwnbT0sA9ixW3ytlIayj40 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJVIjzbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOlPUP/j25VNjm1IGf87lbvWwMqCsc dumNwSAWJA6BZyV3rajI2J5a+hkQqARVQcAKdOrF5SSNpNZEOvBZKd0bOt5mhgnR q0Dx7C8onrTD6ZtqzK9fqP8oh5hou6mQzhrliAp2C5AHiUSsljM49NgOfxLLBZ7J G94NIeyM2zRKRf37OXTG2/BOqQe19iYsTWY2V1grmM2qK0ozVSS5as1ur1TFPQ0x jhjLhRin6RJYTP1LATPPML22sTotQyrEFkflY/NYkQ9BQJhUiVyLnszH7XKY5ENJ ZV1GZgLlQjjOnJs724F/iIa7fztYEzxBsY9h6k35riwAlHVxSl3S7OLEk6xCXJPe XzL8eR2JdUuYjBNLYxQ/bQKXm8xHdZRvdZ8vfADggiDNOxI/FH8n+Xt0DGioHHF/ jNmVyZ8vrQ8T/wrGoWUSSMpqKJtHh7CFyjYBcZ4yzNrmSGDlQZ7TE71SdIOtpSgv GKlfbx9du1SuxHJDJxg4UnkiSlFaR2TZVrRwLp/5WuH0YWKZUwCZZM8RjnrIXiK2 x3woPAPPnj1uasETzuxQqJUlvfAxstrqOz53IusieFV3wRBprjNWwPVcWRi7R4bI yzF5OYXWgr9Vk+5DLw2Z3oga0TCna1DCbgOaGgDKDJvfRSd3SCnRmGryQIHSUhIB O6sQzUxfrb1DSCMDwA2m =7Thu -----END PGP SIGNATURE----- --Sig_/KPwnbT0sA9ixW3ytlIayj40--